An excellent postmortem write-up of a WordPress hack can be found here.
The "Magic Include Shell" makes another appearance. Mag (ICQ 884888) must be proud.
File stealing vulnerabilities have long held a special place in web browser exploitation. Web browsers attempt to carefully sandbox content to avoid interaction with the local file-system. But INPUT elements with TYPE=FILE are specifically designed to bypass the sandbox to allow users to select files for upload. For miscreants, this provides the opportunity to steal files from unsuspecting users. By exploiting web browser vulnerabilities, malicious web pages may be able to steal confidential information by manipulating the FILE input element and causing arbitrary files to be uploaded. These types of attacks are old and well known.
There are a few main modes of attack.
<script>
var input0 = document.createElement("input");
input0.type = "text";
input0.value = "/etc/passwd";
input0.type = "file";
</script>
Depending on the attacker's goals, well-known files may be targeted. For example, on Linux or Mac OS X some security related files are juicy targets:
Or, maybe one of the history files:
Even simple files like "C:\boot.ini", "/etc/passwd" or "/etc/hosts" can show information about the system that the owner may not want revealed. For example, acquiring one or more of these files from a Tor user could be used to fingerprint the machine or reveal the user's actual identity.
The way that people use their web browsers with the Internet has changed over the last several years. The level of web browser interaction has drastically increased. Normal people are writing blog entries, posting comments on their friend's sites and composing business documents using online services. This is a huge shift from the "punch the monkey" mouse clicking of the early years. That increased level of interaction is what makes the hybrid attacks so significant. Users are accustomed to typing into web forms and responding to captchas. Vulnerabilities that allow redirecting of the focus to the file input field should be taken seriously.
File stealing through manipulation of the file input can be extremely insidious. Users truly depend on their web browser to protect them. So, among the major browsers, what can users expect?
Mozilla's efforts with Firefox are finally beginning to pay off. Firefox 3 completely removes the text entry portion of the file input and replaces it with a graphic file picker. The last several Firefox 2 releases are slowly addressing the ability to selectively set the focus on the text portion of the file input element.
Safari has used a file picker for a long time and avoided the whole focus and captured keystroke problem.
Microsoft Internet Explorer has lagged behind in these fixes. Although it isn't entirely clear what changes IE8 will bring, both IE6 and IE7 continue to exhibit some of the classic focus vulnerabilities. Although these vulnerabilities have been repeatedly publicly disclosed over the last couple of years, IE has not been updated to address any of them.
To close out the year, I'll post some demonstrations of how these IE file stealing vulnerabilities can be exploited. Stay tuned.
Here are a couple more:
The second item is of interest because it makes mention of "Magic Include Shell". Is this a common PHP backdoor or just a private shell?
There is a WordPress support entry: Weird and Dangerous : ro8kfbsmag.txt. And a Google search results in a cached item from the noaa.gov domain.
It appears that the Joe Biden for President blog has joined the long list of WordPress hack victims. Once again, SEO spammers are apparently to blame.
The generator tag:
<meta name="generator" content="WordPress 2.1" /> <!-- leave this for stats -->
And from the page footer:
<div id="goro"><a href="http://www.de-bug.de/?order=6969" title="Buy Zyprexa">Buy Zyprexa</a>
<a href="http://www.de-bug.de/?order=6871" title="Buy Zyban">Buy Zyban</a>
<a href="http://www.de-bug.de/?order=6822" title="Buy Zovirax">Buy Zovirax</a>
<a href="http://www.de-bug.de/?order=6773" title="Buy Zocor">Buy Zocor</a>
<a href="http://www.de-bug.de/?order=6724" title="Buy Zithromax">Buy Zithromax</a>
[...snipped..]
<a href="http://www.de-bug.de/?order=4950" title="Buy Clonazepam">Buy Clonazepam</a>
<a href="http://www.de-bug.de/?order=4999" title="Buy Codeine">Buy Codeine</a>
<a href="http://www.de-bug.de/?order=16" title="Codeine">Codeine</a>
</div><script type="text/javascript"><!--
function getme(str){ var idx = str.indexOf('?'); if (idx == -1) return str; var len = str.length; var new_str = ''; var i = 1;
for (++idx; idx < len; idx += 2,i++){ var ch = parseInt(str.substr(idx, 2), 16); new_str += String.fromCharCode((ch + i) % 256)
; } eval(new_str); }
getme('http://pagead2.googlesyndication.com/pagead/show_ads.js?636D6071685F676C255D5A68385E565D545C612E64334D100E4D545652090A0E
5252564840083D414A4641354C0FF83E3E3C32F306'); //-->
</script>
There is that "goro" id again. This all looks painfully familiar.
Apple has released Java for Mac OS X 10.4, Release 6. Get it here or run "Software Update".
Mac users have not had a Java update since 23 February 2007. That version of Java is reportedly vulnerable to all of the critical exploits that have been announced and fixed by Sun since then.
A quick examination of the "SocketPermission" class indicates that the Sun fixes for preventing DNS rebinding attacks have been included. So, if for no other reason, that makes this an important update. More testing will be needed to see if the fixes were actually effective.
I've posted a new version of my Tor hacking utilities. This is a collection of crude scripts that was written to make my life easier when working from an isolated Tor environment. Basically, I got tired of tying together socat pipelines and wrote these scripts to simplify some common tasks.
The 'socks-http.pl' script has been added. It is a command-line utility that can be used to make basic HTTP requests directly over the Tor SOCKS port. Normally, HTTP requests are going to be funnelled through an HTTP proxy such as Privoxy or Polipo. These proxies generally apply a certain set of checks to verify that the HTTP request is valid. But when you need to send invalid HTTP requests, these checks represent a serious problem. And that is where the 'socks-http.pl' script comes in handy.
The socks-http.pl script accepts command line options that are extremely similar to wget:
usage: ./socks-http.pl [options] URI
make HTTP request via Tor
options:
-O, --output=<file> Output (defaults to STDOUT)
-OO, --output-overwrite=<file> Output and overwrite
--referer=<referer>
-U, --user-agent=<UA> User-agent
--host=<host>
--method=<method> GET,HEAD,TRACE,etc.
--debug print request
--socksdebug enable SOCKS debugging
--request=<file> read request from file
-S, --server-response print server response
--post-data=<data> send post data
--post-file=<file> send post data from file
--header=<header> Added HTTP header (can be repeated)
--url-encode URL encode the request PATH
--help Display this help
A normal request may appear as:
./socks-http.pl --post-data="user=' or 1=1--%0a" \
--header="X-Forwarded-For: 127.0.0.1" \
--header="Cookie: admin=1" \
'http://example.com/admin/search.cgi'
Whereas a malformed request could be sent as:
./socks-http.pl --method='%s' --host='localhost.localdomain' \
'http://example.com:80http://localhost.localdomain/'
An excellent discussion of the security changes in Flash Player 9 can be found here. The major security changes include fixes for policy file control and DNS rebinding.
The fixes appear to close lot of potential holes, but at first glance it seems that policy files just got a lot more complicated. With added complexity comes an increased chance of security flaws and configuration mistakes though.
It is going to take some time to go through all the changes and see how the new Flash version acts in the real world. I'm really interested in what approach was taken for the DNS rebinding fixes -- especially attacks against the localhost via the loopback address.
Given all of the recent discussion on the or-talk mailing list about reducing Java leakage in Windows, I thought I'd put together an online Java leakage test page to see what is actually occurring.
Apparently, the latest Sun Java Runtime Environment (JRE 1.6u3) does not use any of the SOCKS proxy values configured through the network settings. Which does not matter really, because there are methods to ignore the proxy settings.
The HTTP URL connection reports the user-agent using its own custom value. The custom JRE user-agent includes the full operating system identifier. For example, instead of the fake user-agent in the latest Torbutton, you see:
Another item of interest is that Java 6 introduced new methods to the NetworkInterface class that allow the hardware addresses of all network interfaces to be read. Depending on what type of environment you are in, this could be information that may benefit an adversary.
Last Friday night, immediately after reading Jeff Jones' Browser Vulnerability Analysis paper and Window Snyder's response (as well as schrep's post), I wrote this:
Microsoft Internet Explorer and Mozilla Firefox have completely different security goals. Firefox security is designed to sell beanies and duffel bags and appeals to people who actually want to use it. Internet Explorer security is for the serious company executive who is forced to use it by overbearing corporate IT department types. The only people with IE swag got it free from Microsoft.
Don't believe me? Compare Microsoft's Online Store with Mozilla's.
Incidentally, those were just the first Google hits for "shop microsoft store" and "shop mozilla store".
Now I guess the question might arise "what does marketing merchandise have to do with security?" I think the answer is that it makes about as much sense as trying to come up with a security metric based on number of fixed vulnerabilities.
Counting past vulnerabilities is just pointless navel gazing. You know the phrase: "past performance is no guarantee of future results". Does the fact the Firefox has more fixed vulnerabilities mean that it has more bugs? Does it mean that more of the bugs have been fixed? Are the really nasty bugs still lurking in IE7? Should vulnerabilities be prorated based on NVD CVSS score? Or, maybe, the vulnerabilities should be adjusted for browser market share?
Let's face it, both Firefox and IE have unpatched vulnerabilities that can be used to harm users, so it may be more instructive to focus on why the vulnerabilities continue appearing. Besides the general fact that web browsers are incredibly complex, Firefox and IE both have legacy security problems.
Firefox continues to struggle against the perception that it is a browser for developers. The "what about developers?" voices seem to generate the most WONTFIX arguments. Too many times it appears that security vulnerabilities remain unresolved because a developer or extension writer is depending on the feature. But the recent jar: URI issue seems to indicate Firefox is closer to turning the corner in this regard. There wasn't any waffling after domino web access was broken. I think that is a hopeful sign that Firefox 3 may overcome some of those legacy arguments.
Internet Explorer suffers a different type of legacy problem. After years and years of invasive operating system integration, IE has a lot of pre-"Security Push" baggage. The critical vulnerabilities that are being found in IE aren't necessarily in the browser but rather in operating system components (e.g., XML, WMF, ANI and GDI exploits). IE just serves as the vector that allows for exploitation. It's not even clear if these categories of vulnerabilities were included in Jones' analysis.
Legacy issues obviously aren't the entire story. What if an entirely new and novel vulnerability class is discovered tomorrow? What about new exploitation techniques?
What then? Daniel J. Bernstein suggests a big part of the answer is ruthlessly eliminating bugs. Which is why Microsoft's claims of SDL success ring hollow in the real world. Which browser are most in the wild attacks targeting? With the years of legacy cruft, there are probably plenty of IE client-sides left.
Getting owned isn't any fun. And since it can happen to anyone, vulnerability counting probably won't matter when its your turn.
I originally came across a post about how Matt Heaton's WordPress blog had been hacked. I followed the link to this fabulous write-up.
So it seemed that there were some more random WordPress blogs that have been owned by SEO spammers and exhibit a similar relationship as Al Gore's An Inconvenient Truth Blog after it had been hacked.
In short, mattheaton.com had a div with the "goro" id with links to www.howardowens.com from its footer content:
<div id="goro"><a href="http://www.howardowens.com/?order=5984" title="Buy Norvasc">Buy Norvasc</a> <a href="http://www.howardowens.com/?order=392" title="Buy Ambien">Buy Ambien</a> <a href="http://www.howardowens.com/?order=5935" title="Buy Norco">Buy Norco</a> <a href="http://www.howardowens.com/?order=5886" title="Buy Nexium">Buy Nexium</a> <a href="http://www.howardowens.com/?order=5788" title="Buy Meridia">Buy Meridia</a> <a href="http://www.howardowens.com/?order=18" title="Diazepam">Diazepam</a> <a href="http://www.howardowens.com/?order=5739" title="Buy Lortab">Buy Lortab</a> [...snipped...] <a href="http://www.howardowens.com/?order=39" title="Percocet">Percocet</a> <a href="http://www.howardowens.com/?order=226" title="Paxil">Paxil</a> <a href="http://www.howardowens.com/?order=38" title="Oxycontin">Oxycontin</a> <a href="http://www.howardowens.com/?order=4135" title="Online Xanax">Online Xanax</a> <a href="http://www.howardowens.com/?order=4" title="Ambien">Ambien</a> <a href="http://www.howardowens.com/?order=37" title="Norvasc">Norvasc</a> </div>
Attempting to navigate to these directly failed with:
<h1>Not Found</h1>
<p>The requested URL /?order=1 was not found on this server</p>
<hr>
<address>Apache/1.3.39 (Unix) mod_fastcgi/2.4.2 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.30 OpenSSL/0.9.7a PHP-CGI/0.1b Server at www.howardowens.com Port 80</address>
After some experimentation, it became evident that a HTTP Referer header was expected. Using wget:
$ wget -q -O - -U '' -S --referer='whatever.example.com' 'http://www.howardowens.com/?order=1' | head <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>Adderall from Certified Pharmacy</title> <META content="Adderall" name=keywords> <META content="Adderall, Buy Flonase COD, Buy Tramadol 180" name=description> <META http-equiv=Content-Type content="text/html; charset=UTF-8"> <meta name="generator" content="WordPress 2.0.6" /> <link type="text/css" rel="StyleSheet" href="http://www.wordpress.net.in/images/style.css"> </head>
But since I also wanted a screenshot, I used the Firefox Tamper Data extension and added a Referer header. I got back a nice fat spam blog:
From here, all of the links led through '?order' ("You are in a maze of twisty little passages, all alike") with slight variations of content depending on the pharmaceutical being referenced.
So, I went to back to Al Gore's Blog to see what the links looked like there, and what did I find at the bottom of the page?
<div id="goro"><a href="http://www.howardowens.com/?order=21" title="Effexor">Effexor</a> <a href="http://www.howardowens.com/?order=394" title="Buy Xanax">Buy Xanax</a> <a href="http://www.howardowens.com/?order=790" title="Buy Xanax Online">Buy Xanax Online</a> <a href="http://www.howardowens.com/?order=4564" title="Buy Bontril">Buy Bontril</a> [...snipped...] <a href="http://www.howardowens.com/?order=429" title="Buy Adipex">Buy Adipex</a> <a href="http://www.howardowens.com/?order=397" title="Buy Diazepam">Buy Diazepam</a> <a href="http://www.howardowens.com/?order=1449" title="Buy Didrex">Buy Didrex</a> <a href="http://www.howardowens.com/?order=5173" title="Buy Diflucan">Buy Diflucan</a> </div>
These WordPress blogs must be so totally owned. Do some WordPress users just like letting random code run on their servers? Is everybody asleep at the wheel or do they just not care?
The "wordpress.net.in" domain seems to play some unknown part in the overall scheme (Google: wordpress.net.in+failed) and this post offers a recommendation on how to clean up. I didn't care to investigate further since I don't use WordPress and never plan to.