Hardening in practice

On the eve of the start of the course “Administrator Linux. Professional“ prepared an article authored by Alexander Kolesnikov. If you are interested in learning more about studying on the course, come to demo day of the course.

The previous article considered an example of vulnerable machines that were created in order to be used in the practice of testing systems for vulnerabilities. This article will tell you how non-standard vulnerabilities can be detected in systems if, for example, we received them already in a working state and in no case should they be disabled, but continued to be maintained.

Hardening

The process of closing possible vulnerabilities on a completely unknown machine is a rather serious challenge. Firstly, you never know which service will stop working if you change a separate setting of the firewall or the entire operating system.

The problem is not new enough, and naturally there are 100,500 page guides that, if followed correctly, should save you from imminent problems. Examples of such guides can be found here, here and here… The list is far from complete, only the most interesting from the point of view of the author are presented.

But this article is not about how to go through the list of formally described actions and figure out how to implement them. Let’s try to do it a little differently. What if we turn to the help of pentesters instead of administrative tools?

Any enthusiast or professional pentester’s kit has a project or script that should check the standard deviations of a secure configuration for various systems. Usually they concentrate on the most popular ones: Windows, Linux, macOS. And it is in this sequence, because they are so popular in the enterprise environment.

To close all attack vectors, let’s split their groups:

Attacks that work in applications accessible to the outside world
Attacks that work inside the OS and their purpose is elevation of privileges

For the first type of attacks, security scanners can be used. We will be using the Kali Linux machine toolbox. These are nmap, Burp Suite, etc.

For the second type of attacks, we suggest that you familiarize yourself with this one. project… Since the procedure for finding incorrect configurations is in most cases deterministic, it is easy to automate it. Run the command to get the configuration data and parse the result – you’re done. Using scripts is quite simple, you need to select the one you need for the platform and copy it to the working directory of the vulnerable machine. The scripts do not launch any attacks, their only task is to show that a vulnerability may be present in the system and to offer a link to an article with an attack. The script is automation and therefore it should be expected that it can give false positives for probable vulnerabilities. Each individual case will have to be considered separately.

Vulnerable Stands

To make the process even more unpredictable. Let’s enumerate the cars to be created and generate a car number using the following command:

echo $RANDOM % 5 + 1 | bc

The script implies that for each launch a random vulnerable machine will be created, which needs to be fixed so that it cannot be hacked in the way that was put into it during assembly. An additional condition for intervention is that no matter how simple and useless the service inside this machine may look, it must continue to function after the changes are made.

Compared to our previous experiment, now all machines will have different classes of vulnerabilities. With the help of them, it will be possible not only to elevate privileges, but also to simply execute commands on behalf of the user.

Experiment

For the first experiment, we will use this one. box… Let’s conduct an experiment in 2 stages.

Stage 1 – search for vulnerable configurations and services operating outside the server. First commands to run:

nmap -n -A -p- --max-rate=1000 machine.ip.address

As a result, here is a list of services that are visible from outside the server:

We have access to the user inside the machine, so let’s try to find out which ports are open:

netstat -tulpn

It turns out that the only service on the 80m port. Let’s collect data on the structure of web applications that can work there:

dirb http://machine.ip.address

The result of the tool:

It looks like it is wordpress. the server directories contain WordPress 5.6 and the “contact-form” plugin. CVE-2020-35489 is very well suited for this dataset. The test script can be found here… Let’s try to test the service. The script did not want to work, but in fact only one line is functional, which sends a request to the address “/wp-content/plugins/contact-form-7/readme.txt”. If you execute it, you can see that the plugin used can be vulnerable to attack.

We do not know exactly how this service works and whether a vulnerable plugin is needed in order for it to continue providing its services. Let’s try to leave it as it is. Let’s add only an additional plugin to the server – WAF. Can be used here this… It will defend the vulnerable plugin on our server, and as soon as the opportunity arises, we will install updates and close this vulnerability.

Second stage of testing. Run the script described above and wait for the result. Below are the output from the script:

First configuration vulnerability. As you can see from the picture, we are interested in those records that are highlighted in red. This is actually the only vulnerability besides the presence of a vagrant user on the system.

Thus, you can get information about vulnerabilities on an unfamiliar server. Further fixes depend on server functionality. The reader is also invited to go through the experiment on his own, but use this one box…