Relentless Web Attack Hard To Kill 218
ancientribe writes "The thousands of Web sites infected by a new widespread SQL injection attack during the past few days aren't necessarily in the clear after they remove the malicious code from their sites. Researchers from Kaspersky Lab have witnessed the attackers quickly reinfecting those same sites all over again. Meanwhile, researchers at SecureWorks have infiltrated the Chinese underground in an attempt to procure a copy of the stealthy new automated tool being used in the attacks."
Whatever happened (Score:5, Insightful)
Re: (Score:3, Informative)
AFAICT, they are patching the hole, they're just finding even more holes of the same type.
Re: (Score:2)
It's the plugins... (Score:3, Insightful)
At the end of the day it's the problem of plugins...I mean, besides the fact that the website is being infected, it's the flaws and vulnerabilities of the ActiveX/Browser plugins that allow this kind of activity to be profitable.
Just yet another reason, besides bandwidth, to get Flashblock.
And install as few as browsers plugins/ActiveX as possible.
Don't rely on FlashBlock for security... (Score:3, Insightful)
noscript (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
SO WHY CAN'T YOU WHITELIST THE SITE THAT YOU HAVE TO SUPPORT? Along with any other sites you support?
Its not that hard to build up a whitelist. The first time you visit a "trusted" or regular site, add it to the white list. Does it have any subdomains, or "partner" domains that you also need to add? Go ahead and add them.
So many people complain about how NoScript breaks pages, but its really not that hard at all to setup a whitelist.
Now when your redirected/accidentally click on a link to dgdrklgdr.com/e3re
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Yes, we should stick to the old tried and true "overload the server and piss off the user" method of the 1990's.
Name: Dave
Country : Thailand
Telephone : 12345678
Date of Birth : 29/02/2000
[SUBMIT]
Oops' looks like some problems with your submission - please correct the following :-
Please supply your Firstname AND Surname ...
Name : Dave Mullen
[SUBMIT]
Oops' looks like some problems with your submission - please correct the following :-
You are from Thailand, where people don't always HAVE surnames - please just s
No, it's not. (Score:4, Informative)
Your're right to publicise a good product that I also use and reccommend. However:
Most people that get caught by malware don't understand all these arcane details.
Most people use IE, (no noscript here..) and blindly click 'OK' when they cannot see the porn.
Bad web sites / pages don't just install viruses.*
Trust (Score:2, Insightful)
Okay keep using Noscript. I don't have a problem with that, but be warned that you are not fully protected by Noscript when the website you TRUST is attacked by an exploit like SQL injection, because YOU TRUST THAT WEBSITE.
White-lists are better than no-lists, but they aren't perfect.
Re:Trust (not exactly) (Score:2)
Infiltration (Score:2, Funny)
SecureWorks: Can I have a copy of your super secret automated tool?
ChineseUnderground: No...
Re: (Score:3, Funny)
*** Joined #ChineseUnderground
<SecureWorks> Can I have a copy of your super secret automated tool?
*** Mao set mode +b *!*@secureworks.com
*** Kicked from #ChineseUnderground by Mao (No.)
(sorry, crapdot ate the brackets)
Infected Websites (Score:4, Interesting)
Can someone explain to me how websites get infected?
Oh, that's right, running ads and other shit from shady people (directly or indirectly).
I really wish websites would simply stop hosting foreign (not theirs, not trusted, not checked) code and content.
Re: (Score:2)
Just so we're clear, that includes flash and pdf.
Re: (Score:2)
The article says that the websites are getting hit with a sql injection [wikipedia.org] attack, so ads shouldn't be the problem, unless the ad server is vulnerable.
This probably has nothing to do with ads and more to do with failing to validate user input. (Obligatory xkcd [xkcd.com] reference)
Re: (Score:2)
In this case, yes, but see above:
I really wish websites would simply stop hosting foreign (not theirs, not trusted, not checked) code and content.
Re: (Score:2)
My understanding was that people are passing input as a big string and then turning that into queries instead of doing it the right way, which is passing parameters.
Re: (Score:2)
I really wish websites would simply stop hosting foreign (not theirs, not trusted, not checked) code and content.
I really wish websites would simply stop expecting me to run their code.
Re: (Score:2)
Agreed!
Re: (Score:2)
Are you joking?
Sanitize your inputs and you've defeated SQL injection.
Re: (Score:2)
Which is exactly my point!
Most websites taking orders online simply used a cookie cutter ecommerce front end that they get free/cheap with their hosting.
This disgusts me (Score:4, Insightful)
I develop web applications for a living right now and as someone who's only been in this game for a few months, this disgusts me. I already know how to prevent SQL injection with prepared statements. It's easy to do and requires no extra knowledge, so why doesn't everyone do this?
Re:This disgusts me (Score:4, Insightful)
The problem is a frightening amount of training material on the web uses concatenated SQL strings to teach SQL. Pull up your average PHP/.Net/Java SQL tutorial and odds are that it will be concatenating strings. Throw that in with the fact that roughly half of the programmers reading that are going to be below average, and there you go.
Re:This disgusts me (Score:5, Funny)
I'd say fully half of all the programmers are going to be below average...
Re:This disgusts me (Score:5, Funny)
I'd say fully half of them will be below median.
Re: (Score:2)
Re: (Score:2)
1.) Are there equal programmers?
2.) Is the number of programmers even or odd?
Re:This disgusts me (Score:4, Insightful)
Um for anything that is approximately normally distributed,... half of the X are going to be below average. (Especially if it is a continuous variable and you use the median)
Re: (Score:2)
Insightful? Nope. (Score:2)
If you're going to show off, do it right.
Many continuous distributions are not normally distributed, and no discrete distributions are. So don't understand the 'especially if it is a continuous variable' part. Should be 'only if'.
He said the average, not the median. Sure, for a perfect normal distribution all 3 measures of central tendancy are the same - mean, median & mode. Of course, in real life this never happens.
So the other AC got it right...'fully half if even number' is only right interpret
Re: (Score:2)
I did, "(Especially if it is a continuous variable and you use the median)"
Re: (Score:3, Insightful)
Throw that in with the fact that roughly half of the programmers reading that are going to be below average, and there you go.
That is what comes of outsourcing and offshoring especially, but there are still managers out there who refuse to acknowledge what I like to call the Iron Law of Software Development or more generally the Project Triangle [wikipedia.org] (good, fast, cheap...pick two).
Re: (Score:2)
Well there are good offshore companies, but when a company off-shores they tend to do so to save money, which means they go for the cheap and crappy companies. Unfortunately, because a lot of these places are a growing market, there tend to be an abundance of the cheap places, who subsequently stock up on poor programmers. The hatchet of the market hasn't had opportunity to trim the fat yet. You'd see a lot of the same stuff going on if you looked at what some companies in the late 90's were producing in
Re: (Score:3, Informative)
Languages can make bad code harder or easier to write however. Its perfectly acceptable to blame a language if it makes it hard to do things the "right way." I'm not much of a PHP hater, but a lot of stuff that they've done with the language makes me roll my eyes.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I agree that parameterized statements are the way to go, but in many cases it *is* pretty easy to filter input that shouldn't be present, and using both techniques together can provide protection from things other than SQL injection.
In many instances you may simply be able to allow only \w or \w\s\.\- without ever destroying valid input. Even if you have wider input requirements it's often possible to drop anything outside the normal printable range and any quoting characters (where "quoting characters" may
Re: (Score:2)
Yes, in some cases it is possible. However, I would argue that it is much more likely that you will either miss something that is harmful, or inadvertently place unnecessary restrictions on input.
I should note that I don't consider parameterized statements to be a replacement for input validation. You should still make sure that your input makes sense for the data it is supposed to represent. However, filtering for "harmful characters" really shouldn't need to be a part of this.
Re: (Score:2)
No, he's right. Prepared statements are how you block SQL Injection attacks.
Re: (Score:2)
No, he's right. Prepared statements are how you block SQL Injection attacks.
Or parametrised statements are also an absolute defence against them; not as fast, but they're what I use for one-off quick programs that don't need to be efficient or production-quality. (I don't see why such quick programs should have to be insecure, though; using a technique that blocks SQL injection altogether - and let's face it, it's not difficult - is greatly preferable to having your website serving other people's viruses.)
Re:This disgusts me (Score:5, Informative)
You're right, you're no programmer. Go read up:
http://en.wikipedia.org/wiki/SQL_injection [wikipedia.org]
Prepared (or parametrized) statements are an easy and absolute defense against SQL injection attacks. The OP is right, the fact that such attacks still succeed is disgusting and inexcusable.
Re: (Score:3, Funny)
The more I think about it, the more I think your post should read
"...disgusting, inexcusable, and potentially hilarious."
Re: (Score:2)
I agree. Headlines with "SQL injection" make me chuckle; but including Travelocity.com and other high profile sites in the victims list is priceless!
-dZ.
Re: (Score:2)
Prepared (or parametrized) statements are an easy and absolute defense against SQL injection attacks.
They're actually not an absolute protection. If anything you are doing ends up working with stored procedures that do concatenation internally, your prepared statements can still end up allowing a SQL injection.
Prepared statements are a very, very good idea that provides a lot of built-in resistance to SQL injection, but they're not bulletproof.
Re: (Score:2)
Well, of course, you should never underestimate the tenacity of stupid programmers.
Re: (Score:2)
Re:This disgusts me (Score:4, Insightful)
Kaspersky can't figure it out because a virus scanner can't fix a web application. Fixing SQL injections is beyond their realm.
Travelocity can't figure it out because their developers must suck. Travelocity is well-known because they have a decent service, not because the software that runs the service is really great software.
Re: (Score:3, Insightful)
Re:This disgusts me (Score:5, Insightful)
You're working off of the false assumption that security is about knowledge.
We know abundantly well exactly how SQL injection attacks occur, and we also have many tools at our disposal to -absolutely- prevent them. What we don't have is the cooperation or effort from programmers on a widespread basis. Many are simply too lazy to research and implement reasonable security measures. It's easier to pretend that there are no ways whatsoever that anything can go wrong with your code because when you tested it it worked right. This willfull turning a blind eye to well-established security caveats is what has given us this terrible and prevalent security problem. It's easier to write code that checks nothing, it's quicker to do so, and it requires less think-juice on the part of the lazy programmer.
Re: (Score:2)
It's easier to pretend that there are no ways whatsoever that anything can go wrong with your code because when you tested it it worked right.
Not if the QA guy is even halfway competent. I had a website tested recently by a pro, and the first thing he did was enter various horrible things into every textbox, including all of the fun variants of "DROP DATABASE". Then he started doing even worse things to the URL. If your web app can't stand up to things a human being can enter, don't expect to last long against the internet and script kiddies!
Re: (Score:2)
Kaspersky has, I can assure you; they just figured that there will always be stupid programmers out there doing crap, buggy code, and decided to help mitigate the consequences.
As for Travelocity, they probably hired cheap programmers or a third-party contractor who employs inexperienced code monkeys. Bad programmers are more common than you think!
-dZ.
Re:This disgusts me (Score:5, Insightful)
The idea of a SQL Injection attack is to pass a parameter in such a way that it changes the structure of the query itself. Typical beginner's SQL query:
This uses 'String Concatenation' to build a line of text from several smaller parts. The completed string is then, in this example executed by a database. A new query is dynamically created and executed based on the text passed to it. Thus, we are able to at this point change what query will be run. Form data:
So when the string is being put together, we get:
Certainly, even with no programming experience, one can see that the letter E will always be equivalent to the letter E. Thus, any validation of the password will return a false positive.
Prepared statements avoid this whole deal by only allowing you to pass parameters. The query is already set in stone. You cannot change how it basically works, only its criteria / filtering / etc. A prepared statement would execute basically:
Since the query does not change dynamically when it's executed as a prepared statement, you can't add your logical 'OR' operator after having broken out of your parameter. You just get no rows returned, as should be the case.
Re: (Score:2)
You'd think so, wouldn't you? It makes sense that such a widespread problem would have to have some sort of complicated solution.
Unfortunately, the reality is that the solution is in fact simple, but yes everyone *really is that stupid*.
Or the company is cheap, so they hire a crap programmer. This is the same as deciding you'd rather get hit than have any sort of minimum standard when it comes to your code. So they get hit. Not a huge suprise to anyone, except the security researchers, who get publicity by
Re: (Score:2)
Until your database gets dropped, then there's plenty of time, since you won't have those pesky customer orders to deal with :)
Install a proxy (Score:5, Interesting)
We had this problem a few months back at work. Old but necessary asp web sites kept getting infected. It only took a few hours to install a reverse proxy with mod_security on EC2 and we were in the clear.
Full story on my blog:
http://guillaume.filion.org/blog/archives/2008/05/i_love_ec2_and_rightscale.php [filion.org]
Re:Install a proxy (Score:4, Informative)
mod_security is a reactive security measure. It's blacklist based, which makes the classic error of attempting to "enumerate badness" [ranum.com].
While it's great if you've identified an existing threat to an application you cannot properly secure, it does nothing to protect you against future attacks using less obvious techniques.
mod_security alone is not an adequate solution. It's still necessary to proactively write secure applications in the first place, which means making sure you're never allowing raw, unfiltered/unescaped user data into places where it shouldn't go.
yet another ugly side of DRM (Score:3, Insightful)
"The toolkit is protected with a layer of digital rights management and appears to be sold mainly in China. "
this is why I don't believe in "Tusted" computing.
When software or hardware are used to take control of a computer away from that computer's owner bad things will happen.
Re: (Score:2)
lol,
... on an article about viruses. Yes well done, +1 Insightful. Never mind that trusted computing != DRM and that the most common use of TC is for security software, doh.
Chinese underground (Score:5, Funny)
Is it like Big Trouble in Little China, with the lightning ninjas and floating eye thing? Did they get Kurt Russel to help?
If so, that would be AWESOME.
Re: (Score:2)
This Relentless web attack sounds more like a Little Big Adventure to me.
No DRM trolls? (Score:5, Funny)
Where's the outrage?
Why aren't we demmanding an open source solution?
notSoGreat Firewall O' China (Score:2)
Sure! They can block users from nasty ol' Capitolist porn. But, do they keep users from attacking overseas networks? Noooooo.
Sorry. I'm in touch with my inner child today.
What a job description. (Score:2, Funny)
"researchers at SecureWorks have infiltrated the Chinese underground in an attempt to procure a copy of the stealthy new automated tool being used in the attacks"
I wish my job description sounded as exciting as this one.
Where's the vulnerability (Score:2)
I keep seeing "SQL injection", but injection into what? PHP? ASP? Plesk? Something else? Specific scripts, or the language engine itself?
Re: (Score:2)
"I keep seeing "SQL injection", but injection into what?" ...into anything that will then turn around and execute the tainted SQL query (dynamically generated).
SQL in the HTML...! (Score:2)
McColo? (Score:3, Insightful)
I wonder how many of the malicious servers the injected SQL dumped the users into were hosted on McColo - and are thus now not available?
Why Are There Even SQL Injection Attacks in 2008? (Score:2)
Seriously, SQL Injection is one of the simplest attack vectors to prevent. If you can't prevent SQL injection, you should not be allowed to write a web application.
Comment removed (Score:4, Informative)
Re:RTFA (Score:4, Funny)
Didn't you RTFA?
You must be new here, in spite of that two-digit user ID!
Re: (Score:3, Funny)
You must be new here, in spite of that two-digit user ID
He probably is new. I saw Slashdot UID 56 for sale on E-Bay about a month ago for 17 cents or 4 sticks of Trident.
Re: (Score:3, Informative)
Re:Kaspersky (Score:4, Funny)
Re: (Score:2)
Why do you say that? They patch ALMOST every hole within AT LEAST 8 years! http://tech.slashdot.org/article.pl?sid=08/11/12/199215 [slashdot.org] Sigh.
Re: (Score:2, Interesting)
Re:Kaspersky (Score:5, Insightful)
It's a bloody SQL injection attack. I'd like to see your virus checker automatically rewrite your web application to use input filtering.
What these people need is a real web application instead of some self-built PHP script - not a virus scanner, whether free or expensive.
Big Picture (Score:4, Interesting)
This is going to sound like a little bit of double speak but I'll remind you that Kaspersky found these attacks were happening. Also, they are studying the behavior. Furthermore, Kaspersky protects systems from nefarious things that attackers will do, regardless of how they get on the system. Nothing is perfect with Windows, but if you look at the options, Kaspersky is the best out there.
Now of course, if you want to insist that the attacks happen whether Kaspersky is running or not, you will be correct. But what you're not saying is how LIMITED the attackers are when trying to get past Kaspersky after they get on a system.
Noscript also helps, but isn't perfect either.
Re: (Score:3, Informative)
Sorry, I see we're talking about different user groups.
From the user perspective a virus scanner (and NoScript) will indeed protect you from installing malware on your computer, which may be downloaded from a hijacked website (XSS is a more common attack vector for that, but I've had an Invision forum hijacked via SQL injection too).
I was speaking more from the perspective of the web admin whose site gets defaced, who won't get around some lessons on secure input handling. ;)
Re: (Score:2)
Now that's an Anti-Virus software I'd pay for!
Re: (Score:2)
What these people need is a real web application instead of some self-built PHP script - not a virus scanner, whether free or expensive.
Uh, this exploit is targeting ASP/MSSQL.
Re: (Score:3, Interesting)
PHP is just as vulnerable to SQL injection as ASP...I think he was speaking in generic terms.
The problem isn't in the scripting engine. The problem is bad code. You can put a bad developer in front of system you want, and he'll still write bad code.
Re: (Score:2, Interesting)
You know, something just occurred to me. The biggest reason SQL injection attacks are so common is that SQL allows multiple commands per input line and allows you to comment out the rest of the line, neither of which is useful when called from a programming language (or really anywhere outside of dump/restore tools). If you built a custom SQL library that PHP/Perl/* linked into that would return an error and do nothing if it detects more than one command or a comment start character anywhere in a command,
Re:Kaspersky (Score:4, Informative)
Re: (Score:2)
Do you know what an SQL injection attack is?
Clue: It's not something an antivirus can ever protect people from.
No kaspersky for me (Score:4, Funny)
zsh% apt-cache search kaspersky
zsh%
Re:Kaspersky (Score:4, Informative)
You're not supposed to run them at the same time. They fight for control and eventually stalemate. Uninstall AVG and reinstall Kaspersky, but by now you may have damaged your system configuration. Kaspersky is pretty brutal if it gets unhinged, but it's unstoppable if you get it configured correctly.
Re:Kaspersky (Score:4, Insightful)
...AVG...
<mechanic>Well there's your problem.</mechanic>
Re: (Score:3, Informative)
Re: (Score:2)
I think you dropped this [instantrimshot.com].
Re: (Score:2)
Where's the "-1 fail"
In your heart, my friend. In your heart.
Re: (Score:2)
> PHBs are notoriously hard to kill.
Only if you're working for the ship's cook.
Re: (Score:2)
The post you read must have looked like this:
"Meanwhile, researchers at SecureWorks have infiltrated the Chinese underground using the alias of S00p3r-1337 in an attempt to convince them to e-mail a copy of the stealthy new automated tool being used in the attacks to viruscheckers@secureworks.com"
Which is weird because that's not what I saw...
Re: (Score:2)
Here's what I saw: maybe the crackers in general will be a little bit more careful now that this news came out. Maybe that will make SW's attempts at getting a copy of the tool harder.
The screwed up thing here is that no one needs to be trying to get it in the first place. Just prevent the damn SQL injection attack in the first place. Instead of looking at every single coding problem and saying "omg! i can parse this string by hand! yay!"
The fact that this a particularly nasty automated exploit does not mea
Re: (Score:3, Funny)
Chinkies broked the web. :(
Okay, now that there is a black president you realized that being racist against blacks would be unpatriotic ... so now you go after Chinese instead?
I for one (don't) welcome our new sino-phobic first-posting anonymous-coward overlords...