Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New SQL Injection Attack Fuses Malware, Phishing

kdawson posted about 6 years ago | from the trust-me-just-click-on-it-ok dept.

Databases 202

PainMeds tips a recent post in Secure Computing's research blog describing a new SQL injection attack that had infected thousands of MSSQL-based web servers by last weekend, turning them into malware delivery systems. The attack apparently rewrites the server's Web pages to include JavaScript which pushes malware to the visitor as if it were from the genuine site. Sites using Sybase might possibly be vulnerable, as it uses the same exploited syntax that MSSQL does. The post includes an example of the attack. Unlike most malware attacks, this one appears to originate from the site the user is actually visiting. From the blog: "'Similar to phishing, this attack takes advantage of the website visitor's trust in the site they are visiting. Instead of phishing for information, however, malware is sent to the client, which the client has a higher likelihood of accepting being from a trusted site... These web pages are associated with Web sites from around the world and supplying various content — including government sites, sales sites, real estate sites, and financial information sites among others."

cancel ×


Sorry! There are no comments related to the filter you selected.


Anonymous Coward | about 6 years ago | (#24574191)

echo 'show tables'|mysql slashdot|awk '{print "delete from " $1}'|mysql slashdot


ianare (1132971) | about 6 years ago | (#24574311)

sure, send piped UNIX commands to a javascript living in a MSSQL server ...


Bert64 (520050) | about 6 years ago | (#24574357)

Yes, with MSSQL you want to send:

exec xp_cmdshell 'del c:\*.*';

Or something similar, my grasp of dos commandline is rather weak, being primarily a unix user.

Who the hell thought it would be a good idea to allow users of an sql database the ability to execute arbitrary system commands?

Re:DELETE FROM USER* (1, Insightful)

Anonymous Coward | about 6 years ago | (#24574595)

By default, that is switched off.
So, no - you can't do that out of the box.

Re:DELETE FROM USER* (2, Interesting)

liquidpele (663430) | about 6 years ago | (#24574715)

Only starting in SQL Server 2005 iirc... Do you have any idea how many people use MSDE 2000 still??? It's scary.

Re:DELETE FROM USER* (2, Informative)

Anonymous Coward | about 6 years ago | (#24575329)

Only starting in SQL Server 2005 iirc... Do you have any idea how many people use MSDE 2000 still??? It's scary.

Absolutely not true. xp_cmdshell is denied by default in MSDE 2000 (and sql server 2000).

Incidentally, there is nothing inherently wrong with MSDE from a security standpoint. MS still releases patches for it. MSDE is a solid, ACID-compliant database (unlike a popular open-source database that also starts with the letter M). MSDE is the same robust database engine as its bigger brother, sql server 2000.

MSDE does have size limits (2 gig per database) and performance limits (more than 5 concurrent threads and it starts to slow down), but if those limits are acceptable for your application it's great.


beckerist (985855) | about 6 years ago | (#24575309)

format c: /q

and wouldn't that only work at formatting the server?

Re:DELETE FROM USER* (2, Informative)

LordSnooty (853791) | about 6 years ago | (#24575547)

Either way, blitzing the server is probably the worst way to turn it into a malware delivery bot.


Anonymous Coward | about 6 years ago | (#24575313)

exec xp_cmdshell 'rm /s C:\';

Re:DELETE FROM USER* (0, Flamebait)

Corwn of Amber (802933) | about 6 years ago | (#24574327)

Bah, only morons use MSSQL anyway. Who wants to pay for that when any neighbourhood kid with eight hours of free time can go on the scary machine, enact an esoteric ritual and you've got a LAMP stack?

Not really new (5, Insightful)

liquidpele (663430) | about 6 years ago | (#24574229)

They're just inserting the javascript directly into the websites's content, instead of putting an iframe to a hacked server to then run the javascript...

Seriously, did anyone *not* see this coming? I always wondered why they didn't do this to begin with... I guess so they could update the malware being distributed since it was all from a central location.

Re:Not really new (1, Funny)

Anonymous Coward | about 6 years ago | (#24574271)

No I didn't see this coming you insensitive clod.. I'm blind.

Re:Not really new (1)

linal (1116371) | about 6 years ago | (#24574317)

Although this isn't really new why do SQL injection attacks still occur. There are countless [] articles [] on [] how to protect yourself. Or do the webmaster simply not care?

Re:Not really new (3, Insightful)

jellomizer (103300) | about 6 years ago | (#24574473)

Why do you assume all code is new. Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix. Not really taking into account that the interface is not controlled by the server anymore. But can be easily altered by the client. being that the bug is threw Microsoft SQL there is a higher chance that it is threw Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe. As well a bunch of people have a poor understanding on how to use SQL, they just think it is bit more optimized version of a flat file. Where the hard stuff are using joins. So they figure well this data isn't that important.

Re:Not really new (1)

jellomizer (103300) | about 6 years ago | (#24574535)

addendum: constraints often occur too they work to get a proof of concept and run out of money to harden their code. In theory they should have harden it before hand however, sometimes those methods get in the way of proof of concept testing, and their not paid for that. Also there is a huge number of developers who have no idea about SQL injection errors they just never thought about it before. Not all developers are on top of their game. They go to work and leave, and don't bother to learn anything new.

Re:Not really new (3, Insightful)

Anonymous Coward | about 6 years ago | (#24574801)

There is also deliberate gross misconduct. A lot of the code is written by outsourced divisions, I-9 lackeys, or contractors who will be long gone by the time someone discovers the SQL injection bug. Most companies don't pay for audits of their Web code, nor do they care to.

Sad thing is that MS is doing their best to prevent this, but they still get blamed for what their customers do (or fail to do.)

Re:Not really new (3, Insightful)

jellomizer (103300) | about 6 years ago | (#24574915)

Don't blame the contractors, If they mess up it is usually do to bad management on the company. Having worked as a contractor/consultant I can tell you when there is good management at the company I produce really good work. When there is bad management my work isn't that great. The case of leaving a bug and being long gone has a flaw. Because people want return business and a good name. Doing a Hit and run of coding doesn't allow for a good professional credentials. But with contractors they are often under the gun far more then W2 employees to be cost efficient, any work they do needs to be approved as the company doesn't want to pay for extra non-speced work, and if that spec doesn't cover SQL injections or security and they do the right thing and bring it up, bad management will say it isn't an issue and just do what is speced, thus causing the problem. If they did go and take an extra 4 hours to make it secure they will not get paid for it. If the manager was smart and listed to the advice then good quality code can be released.

Re:Not really new (1)

billcopc (196330) | about 6 years ago | (#24574813)

Sure, blame the coders... we're partly at fault here, but a bigger piece of the problem is that such arbitrary code is allowed to be executed at all, with no way to disable it.

You can restrict queries, but there's no option to disable EXEC. That, to me, is a grave oversight. What's worse is the SQL folks sternly refuse to implement such a feature.

Re:Not really new (2, Informative)

Bert64 (520050) | about 6 years ago | (#24574387)

Yes, nothing new at all...
People used to do this by compromising the site in other ways, and inserting their malware rather than defacing the site... Some subtle malware tagged to a site is a lot less obvious than a blatant defacement so it lasts a lot longer and gets more hits.

Re:Not really new (1)

ShieldVV0lf (1343419) | about 6 years ago | (#24574477)

The problem with Javascript is that it is inherently insecure. The Javascript model created in the 90's did not adequately address security as no one ever even thought that malware would exist.

You may want to rethink what you know about modern-day Javascript after reading this article [] .


We implemented some simple but useful policies in the context of resource usage and secrecy, and tested the prototype with them on a number of web pages, including malicious or exploited pages from the real world, well-intended pages which might raise false positives, random popular pages, and some pages specially written to explore the boundaries of existing tools. Here we focus on two policies for demonstration purposes.


Anonymous Coward | about 6 years ago | (#24574701)

Die mund halten!!

Re:Not really new (1)

tha_mink (518151) | about 6 years ago | (#24574821)

They're just inserting the javascript directly into the websites's content, instead of putting an iframe to a hacked server to then run the javascript...

No, they're still using a central location. It's only a script tag instead of an iframe. Same idea though.

Re:Not really new (0)

Anonymous Coward | about 6 years ago | (#24575485)


malware + phishing = (4, Funny)

Anonymous Coward | about 6 years ago | (#24574233)

malware + phishing = phalware?

Re:malware + phishing = (0)

Anonymous Coward | about 6 years ago | (#24574337)

I was hoping for mishing.

Re:malware + phishing = (1)

Freeside1 (1140901) | about 6 years ago | (#24574461)

'phishware' must've been too obvious

Re:malware + phishing = (2, Funny)

FooAtWFU (699187) | about 6 years ago | (#24574519)

Phailware. You get it from web sites who phail at security?

Re:malware + phishing = (0)

Anonymous Coward | about 6 years ago | (#24574521)

no, it is Malwishing.

Re:malware + phishing = (1)

Seraph787 (859123) | about 6 years ago | (#24574593)

I prefer the term
MAlware + phiSHING = mashing!

Re:malware + phishing = (1)

hostyle (773991) | about 6 years ago | (#24575005)

mallic phacking ?

Re:malware + phishing = (1)

cleatsupkeep (1132585) | about 6 years ago | (#24575131)

mallic phacking ?

Phallic macking? What?

The internet has gone to the dogs. (0)

Kingrames (858416) | about 6 years ago | (#24574259)

No wonder my dogs are always barking at the Squirrels.

Re:The internet has gone to the dogs. (1)

Allicorn (175921) | about 6 years ago | (#24574825)

The internet was always populated by dogs - just that nobody knew.

fixes? (0)

Anonymous Coward | about 6 years ago | (#24574269)

Anyone know of a good way to scan through all databases and tables on a server to search for any code? Currently I know 'we' have around 200 databases with over 10,000 tables total. It would be bad to see any of these DBs compromised.

Re:fixes? (2, Informative)

Tridus (79566) | about 6 years ago | (#24574549)

Take a look at the article from this comment, it has a "use at your own risk" procedure. You could probably modify it appropriately. []

Re:fixes? (2, Informative)

johnathan (44958) | about 6 years ago | (#24574933)

I've used that procedure for a couple clients with success. There are two things you have to consider, since if you've been hit once, you've probably been hit multiple times.
  1. Some fields have probably hit their maximum length, causing the last injected script tag to be truncated, so this procedure will miss them. Clean these up manually so that the field ends in "</script>" (the closing tag for the previous injected script tag). Of course, you could just manually clean up the whole field at this point, but I found it easier to just fix the end and then let the SQL script do the rest of the work.
  2. You'll need to execute the procedure multiple times, since each time will only remove one script tag from each field.

Re:fixes? (0, Redundant)

morgan_greywolf (835522) | about 6 years ago | (#24574731)

1. Install *nix
2. Install PostgreSQL
3. Convert tables from MSSQL to PostgreSQL
4. ???
5. Profit!

Re:fixes? (1)

Tridus (79566) | about 6 years ago | (#24575025)

4. Wait for someone to realize your code still has SQL injection vulnerabilities, and just write an attack query in PGSQL syntax instead.

Re:fixes? (1)

domanova (729385) | about 6 years ago | (#24575477)

Correct. It's probably less likely with postgres, because it isn't as common, but I could write crap code on my linux/tomcat/postgres stack to let in such an attack. Well, I say I could, but I'd probably bite my arm off first.

Re:fixes? (-1, Troll)

Anonymous Coward | about 6 years ago | (#24575669)

How to fix a SQL injection vulnerability by morgan_greywolf:

1. Install *nix
2. Install PostgreSQL
3. Convert tables from MSSQL to PostgreSQL
4. ???
5. Profit!

You're the sort of person that solves frequently blowing fuses in your house by sticking a penny across the fuse contacts, aren't you?

Congratulations on having your brilliance immortalized on Slashdot.

Re:fixes? (2, Funny)

liquidpele (663430) | about 6 years ago | (#24574797)

declare @wtf varchar(100)
declare holyshit cursor for select name from
sysobjects where xtype='U'
open holyshit
fetch next from holyshit into @wft
begin select * from @wtf where thehtml like '%code%'
print 'please kill me'
fetch next from holyshit into @wtf
close holyshit
deallocate holyshit

Re:fixes? (1)

DeAgua (707093) | about 6 years ago | (#24575303)

That "queer"y wouldn't even pass a syntax check.

Saw this 1 month ago (1, Interesting)

Anonymous Coward | about 6 years ago | (#24574273)

I saw attacks that were the same as this 1 month ago in our webserver logs

Re:Saw this 1 month ago (1)

hostyle (773991) | about 6 years ago | (#24575083)

You may have. Did it use generated iframes to inject the malware like the previous versions? Or inline javascript like this one? Very similar, but probably enough difference to make it worthy of a new alert.

Re:Saw this 1 month ago (1)

Target Practice (79470) | about 6 years ago | (#24575321)

I just like knowing others are seeing this. I should really be more lazy, though. I spent yesterday morning casting those numbers (and variants I found in my logs) to CHARs in MySQL to see what the crap they were trying to do.

Ah, /.! Another reason to just stop trying.

Attempts made on our systems... (2, Informative)

Anonymous Coward | about 6 years ago | (#24574291)

Our web apps got hammered with this over the weekend... our simple but effective SQL injection block kept them out, but it is also comforting to know that even if it had not, it would not have worked on good ol' MySQL 4.1

Also, for what its worth, all of the IPs (100s of them used in the course of 3 days) trace back to ISPs based in Beijing. Hmmm...

Re:Attempts made on our systems... (3, Funny)

corsec67 (627446) | about 6 years ago | (#24574347)

Also, for what its worth, all of the IPs (100s of them used in the course of 3 days) trace back to ISPs based in Beijing. Hmmm...

The Olympics are trying to hack your webserver?

I wasn't aware that Server CTF was an Olympic sport.

Re:Attempts made on our systems... (2, Funny)

isomeme (177414) | about 6 years ago | (#24574811)

In Communist China, the Olympics hacks you!

Re:Attempts made on our systems... (1)

74nova (737399) | about 6 years ago | (#24575561)

all your medals are belong to us

Re:Attempts made on our systems... (1)

DotNetZombie (1343503) | about 6 years ago | (#24575495)

Our system got hit a couple months ago... since then the attacks have lessend and I only log a few IPs every couple days or so. I noticed a lot of the attacks did come from China as well, however, a good portion of them came from Egypt, New York, and even some in Australia. So far I've logged attacks from 4 continents! :) There's unity in everything :)

$conn_id = mysql_connect("") (2, Funny)

Aardpig (622459) | about 6 years ago | (#24574325)

UPDATE management SET perf_review='Epic Fail' WHERE jobtitle='MSSQL Engineer';

Re:$conn_id = mysql_connect("") (5, Insightful)

Anonymous Coward | about 6 years ago | (#24574443)

You'd have to be an idiot programmer to have a site succumb to this... It's not even "microsoft specific".

It would affect any site that takes request parameters and passes them straight through to the db engine (well, not specifically this syntax, but the concept behind the attack).

To be fair to Microsoft (heresy here, I know) built-in validation throws an exception.

In other words, not only would a programmer have to use raw request string data with the db, he would also have had to specifically disabled the default page validation. In other words, an idiot.

My website got hit with this type of attack last week, and the attempts were all rejected by the default validation. Even if the default validation had got past, all of the database queries use parameterized stored procedure calls which pretty much ignore this kind of crap anyway.

Still, it's made me think more about security and additional parameter validation. Maybe the next attack will be a bit sneakier..

Re:$conn_id = mysql_connect("") (1)

Knux (990961) | about 6 years ago | (#24574639)

The SQL statement itself scans through all of the tables in the database

correct me if i'm wrong...

but even if the programmer is in fact an idiot, the sql injection attack shouldn't be able to scan the data dictionary and retrieve all tables, so it could be able do corrupt the data in each and every one of them. this piece, i think, is MS fault.

Re:$conn_id = mysql_connect("") (0)

Anonymous Coward | about 6 years ago | (#24574657)

You are wrong.

Re:$conn_id = mysql_connect("") (0)

Anonymous Coward | about 6 years ago | (#24574761)

That's not a microsoft problem.
I don't know the structure of other dbs such as Oracle and mysql, but I assume they store the user table structure in system tables?

If that's the case then they could be affected too.

It's the developer's responsibility to ensure that the sql logon account used to access/update the database has only the necessary permissions, not Microsoft's.

Note: I'm not a huge microsoft fanboi, but it really isn't their fault that developers using their tools write crappy code.
That happens on linux too!

Re:$conn_id = mysql_connect("") (1)

dvice_null (981029) | about 6 years ago | (#24575037)

> If that's the case then they could be affected too.

But for some reason they are not. This means that either
a) It is Microsoft's fault after all
b) People who use MSSQL write more crappy code than those who use e.g. MySQL
c) Attackers only target MSSQL for some unknown reason. Which means that it is less secure by default.

So, which option would you like to take. Or do you see some other options?

Re:$conn_id = mysql_connect("") (0)

Anonymous Coward | about 6 years ago | (#24575371)

option a:
    - Microsoft has a lot of boxes out there. If you're writing this kind of thing, you'll get a good hit rate. It's Microsoft's fault if you blame them for having a lot of people using sql server.

Not only that, but Microsoft (whether you like them or not) make some extremely good developer tools.
That lowers the barrier for entry: In other words, there are more idiot level programmers using Microsoft stuff because the tools are easier to use.

Option b) See above.

Option c) strawman argument. See option a)

Of course, if you're determined to make it Microsoft's fault you can, but I strongly suspect that the same type of attack would be common on LAMP if the barrier for programmer entry were as low.

Re:$conn_id = mysql_connect("") (2)

dvice_null (981029) | about 6 years ago | (#24575659)

According to this study, there are more MySQL users than there are MSSQL users. So there goes down pretty much all your arguments (unless you can provide better source for database market share): []

> there are more idiot level programmers using Microsoft stuff

Can't disagree with that argument.

Re:$conn_id = mysql_connect("") (1)

Tridus (79566) | about 6 years ago | (#24574765)

It looks like its creating a procedure and then running it, which can do that. Technically I guess you could blame MS, but it'd be like blaming them because a third party used Visual Studio to write a program with a buffer overflow, which got exploited and was used to run a spambot.

They've been giving people the tools to prevent SQL injection for a very long time now. That its still happening isn't their fault, any more then its the fault of <language that lets people run direct SQL>.

Take a look down here for more info: []

Re:$conn_id = mysql_connect("") (1)

rdavidson3 (844790) | about 6 years ago | (#24575645)

More like a T-SQL problem than a MS problem.

Sigh... (1)

jellomizer (103300) | about 6 years ago | (#24574333)

Why is using stored procedures so taboo. It is a very easy way to protect against most SQL Injections. It also allows you to share the database logic to different apps as well, allowing more integration across your other apps. update x set x.y=@varname where x.j=@find is so much more secure then sql_exec("update x set x.y='"+varname+"' where x.j='"+find)

Re:Sigh... (1, Insightful)

Anonymous Coward | about 6 years ago | (#24574377)

It's so easy to protect from sql injection without using stored procedures too. Only someone not understanding the details involved would claim otherwise.

Re:Sigh... (1)

BlackSnake112 (912158) | about 6 years ago | (#24575393)

If your a good DBA you always want to know how a web site/app/developer/etc is accessing your database. You only give that person/app/what ever the access it needs to work no more. If you can control how they update, insert, select, and delete data from the system the better off you are. The developers may not like it, but you are doing your job if you make sure that they cannot take down or damage the database system or the integrity of the data in the system.

Most likely every developer and contractor is going to disagree with me on this. Then again, are those people the ones whose head is going to roll if the database system is not working as the bosses expect it to?

Re:Sigh... (2, Insightful)

Anonymous Coward | about 6 years ago | (#24574453)

The whole SP vs inline sql debate is an entirely different kettle of fish (btw stored procs suck =P). The easiest way to protect against sql injection is parameterise your sql (yes you can do that with inline sql!). Next easiest thing - realise that everything from outside the system is essentially user input and treat it as such.

I use .NET / Sql Server on a daily basis - it isn't hard to make these kind of attacks a non-event, the problem is the multitude of drag and drop developers who have nfi what they are doing. If only software development required a license to practise =)

Re:Sigh... (1)

PotatoFarmer (1250696) | about 6 years ago | (#24574597)

Using parameterized queries with bind variables is even easier, and doesn't split your logic between the app and database tiers.

Re:Sigh... (1)

jellomizer (103300) | about 6 years ago | (#24574697)

It really depends on the setup though. For the most part I am working in places with a hefty Database Servers and apps that often do the same thing with different interfaces. For this case a lot of stored procedures and interface shells of apps tend to do the trick, as updates update all the systems at once and there is a single location to adjust security. For cases where you are working on big app with a small database server for its use. Just parameterizing queries are ok. But I found using stored procedures makes you look like a mirical worker as for most problems you can fix very quickly and it is live and up to date without many deployment issues (this is with .NET, working with PHP on the server doesn't really have those problems)

Re:Sigh... (1)

PotatoFarmer (1250696) | about 6 years ago | (#24574879)

I agree, it does depend on your requirements, and it does sound like stored procs are the appropriate choice for your environment. That being said, if you ever need to support more than one database you're kinda screwed if you're heavily invested in stored procedures. I've run into this sort of problem before, and it isn't pretty.

Re:Sigh... (1)

grassy_knoll (412409) | about 6 years ago | (#24575223)

You can also run into problems in supporting multiple databases without using stored procedures.

DB specific functions can cause a similar amount of grief. Like porting SQL Server code to Oracle, then getting errors when trying to use a GETDATE() function.

Re:Sigh... (1)

PotatoFarmer (1250696) | about 6 years ago | (#24575451)

True. Date functions are not as portable as they probably should be. Artificial key generation and LOB allocation tend to be very specific as well.

I'm not saying that using stored procedures are avoid-at-all-costs bad, or that not using stored procedures means your app is instantly portable between Access and Oracle and everything in between, but it's been my experience that stored procedures, functions, and triggers are the hardest thing to migrate between different database types.

Re:Sigh... (1)

ca111a (1078961) | about 6 years ago | (#24575475)

because sometimes your app has to work with multiple DMBS

I got Quigley! (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24574367)

Fellas, I was looking for some CowBoyNeal non-animalsex related videos, and I found this cool photo directory. Of'course, it was through GOOGLE with a search for "index of" and my things followed by a "name last modified" and/or "apache." []

Someone hacked their server homepage, so everything is exposed. Get it free while it'snot!

Am I in a time warp? (4, Informative)

johnathan (44958) | about 6 years ago | (#24574393)

This attack has been going on for months... []

Re:Am I in a time warp? (1)

ShaunC (203807) | about 6 years ago | (#24574961)

Thanks, I was just about to go dig that up myself. Every couple of days, someone new shows up on DZone claiming to have "discovered" this "new attack" (typically by having been a victim of it), and the meme makes the rounds yet again. Quite frustrating hearing so many cries of wolf.

Re:Am I in a time warp? - (0)

Anonymous Coward | about 6 years ago | (#24575501)

No. You're right. This isn't "new(s)" at all. I was blocking against this at least 4 months ago, if not longer. Anyone silly enough to not parse their Querystring data before allowing it to be executed against the database *will* be impacted by this.

On the upside, the SQL used in the injection (convered to Hex) was pretty impressive. These micreants ought to get a day job...

Major Canadian bank was hit a couple of weeks ago (1)

OhBoy! (842699) | about 6 years ago | (#24575605)

TD Canada Trust (one of the largest Canadian banks) had one of their servers infected by this virus for at least 48 hours before taking the server down. I tried through a few different channels to get them to notice they are infected, but it took a day of effort until they reacted. And they decided to not alert their visitors that there had been a problem. In my world, a financial regulator would be all over their ass about something like this. You can see gory details at []

We got hit a few weeks back (5, Interesting)

G33kDragon (699950) | about 6 years ago | (#24574459)

We were added to the attack list a few weeks back, and one of our largest, most popular websites was hit. Apparently, the developers had never thought to sanitize their data, and we had multiple vulnerabilities throughout the site.

I implemented a transparent reverse proxy server running Apache with mod_security that helped prevent further attacks from getting through, but the developers finally saw the error of their ways and converted hundreds of inline SQL calls into stored procedures.

Since we were added to "the list", I've been seeing the same attack happen across multiple pages every 20 seconds, so they are definitely not letting up anytime soon.

Re:We got hit a few weeks back (1)

pembo13 (770295) | about 6 years ago | (#24574641)

Stored procedures? Or prepared statements? Just asking.

Re:We got hit a few weeks back (2, Interesting)

CastrTroy (595695) | about 6 years ago | (#24574689)

Let me guess, they converted

"Select * from Users Where UserID='" & Request("UserID") & "'"


exec('SELECT * FROM Users WHERE UserID=''' + @UserID + '''')

Using stored procedures doesn't solve anything if developers don't actually understand what the problem is. You don't even need to use stored procedures. Simply switching to prepared statements would have fixed the problem.

Re:We got hit a few weeks back (1)

RingDev (879105) | about 6 years ago | (#24574873)


On a side note, I ran into a similar situation a few days ago. I was toying around with the idea of writing my own forum years ago when I was in school with way too much free lab time. I was smart enough to use validate parameters before passing them to stored procs, but when I ran out of time to play with it I just pulled down the posting and listing pages, so that people going to the website could no longer browse or post. What I forgot to pull down though, was the actual script that posted pages. Someone had managed to stumble across it and was using it to submit posts containing javascript redirects. Then they would link directly to the post page. The result being that they had managed to use my site as a un-blocked re-director. And since I had pulled off all the public facing pages for it, I didn't even notice it until I went to do some database maintenance and found an absurd number of posts in the forum tables.

Not a SQL injection issue, but another example of how a smart person can make a dumb mistake ;) And yes, I pulled down the script and post viewing page immediately before scrubbing the database.


Re:We got hit a few weeks back (1)

hostyle (773991) | about 6 years ago | (#24575147)

+1 Eat more Smarties

Re:We got hit a few weeks back (1)

G33kDragon (699950) | about 6 years ago | (#24575267)

The original developers were more like glorified designers who didn't know anything about SQL to begin with. The team that fixed the holes were the real developers who make security a priority and who really know there stuff when it comes to SQL. I know they're smart enough to do it right the (albeit) second time. :)

Re:We got hit a few weeks back (1)

hypersql (954649) | about 6 years ago | (#24575493)

Using stored procedures doesn't automatically protect you. For example, this is still insecure:

stat.executeQuery( "CALL GET_USER('"+name+"', '"+password+"')");

Using parameterized queries / prepared statements / bind variables works. But that means code reviews.

There are solutions that don't require code reviews at all, for example enforcing the use of bind variables [] . Even better is to use LINQ or the Java variant of it, JaQu [] . Disclaimer: I am the developer of the open source database H2.

Not new at all (3, Informative)

dzfoo (772245) | about 6 years ago | (#24574635)

This trojan, called Asprox or Danmec, has been around for a few years. It was originally intended as a Spam distribution system but I believe that sometime in 2007 an SQL Injection tool was installed via its botnet. It has been doing the rounds every so often on the Internet since at least January. [] []


Why the missing quotation mark? (2, Interesting)

Sloppy (14984) | about 6 years ago | (#24574655)

I just looked and see this in my logs too; looks like they started on August 6 over here.

What's funny is that it looks like they're trying the attack in pairs: once in the "classical" quotation mark form (GET /index.php';SQLCOMMANDSHERE) and then again without the quotation mark (GET /index.php;SQLCOMMANDSHERE). How is that second form supposed to get executed? They've gotta be trying it for a reason.

Re:Why the missing quotation mark? (2, Informative)

Rearden82 (923468) | about 6 years ago | (#24574809)

I know MySQL permits un-quoted integers, as in "SELECT * from foo where foo_id=42".

In that case your first example would be adding an opening quote, so the injection would fail. Perhaps MSSQL is even more lenient and lets you get away with un-quoted strings as well.

Re:Why the missing quotation mark? (1)

Sloppy (14984) | about 6 years ago | (#24574855)

Oh, of course. It's for numeric queries. I feel like an idiot for not seeing that. Thanks. :-)

Re:Why the missing quotation mark? (1)

bhsurfer (539137) | about 6 years ago | (#24575001)

No, MSSQL doesn't let you use unquoted strings. When you decode the string the attack is sending in you will find quotes around info the it's sending into the sysobjects.xtype parameters.

It's a pretty interesting attack, really. It gets around sql-scrubbing code by sending the quotes in as hex, and it only runs the update code to append the javascript on char, varchar, ntext & nvarchar fields, at least on the versions of it i've seen.

i won't get too redundant on the "you should use stored procs" thing, except to say that non- "EXEC" type stored procs would prevent this...

Re:Why the missing quotation mark? (1)

chrisbro (207935) | about 6 years ago | (#24574829)

Some sort of strange logging where it's saving all requested page URLs straight to a DB? That's about all I can muster.

Re:Why the missing quotation mark? (1)

Corwn of Amber (802933) | about 6 years ago | (#24574945)

Because they're *exactly* as lazy and stupid as the morons who wrote MSSQL in the first place, to say nothing of the brain-dead zombie who explicitly allowed unsanitized user input.

They're trying to insert that command, and it *might* need to be escaped by a ' before it... or has needed to be escaped in a version as ancient as the trojan they're pushing... go figure. Why? Because it's safe. It's safe for them, I mean - I mean, it's almost impossible to figure how to escape characters in UNIX Bash/sed/awk regular expressions, in what order they'll be interpreted, how they'll be expanded, and such.

Re:Why the missing quotation mark? (0)

Anonymous Coward | about 6 years ago | (#24575091)

It's for numeric parameters or if a developer used a field name directly from a URL variable in an order by clause.

Web Security Consultant / Database Expert Needed (1, Funny)

Anonymous Coward | about 6 years ago | (#24574713)

I saw a post in the "best of" section of craigslist from early July that described the same attack from the article. The victim included some great documentation of the attack:

So, to recap... (1, Informative)

seanonymous (964897) | about 6 years ago | (#24574763)

Users of Microsoft operating system who use Microsoft's browser may be at risk from malware served by infected Microsoft servers.

Re:So, to recap... (1)

hostyle (773991) | about 6 years ago | (#24575245)

    user FROM users
    os_id IN (SELECT os_name FROM os_list WHERE vendor = 'Microsoft' OR vendor = 'Bob')
    user_browser IN (SELECT browser_name FROM browser_list WHERE vendor = 'Microsoft' OR vendor = 'Bob')
    1 = 1''--DROP users; --DROP os_list; --DROP pants;

Broken? (1)

MLCT (1148749) | about 6 years ago | (#24574817)

It seems with each passing year that the web is becoming more "broken".

Perhaps the problem is too many groups are attempting to use it as if it is a fail-safe system - banks, corporations, financial institutions, governments. It was never designed to be fail-safe. Frankly if they had treated it more like a the "wild west web" and less like a "cheaper and easier platform for advertising/cost-cutting" then we wouldn't be in this mess.

Answers on a postcard as to how to fix it.

Re:Broken? (1)

CorporateSuit (1319461) | about 6 years ago | (#24575135)

This has nothing to do with the web becoming more broken. It's simply a matter of SQL-injection evolution. Before, when every idiot web developer/dba would use sa for the database permissions on a website, the popular thing was to reformat the server harddrives (or in less-malicious cases, just reboot the server every now and again for laughs)

Since then, using sa as the iuser became more and more ostracized, but complete sql injection protection was still not implemented across some older code in many sites, so people have tried to find the most fun way to manipulate such available windows. Right now, the flavor of the day is apparently injecting javascript (as was popular back during the XSS days of about 4 years ago)

Now, the DNS vulnerability that doxpara research was warning everyone about last month is new and internet-breaking, but this is just more of the same old shenanigans with assorted flavors -- something that any semi-vigilant non-idiot has protected his site against for 5+ years.

Queue The MSSQL Bashing (2, Insightful)

TheNinjaroach (878876) | about 6 years ago | (#24574875)

I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..

Get out of the 1990s man! (1)

BitterOldGUy (1330491) | about 6 years ago | (#24575649)

I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..

Man, that is sooo late 90s and early 00s.

/. is becoming a platform independent idiot basher. Whcih is good; in a way. Unfortunately, they don't take into account that folks are human; many times they're hired for one thing and then have go and develop or port an app to the web; are trying to learn new skills and screw up a web app because they've been developing corp intranets for the last decade and that's all they've been doing; /. posters are geniuses and they would have NEVEER made such a stupid error regardless of platform; all proprietary platforms are evil and therefore promote such stupidity; some of us are great at the "big picture" and horrible with the details; some of are great with details but miss the "big picture"; did I mention that we're all human and fuck up now and again; and I ran out of things to say.

This isn't really that new (1)

wmbetts (1306001) | about 6 years ago | (#24574911)

I've seen it done before to generate backlinks for spam websites. They'd hack several websites via sql injection and insert "hidden" links to the sites to gain search engine ranking.

This is from a couple of months ago, afaik (0)

Anonymous Coward | about 6 years ago | (#24575087)

Disabling redirects doesn't help (0)

Anonymous Coward | about 6 years ago | (#24575385)

I'm afraid to say any more but I may have invented this hack, but it was for a marketing company in 1998 so its okay. :)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>