• Home

  • Custom Ecommerce
  • Application Development
  • Database Consulting
  • Cloud Hosting
  • Systems Integration
  • Legacy Business Systems
  • Security & Compliance
  • GIS

  • Expertise

  • About Us
  • Our Team
  • Clients
  • Careers

  • Blog

  • EpiTrax

  • VisionPort

  • Contact
  • Our Blog

    Ongoing observations by End Point Dev people

    SELINUX=disabled? Read this and think twice!

    By Emanuele “Lele” Calò
    April 10, 2017

    Not long ago, one of our customers had their website compromised because of a badly maintained, not-updated WordPress. At End Point we love WordPress, but it really needs to be configured and hardened the right way, otherwise it’s easy to end up in a real nightmare.

    This situation is worsened even more if there’s no additional security enforcement system to protect the environment on which the compromised site lives. One of the basic ways to protect your Linux server, especially RHEL/Centos based ones, is using SELinux.

    Sadly, most of the interaction people has with SELinux happens while disabling it, first on the running system:

    setenforce disabled
    # or
    setenforce 0
    

    and then permanently by manually editing the file /etc/sysconfig/selinux to change the variable SELINUX=enforcing to SELINUX=disabled.

    Is that actually a good idea though? While SELinux can be a bit of a headache to tune appropriately and can easily be misconfigured, here’s something that could really convince you to think twice before disabling SELinux once and forever.

    Back to our customer’s compromised site. While going through the customer’s system for some post-crisis cleaning, I found this hilarious piece of bash_history:

    ls
    cp /tmp/wacky.php .
    ls -lFa
    vim wacky.php
    set
    ls -lFa
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    fg
    ls -lFa
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    vim wacky.php
    php wacky.php 2>&1 | less
    php wacky.php > THE-EVIL 2>&1
    vim THE-EVIL
    ls -lFA
    less wacky.php
    ls
    less THE-EVIL
    less wacky.php
    cat /selinux/enforce
    ls
    less THE-EVIL
    exit
    

    As you can see, what happened was that the attacker was able to manage having a shell connection as the customer user, and started using a PHP files injected in /tmp as a possible further vector of attack.

    Sadly, for the attacker at least, what happened was that SELinux was setup in enforcing mode with some strict rules and prevented all kind of execution on that specific script so after a few frantic attempts the attacker surrendered.

    Looking into the /var/log/audit/auditd.log file I found all the type=AVC denied errors that SELinux was shouting while forbidding the attacker to pursue his nefarious plan.

    Hilarious and good props to SELinux for saving the day.

    less THE-EVIL, more SELinux! 🙂

    redhat linux security selinux wordpress


    Comments