back to article MySQL.com hacked via... SQL injection vuln

MySQL.com was hacked over the weekend via an attack which used a blind SQL injection exploit to pull off the pawnage. Hackers extracted usernames and password hashes from the site, which were subsequently posted to pastebin.com. Any easy to guess login credentials could be easily extracted from this data using rainbow tables …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    FAIL

    Two or three steps above EPIC fail

    oh, and the https certificate for the customer.mysql.com domain expired a month ago

    1. BillG
      FAIL

      Ten or Twenty steps above EPIC fail

      You're joking. The HTTPS certificate expired a month ago? Well, I just checked it and you're right: Firefox gives me an Untrusted Connection warning with:

      "customer.mysql.com uses an invalid security certificate.

      The certificate expired on 2/27/2011 6:59 PM."

      It's a measly two-year certificate.

      Oh, if you go to mysql.com, there is no concerned warning telling you that your credentials have been hacked.

      Coming so soon after the PHP Wiki hack, this is really sad...

      1. Steve Evans

        expired cert...

        Oh that's good timing for them, I believe there is a lad in Iran who can do them a good deal on a new one right now.

    2. Ilgaz

      That prompt is a lot for black hat

      It shows a company/server is not managed at all, all in "auto pilot". As we speak about Oracle, money can't be a problem, it is the management who doesn't understand what kind of a message it sends to outside.

      Remember hotmail forgot to renew their domain and a linux hacker, feeling pity for the end users renewed it for them?

      These are number 1 and number 2 software companies on this planet. Tells a lot about where the IT would be today.

    3. gollux
      Grenade

      The irony of it all...

      Bwaahaha

  2. Tom_

    doh

    "the director of product management at WordPress used a four digit number as his password"

    Might be time for him to change his PIN and/or any door codes he uses. :)

    1. Tony Humphreys
      Thumb Up

      President Skroob

      I use the same combination on my luggage!

  3. Michael H.F. Wilkinson Silver badge
    Thumb Up

    Excellent sub-title

    FACEPALM says it all

  4. Matt 116

    The title is required, and must contain letters and/or digits.

    For bonus points it would be interesting to see if those 4 digits related to a day - month part of his or other halves birthday.

  5. Anonymous Coward
    Anonymous Coward

    ˙˙˙pıɐs ʇı ʇɐɥʍ ǝʇınb ʇou s,ʇɐɥʇ 'ou

    "This information revealed that the director of product management at WordPress used a four digit number as his password"

    Ehr, no.

    Said director AT MySQL used a 4-digit password FOR his (presumably locally installed) Wordpress account.

  6. Grendel
    FAIL

    Salt and hashes

    Why is it sooooooo easy to match hashed passwords using rainbow tables? Doesn't anyone implement "salt" (salting) of hashes?

    All the systems we install for customers have username/passwords stored as SHA1 hashes of username+password+salt where 'salt' is an installation or site-specific string hidden elsewhere in system configuration. This means that even if you read out the usernames+hashes from the tables you can't necessarily get the password from it...

    Mike

    1. Rhys Briffett
      Thumb Up

      Thanks...

      For the info. Now if anyone gets password hashes from any of your clients they know what the salt will most likely be.

      1. JimC

        >what the salt...

        Of course he might be describing the general technique they use rather than giving the precise recipe you know.

      2. web_bod
        Badgers

        Hashed salty hash

        We cache the hash of the hash of the encrypted salted input, unhashing the cached hash gives you a hash, unhashing that hash gives you an encypted string, decoding that gives you the salted input, but our salt is a method not a constant, so you need the secret recipe.

        All this to protect frickin' car insurance quotes.

        1. Anonymous Coward
          WTF?

          UNHASH ?????

          Isn't the whole point of cryptographic systems that such a process is near-impossible?

    2. Sir Cosmo Bonsor

      The title is required, and must contain letters and/or digits

      Enjoy your false sense of security. If the bad guys compromise the system to the extent that they gain access to the hashes, the salt won't remain "hidden" for very long.

      1. Ross 7

        @Cosmo

        *sigh*

        The salt doesn't need to be in any way hidden. As long as it differs enough from hash to hash (and in the case stated it *must* be different from hash to hash as it uses the username) it serves its purpose which is to avoid collisions.

        By hiding the salt it adds another layer of pain, however once discovered, the salts still do their job as designed.

      2. Anonymous Coward
        Boffin

        You have totally missed the point

        Using a salt renders any 'rainbow tables' completely useless, therefore it is not trivial to automatically extract plaintext passowrds from their hashes in the database.

        Also, if the designers of the system have a brain, the salt value will be stored in a file and not in the database itself. To get the salt value would likely require a totally different entry point for the hack. It would most certainly NOT be exposed by a database injection exploit.

        Even if the salt value itself is compromised, a new rainbow table would have to be created specially for that particular salt value. While not impossible, it is significantly more hassle and more computationally expensive than using a pre-compiled rainbow table.

        Oh, and it is worth noting that Grendel did not actually reveal what his salt value is.

        1. streaky
          Boffin

          Salting

          "Using a salt renders any 'rainbow tables' completely useless, therefore it is not trivial to automatically extract plaintext passowrds from their hashes in the database"

          Rainbow tables were rendered useless when people discovered you can do this with a GPU. Amazon conveniently puts GPU boxes in their cloud for anybody who wants to break this stuff at extreme speeds.

          Honestly if you care you'll sha512 with like a billion rounds or use whirlpool or something, if you don't you'll just md5() your shiz. md5() isn't bad in and of itself - it just won't stand up to much scrutiny, it's just means you need a lot of trust in your data security because if it leaks out you're screwed.

    3. Anonymous Coward
      Anonymous Coward

      use bcrypt

      The salt, it does nothing! Use bcrypt. codahale.com/how-to-safely-store-a-password/

  7. Anonymous Coward
    Unhappy

    But..

    But.. as with the Gawker hack, having an insecure password on a trivial system is not really a problem. How many people give a stuff if their mysql.com account is hacked? The key is different passwords for different systems.. if the back-end system isn't secure that it probably doesn't matter how good your password is!

  8. Stuart Halliday
    Unhappy

    Biggest security flaw of all

    As a IT engineer, it's not always our fault. Sometimes the damn boss refuses to adopt procedures like common sense complex, aging and minimum length passwords!

    1. Anonymous Coward
      Unhappy

      Complex passwords....

      All well and good but if you insist on x$£dvEt@@756thisImypAssW0rd4321 as your passwords, then people will just write them down and post it to the monitor. Ok for a web facing server, not so good for an internal system.

    2. Framitz

      You got that right

      As an IT security analyst, I can vouch for the truth of that.

      I once had a CEO that refused to use a password to log on. He got lucky and wasn't compromised. We did finally manage to scare him into compliance and he was grateful in the end.

  9. ratfox
    FAIL

    Doesn't anybody use prepared statements or what?

    I fail to sympathize with any organization that fails to use prepared statements and gets hit by an SQL injection.

  10. doperative
    IT Angle

    SQL injection exploit ..

    Instead of passing an SQL statement to the end user app, which fills in some place markers and then the entire statement is loaded back to the server. How about designing a system where it's impossible to run such remote scripts. Is there any other method of providing such functionality?

    1. Oninoshiko
      Boffin

      As ratfox mentioned above

      prepared statements are pretty close to what you want. They allow you to write up the SQL statement, and sent it off to the server, then you just call that statement later and send the variables for it. Because the variable-values are kept separate from SQL, it's (AFAIK) immune to SQL-injection attacks.

      You also get the side benefit of having more responsive queries (you don't have to keep sending the query and redoing the planning phase each time).

      1. streaky
        Troll

        Prep statements

        PDO in PHP with bound params, it's actually more efficient for obvious reasons too.

        Anybody vulnerable to SQL injections in this day and age really needs to start firing people.

  11. Anonymous Coward
    Anonymous Coward

    read only

    The MySQL Customer Support Center retired on February 11, 2011 and migration to My My Oracle Support is now complete. As a result, the MySQL Customer Support Center is in read-only mode.

    Access the My Oracle Support Welcome Center for migration information, training, significant changes and answers to Frequently Asked Questions.

  12. Neal 5

    @Oninoshiko

    "Because the variable-values are kept separate from SQL, it's (AFAIK) immune to SQL-injection attacks."

    Wouldn't you put the select statement in a stored procedure, the parameter would be on the WHERE clause.?

  13. Grendel
    Go

    The bigger problem is "passwords" and perceived security

    Ok, so we recognise that storing plain passwords is bad or even passwords that have been simply hashed - which are vulnerable to attack.

    There are various layers of defence available, such as hashing with passwords with a 'salt' (yes, my comment was generic and doesn't represent the exact recipe we use on any specific system) but better solutions exist - for example maintaining the authentication on separate back-end systems accessed via RADIUS or LDAP.

    Personally, I think that the time for static passwords has passed... how many people use the same password on multiple systems? How many people never change passwords? Answer: the great majority of people. Why? Because we're innately lazy! ... and we think security is someone else's problem.

    [BTW: how many of the people reading this post have an insecure front door on their house, flat or property?... Brute forcing that old Yale lock is very easy these days... http://en.wikipedia.org/wiki/Lock_bumping or YouTube 'lock bumping'. You won't get in to my castle trying that technique either... ]

    The days of the "fixed password" have to be numbered? We need something better and while RSA's Secure-ID looks to have just had a significant compromise of its own recently one-time-passwords (OTPs) have to the the future...

    We've just built our own implementation of RFC4226 HOTP and are evaluating it for a client project as the majority of users have Crackberry, Droid or iJobs smartphones and can run a software implementation of OTP so we don't even need a token. For those users that do need a token they can be purchased from China for $8 USD each these days :) Who needs RSA Secure-ID anyway?

    Mike

  14. Chris Jakeman

    @read only

    "Access the My Oracle Support Welcome Center for migration information, training, significant changes and answers to Frequently Asked Questions."

    but links for the free MySQL Community Edition take you back to www.mysql.com.

This topic is closed for new posts.

Other stories you might like