Lizamoon Attack Targets SQL Injection Vulnerability

[Renegade]

http://www.pcworld.c...ou_need_to_know.html

The world was rocked today by LizaMoon--a SQL injection attack which has compromised well over one million Websites. No need to panic, though. A little information and common sense are all you need to make sure that LizaMoon is nothing more than a minor annoyance.

What Happened?

LizaMoon is a SQL injection attack that inserts malicious code on otherwise legitimate sites. However, don't let the fact that it is called SQL injection cause you to jump to the conclusion that there is a flaw in Microsoft SQL Server.

An FAQ from Websense--the security firm credited with the initial discovery of LizaMoon--explains, "Everything points to that this is a vulnerability in a web application. We don't know which one(s) yet but SQL Injection attacks work by issuing SQL commands in un-sanitized input to the server. That doesn't mean it's a vulnerability in the SQL Server itself, it means that the Web application isn't filtering input from the user correctly."

Ahem...





Nuff said.

[barney]

Nuff said.

-Renegade (April 02, 2011, 10:56 PM)

Well-l-l-l ... maybe not  .  Most anything I've seen for sanitization involves regular expressions.  Not something many Web masters cleave unto, much less understand.  Until the script providers - PHP, JS, et. al., actually provide cleansing routines, many Web folk just aren't/won't be qualified for cleansing of that nature.  (Of course, if it's provided in the language, any baddie past the script-kiddie stage will likely overcome it unless it's really good  .)

Professional sites have no excuse, of course, but then, how many sites on the Web are really professional  ?  And how many of those sites were hit  ? 

Injection attacks are no joke, but there's really not a lot out there to make folk aware how dangerous they can be, and even less on practical advice on avoidance of such.  (Learn, as a command, is neither practical nor effective  .)

[Renegade]

There are abstraction layers that you can use to take care of things for you. There really is not excuse. Nobody should ever be writing SQL statements dynamically in a production system, and especially in a front-facing production system.

[f0dder]

Nobody should ever be writing SQL statements dynamically in a production system, and especially in a front-facing production system.

-Renegade (April 03, 2011, 02:00 AM)

Well, you definitely shouldn't be doing it the string-concatenation way, that's for sure - but technologies like LINQ uses dynamic SQL under the hood

I'm pretty miffed that a lot of people still are doing string-concatenated SQL by hand. Like, wtf? It's insecure, it's slow, and if you're using a SQL provider that doesn't support bound arguments... go hang yourself.

[Renegade]

Nobody should ever be writing SQL statements dynamically in a production system, and especially in a front-facing production system.

-Renegade (April 03, 2011, 02:00 AM)

Well, you definitely shouldn't be doing it the string-concatenation way, that's for sure - but technologies like LINQ uses dynamic SQL under the hood

I'm pretty miffed that a lot of people still are doing string-concatenated SQL by hand. Like, wtf? It's insecure, it's slow, and if you're using a SQL provider that doesn't support bound arguments... go hang yourself.

-f0dder (April 03, 2011, 06:35 AM)

That's exactly what I mean. There's an abstraction layer there that takes care of it for you. Why would anyone want to do it themselves?

I think I probably phrased that wrong, but you obviously know what I mean.

[wraith808]

There are abstraction layers that you can use to take care of things for you. There really is not excuse. Nobody should ever be writing SQL statements dynamically in a production system, and especially in a front-facing production system.

-Renegade (April 03, 2011, 02:00 AM)

This.  That kind of stuff should make heads roll...  and there are ways to check for this that don't involve regular expressions nor abstraction layers, i.e.

Code: C# [Select]

1. private static string[] SQLKeywords = new string[]
2.       {
3.             ";", "--", "EXECUTE ", "EXEC(", "SELECT ", "INSERT ", "UPDATE ", "DELETE ", "CREATE ",
4.             "TRUNCATE ", "DROP ", "ALTER TABLE ", "TABLE ", "DATABASE ", "WHERE ", "ORDER BY ", "GROUP BY ",
5.             "DECLARE ", "CAST(", "CONVERT(", "VARCHAR(", "NVARCHAR("
6.       };
7.  
8. ...
9.     protected void Application_BeginRequest(Object sender, EventArgs e)
10.     {
11.         ....
12.  
13.         queryString = Server.UrlDecode(queryString).ToUpper();
14.         foreach (string keyword in SQLKeywords)
15.         {
16.             if (queryString.IndexOf(keyword) != (-1))
17.             {
18.                 errorMessage = String.Format("Unexpected T-SQL keyword ('{0}') has been detected ({1})", keyword, queryString);
19.                 throw new Exception(errorMessage);
20.             }
21.         }
22.     }

Putting that kind of code in the global.asax page would nip that in the bud.  And that's just a simplistic example off of the top of my head.

[barney]

Ahem {continuing DA role}.

