The interesting things about these attacks so far is what they are actually doing. They are not attempting to steal data out of these databases directly, they are populating the pages with links that attempt to do drive by malware installs by exploiting browser vulnerabilities. It was pretty successful but SQL Injection is a  vulnerability  that is on the decline (and will decline even more after this attack). I begin thinking about vulnerabilities that would do the same thing but have a much broader reach.

Our good friends XSS and CSRF.

So here is the attack.

1. Find a few permanent XSS vulnerabilities in some high traffic sites.
2. Find some CRSF vulns in popular blog and forum software.
3. Craft your payload.
4. Profit!

So the bot software basically sits back and waits until the computer it is on visits a vulnerable site and then places it payload in the vulnerable spot. It could of course do this without you visiting a site with a little more coding to check if you are permanently logged in.

Considering the number of sites with XSS and CSRF this attack would dwarf the current SQL Injection attack happening today.

Post from: Grumpy Security Guy

Bots + Web Vulnerabilites - An Approaching Storm

You may have read recently about a large number of Web servers that were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic  so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user's perspective the real attack was compromised Web pages that serve up malware to attack user's through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.

The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.

I think the first lesson from this attack is this:

If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work.

So now that you've determined the database access code, now what? The SDL is very specific about what do here, there are three requirements - they are requirements not recommendations, which means you must do the following coding requirements and defenses

• Use SQL Parameterized Queries
• Use Stored Procedures
• Use SQL Execute-only Permission

Use SQL Parameterized Queries

From the SDL documentation:

"Applications accessing a database must do so only using parameterized queries.

Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.

Combining the use of parameterized queries and stored procedures helps to mitigate the risk of successful exploitation of user input which is not correctly verified."

This defense has been known about forever; heck, David and I discussed this in detail in the first edition of Writing Secure Code in 2002:

From page 320, "Another way to perform this kind of processing is to use placeholders which are often referred to as parameterized commands."

Just about every database access technology supports parameterized queries; work out what they are for your DB technology and use them: the defense for a PHP/MySQL combo will not be the same as a C#/SQL Server combo.

The most likely cause of these recent compromises is using string concatenation to build SQL statements. Just don't do it, even if you think you're safe, just don't use string concatenation to build SQL statements! There are some very specialized cases where string concatenation is valid, but they are rare, especially for Web apps. In my opinion, any use of string concatenation in a Web application is a high-priority bug.

Use Stored Procedures

From the SDL documentation:

"Applications accessing databases should do so only using stored procedures. "

-and-

"Do not use "exec @sql" construct in your stored procedures.

Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints the stored procedures will throw an exception. In the vast majority of the cases, this should be properly handled within the application.

However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer."

Note the words "help mitigate," by themselves stored procedures do not remove SQL injection vulnerabilities; they just raise the bar on the attacker by hiding much of the underlying database schema from the attacker.

Use SQL Execute-only Permission

This next defense is interesting in that it is a defense in depth method; in this case it assumes the attacker has successfully found a SQL injection bug in your code. Now what? Thankfully, this defense will stop most every attack dead in its tracks.

From the SDL documentation:

 "Only grant ‘execute' permission on all stored procedures, and grant that permission only for the application domain group.

Ensure that this group is granted execute permissions only on your stored procedures. Do not grant any other permission on your database to any other user or group."

This is a great defense, because if the attacker attempts to access any other database object other than through a stored procedure (you can use views also), the underlying database permissions model prevents the attack by denying access to the attacker.

It's interesting that the SDL offers three SQL injection requirements; only one actually remedies the problem (secure by design) and the other two offer mores defenses assuming failure (secure by default.)

Of course, a simple set of rules is not a substitute for careful design, implementation, and test. The SDL is a holistic process that covers the software lifecycle end-to-end, so don't mistake these simple rules as a guarantee that you will avoid SQL injection problems. You need to understand the situations in which the rules apply. You may find, for example, that string concatenation is the best - or perhaps only - solution to a particular problem and these rules may not guard against SQL injection in those situations. Follow secure development practice throughout the lifecycle of your project - including things we left out of this blog, like testing and security response, for best results.

The SQL [structured query language] inserts that came earlier were just pablum intended to lull the Army cadets into a false sense of security. But then the bad guys unleashed a stealthy kernel-level rootkit that burrowed into one workstation, started scraping data and "calling home."

