There are a few benefits to this from the attackers perspective. The main benefit is that utilizes HTTP GET which is quite difficult to find anomalies from the http logs, even with Splunk (unless the attacker calls the file webshell.php). I would bet most people would be on the lookout for http posts to a new file versus http get. With Splunk you can monitor and alert on http POST deviations, but with GET it seem that strategy won't cut it.
Using curl we GET the request 48bytes.php and add in the Accept-Language header followed by the shell command of 'cat /etc/passwd'. Additionaly I added in the -A to use a less conspicuous user agent.
curl -H "Accept-Language: cat /etc/passwd" -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 13.3; rv:72.0) Gecko/20132121 Firefox/19.0" http://192.168.110.114/webshells/48bytes.php
The response from the web server, as you would expect looks like this:
Following the tcp stream in wireshark gives us this view: (notice the Accept-Language: cat /etc/passwd)
So how do the good guys detect this?
I was hoping that Bro Network Security Monitor would help, however by default it doesn't log the Accept-Language string (It logs which headers are used). Even if the majority of sites in your enterprise use TLS it's probably not a bad idea to enable the collection of header data to your web servers. If you're sending the Bro logs to Splunk (with header data) you can create an alert to fire on key words, length etc.
Bro_http log of 'cat /etc/passwd' via webshell:
1378069940.789597 SvWL0TLDOB3 192.168.110.129 58148 192.168.110.114 80 0 - - - - - 0 1973 200 OK - - - (empty) - HOST,USER-AGENT,ACCEPT,ACCEPT-LANGUAGE,ACCEPT-ENCODING,REFERER,CONNECTION HOST,USER-AGENT,ACCEPT,ACCEPT-LANGUAGE,ACCEPT-ENCODING,REFERER,CONNECTION
Using Snort also has the same drawback of missing out on TLS connections. If you are using a Proxy and have a tap into the unencrypted traffic this would be an ideal solution (along with using Bro).
Using Google Rapid Response (GRR) you can launch a hunt on your web servers (or all servers for that matter) for files containing 'passthru' and '<?php'. Of course prevention is much easier to do then detecting it.
With OSSEC file integrity monitor you will have a file based method of detection depending on the site content and structure. Since most people exclude temp directories from file integrity monitor, its the best place to put a webshell ;)
Prevention
If you have a public facing server without grsecurity, yer gonna have a bad time. In my opinion grsec with a well defined policy is the first place to start. Well maybe the first place start is having the admins disable exec(), passthru() and system()! Good luck with that :)
