SELinux in practice: DVWA test

After the publication of the previous article about SELinux , there were many proposals to “prove the utility in practice” of this security subsystem. We decided to test. To do this, we created three vulnerable stands with typical configurations (Damn Vulnerable Web Application on CentOS 5.8). The differences between them were only in the SELinux settings: on the first virtual machine it was turned off, on the other two “out of the box” policies - targeted and strict were applied.

In this composition, the virtual machine stand was subjected to penetration testing. Take a look at the results?


However, let's first turn to the settings of the nodes. To create templates, the CentOS 5.8 operating system was used with a “light bulb” ( LAMP ) deployed on it. In the process of setting up, I tried to make all the typical errors possible in this case: connecting to the database with superuser rights, setting everything up that can be done by default. In this way, we tried to recreate three lines of events with a single starting point.
')
The original server is Apache in the arms of Little Red Riding Hood, who received all possible new clothes - with the help of the standard utility yum. Of course, this tale was not without its Grandmother: MySQL database is installed on the nodes. This excellent company is complemented by the extremely vulnerable Wolf - Damn Vulnerable Web Application , through which you can get to almost all other characters. However, on two servers out of three hackers, there is a Hunter with a gun waiting for him - SELinux, who is going to shoot all extra limbs to the Wolf with dubious activity.

On an unsecured server, SELinux is in “Disabled” mode. This is a classic solution from Site-Which-Not-Call instructions. Everything is in place, httpd and mysqld have a default configuration. Thus, there is no additional protection on the node, and everything depends on the stability of the services themselves.

As one of the options for protecting the web server, I used SELinux with the policy targeted. I didn’t make any changes to it: the solution is “out of the box” exactly in the form in which the vendor offers it. The services run in prepared domains and operate within the framework of the “standard operation” - from the point of view of Red Hat engineers.

The latter configuration is a “strict” policy of SELinux, and acts in accordance with the white sheet principle in accordance with the inherent idea. What is not allowed is forbidden. I tried to mark the file part with the necessary contexts, with a sparse emphasis on privileges. This setting gives a fairly “twisted” system, although without fanaticism.

I asked my colleague from Positive Technologies (on Habré, he is known as ki11obyte ) to perform a penetration test. Then he will tell.

Let's start with the machine on which SELinux was disabled. The server was initially positioned as vulnerable, so getting a web shell was easy.

Given the form of uploading images to the server, which checks only the Content-Type field in the request. Fill the web shell with PHP by changing the Content-Type (in this case with BurpSuite) to image / jpeg.



Shell is tested and uploaded to the server.



The configured SELinux was also unable to protect the system in this case.

Next you need to run a web shell. To do this, we find on the site a vulnerable script with the ability to download other scripts.



The file was connected successfully on each of the machines. SELinux thus does not protect us from errors in web applications.

Now we can safely execute commands via the loaded web shell.



Or we can use reverse connection to get a more familiar console.



Now the machine queue with SELinux enabled. We get the web shell again - and we are a little disappointed: there are not enough rights to create sockets and even to execute ls.





However, despite the inability to list directories, we can easily view the files.



Listing, by the way, managed to implement the means of PHP.



In addition, we managed to create a file, make it executable and execute.



The next step was to capture the DBMS. With the help of a web shell, we look at the MySQL configuration file of a web application and use it to connect.

The SELECT LOAD_FILE ('/ etc / passwd') query allows you to read files. We also easily manage to write the file to a temporary directory: SELECT 1 INTO OUTFILE '/ tmp / ololo'. What turned out to be really strange is the rather unusual rights to the created file.




No differences were found on the machine with SELinux enabled and configured, which was somewhat disappointing.
-

As a result of the experiment, we came to the following conclusions. First, I was mistaken with the choice of the vulnerable application: DVWA is a bad example for SELinux. The bulk of the "vulnerabilities" is aimed at something to which there is access in the httpd_t domain. As a result, it is completely incomprehensible - how to help the unfortunate Little Red Riding Hood and the unfailing, all-agree Apache. The only suitable solution was to restrict access to most binaries - with the prohibition of the reverse connection. In all other cases, the actions of the attacker simply did not fall within the scope of competence of the security subsystem with the standard settings.

Secondly, it finally became clear that setting up SELinux for a web project is a very laborious task that requires confident knowledge and considerable effort. I note: not just “to protect the web server”, but specifically to seriously protect the project as a whole. It is possible to create your own policy of interaction of contexts, but the expediency of this is in doubt. My personal opinion: much more depends on proper configuration of php and httpd and regular updates.

So, SELinux is able to at least log unhealthy activity in the system. And if you carefully perform the setting - even prohibit unauthorized actions. Unfortunately, however, it will not be able to protect your web project from errors in the code or incorrect application settings.