Patches Not Cure-all for Shellshock

Earlier this year, Linux system administrators all over the world had to deal with the Shellshock vulnerability, which could lead to malicious code being run on Linux systems. Servers running various web services were at particular risk.

By now, most major distributions have been able to release patches that upgraded the vulnerable bash shell to versions not affected by Shellshock. Enough time has passed that some may think that the threat is “over”, but is that the case? We decided to carry out a small experiment.

We decided to test if you could find a way to exploit Shellshock on a system that already had a patched bash shell. We took a server running Ubuntu 12.04 LTS (with bash 4.2 installed) and installed a web server on it (Apache2 + mod_wsgi). This was used to run a test web service created using the Django framework, which exposed an upload REST method for clients.

We found that if an attacker was able to acquire appropriate levels of access into a network, they would be able to introduce a vulnerable version of bash onto the target system. This could be used in a multi-stage attack to completely compromise and take over a server.

For the benefit of this experiment, the “payload” was simpler:  /user/sbin/service was modified to print out the text vuln every time several options of the service are used (specifically: status, start, stop, and restart). This highlights how other solutions like network traffic inspection and whitelisting can be useful even in dealing with a “patched” threat.

Prerequisites

To carry out this experiment, we found that the following items were necessary:

1. Source package of a vulnerable version of bash
2. Specially crafted Python script
   This script (named expl.py) will modify the /usr/sbin/service. The actual code is:

   

   Figure 1. Python script code

3. FTP server (used to host items #1 and #2)

   

   Figure 2. Files on FTP server

4. Web server (this will run on the target)
5. Proof of concept web service
   This last item is most critical. This web service exposed an upload file REST method to the users. We also expanded the capabilities of this web service to run the uploaded file. For the purposes of this test, we did this for two reasons:
   1. This triggers the execution of the uploaded Python script, which starts the exploitation in the web server side. This approximates the auto-start routine of drop malware.
   2. It allowed us to save time and focus our efforts in creating a Shellshock exploit. In line with the previous item, we also skipped the implementation of an auto-start routine for the uploaded script in a different module. We believe that in an actual exploitation scenario, the attacker would already possess this ability through other means.
6. Exploit shell code (expl.sh)
   This is the exploit script uploaded to the web server, via the above web service. It performs the following:
   1. Download the vulnerable bash source package
   2. Download expl.py, which will modify /usr/sbin/service
   3. Decompress the downloaded bash source package
   4. Configure and install the vulnerable bash package onto the web server
   5. Execute expl.py

The actual exploit shell code is below:

Figure 3. Exploit shell code

Overall methodology

The figure below shows the overall plan for our experiment.

Figure 4. Overall plan

The actual steps were as follows:

1. Manually upload the vulnerable bash source package to the FTP server.
2. Manually upload expl.py to the same vulnerable FTP server
3. Upload expl.sh using the upload REST method exposed by the web service. Here’s the code we used to do this:

   

   Figure 5. Code to upload file

4. Check if exploitation was successful.

Figure 6. Results before exploitation

Figure 7. Results after exploitation

Conclusions

Our experiment shows that under certain circumstances, patching is not a complete defense against Shellshock. An attacker with enough access to a system can still exploit Shellshock even on a patched system. Are these attacks possible? We believe so, for the following reasons:

Archived vulnerable bash source packages

While the available bash source code is for the patched versions, archived source packages for older, vulnerable versions are already archived by various threat actors. It is quite likely that in the future we will receive some reports of attacks using these older versions of bash.

Reduced reliability on AV scanners

Every build of bash may have different hashes. This makes signature-based scanning less reliable, making detection based solely on that technique more difficult.

Solutions

The above shows that in certain circumstances, Shellshock can still be exploited on already-patched systems. A carefully orchestrated, multi-layer attack can be used by an attacker to expand his footprint onto the affected system in an unexpected manner, which may help avoid detection.

Patching in and of itself is no assurance that the Shellshock threat is no longer present; other solutions need to be in place to ensure that the threat is minimized. This highlights the importance of a defense in depth strategy: multiple steps and layers need to be in place to protect networks from various threats, even if they have been fixed.

In particular, the two following steps are useful to protect Linux servers and endpoints:

Use an Intrusion Detection System/Intrusion Prevention System (IDS/IPS)

IDS/IPS systems with deep packet inspection capabilities like Trend Micro™ Deep Security are able to block these threats at the network level, reducing the risk to servers significantly. Rules that cover Shellshock have been available since the threat first emerged.

Use an Application Control to limit which applications can run

If an attacker is able to bypass IDS/UPS systems, application control can still block any attacks that do hit servers. For critical systems, whitelisting technologies that limit the ability of any malware to run. Deep Security contains application control capabilities which are powered by GRID; this is our database of known good files and binaries that can be used as a basis for application whitelists by system administrators.