Disabling this tool is still a common mistake. SELinux is a great help to do hardening
How important can SELinux be? Can you imagine being in this situation? «Monday, 8 in the morning. You turn on the computer and you are ready to login at the company’s website to publish a new blog entry… But instead of the login panel, a message appears in your browser, Error 503: Service not available. You get the usual fears: I’ve been hacked!
Now what do I do? Quickly you pick up the phone and call your sysadmin. He confirms that he hasn’t changed the server configuration in years, but he will do some checks.
After an hour, the IT technician calls to discuss the situation. He has accessed the machine through SSH without problem and has observed there is a program consuming all the server’s CPU. The point is that every time he deletes it, it reopens itself after a while and he doesn’t know how to remove it. Restarting the server isn’t working either.
He informs you that the backup cannot be restored because it has stopped working a while ago due to lack of space, so he will need help with disinfection. He can’t say how long the web has been like this».
This case is more common than you may think. The software running at a machine exposed to the Internet is not updated, backups are not checked and when something fails, the impact can mean the complete loss of information.
So after a call they give us access to a copy of the server’s hard drive, which we statically analyze without actually turning it on, in order to identify where the virus persists.
We start to review the system startup scripts until we get to the root user’s .bashrc file. It seems that some lines have been appended to download a script, install a Bitcoins mining program and save persistence in cron.
Once the script has been deobfuscated and reviewed, it is possible to perform a complete disinfection by deleting all the files that are referenced from it.
However, to be sure we use tools such as rkhunter or ClamAV in order to identify any other malicious script that may have remained in the system.
The only task left is to identify the entry point. A review of the initial firewall rules reveals that only web ports were exposed to the internet, which greatly narrows the possibilities.
The published application is a Drupal version 8.5.10, affected by a vulnerability (code CVE-2019-6340). This vulnerability allows a malicious user to execute system commands using the REST API functionality.
We proceed to review the configuration of the web application and confirm that it was running as a non-privileged user. But the log files reveal a large number of login attempts in a row in a short space of time. Unfortunately, they ended up in a successful root login.
To check the strength of the password we crack the encrypted passwords stored in the file “/ etc / shadow”. In a matter of seconds we can verify that it was a common access key. In the improvement recommendations, in order to avoid this problem again, the following points could be included:
- Regularly update the web application.
- Deploy WAF solutions (Web Application Firewall) in front of the server to protect it against attacks.
- Install endpoint monitoring or protection software that collects server logs and allows identifying unusual behaviors.
- Perform a website security audit on a regular basis by hiring an external agent.
- Protect the web application with a MAC (Mandatory Access Control) system such as AppArmor or SELinux.
The Mandatory Access Control system
And this last recommendation is the one we want to emphasize. In the event of a zero-day exploit, the updates and signatures of a WAF are likely not sufficient.
Also, the attack might go undetected at an early stage depending on its sophistication, rules, and actions taken. For these reasons it may seem impossible to block all attacks.
A MAC system consists of a series of rules that define what permissions each process has, such as which files it can access or whether it can open network connections to other services.
The most popular MAC systems are AppArmor, bundled with Ubuntu Server or derivatives, and SELinux, pre-installed on RedHat or derivatives.
In the case of SELinux, many guides for installing software on RedHat or CentOS have a first step in their index titled «Disable SELinux». This is due to the fact that this is a system that, if not configured correctly, prevents the connection between the web server and the database or even the reading files that are to be published to the internet.
For this reason, there are manufacturers that, in the official installation guide for their software solution, include this step.
If SELinux had been enabled and configured in the initial scenario, remote code execution would also have existed. But the difference would have been that the attackers wouldn’t have been able to launch the process to elevate privileges, or they wouldn’t even have been able to perform network connections to the outside.
The deployment of the Bitcoins mining agent that consumed the entire CPU would have been more complicated and probably, despite having a vulnerable software version, there would have been no intrusion.