Zscaler Blog

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Security Research

USPS.gov Website Infected with Blackhole Exploit Kit

image
MICHAEL SUTTON
April 07, 2011 - 4 Lesezeit: Min
 
Update (04/07/2011 10:03am PST): USPS officials have taken the http://ribbs.usps.gov web site down to address the infection.

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:




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('');


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:




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)
  • java_skyline.php - detection rate: (2/41 AV vendors)

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
form submtited
Danke fürs Lesen

War dieser Beitrag nützlich?

Haftungsausschluss: Dieser Blog-Beitrag wurde von Zscaler ausschließlich zu Informationszwecken erstellt und wird ohne jegliche Garantie für Richtigkeit, Vollständigkeit oder Zuverlässigkeit zur Verfügung gestellt. Zscaler übernimmt keine Verantwortung für etwaige Fehler oder Auslassungen oder für Handlungen, die auf der Grundlage der bereitgestellten Informationen vorgenommen werden. Alle in diesem Blog-Beitrag verlinkten Websites oder Ressourcen Dritter werden nur zu Ihrer Information zur Verfügung gestellt, und Zscaler ist nicht für deren Inhalte oder Datenschutzmaßnahmen verantwortlich. Alle Inhalte können ohne vorherige Ankündigung geändert werden. Mit dem Zugriff auf diesen Blog-Beitrag erklären Sie sich mit diesen Bedingungen einverstanden und nehmen zur Kenntnis, dass es in Ihrer Verantwortung liegt, die Informationen zu überprüfen und in einer Ihren Bedürfnissen angemessenen Weise zu nutzen.

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.