Mass Injection Compromises More than Twenty-Thousand Web Sites

http://securitylabs.websense.com/content/Alerts/3405.aspx

 

This is bad. Thank the maker I use Sandboxie. I tell you, my understanding of infection vectors is more than a couple of years behind the times.

 

This Websense article is a very instructive one for security-minded people to study.

First, as with many such articles that give quite (seemingly) startling statistics, it is picked up by other news organizations (guaranteed to attract lots of readers):

• PC-pwning infection hits 30,000 legit websites And counting
  http://www.theregister.co.uk/2009/05/30/mass_web_infection/
  
  
• Report: Mass Injection Attack Affects 40,000 Websites
  http://www.darkreading.com/security/attacks/showArticle.jhtml?articleID=217701136

Well, the number of sites seems to have increased since these articles are a couple of days later (Websense appeared May 29). It's the numbers, of course, that are supposed to impress us.

But in another place on their site, Websense states that their ThreatSeeker™ Network
"scans more than 40 million Web sites for malicious code every hour."

Somehow 20 - 40,000 doesn't seem like a large percentage when viewed against the total survey.

But on to the report. If we are looking for information about the mass injection attack and how we might be affected, thus, how we might protect against it, what do we learn from the Websense article:

• First, javascript on the legitimate site triggers the redirection to an active exploit site. Turn off Javascript? But suppose the legitimate site you are visiting is one where you permit Javascript? Away you go to the exploit site.
  
  
• Second, you can block the fake google-analytics domains, if you knew them. But this would be just a temporary bandaid, since there have been and still are many mass injection attacks that don't use this trick.
  
  
• Third we learn that the exploit site has "various attacks" but no specifics. Websense gives a snippit of the code but they don't decipher it for us.
  
  
• Fourth, a malicious file is run, but we don't know what that is.
  
  
• Last, if you depend on AV, you are worried.

However, never fear, help is near:

There you are!

Not too comforting if we are not one of their customers. So, we have to look elsewhere for more information. Searching for "mass injection attacks" brings up lots of sites and if you poke around you can find more thorough analyses.

It turns out that this is just a variation on continuing code injected attacks, probably by SQL injection into legitimate sites whose servers have unpatched vulnerabilities. Note that the Register article quoted the Websense researcher about SQL yet Websense didn't elaborate on this in their own article.

From other sources: The code in the injected legitimate site calls out to another site to load a javascript file which identifies the browser. If IE, it serves up old, patched exploits that target that browser. If not, then one of the current PDF exploits.

So:

If you use IE: if patched, nothing happens.

If Firefox or Opera, by now with the PDF exploits being "old stuff"' you know that disabling the Reader Plug-in to keep the PDF file from loading in the browser nullifies the exploit. This applies also to IE if that browser is targeted with a PDF exploit.

Finally, you have (or should have) your own protection against the resulting malware executables in a drive-by attack, should all else fail.

CONCLUSION

• Articles about attacks often focus mostly on the sensational aspects and don't give much useful information for zeroing in on the specifics so that you know exactly what you are protecting against.
  
  
• This particular article seems to be an Alert for their customers, rather than a Research Report or White Paper which appear on another page of their site.
  
  
• Spending time looking for other sources will give you better information. Sometimes you have to dig and follow lots of links, but you eventually get to the pertinent stuff.
  
  
• Some of the articles may seem technical, but just look for what a script does, for example:
  
  Malicious “Stats” from 84.244.138.0
  http://blog.unmaskparasites.com/2009/04/02/malicious-stats-from-84-244-138-0/
  
  We see that the code in the legitimate page loads another javascript file: ga.js or stats.js
  (Note how the code can be copied for analysis, unlike the Websense article.)
  
  After awhile, you begin to pick up on what is going on behind the scenes in these attacks, and it becomes evident that they are not so difficult to protect against.

----
rich

 

@Rmus, nice walk through of logic.

About those .pdf attacks. If you have no plugin for .pdf, and you download the rogue .pdf, what happens if you view it in 3rd party like foxit?

Sul.

 

Thanks, Sul.

You can't tell whether the bad file PDF file exploits Adobe or Foxit. In both cases -- assuming an unpatched REader -- the exploit code will call out to download the malware, so a firewall that monitors outbound connections will catch the attempt. And in your case, Software Restriction Policies would block the attempted installation of the malware executable.

You can keep up with the exploits for both:

Foxit
http://www.foxitsoftware.com/pdf/reader/security.htm

Adobe Acrobat
http://www.adobe.com/support/security/?securityadvisoryproduct=#acrobatwin&Submit=Go


Here is one analysis of a PDF file exploiting Foxit:



So you can't be sure about a PDF file unless you can analyze it.

But the filenames for these in the exploits are suspicious, so normally one would question that, and also the source of the file. Hopefully one wouldn't open a PDF file received in an unsolicited email!

----
rich

 

For sure! How should they do this?

Articles refer to the ease with which malware writers find ways to inject code into websites. How can proprietors discover these vulnerabilities?

For example, could Wilders Security Forum be exploited with a code injection?

If not, What do the proprietors here do to prevent this?

EDIT: Rhetorical questions, for I'm not expecting any secrets to be revealed: just general ideas!

thanks,

rich

 

Thanks for the article!

I think many people here focus on what happens if we encounter a compromised site, and don't think so much about web proprietors' responsibility to protect their sites.

----
rich