Why bother setting up dedicated websites to host malicious content when you can just infect trusted sites like BusinessWeek? This is becoming something of a trend, as evidenced by the mass SQL Injection attacks from a few months ago.

The idea is simple -- find SQL Injection vulnerabilities in high-traffic, trusted websites where the site's content is dynamically fetched from a database (i.e. just about any content-rich site). Then use an automated tool to prepend or append malicious content to that content in the database. When the unsuspecting user visits the page to read an article, they will be treated to a barrage of <script> or other tags fetching content from sites in .ru, .cn, or who knows where else.

The guidance you give to mom and dad, "don't visit sketchy looking sites in other countries," is no longer good enough. If BusinessWeek can be compromised, it's a given that USA Today, CNN, the New York Times, and other establishments are being targeted as well.

For this and similar examples, NoScript would have thwarted the attack because it wouldn't permit the .js file to be loaded from an off-domain location. But what happens when the attackers start injecting the entire .js payload into the database instead of just a <script> tag? Now the malicious code is coming from the trusted domain, and if I've configured NoScript to allow scripts from businessweek.com, I'm out of luck. In fact, I have no idea why the attackers aren't using this tactic already. Any ideas?

FREE Security Tutorials from Veracode

Cyber Security Threats
Mobile Phone Security
Flash Player Security
SQL Injection Attack
CRLF Injection

Veracode Security Solutions

Software Security Testing
Binary Code Analysis
Application Testing

Veracode Data Security Resources

Data Breaches
Data Loss Prevention
Data Security

About Chris Eng

Chris Eng, vice president of research, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Comments (5)

Andre Gironda | September 15, 2008 7:37 pm

Probably for analytics. Combine the fact that about 0.2 percent of web browsers roll NoScript

kurt wismer | September 15, 2008 10:39 pm

1) cnn has already been a victim...
2) it's hard to implement any kind of server-side polymorphism with such tenuous influence over the server...
3) the scripts are usually part of a multi-stage attack (rare that an attack would end with just javascript) and the other stages are likely not nearly as easy to inject into vulnerable databases - so, since an external malicious content host is probably going to be needed anyways why not use it for the javascript too...

CEng | September 15, 2008 11:32 pm

@Andre: Probably right about the low occurrence of NoScript.

@Kurt: 1) Oops, I must've missed that. 2) Do they really care about polymorphism? 3) The mass SQL injection attack just loaded some .js that injected a bunch of IFRAMEs attacking client-side vulns, so I wouldn't call it a particularly complicated attack. Why not just document.write() those IFRAMEs rather than add the extra hoop of loading .js from an external site?

I don't really follow the malware space that much so I am fully expecting to be called out for asking ridiculous questions!

Cody | September 16, 2008 12:02 pm

This problem will never be solved with current technology in my opinion (ignoring the source of the problem being sql injection). It seems very difficult, if not impossible, to block javascript originating from the same host as legitimate code.

We need to move to a system of content validation for the web. Whether that is a signature the database can use to verify integrity of data, or web server content validation before serving pages.

kurt wismer | September 17, 2008 10:21 am

do they really care about server-side polymorphism? some do, yes...

as for why they use external .js files instead of instead of inline document.write() calls? the footprint on the legitimate site's content is smaller and better obscured if there's just a reference to some outside js file as opposed to putting the malicious document.write() calls right in their system... it's not *really* obscured, of course, but a lazy webmaster might not check the contents of that external file and for complex sites that have a lot of people developing them there's a good chance that no single person is familiar enough with the the entire code to know that an external reference should or shouldn't be there...

in short, it raises the amount of work necessary to stumble across the problem unknowingly...

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.