Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Worms IT

Why Old SQL Worms Won't Die 64

Posted by ScuttleMonkey from the looking-for-a-user-security-patch dept.
narramissic writes "In a recent ITworld article, Security researcher Brent Huston ponders how it is that versions of SQL worms dating back to 2002 represent nearly 70% of all malicious traffic on the Internet today. 'I have made a few attempts to backtrack hosts that perform the scans and at first blush many show the signs of common botnet infections. Most are not running exposed SQL themselves, so that means that the code has likely been implemented into many bot-net exploitation frameworks. Perhaps the bot masters have the idea that when they infiltrate a commercial network, the SQL exploits will be available and useful to them? My assessment team says this is pretty true. Even today, they find blank "sa" passwords and other age-old SQL issues inside major corporate clients. So perhaps, that is why these old exploits continue to thrive."
This discussion has been archived. No new comments can be posted.

Why Old SQL Worms Won't Die More

Why Old SQL Worms Won't Die

Comments Filter:

  • of course (Score:5, Funny)

    by stoolpigeon ( 454276 ) * <bittercode@gmail> on Monday February 25, 2008 @03:33PM (#22550230) Homepage Journal
    cut them in half and now you just have 2 worms! stop the madness!

    • stop the madness! (Score:5, Interesting)

      by Gary W. Longsine ( 124661 ) on Monday February 25, 2008 @04:19PM (#22550806) Homepage Journal
      I'm surprised by this article. I thought it was common knowledge that botnets are full of these old exploits. The guessed purpose is exactly what's going on. Worms these days don't spread as rapidly as they used to on the wild internet because botnets are serving a purpose -- they are making somebody money. If they spread like wildfire on the internet as a whole, they would attract too much attention, and get cleaned up. They can't get into most corporate networks using worm probes, either, but they can and do get in by exploiting browsers, as email attachments, and so forth. Once inside, they probe around looking for all manner of things. It's not just SQL exploits, either. I'd guess the sample data they looked at was biased somehow. Maybe some big botnet was running a sweep with those particular exploits during the sample period.
  • They just fade away... into am obscure mess of system tables/schema of new releases and older hardware and unpatched servers for old releases.

    Besides, you can't kill what's isn't "alive"...
  • You mean that people are still exploiting 'exploits' that were never fixed? Shocking! And passwords will always be a problem. There will always be people who never change the default passwords so that will always be a viable mode of attack.
    • It doesn't have to be; the default password could be set (or even just randomized) on installation, or the account marked for "must change password" if the auth mechanism supports that concept. Either way users would be to required to pick a password before logging in. That obviously doesn't stop anyone from using bad passwords, but you can most certainly stop default passwords -- they've always been a bad idea from lazy installation systems.
      • Microsoft is already doing this with Windows Server 2008. After installation, before proceeding any further, the Administrator password must be set. I installed WS2008 last week after downloading it from Technet, and was pleasantly surprised to see this at first login.

        • Re: (Score:2)

          by Amouth ( 879122 )
          it was required in server 03 too.. and even complains if you use simple passwords.

        • Re: (Score:1)

          by ydra2 ( 821713 )
          Thank you mister...

          User: Administrator
          Password: Password

          Oh, that's not you? Well it's about a million others, so who cares. Botnets aren't looking for you anal password types, they're looking for everybody else, and the non-anal-retentive password people outnumber everybody else by thousands to one or maybe even worse.
    • I've wondered about this before. Perhaps server software vendors need to come up with a better default password scheme than just a blank password, or even a static, generic password like 'admin', or 'linksys'. Something where a unique password is generated for every machine during installation, displayed to the user, then saved to a text document on their desktop or a standard 'repository' for the passwords (something like KeePass, Apple's keychain, etc, where you provide a master password to lookup the cur
      • The safer(imo) is to make the product do almost nothing until the default password is changed. However, most vendors like to advertise "works out of the box!" so the odds of this happening are about 0....
      • For hardware like home NAT routers and the like, I'd just print the default password on the label, right next to the serial number -- or just use the serial number as the default password.
        • It's not good because serial Numbers are err.... serial.
          You could of course print a somewhat random formula to be used as a hash function to be fed with the serial. The user would have to calculate this by hand to find out the default password. Anything involving partial differential equations would nicely fit this purpose with the advantage of being utterly user-friendly.

          • Doesn't matter if they're sequential -- if there are a hundred thousand Linksys WRT54Gs out there, that's a hundred thousand passwords you'll have to try for each router you're attacking.
    • Actually, if you forced everyone, upon installing/activation/account generation to implement a passcode, then this would not be as much of a problem. (And by force, I mean this program will not install or run; or the user's account will not be created unless the user creates a password).
    • I'm sad to say that even people who should know better are lazy with security. A guy a work is a good web designer, and before they hired me as sysadmin, shared the admin with a couple of colleagues, and *seemed* to know what he was doing. Well, not at all. His webapps connect to the database using his own personal login, with dictionary words as passwords, he doesn't set a root password, doesn't put anything into the mysql tables to restrict which hosts/users have access, and thus the system is wide open.
      • I routinely wiped the database via the website at a place I used to work at, and detailed the process every time.

        Two years later and I see that the database is still attackable via anyone with a copy of "Advanced SQL Injection" and an hour spare.

        Never underestimate the power of human stupidity.
        • I recall a recruitment agency whose job search put the SQL into webpage as links for next and previous. Do could change the URL to be "drop table X" instead, and it worked. Yes really. I'm still stunned by that.
    • Nobody should be surprised by password issues anymore. That's like being surprised that some people cheat on their taxes; it's just a fundamental part of human nature.

      Anyone remember these [wired.com] stories [hamptonroads.com]? Someone got an ATM manual off the web, learned the default password ... and walks up to an ATM, switches it to debug mode, makes it think the $20's were actually fives -- oh, and dispense everything in fives. And promptly makes off with hundreds of dollars by cleaning out (untraceable) prepaid debit cards.

      On
  • Presumably, the sysadmins at those companies are at least semi-competent, given that they've blocked SQL access from outside--but why is it that the various vulnerabilities have not been patched?

    Is it perhaps because SQL is not something that is particularly high-profile patchwise, unlike operating systems and webservers? Or are unauthorized users running various SQL databases for internal department issues or whatnot, outside the official purview of the IT departments? Or perhaps is it a case that the ad

    • Or perhaps is it a case that the administrators of the databases are simply unaware that they can be compromised in this fashion?
      I think you, sadly, have nailed it. I find more companies have someone who is not qualified to be a DBA performing DBA tasks. I've been to too many SQL classes as refresher courses where the people are coming from data entry positions to DBA roles. Blind leading the blind.
      • Ah, so the usual: educational weaknesses with a side order of shiny-suit apathy towards said education.

        Well, it's a way to sell custom DB installations, I guess--whip up a glossy brochure with lots of FUD over DB insecurities, and offer a "locked down" version with an installer that asks for the SA password on installation, much like most current Linux distros.

        Or, hell, just whip up a script that'll "secure against intrusion" and sell that off for a few thousand bucks per unit. Higher the price the better
        • I have no problem with people "working their way up". It kind of makes me glad to see it, but, I feel you do need SOME kind of IT background. SQL Admin isn't just wizard ran software there homeslice.
          In my experience the SQL Admin is a bit of a developer, a bit of a sysadmin, and something all of their own. To hear that they where only ever data entry makes me shutter! I'm more comfortable with shifting from within IT than from the secretary pool.

      • Re: (Score:2)

        by Shados ( 741919 )
        Yup. I worked in a company thats in the fortune top 10... so a company that has millions upon millions of dollars of transaction saved per day... Their DBA Is a "Senior" DBA, having almost more years of DBA experience than I have years of BREATHING experience...

        Yet they had no clue what synonyms were... no clue how to solve table locking issues (a common SQL Server problem and one of its main flaws in the 2000 edition and before, but if you're going to go the SQL Server route, you need to know how to handle

        • Re: (Score:2)

          by Splab ( 574204 )
          I work as a DBA and have never heard of synonyms, but thats because its a MS SQL specific thing? I have worked a few years as TA on introduction to SQL, and I'm pretty sure none of the books I have mentions synonyms. (Just googled it and it seems to be MS and oracle specific which is DBMS I've never worked with, while I see the usefulness of it, slamming someone for not knowing about them or not wanting to use them is wrong (imo))

          Solving locking issues can be very tricky, especially since quite a lot DBMS o

          • Re: (Score:2)

            by Shados ( 741919 )
            You didn't know of synonyms, but you've also haven't been working (from your post) with RDBMSs that have it as a first class feature for almost a decade, so its normal... I don't know much about non-standard compliant features of MySQL or Postgres either. In an SQL Server environment however, its no more obscure than the temporary table syntax. For locking issues, in SQL Server, its stupid simple: if your stored procedure is used mostly in static data (a report or something), you add the No Lock optimizer h

            • Re: (Score:2)

              by Splab ( 574204 )
              I should probably have clarified it. We use Solid for our HA/HP system, their replication scheme is probably the fastest I have seen around.

              Hinting a no lock will of course remove any issues, but asking it to remove the locks might not be a good idea, I would certainly have someones head removed if they decided to run without locks on my system.

              And we do use explicit cursors, its fast and we get to choose what is dropped when.

              About the horizontal scaling, you just made it sound like everything is a piece of
      • Not just DBAs, it's nearly all administrators.

        I have seen one (1) customer where the resident admin asked for an account to install the server-side piece of our software provided something else than "root", even when explicitely told not to. I don't think I need to describe the rest of the security at their places. I've learned that trying to tell them anything about the basic common sense rules is counterproductive, too. If I try, I and our company get labelled as "troublemakers" behind our backs. Even
    • A good SQL Developer not a DBA Make. I am a good SQL Developer, My SQL Calls really blow the pants off some people who said to me that you can't do that in SQL... But... I would make a sub par DBA. I can probably get the job done and keep the company in one piece, But I would probably make bad decisions on what policies to set up for the users Give them to much or too little, etc... It is the same time as a good software developer doesn't make a good system administrator. They are actually very differen
  • Trying SA,"" is cheap. Why wouldn't you try it?
  • Comment removed based on user account deletion

    • Re: (Score:2)

      by cnettel ( 836611 )

      I don't see that many myself... that's a pretty high number.
      Most of mine lately are the windows RCP exploits and the exploit for old symantec overflows on port 2967. That, or I used to get a lot of traffic from SSH brute force attacks and malicious HTTP stuff...
      Do you mean RPC? (Not trolling, I was really confused and that's the explanation that makes most sense to mean.)

    • Re:70% really? (Score:4, Informative)

      by tcopeland ( 32225 ) <(tom) (at) (thomasleecopeland.com)> on Monday February 25, 2008 @04:23PM (#22550842) Homepage
      > I used to get a lot of traffic from SSH brute force attacks

      Yup. One of the first bits I install on a new server is DenyHosts [sf.net]; "service denyhosts start" and an hour later there are a half dozen IPs in /etc/hosts.deny. Good times.
      • I used to use denyhosts on a remote machine until I nearly locked myself out while trying to set up a svn+ssh client (I had the syntax wrong).

        The only reason I wasn't locked out is because I had an open SSH session currently in progress.
        • > I nearly locked myself out while trying to set up a svn+ssh client

          Yeah, that's a bad feeling. But the good thing is that you can usually ssh in from some other subnet. Unless you've already set up AllowHosts or something, in which case, yeah, a drive to the colo is in your near future :-)
    • I used to get a lot of brute force SSH attacks as well when I was running a Linux server. I was glad that I ONLY allowed access via public key exchange and not passwords.
      • Instead of disabling passwords completely to stop the brute force SSH attacks, I disable password authentication but leave public key and keyboard-interactive enabled. Keyboard-interactive is just a fancy way to request a password by default, but won't work with the brute force attacks I've seen so far. It's not going to work forever, but seems to be effective for now.

      • Re: (Score:2)

        by TheLink ( 130905 )
        I just run the sshd on a different port. That way if someone targets my sshd, I KNOW something unusual is going on.

        If someone writes a "zero day" worm, they are likely to stick to the default ports to maximize the spread speed. So that means I have more time to fix the affected service.

        There are people who think obscurity isn't useful, and there are people who genuinely have more time to read Slashdot :).

  • Team 17 just made it too good (Score:4, Funny)

    by Alzheimers ( 467217 ) on Monday February 25, 2008 @04:05PM (#22550662)
    What can I say? Team 17 made it a fun, accessible, simple yet requiring thought and strategy. The later 3D versions had problems with the camera, and the humor never matched up to the original.

  • I can imagine a legacy system never getting patched because everyone is afraid that it won't boot up properly or they need it up 100% of the time.

    I can imagine a blank password due to struggling with ignorant users and bad application coding.

    • Re: (Score:1)

      by Briden ( 1003105 )
      I see, you must have really worked in the industry then. Fact is, there is a reason that defaults are used, and that they are attacked: simplicity. Simplicity is also responsible for many deliberate "loosening" of security reasons, most commonly in development to "get it working", then, a thought is put to beefing up security later. a good thing? certainly not. what's going to keep happening? certainly. i'd have liked to see the look on someones face when the first piece of malicious traffic ever trav
  • Because 0ld SQ00l never dies!!

    *rimshot*

  • Let's see. Viable infection vectors are still being used. This is kinda common sense. I expect to see a Phd paper on it next week.

    Let's compare this to medical infection vectors. There is sexual, by touch, by air, by liquid/drink, or by food. I can't really think other disease transmission ways. We've got what millions of bacteria/viruses spreading by those means every second. As long as its still effective, it'll still be in use.

    I think of net security sort of like keeping a eco system healthy and without
    • Blood to blood contact (fairly rare, thankfully -- mostly of a concern to medical workers)
      Parasitic infection (mosquito is carrier of malaria, mosquito bites you, etc)
      Pathogen touches skin (thankfully, we're pretty robust against this, but it worths for some pathogens and for folks with weakened immune systems. You might be familiar with planter's warts, athlete's foot, etc.)
      Pathogen enters through compromise in skin (nick finger, open floodgates)
      etc, etc

      Basically, all you need for an infection is to get a

      • Re: (Score:2)

        by kabocox ( 199019 )
        Basically, all you need for an infection is to get a pathogen inside a cell it can infect. A vector can be anything that compromises your body's numerous and insanely effective defenses against that happening. (Oh sure, we get sick fairly frequently from our point of view, but we're walking around in a lethal organic soup for every minute of our lives. That tabletop you just disinfected makes the .ru namespace look like a threat-free Eden.)

        Sometimes I'd want my immune system running my virtual security. It
  • And why shouldn't some malicious attacker use every single exploit they've ever written/downloaded/stolen in their botnet payload? It's not like they're really concerned about bandwidth or CPU loads.

  • Umm....SQL? (Score:1, Offtopic)

    by Karellen ( 104380 )
    Uh.....so what is so special about SQL? Why are SQL worms so prevalent compared to C worms, or PHP worms, or Java worms, etc...?

    OK, so SQL injection doesn't require the kind of in-depth knowledge to exploit that buffer overflows in C do, so I imagine SQL exploits might be easier to craft to begin with ... but surely they're easier to spot. If you're pasting values into an SQL string instead of using named/positional parameters, you're vulnerable. That sort of thing should be much easier to do an automated s
    • Offtopic? WTF? How is "I read TFA and it doesn't make sense or explain things well" offtopic?!?
  • It seems to me that what they are saying is not that 70% of malicious traffic is SQL worms, and 30% is other kinds of worms, but that 70% of the worms include SQL attacks in their repertoire.

    I have made a few attempts to backtrack hosts that perform the scans and at first blush many show the signs of common botnet infections. Most are not running exposed SQL themselves, so that means that the code has likely been implemented into many bot-net exploitation frameworks. Perhaps the bot masters have the idea th

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close