It was a highly sophisticated attack, but this time the bad guys were really good guys in wolves' clothing.

For four days in late April, the National Security Agency -- the nation's most secretive repository of spooks, snoops and electronic eavesdroppers -- directed coordinated assaults on custom-built networks at seven of the nation's military academies, including West Point, the Army university 50 miles north of New York City.

It was all part of the seventh annual Cyber Defense Exercise, a training event for future military IT specialists. The exercise offered a rare window into the NSA's toolkit for infiltrating, corrupting or destroying computer networks.

The 34 Army cadets comprising the West Point IT team operated in a different kind of battlefield, but their combat skills and instincts need to be every bit as sharp. Like George Washington said: "There is nothing so likely to produce peace as to be well prepared to meet the enemy."

The SQL injections, targeting their Fedora Core 8 Web server, were a piece of cake for these IT combatants. Each injection tried to smuggle malicious code inside the seemingly harmless language used by the network’s MySQL software. The cadets handily defended with open source Apache web server modules, plus some manual tweaking of the SQL database to "avoid any surprises," in the words of Lt Col. Joe Adams, a West Point instructor who helped coach the team.

But the kernel-level rootkit was much more dangerous. This stealthy operating-system hijacker can open unseen "back doors" into even highly protected networks. When they detected the rootkit's "calls home" the cadets launched Sysinternal's security software to find the hijacker, then they manually scoured the workstation to find the unwelcome executable file.

Then they terminated it. With extreme prejudice.

"This was probably the most challenging part of the exercise, since it required them to use some advanced techniques to find the rootkit," Adams says. And rooting it out helped boost the West Point team to the top of the pile when, in the aftermath of the exercise, the referees rated all the universities' network defenses.

For the second year in a row, the Army placed first over the Navy, Air Force, Coast Guard and others, winning geek bragging rights and the privilege of holding onto a gaudy, 60-pound brass trophy festooned with bald eagles and American flags. Adams credits the team’s thorough preparation and their excellent teamwork despite the round-the-clock schedule.

At the network control room on the second floor of West Point’s 200-year-old engineering building (which once was an indoor horse corral and still smells like it in some remote corners, according to one instructor), the IT team set up cots and, just for the hell of it, camouflaged netting. They worked in shifts, with one team member always monitoring incoming and outgoing traffic. He or she would alert other cadets -- "router guys" -- to block any suspicious addresses. Meanwhile, off-shift cadets would make food and coffee runs to keep everyone fueled up and alert. Together, the team was "faster than anyone else," Adams says.

But the way the cadets designed their network was a big factor in their victory, too. The NSA dictated some terms: All networks had to be capable of e-mail, chat and other services and had to be up and running at all times despite any attacks or defensive measures. Beyond that, the teams were free to come up with their own designs.

West Point's took three weeks to build. The cadets settled on a fairly standard Linux and FreeBSD-based network with advanced routing techniques for steering incoming traffic in directions of the IT team's choosing.

The choices in software tools for responding to any attack really boiled down to "automatic" versus "custom," says Eric Dean, a civilian programmer and instructor. He adds that while automatic tools that do most of their own work are certainly easier, custom tools that allow more manual tweaking are more effective. "I expect one of the 'lessons learned' will be the use of custom tools instead of automatics."

Even with a solid network design and passable software choices, there was an element of intuitiveness required to defend against the NSA, especially once it became clear the agency was using minor, and perhaps somewhat obvious, attacks to screen for sneakier, more serious ones.

"One of the challenges was when they see a scan, deciding if this is it, or if it’s a cover," says Dean. Spotting "cover" attacks meant thinking like the NSA -- something Dean says the cadets did quite well. "I was surprised at their creativity."

Legal limitations were a surprising obstacle to a realistic exercise. Ideally, the teams would be allowed to attack other schools' networks while also defending their own. But only the NSA, with its arsenal of waivers, loopholes, special authorizations (and heaven knows what else) is allowed to take down a U.S. network.

And despite the relative sophistication of the NSA's assaults, the agency told Wired.com that it had tailored its attacks to be just "a little too hard for the strongest undergraduate team to deal with, so that we could distinguish the strongest teams from the weaker ones."

In other words, grasshopper, nice work -- but the NSA is capable of much craftier network take-downs.