Assume I just bought a couple of books on building a Website with PHP & MySQL.  Also assume RTFM has been accomplished.  I'm ready to publish my site, go live with a dynamic, data-driven site.  Y'know what?  It's funny, but there wasn't anything anywhere in those books about how to avert SQL injection if it was mentioned at all.  Now, since I have my site up and running, I'm looking around on various scripting sites to find ways to make my site better, more exciting.  Once again, there's not much on prophylactic measures unless I search on a specific attack.  {Steps out of DA role.}

wraith808 posted a bit of C#(?) code that would easily transport to PHP, so I'm assuming it'll just as easily translate to other Web scripts.  But that's the first piece of [someone else's] code I've seen in years to address the issue.  And of the thirty (30) to forty (40) books in my library dealing with things Web-ish, one - and only one - has more than a paragraph or two (2) dealing with prophylaxis.

So, the end result?  There's little to no awareness of a need for scrubbing inputs until someone gets hit.  And it gets publicized.  Gee, I wonder where the publicity about that danger was, before?!?

[f0dder]

You're touching on a pretty important point, barney - that there's boatloads of bad information out there, and not nearly as much good. The situation is especially grave in the shallow end of the market, like that "teach yourself X in Y timeunits" - ugh. And various code snippets at various programming resource sites aren't necessarily good either; some suck because they're written by not-so-experienced programmers, other can be dangerous because they're hacked together to show how a specific piece of technology is used, and error handling would obscure the guts of the snippet.

So, what to do? Dunno if there's any books dedicated to the topic, or if there's any decent php/asp/whatever books that cover the safety aspects properly. But whether there are or not, you'll still have to do what you can yourself to keep current on the topics - follow blogs, spend time on StackOverflow, look at some of the horrible crap exposed on DailyWtf et cetera

[wraith808]

I'd agree.  Getting down from my high horse, I can see how someone who's doing it for fun might not even know about SQL injection, let alone how to avoid it, if they didn't just happen to be in the know because of a bad situation.  I do wonder why it isn't mentioned more.  I've been asked about it several times in interviews, but never have I actually read anything about it that I can remember.  Strange.

(And it is C#- and I fixed a bug in the code)

[f0dder]

If you use bound arguments, btw, scrubbing for the various SQL keywords shouldn't be necessary - and it might not be a good idea to scrub for it where you're doing, Wraith - stuff like "update" or "delete" could very well be valid in a lot of situations... but even with bound arguments, some data validation/scrubbing is a good idea, you might be interfacing with a system where the rest of the components are retarded. And depending on what you do, there might even be more cases of scrubbing you need to do (dealing with HTML tags being one very common and important subject).

Btw, it's almost always a bad idea to use regular expressions for this - for single-word deletes/replacements you can go faster without, and for more complex scenarios you'll need a proper parsing engine to not fight a hopeless battle.

[wraith808]

^ True... that was just a simplistic example from the past   But yes, it could be legitimate in some situations.

[Renegade]

If you use bound arguments, btw, scrubbing for the various SQL keywords shouldn't be necessary - and it might not be a good idea to scrub for it where you're doing, Wraith - stuff like "update" or "delete" could very well be valid in a lot of situations... but even with bound arguments, some data validation/scrubbing is a good idea, you might be interfacing with a system where the rest of the components are retarded. And depending on what you do, there might even be more cases of scrubbing you need to do (dealing with HTML tags being one very common and important subject).

Btw, it's almost always a bad idea to use regular expressions for this - for single-word deletes/replacements you can go faster without, and for more complex scenarios you'll need a proper parsing engine to not fight a hopeless battle.

-f0dder (April 03, 2011, 03:13 PM)

+1

[CWuestefeld]

What Renegade said.

There is absolutely no excuse for SQL Injection attacks to work. The kind of programming that sets up this vulnerability is just bad programming. *Every* communication with the DB should pass data via out-of-band parameters, rather than with the values concatenated in, no exceptions. And doing so is easy, at least on any decent development platform.

Doing it the right way

• Is secure, which should be all the reason you need. It's very difficult to cover all the possibilities if you don't do it this way, far harder than actually doing it right.
• Is more performant. Many database engines (including MS SQL Server up to SQL 2005, iirc) are able to cache query plans if the data is parameterized, but if the query is hard-coded (from the DB's point of view), it gets cached with those specific values.
• Is a better user experience. Anytime you've got to sanitize the user's input, it means that you're either forbidding the user from entering some set of values that he might want, or mangling his data. The naive example (that you still see occasionally) is the removal of quotes, like changing someone's name from O'Reilly to OReilly.

Bottom line: if you want to work on my team, at least, you will do it the right way, or you won't work here. Period.

[Stoic Joker]

I gotta go with barney here, much vehemence is coming from the pulpit ... but no details.

Sure specific general statements are made about do X not Y ... But no how is given.

Many of the concepts mentioned in this thread could take a great deal of time to explain, or research, I'm sure. But if (say) 3 - 5 lines of code were posted with them outlining what is to should be happening. Well... That could ge a long way towards being part-of-the-solution ...Don't Ya think?


While wraith808's example might not have been the most perfectly correct answer. It was at least one of the best attempts at a clear straight answer I've seen yet.