Shellshock: Vulnerable Systems you may have missed and how to move forward - Internet Security

Shellshock: Vulnerable Systems you may have missed and how to move forward
By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable: iOS, Android and many similar systems that use ash instead of bash. Many systems are vulnerable, but the vulnerability is not exposed by default. In this case, patching is less urgent but should still be done as soon as patches are available. For example in OS X, there is no web server installed by default, and the DHCP client does not call shell scripts the way Linux does. Solaris uses ksh by default. Many small embedded systems use busybox, not bash, and are not vulnerable. Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed. In Apache, look for the ExecCGI anywhere in your Apache configuration (not just httpd.conf, check files that are included by httpd.conf like virtual host configurations). If possible, remove ExecCGI if it was just setup by a default install. Check if /bin/sh is a symlink to /bin/bash, or worse, a copy of /bin/bash. Just to make sure, try the exploit against other shells on the system (I have seen admins rename bash for convenience...) While Android is not vulnerable by default, it is possible to install bash on Android Even Windows can be made vulnerable, if you install tools like cygwin and expose them via a web server "larger" embedded devices, unlike the small devices based on busybox, do sometimes include bash. Depending on how much access you have to the device, this can be hard to figure out cgi web applications that are written in languages other then bash, but call bash (e.g. via exec(), popen() or similar commands. And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit. So in short, your priority list should look like: If today, you find exposed bash scripts in a publicly reachable server in cgi-bin: Assume the server is compromised. Focus on web servers. Patch all web servers as soon as possible even if you currently don't use cgi-bin. It is too easy to miss a script. Any vulnerable system that uses restricted ssh shells Any vulnerable system that is used outside your perimeter (to avoid DHCP attacks) Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block. Fellow handler Rob put together this list of "likely to be missed" machines: web content control servers e-mail gateways proxy servers web application firewalls (WAFs) IPS sensors and servers Wireless Controllers VOIP Servers Firewalls Enterprise class routers or switches (yes, really) Any Virtual Machine that you got as an OVA or OVF from a vendor --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn I will be teaching next: Defending Web Applications Security Essentials - SANS Security West 2019	Johannes 3508 Posts ISC Handler
Reply Subscribe	Sep 29th 2014 4 years ago
Windows machines running cygwin I believe are vulnerable as well.	James 34 Posts
Reply Quote	Sep 29th 2014 4 years ago
Courier email server (default install): /etc/courier/courierd:SHELL=/bin/bash /etc/courier/esmtpd:SHELL=/bin/bash Unclear whether any user-supplied data is injected into the env before running a courier script. CUPS: /usr/lib/cups/filter/textonly:#!/bin/bash CUPS sets a bunch of env variables prior to running the filter, but it's unclear whether any are injected from the print request. The MIME type and device URI probably originate from the job, but you can only get the textonly filter to run if it's set up to process a particular MIME type, typically text. Don't know what filtering might be done with the device URI. Of course, it's possible other filters or things that other filters run (has anyone looked at ghostscript?) to trigger a call to bash.	Pat Wood 3 Posts
Reply Quote	Sep 29th 2014 4 years ago

By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable:

iOS, Android and many similar systems that use ash instead of bash.
Many systems are vulnerable, but the vulnerability is not exposed by default. In this case, patching is less urgent but should still be done as soon as patches are available. For example in OS X, there is no web server installed by default, and the DHCP client does not call shell scripts the way Linux does. Solaris uses ksh by default.
Many small embedded systems use busybox, not bash, and are not vulnerable.

Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed.

In Apache, look for the ExecCGI anywhere in your Apache configuration (not just httpd.conf, check files that are included by httpd.conf like virtual host configurations). If possible, remove ExecCGI if it was just setup by a default install.
Check if /bin/sh is a symlink to /bin/bash, or worse, a copy of /bin/bash. Just to make sure, try the exploit against other shells on the system (I have seen admins rename bash for convenience...)
While Android is not vulnerable by default, it is possible to install bash on Android
Even Windows can be made vulnerable, if you install tools like cygwin and expose them via a web server
"larger" embedded devices, unlike the small devices based on busybox, do sometimes include bash. Depending on how much access you have to the device, this can be hard to figure out
cgi web applications that are written in languages other then bash, but call bash (e.g. via exec(), popen() or similar commands.

And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit.

So in short, your priority list should look like:

If today, you find exposed bash scripts in a publicly reachable server in cgi-bin: Assume the server is compromised.
Focus on web servers. Patch all web servers as soon as possible even if you currently don't use cgi-bin. It is too easy to miss a script.
Any vulnerable system that uses restricted ssh shells
Any vulnerable system that is used outside your perimeter (to avoid DHCP attacks)

Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block.

Fellow handler Rob put together this list of "likely to be missed" machines:

web content control servers
e-mail gateways
proxy servers
web application firewalls (WAFs)
IPS sensors and servers
Wireless Controllers
VOIP Servers
Firewalls
Enterprise class routers or switches (yes, really)
Any Virtual Machine that you got as an OVA or OVF from a vendor

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

I will be teaching next: Defending Web Applications Security Essentials - SANS Security West 2019

Johannes

3508 Posts
ISC Handler

Windows machines running cygwin I believe are vulnerable as well.

James

34 Posts

Courier email server (default install):

/etc/courier/courierd:SHELL=/bin/bash
/etc/courier/esmtpd:SHELL=/bin/bash

Unclear whether any user-supplied data is injected into the env before running a courier script.

CUPS:

/usr/lib/cups/filter/textonly:#!/bin/bash

CUPS sets a bunch of env variables prior to running the filter, but it's unclear whether any are injected from the print request. The MIME type and device URI probably originate from the job, but you can only get the textonly filter to run if it's set up to process a particular MIME type, typically text. Don't know what filtering might be done with the device URI. Of course, it's possible other filters or things that other filters run (has anyone looked at ghostscript?) to trigger a call to bash.

Pat Wood

3 Posts