Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Mass Hack Infects Tens of Thousands of Sites

Posted by kdawson on Tue Jan 08, 2008 08:09 AM
from the stay-safe-out-there dept.
Security The Internet
An anonymous reader writes "Tens of thousands of Web sites have been compromised by an automated SQL injection attack, and although some have been cleaned, others continue to serve visitors a malicious script that tries to hijack their PCs using multiple exploits, security experts said this weekend. Hacked sites included both .edu and .gov domains, the SANS Institute's Internet Storm Center reported in a warning posted last Friday. The ISC also reported that several pages of security vendor CA's Web site had been infected. Roger Thompson, the chief research officer at Grisoft, pointed out that the hacked sites could be found via a simple Google search for the domain that hosts the malicious JavaScript. On Saturday, said Thompson, the number of sites that had fallen victim to the attack numbered more than 70,000. 'This was a pretty good mass hack,' said Thompson, in a post to his blog." By Sunday a second round of the same attack had infected over 90,000 servers.
+ -
story

Related Stories

Submission: Mass hack infects tens of thousands of sites by Anonymous Coward
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Mass Hack Infects Tens of Thousands of Sites 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • ...those of you who thought "Awesome!"

    I am no fan of malicious hacking, but my inner geek always stirs when I read something like this, much like watching someone in the real world accomplishing an amazing but insane feat, like those guys with the squirrel suits base-jumping, or something *cough*

    Question, where any *nix or L*X machines compromised? Might be a dumb question, so bash me all you want if it was...

    • Re:Okay Hands Up... (Score:5, Insightful)

      by ricebowl (999467) on Tuesday January 08 2008, @08:25AM (#21952806)

      I don't know about "awesome," my first thoughts were along the lines of "oh...for fuck's sake..." and "how do I check?"

      While I share your appreciation of feats, I'd prefer the feat achieved to be a positive application of the knowledge rather than a mass-hack.

      But hey; that's just me being a grumpy old folk I guess.

    • Re:Okay Hands Up... (Score:4, Insightful)

      by slashbob22 (918040) on Tuesday January 08 2008, @08:26AM (#21952812)

      Question, where any *nix or L*X machines compromised? Might be a dumb question, so bash me all you want if it was...
      Considering it is a SQL injection attack I would assume that any system (of whatever OS) which is running a SQL database and is not scrubbing their input is vulnerable.

    • Re: (Score:2, Informative)

      by fmobus (831767)
      TFA guesses the exploit is a simple SQL injection where the injected code consists of calls to MS SQL Server's sysobject calls. I imagine this would give the attacker some file system access, allowing for injection of script tags pointing to the attacking javascript, and so on. This is a clever attack, once again allowed only by MS insistence in allowing things like an SQL Server to execute stuff not related to its task. Note that, while this is convenient and useful, it should never be allowed by default.

      • Re: (Score:2, Interesting)

        by AndGodSed (968378)
        Ah there you have it then.

        Cue the chorus; "Windows machines are only attacked because there are so many users..."

        Sheesh, forgetting that 70% of servers run Linux...

          • Re: (Score:3, Insightful)

            by mhall119 (1035984)
            Nobody seems to know how the malicious code actually got into the server in the first place. Simple SQL injection is definitely a prime suspect, but it's also possible that there is some flaw in SQL Server's processing of properly parameterized code that still allows the tainted user-input to be executed.

      • Re:Okay Hands Up... (Score:5, Informative)

        by pwilli (1102893) on Tuesday January 08 2008, @08:37AM (#21952932)
        It was even simpler than that (according to TFA):

        1. SQL-Query for all tables in the database
        2. Search for text-columns in table
        3. add script-tag to every entry in those columns
        4. hope at least some of those entries get included into the webpage without filtering (or escaping) the injected HTML

        No need for FS access or root rights (as another ./er suggested), but also not really spectacular creative.

          • Re:Okay Hands Up... (Score:4, Insightful)

            by anotherone (132088) on Tuesday January 08 2008, @10:59AM (#21954812)
            ah ok let me just look this up on the vulnerability chart here ok, your server is Linux... very good, very good your databases are all only accessible to localhost, ok looks like you are EXACTLY as vulnerable to SQL injection as everyone else. Running Linux and preventing remote users on your database does NOT protect you. If you have a script on your server that doesn't sanitize even one input, you are just asking for trouble. you WILL get hacked sooner or later.

      • Re: (Score:3, Interesting)

        by Bert64 (520050)
        Or they could have used the xp_cmdshell function of mssql to actually execute commands, often as the SYSTEM user and thus infected the servers themselves with the malware payload.

      • Re:Okay Hands Up... (Score:5, Informative)

        by Anonymous Coward on Tuesday January 08 2008, @09:14AM (#21953320)
        Helps to understand the database, doesn't it? The "sysobject calls" are just reads to the underlying tables that store the database schema. The injection attack uses sysobjects to determine what tables exist. They did use sysobjects which is specific to MS SQL Server and Sybase, but they could have just as easily used INFORMATION_SCHEMA which are a series of ANSI compliant views that contain the same information and work on virtually all databases.

        This attack has nothing to do with system access of the database server. Other than the fact that the specific exploit looks to sysobjects, there is nothing specific about this attack to MS SQL Server at all. This same kind of attack would work just as well on any other web server with an application using any other database. The problem isn't that the web server or the database has a vulnerability, rather that the specific web application itself does. SQL injection attacks are stupidly common because the people who write web applications, on any platform, simply ignore written secure programming conventions.

        For those who don't know what SQL injection is, it is caused when the web application does something stupid like concatenate unvalidated user input directly into a SQL string that is then sent to the database. This enables the attacker to pass user input which contains portions of SQL that will be also be sent to the database and executed under the security context of the web application. More often than not the developer who made this stupid mistake also made the stupid mistake of connecting to the database using significantly higher privileges than necessary, possibly even root/admin level privileges. Thus, the attacker can do virtually anything they want, from inserting new data to dropping objects and breaking the web application entirely, if they felt like it.

        Basic rules when developing a database-driven web site:

        1. Never concat input into SQL. In fact, avoid dynamic SQL entirely. Use stored procedures with parameter binding so that user input can never be used to inject SQL statements to the database.
        2. Always validate/encode user input. Even if you stave off SQL injection it's still possible for an attacker to attempt to hide HTML or JavaScript in their input. If the web application stores and displays the information as it has been entered it would be possible for the attacker to embed malicious script into the content sent to the browser. Most frameworks have the ability to find this material in user input, or you could encode it so that it's not executed by the browser and shown as plain text.
        3. Always use a database connection with the lowest necessary priveleges. This reduces the possible attack surface by preventing a successful attack from having the leverage to compromise the data or the database server itself. Couple this with item 1 and you have a security context in which the web application can only execute a handful of stored procedures and cannot directly read/write to any of the user tables.

        • Re: (Score:3, Interesting)

          by Tablizer (95088)
          1. Never concat input into SQL. In fact, avoid dynamic SQL entirely. Use stored procedures with parameter binding so that user input can never be used to inject SQL statements to the database.

          But things such as Query-By-Example with wild-card (LIKE) potential, a very powerful technique, cannot easily be done using stored procedures. We would have to cripple the power of computers and have programmers wasting time writing trivial queries/reports for users and/or a combinatorial explosion of query forms (I'

  • Phew! Nothing to see here! (Score:3, Funny)

    by thechanklybore (1091971) * on Tuesday January 08 2008, @08:21AM (#21952766) Homepage
    Woah, I was almost worried for a second before I read it was Microsoft specific!

    My darling Apache and PostgreSQL may you never let evildoers overflow your fair buffers.

    *wipes brow*

    • For performance and security reasons, does anyone with real developers run SQL on an externally exposed website?

          • Re: (Score:3, Informative)

            by cHiphead (17854)
            Almost every shared hosting and VPS out there does that... just not with MS SQL quite so often

        • Re: (Score:3, Informative)

          by mhall119 (1035984)

          70,000 server admins could just as easily leave a LAMP system unprotected from SQL injection, but you wouldn't be trolling then, would you.
          Yes we would, only we'd be mocking PHP coders not Microsoft.
    • "It's possible that only Microsoft SQL Server databases were hacked with this particular version of the robot since the script relies on the sysobjects table that this database contains."

      Doesn't mean that the 'bot can't be tweaked. I think that someone is using this as proof of concept.

        • Re:You should still be careful. (Score:5, Informative)

          by Anonymous Coward on Tuesday January 08 2008, @09:27AM (#21953486)
          The server-side exploit is not binary code. It is a SQL injection attack. The only thing that ties it to MS SQL Server is the fact that they decided to use the sysobjects table to locate other tables. They could have just as easily used the ANSI-compliant INFORMATION_SCHEMA.TABLES view, which is available in most databases including MS SQL, MySQL, Postgres, Oracle, DB2, etc.. From there they could have used ANSI standard SQL to push their updates into the database containing their malicious javascript.

          This exploit did not require compromising the web server, or the database server. It required compromising the programming of the web application. Such an attack would work similarly on any combination of web server and database server, if it had been so designed.

          As for the client exploit, yes that would have been tougher. They did rely on a specific ActiveX exploit to compromise the clients. But they could have just as easily use poorly written Apache/PGSQL sites to push that malicious script.

        • Re: (Score:3, Insightful)

          by mhall119 (1035984)
          Only this isn't a Windows virus, it's an SQL injection attack. Most likely the vulnerability isn't even in Microsoft code, but in some popular business web application that uses MS SQL for the backend. Tweaking that to exploit a PHP application that uses MySQL for the backend wouldn't be any more difficult.
    • Well, unfortunately, Apache and Postgres are not magically safe. However, mod_security [modsecurity.org] can definitely help secure Apache, by filtering suspicious requests.
    • Microsoft has saved us all once again. If Microsoft had not trained developers all across the world to use it's proprietary extensions rather than ANSI compatible SQL then something important might have been hit by this attack rather than poorly coded webapps running MSSQL. Thank you Microsoft for taking this bullet for us.

      /too thick?
  • this kind of crap ain't gonna stop until we have a fundamental change in our approach to security: and that is we use a WHITELIST to authorize execution of the programs we trust and exclude EVERYTHING else.

    trying to identify and exclude malware has fallen short of meeting our needs

    and that demonstration continues week after week after week after week as the hacking gets worse and worse

    if we are going to use the internet for business purposes this is UNACCEPTABLE. Change has to happen.

    NO SIGNATURE? NO EXEC
    • That's right. Just make sure it has a GPL or possibly an Apache license, and your security status will improve quite a bit.
    • the problem is nothing that has to do with signed code. signing code "only" authenticates it and does not say that there are no security holes.

      it has, however, something to do with specific precations not being taken: with selinux or apparmor for example this probably wouldn't have happended simply because they handle application privileges in a different (OMHO: better) way - through profiles.

      • Re:dumb or troll ? (Score:5, Informative)

        by Rich0 (548339) on Tuesday January 08 2008, @09:09AM (#21953248) Homepage
        Uh - this attack didn't involve the execution of any "code" - at least nothing that selinux/etc would recognize as such. SQL Server was hit exclusively not because of any particular vulnerability - but because the attack used syntax specific to that server only.

        This is an SQL injection attack. That is when a poorly-written application does not sanitize its input, and passes it onto a database server as part of a SQL script. The malicious input terminates the command the application was running and starts some other command running. It has no access to anything in the system other than the data in the database - which is all this attack compromised. However, that data in tht database was then used by the application to render html output, which then passed the exploit scripts onto web clients.

        This is analogous to a trojan that wipes out all of a user's files in ~ in unix. Simply running as non-root will do nothing to prevent it from working - the user has access to delete their own files already.

        The attack merely used the applications write-access to its own database to modify the database contents - something that is nearly impossible to automatically protect against at the database server level. However, almost all database servers (including SQL Server I'm sure) does offer a semi-manual form of protection - a parametized query. If you prepare a query and put parameters in it, and then pass on user-input data in the parameters, the server will refuse to use the user-input data as anything other than data. Application authors just need to use this feature...

        • Re:dumb or troll ? (Score:4, Informative)

          by lrohrer (147725) <`moc.derauqsl' `ta' `rerhorl'> on Tuesday January 08 2008, @09:36AM (#21953624) Homepage
          Not at all impossible to prevent!

          Webserver user should only have read access to only the tables required. Writes should always go through stored procedures. The SP has write access but not the user. The SP must also do a second (or third) scrubbing of the data.

          It can also make sense to have to databases. One that serves the web pages and another that handles updates.

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      Hypothetical signed program checklist:

      * SQL server: SIGNED
      * Web server: SIGNED

      Well, in this case you are still vulnerable to an SQL injection attack...
    • The average person is not going to be able to tell the difference between "benware" and malware, especially if they are tired of clicking through dialog boxes to approve programs. They'll just ignore it like they ignore clickwraps.

      There's not nearly enough digital signing, even from reputable sources, to make "No signatrue? No execute" work. You can't get the things you want by applying this policy, and because people don't apply the policy, nobody bothers to go through the effort of signing. You would n
      • > There's not nearly enough digital signing, even from reputable sources, to make "No
        > signatrue? No execute" work. You can't get the things you want by applying this policy,
        > and because people don't apply the policy, nobody bothers to go through the effort of
        > signing.

        I install only signed code and I get everything I want. I use Debian.

    • Re: (Score:2, Insightful)

      by lhorn (528432)
      A whitelist wouldn't stop this, MsSQL would run, being on it...
      If the whitelist specified that MsSQL was not allowed to load and execute code from links in data, perhaps that will do it.
      Separation of code and data would fix the situation. I for one would be able to live with the reduced functionality.

  • Add this simple rule:

    http://*.uc8010.com/*

    Yaz.

    • Protect yourself with HOSTS (Score:5, Informative)

      by martyb (196687) on Tuesday January 08 2008, @08:47AM (#21953040)

      Another approach is to just block it in your HOSTS file:

      127.0.0.1 uc8010.com

      Or, even better, use an updated HOSTS file which has entries to block malicious sites: (on last check, this blocked over 16,000 addresses!): http://www.mvps.org/winhelp2002/hosts.zip [mvps.org]

      Description and explanation is here [mvps.org].

      • Re: (Score:3, Informative)

        by Yaztromo (655250)

        Another approach is to just block it in your HOSTS file:

        127.0.0.1 uc8010.com

        Just FYI, doing my own quick Google search, it appears that the hosts used by the bulk of these attacks is actually c.uc8010.com and n.uc8010.com. Indeed, it looks like all one-letter hostnames are used for this domain. So modification of your HOSTS should be made accordingly to ensure all hosts from this domain are indeed re-routed.

        Yaz.

  • Does anybody know the aim of the hack? Starting last saturday we saw a huge surge in incoming spam, with a peak yesterday (monday) at about 25 to 30% more spam than ever before. Today we see a lot less spam, almost at normal levels (normal being around 80-90% of all mail is spam :-S )
  • Shame about this:

    The fourth interesting point is that the only exploit we were able to coax out of them was the venerable MS06-014 (MDAC) patched in September 2006. What this means is that they went to the trouble of preparing a good website exploit, and a good mass-hack, but then used a mouldy old client exploit. It's almost a dichotomy.

    The only thing I can figure is that either

    • a) this was only a test
    • b) they are hoping to catch unpatched systems.

  • NoScript (Score:3, Interesting)

    by j.sanchez1 (1030764) on Tuesday January 08 2008, @08:31AM (#21952868)
    Wouldn't NoScript [mozilla.org] protect the Firefox users out there?

  • Good acts of violence (Score:4, Insightful)

    by MosesJones (55544) on Tuesday January 08 2008, @08:31AM (#21952876) Homepage
    Reading the referenced article it seems to almost applaud the success of the attack. This isn't a "good" attack its a very bad attack in that it has been successful and could potentially inflict damage on thousands or even millions of users. Its like claiming that something was a very "good" fraud because it robbed thousands of old folks of their life savings.

    Its a bad attack, its bad that its been successful and the people who did it are scum. These aren't some rebels fighting against the system they are criminal scum who are aiming to inflict damage on large numbers of people. Remember all those times when you have to clean up your parents/in-law/friends computers because they get compromised by this crap? Well the scum behind this have just given you a whole lot more time doing crappy boring work.

    • Re: (Score:2, Insightful)

      by AdrocK (107367)
      I think everyone agrees that this sort of thing is "bad". I wouldn't call it violence, but criminal nonetheless.

      But I also think slashdotters are amused at the continued running-amok of MS products. When the school bully gets beat up, you tend to not feel as sorry for him as you do for your friend.

      Besides, cleaning up the spyware keeps the fly-by-night pc repair geeks in business

    • Re:SQL injection (Score:5, Funny)

      by Fizzl (209397) <fizzl AT fizzl DOT net> on Tuesday January 08 2008, @09:06AM (#21953216) Homepage Journal

      sql injection to gain root

      I will gnaw my leg of if this dribble gets modded up.

      • Re:SQL injection (Score:4, Insightful)

        by pedestrian crossing (802349) on Tuesday January 08 2008, @09:41AM (#21953666) Homepage Journal

        sql injection to gain root
        I will gnaw my leg of if this dribble gets modded up.

        So far, so good, it's still at 1.

        I am astounded at the (much more than usual) level of misunderstanding of how the attack works. I've seen one correct comment, and much blathering idiocy!

        Running LAMP might protect you from this particular attack only because it is looking for table/column information the MS-SQL way. If you aren't taking effective steps to prevent SQL injection (which has nothing to do with "gaining root"), only luck is keeping it from happening to your LAMP system.

      • I would like to see computer users with more knowledge and more security awareness. However, it is easy to throw some HTML/ASP/whatever on to a website. How can we let novice users create "secure" sites without banning them the web?

        You've hit exactly on the real problem. I'm a sort of hobbyist web developer with no real training. I can hack together websites using ASP.Net and SQL server that work (that is do what they're supposed to do), but I have no idea how write secure websites. I don't even understand the sorts of attacks I should be expecting. Furthermore, the 'my first website' books I learnt from don't really cover this sort of stuff except in passing, and learning about security is frankly boring.

        Sadly I don't have a s

    • Re:Not surprised (Score:5, Informative)

      by Anonymous Coward on Tuesday January 08 2008, @09:09AM (#21953252)
      SQL injection attacks are universal across database platforms. No matter what front-end and back-end you use for a database store, if you're building SQL command strings in memory with unscrubbed external inputs, you're liable for an attack. This attack relied on SQL Server's sysobjects table, but that wasn't the vulnerability, that was just the target.

      • Re: (Score:3, Informative)

        by Bigmilt8 (843256)
        Thank you for printing this statement. It is amazing how most "technical" people don't understand what a SQL injection attack is and that it is platform independent. These attacks have to be stopped in your front-end development and not in the database engine. If you are writing code that is this unsecure (especially in 2007) then you shouldn't be coding at all. Also the MDAC was patched more than a year ago. Why weren't the patches applied?

        • Re:Not surprised (Score:5, Interesting)

          by Corporate Troll (537873) on Tuesday January 08 2008, @09:41AM (#21953684) Homepage Journal

          Do you want to know what is even scarier?

          In many corporate internal applications, SQL Injections are treated as if they do not exist. I have pointed out many times in several projects I have worked on that any malevolent person could do some very very nasty things. They don't care... "It's not open on the Internet". I just hope we'll never have a disgruntled employee that is a bit more geeky than the others.

          *sigh*

          Little Bobby Tables [xkcd.com]

          • Re: (Score:3, Interesting)

            by orgelspieler (865795)
            I've used un-scrubbed corporate app inputs to my advantage. At GE, we had two databases that didn't talk to each other. At all. We had to manually enter the data from one into the other line by line (why they paid engineers to do such mindless work is beyond me, maybe it's because we were on salary). Eventually, I figured out that the second database didn't get rid of things like HTML tags from the company front end app. So instead of entering the data line by line in the second database (which nobody

      • Just One Example (Score:5, Funny)

        by soloport (312487) on Tuesday January 08 2008, @09:43AM (#21953704)
        Here are more details on how such an attack can take place, and the devastation it can cause [xkcd.com].

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.