Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Oracle Sun Microsystems

MySql.com Hacked With Sql Injection 288

Posted by samzenpus from the we-got-a-breach dept.
iceco2 writes "MySql.com and associated sites were hacked today. Among other items some simple passwords were recovered and private emails were revealed. Ironically the attack was performed using a blind sql injection attack."
This discussion has been archived. No new comments can be posted.

MySql.com Hacked With Sql Injection More

MySql.com Hacked With Sql Injection

Comments Filter:
  • Some evidence of server issues here already. Another report: A proper link? [sophos.com]

  • Should be: http://techie-buzz.com/tech-news/mysql-com-database-compromised-sql-injection.html [techie-buzz.com]

    (There is an extra l in the summary's link.)

  • USE BIND VARIABLES (Score:5, Interesting)

    by MoNsTeR ( 4403 ) on Sunday March 27, 2011 @04:47PM (#35632638)

    Jesus fuck, people. It's not rocket surgery.

    If you use bind variables, you CANNOT be SQL-injected.

    If you don't, you can be.

    It's that fucking simple. Do The Right Thing.

    • Note that this doesn't mean you should assume you're safe just because you're using bind variables -- be aware of stuff like LIKE, for instance.

      But yes, that is exactly the frustration I have when I hear about things like this. There's pretty much never a reason to build your own SQL string outside of a library.

      • Re: (Score:2)

        by vlm ( 69642 )

        Note that this doesn't mean you should assume you're safe just because you're using bind variables

        For example, bind variables are a great way to store the wrong value in the wrong column. Admittedly I'd rather discover that bug in the unit tests on the dev server, than discover the injection on the production server, but I can none the less hear the siren call of doing it the wrong way...

        Now what would be nice would be libraries for ALL languages that look like convenient, yet vulnerable, inline SQL but translate behind the scenes into bind variables.

        Also fun, if the (numerous) lint-y / perltidy-y what

      • There's pretty much never a reason to build your own SQL string outside of a library.

        Not to negate your argument (with which I agree), I want to demonstrate a case where building your own SQL string makes sense. Suppose you want to perform a SELECT that matches a set rather than a given value:

        SELECT make, model
        FROM vehicle
        WHERE vin IN ('1M8GDM9A_KP042788', '1M8GDM9A_KP042789');

        The prepared statement is a function of the number of VINs in the set. Something like this python code:

        VINs = ("1M8GDM9A_KP04

        • Re:USE BIND VARIABLES (Score:5, Insightful)

          by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Sunday March 27, 2011 @07:07PM (#35633686) Homepage Journal

          SQL = """
          SELECT make, model
          FROM vehicle
          WHERE vin IN (%s)
          """ % ', '.join(["%s"] * len(VINs))

          My eyes, they bleed! Write that like:

          VINs = ("1M8GDM9A_KP042788", "1M8GDM9A_KP042789")
          SQL = """
          SELECT make, model
          FROM vehicle
          WHERE vin = ANY(%(vin)s)"""
          dbconn.execute(SQL, {'vin': VINs})

          Or even better:

          vehicles = session.query(Vehicle).filter(Vehicle.vin.in_(VINs))

          Voila. Those work, they're not hideous, and they prevent injection. To repeat the earlier idea: there's no need to write unsafe code. If you are, you're in the wrong line of work.

          • I prefer:

            $db->select('make, model');
            $db->where_in('vin', $vins);
            $db->get('vehicle');

            Ahh CodeIgniter. I dont write SQL anymore.

      • Re: (Score:2)

        by madprof ( 4723 )

        Are you saying MySQL does not escape the delimiter characters within values passed to the LIKE operator?

    • Re: (Score:2, Funny)

      by Anonymous Coward
      I just use something : addslashes(addslashes(addslashes(addslashes($str)))) ;
      I like slashes ;-) ;

      • Re: (Score:2, Funny)

        by Anonymous Coward

        addslashes() is unsafe. In PHP you want to be using the standard function "mysqlreallyescapethingsanddoitproperlythistime()". Don't go using "mysqlescapethingscorrectly()" by mistake, that one is completely insecure.

        (Seriously, why do people use PHP?)

      • Addslashes...Ah the mascara function.

      • Re: (Score:2)

        by thebra ( 707939 )
        And then while (strpos($string, "'") !== false) { $string = stripslashes($string); }

    • Re:USE BIND VARIABLES (Score:5, Funny)

      by Dunbal ( 464142 ) * on Sunday March 27, 2011 @05:02PM (#35632748)

      Jesus fuck, people. It's not rocket surgery.

      Apparently it's brain science.

  • Yo Dawg (Score:5, Funny)

    by mrstrano ( 1381875 ) on Sunday March 27, 2011 @04:56PM (#35632690) Homepage

    I herd you like Sql, so we injected Sql in your Sql so you can have Sql while you code MySql

  • After I finished visit all the funny sites I usually go to daily, that title made laught much much more than all of them.

  • The work of a lonely developer (Score:4, Insightful)

    by danielcolchete ( 1088383 ) on Sunday March 27, 2011 @05:02PM (#35632744)
    Even inside a big team of a big company it is amazing how so many people are working by themselves. That's the kind of error that a simple code review by an experienced programmer would have avoided (use bind variables/prepared statements).

    • Re: (Score:2)

      by jd ( 1658 )

      Quite possibly on the lone programmer, almost certainly on the code review. The NSA has some nice whitepapers on how to prevent SQL injection attacks, though they could really be summarized as "follow parent post's advice".

      • The NSA has some nice whitepapers on how to prevent SQL injection attacks

        That is so fucking sad. Imagine your first day at work at the puzzle palace, expecting to work on some shit hot, high tech, super secret stuff and they say "write a paper on how to avoid SQL injection attacks."

  • Could've been worse. Imagine something like this had happened to Zend!

  • Too bad it's not "unbreakable" like Oracle's other database...

    • Re:Too bad (Score:5, Insightful)

      by KiloByte ( 825081 ) on Sunday March 27, 2011 @05:39PM (#35632954)

      Let's think if Oracle has something to gain from intentionally tarnishing the reputation of a product they want to kill.

      I'm not saying it's foul play for sure, just pointing out they do have an incentive to do so.

      • Yeah, they might convince more people to switch to PostGres!

      • Let's think if Oracle has something to gain from intentionally tarnishing the reputation of a product they want to kill.

        I'm not saying it's foul play for sure, just pointing out they do have an incentive to do so.

        Yeah but so does everyone who's ever worked with databases and doesn't have their head stuck completely up their ass. Let's pray this piece of shit is dead and buried soon.

  • Does xkcd explain it? (Score:3, Funny)

    by Anonymous Coward on Sunday March 27, 2011 @05:18PM (#35632854)

    Like this [xkcd.com]?

  • SQL injection attacks? What, is it 1998 again all of a sudden?

    Are there really still people out there mashing user input together into a string that they then feed to the database?

    Why would you even do this - it's not easier, the performance is worse, and it certainly doesn't make for more readable code.

    This level of ineptitude is just shocking.
    • In related news, teenagers are still bad at driving! Won't they ever learn proper lane usage?
    • The thing is, if you have 100 engineers working on your code, and they write or modify 200 lines of code every day - it's very hard to guarantee there's not a single line of vulnerable SQL code written over 3 years. It only takes one mistake to get your server compromised.

      • Re: (Score:2)

        by glwtta ( 532858 )
        100 engineers, for mysql.com?

        Simple solution - fire the 80 incompetent ones, the other 20 will be able to get a lot more done. Heck, also give them 1/4 of the money you were wasting on the dead weight.

    • Re:What year is it? (Score:4, Funny)

      by Software Geek ( 1097883 ) on Sunday March 27, 2011 @06:28PM (#35633332)

      When interviewing people for QA positions, I routinely ask "Do you know what an SQL injection attack is?"
      I have never yet interviewed a candidate who answered yes.
      So, then I explain what an SQL injection attack is, and ask how they would test for vulnerability to one.
      Almost without exception, the answer is "I guess I would try entering some special characters and keywords into the GUI, and see what happens."

      • Re:What year is it? (Score:4, Insightful)

        by discord5 ( 798235 ) on Sunday March 27, 2011 @07:23PM (#35633836)

        When interviewing people for QA positions, I routinely ask "Do you know what an SQL injection attack is?"

        Hahaha, reminds me of what I used to do to interns. We used to get a bunch of interns every year, and every year we'd have them develop small web applications for internal use. They'd work on their project and after a few weeks we'd come in and evaluate their work, steer them in the right direction (if that wasn't necessary earlier) and do a few tests.

        The first thing I always asked was "Do you have a backup?" and after the inevitable googling of the mysqldump command I'd be an utter bastard and sneak in a DROP TABLE, or DELETE FROM statement in the URL bar, right after id=x, and surely enough most of the times it would work.

        "It looks really great, but I think there's a problem with it. Maybe you want to check the logfiles to see what happened." to see if they'd see what was the problem, and if they didn't I would explain an SQL injection attack to them. Few of them managed to find the solution on google, but most immediately suggested such things as "I'll check for ; in the string" which inevitably led to me trashing their tables about 10 minutes later. I have to say, once they had their tables dropped twice they became real careful of permissions and handling SQL statements.

        In a way I hope they learned something from having a complete bastard as a mentor, although I'm sure that a few of them have already forgotten about that one time a single statement ruined their database. Oh well...

  • That simple passwords were revealed shows a lack of understanding or incompetence. The reason only "simple" passwords were revealed was from a poorly made SHA1 hashing function [wikipedia.org]. Yes this is pure conjecture, but it is the only scenario that fits the facts.

    The hackers acquired the database with the hashed passwords. Then the hackers ran the password hashes against a rainbow table [wikipedia.org] which returned the matches for the simple passwords. Now the reason this is incompetence or ignorance is the simple inclusio

    • Re:Password hashing + salt? (Score:4, Informative)

      by BCoates ( 512464 ) on Sunday March 27, 2011 @06:57PM (#35633588)

      The salt isn't a second secret, it's there to prevent the use of a pre-constructed rainbow table for the standard hash functions. Without a rainbow table, you can still do dictionary attacks of weak passwords--and there is no way to prevent this short of not using passwords for authentication. This only harms people who use guessable passwords and re-use passwords between sites.

      • You can very easily convert a rainbow table into a rainbow table + predefined salt, a simple SQL statement and 10 minutes later your 1TB rainbow table becomes rainbow+salt. If you don't keep your salt a secret you may as well not use it.

        Without a rainbow table, you can still do dictionary attacks of weak passwords

        That would only work if you had the hashing function with the salt string. If you're talking about plain old brute force attack against the hashes, well that won't work without the hash function

        • There is one incorrect assumption in your reasoning. You don't have to use one salt for all passwords, you can easily use a different salt per entry, and store it along side the password. This way, even if your database is compromised, and the salts are know, you still have to create a different rainbow table for each entry to be able to try and guess the password. This effectively kills the ability of the breacher to fish around for insecure passwords.

  • You can never sanitize inputs enough.
    Repeat that to yourself 1,000 times. It's impossible(*).
    Parameterized queries / bind variables are the only valid solution.

    If you keep convincing yourself you don't need to use bind variables, and that you can sanitize your inputs enough you've already failed.

    * - Of course it's mathematically possible to sanitize inputs enough; because theory, and reality don't have a damn thing to do with each other. Reality says you will fuck it up and the hackers will find it in less

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close