Ir para o conteúdo.

Início » Open Source » Site oficial do MySQL é invadido usando SQL Injection

Em mais um exemplo de como o ditado “casa de ferreiro, espeto de pau” é verdadeiro, um ataque recente ao site mysql.com não só foi bem sucedido, como os crackers também acessaram e roubaram diversas  informações cruciais. A ironia da história? A invasão foi realizada através de uma simples SQL Injection!

Ataques de SQL Injection normalmente acontecem em sistemas amadores, onde os desenvolvedores (por desconhecimento ou desatenção) não sanitizam as chamadas ao banco de dados, impedindo a inclusão de comandos SQL via adição de código extra. Por exemplo, um simples:

SELECT * FROM 'clientes' WHERE 'id'=1

Pode virar um pesadelo simplesmente adicionando um comando extra, através de chamadas GET ou POST:

SELECT * FROM 'clientes' WHERE 'id'=1;DROP TABLE 'usuarios';

Onde o segundo comando apagaria toda a tabela “usuarios”. Ou seja, o truque mais bobo do manual. E é exatamente essa falha que foi explorada no site oficial do MySQL, por incrível que pareça.

Da invasão, foram obtidas listas de usuários, com seus e-mails e suas respectivas senhas criptografadas. Tais listas já foram divulgadas pela internet, e algumas até mesmo já foram quebradas, revelando dados curiosos: um diretor do MySQL tinha uma senha com apenas 4 (quatro!)  caracteres!

A recomendação dos responsáveis pelo site é que, se você tiver uma conta no mysql.com (ou nos espelhos mysql.fr, mysql.de e mysql.it), que acesse o quanto antes e altere a senha atual. Se essa senha for comum para contas em outros sites, faça o mesmo nesses serviços.

Com informações: Techie Buzz.

70 Comentários (Deixe o seu!)

  • hahaha só rindo… dá licença que tenho que ir ali correndo.

  • Próximo passo, invadir a adobe.com através de uma falha no Adobe Reader ou no Flash kkk

    • weslydias

      kkkkkkkkkkkk boa essa!!

    • Challenge Accepted!

  • @trovalds
    704c

    Bah, nem tem oq comentar. Amadorismo foi pouco nisso tudo.

  • acustodioo
    1c

    E eu achando que esses sites corporativos eram super bem feitos e seguros, decepção. =/

    Nem fizeram aquela chave de segurança básica para dificultar a decodificação da senha?
    define(‘KEY’,’ASDadas987adadadetcetal’);
    sha1($_POST['senha'] . KEY);

    tenso =/

    • HMAC é mais complexo do que este exemplo. :P

      • acustodioo
        1c

        São coisas totalmente diferentes, o exemplo que fiz é para que senhas fáceis e curtas digitadas por usuários fiquem mais seguras, não há intenções em decodificar a senha, muito pelo contrario é para dificultar.

        • Não, não são coisas totalmente diferentes:

          In cryptography, HMAC (Hash-based Message Authentication Code) is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret key.

          O que você fez é quase o que nós chamamos de salted hash. Salt seria uma chave pública diferente para cada usuário, informação esta que é gravada no próprio banco de dados junto com a senha já criptografada por uma função de hash junto com um salt.

          No entanto a implementação normal de salted hash não é segura, pois se alguém tiver acesso ao banco de dados, ganha acesso a todas as contas. É aí que entra o HMAC: você adiciona uma chave “pública” do próprio site na geração dos hashes, ficando algo como: HMAC_SHA1($password . $salt, $site_key)

          É claro que a chave do site deve ficar armazenada fora da raiz do servidor web, e para tanto a função que irá retornar o hash também, de modo a não ter como conhecer tal chave pelo que é público no servidor.

          • É

          • acustodioo
            1c

            Está certo, me equivoquei sobre o HMAC, mas o exemplo que citei não é uma chave publica para cada usuário, é uma chave privada para todos os usuários que cadastrar no site, de qualquer forma não entendo o motivo de usar HMAC em um simples sistema de login e senha, mas em fim.

          • [...] de qualquer forma não entendo o motivo de usar HMAC em um simples sistema de login e senha, mas em fim.

            Segurança de informações críticas do usuário. :)

            Na maioria das vezes, as pessoas usam a mesma senha para tudo (ou quase tudo). Se neste sistema de login você usar uma tabela com o e-mail do usuário, as chances da senha utilizada ser a mesma do e-mail são enormes!

            Com uma chave pública acessível, um ataque de brute force se torna tão fácil quanto se ela não houvesse. :P

          • acustodioo
            1c

            Mas no exemplo que citei não existe chave publica acessível, no artigo foi comentado que tinha senha com apenas 4 caracteres, supomos que foi usado sha1 para criptografar a senha.

            $senha_db = sha1($_POST['senha']);

            Com isso a senha foi gravada desta forma no banco de dados, com apenas 4 caracteres, ficando mais fácil de quebra-la.

            Com exemplo que citei, a constante fica no arquivo PHP no servidor e é fundida com a senha.

            $senha_db = sha1($_POST['senha'] . KEY);

            E a senha seria gravada no banco de dados, e na hora de fazer o login.

            if (sha1($_POST['senha'] . KEY) == $senha_db)

            A chave nunca fica visível para o usuário, nem mesmo ele saberá que está sendo adicionado dados extras em sua senha antes de ser gravada no banco de dados.

            Exatamente este fato da senha ter 4 caracteres e provavelmente ter sido quebrada com brute force ou ser uma senha muito óbvia que me levou a fazer o primeiro comentário.

            Pode ser que eu não esteja entendendo o que você esta dizendo. :(

          • Com exemplo que citei, a constante fica no arquivo PHP no servidor [...]

            That’s the problem. Suponha que eu tive acesso ao ter servidor web. O que eu vou encontrar lá? Provavelmente a chave pública usada para efetuar hashes das senhas e até mesmo os dados de acesso do banco de dados. Pronto, tive acesso a tudo. :)
            Estes tipos de informações não podem ser armazenadas na raíz do servidor (/www ou /public_html), devem ficar em diretórios anteriores. E por conta disso também não podem ser inclusas nos arquivos utilizados na raíz do servidor, pois assim de nada adiantaria colocar os arquivos do lado de fora. Nestas situações o ideal é ter a classe que vai usar o BD do lado de fora e instanciar ela por lá, incluindo a instância dessa classe já criada nos arquivos, usualmente por meio de um singleton. Aí se alguém tiver acesso ao código não terá como saber como ele se conecta ao banco de dados. :)

            Por outro lado, se o invasor tiver conseguido acesso somente ao banco de dados, usar uma única chave pública para gerar o hash de todas as senhas pode comprometê-las. Daí o uso do HMAC para combinar a senha com um salt aleatório para cada usuário junto à uma chave pública.

            A segurança de um sistema de ser feita em múltiplas camadas, do contrário facilita a vida do invasor. :D

          • acustodioo
            1c

            Mas da outra forma sem usar o HMAC, em termos de ter acesso aos arquivos do servidor, não daria na mesma?

            Da mesma forma que se pode tentar esconder está chave usada no HMAC também pode-se tentar com a chave do primeiro exemplo, ambos os casos quem invadiu o servidor terá uma chave, conseguindo acesso ao banco de dados, com o HMAC ele terá acesso a senha criptografada e a outra chave do usuário.

            Com isso para fazer o brute force com HMAC é só usar as duas chaves, a que foi pega no servidor e a que já vem no banco de dados, e começar a fazer os testes.

            while (HMAC_SHA1($password . $salt, $site_key))

            Mesmo usando duas chaves para ter segurança, se o banco de dados é invadido, a outra chave $salt já vai está disponível, com isso não faz diferença se houver uma invasão no servidor e esta chave for roubada.

        • Mas da outra forma sem usar o HMAC, em termos de ter acesso aos arquivos do servidor, não daria na mesma?

          Assumindo que se o cara invadir o servidor terá acesso a todas informações críticas, tu pode usar N metodologias de segurança, o cara vai tomar controle da máquina em questão de segundos. :P

          Tem que haver o isolamento das informações críticas independente da metodologia usada. O HMAC (recomendado pela OWASP) na situação de isolamento aumenta o nível segurança. Se o invasor obter acesso ao servidor, ele de alguma forma vai ter acesso ao arquivo que usa o banco de dados e vai poder fazer as consultas no banco de dados. É uma camada que foi quebrada. Mas se o isolamento for feito corretamente, ele não vai ter como descobrir as senhas dos usuários que estão presentes no banco (usando a chave pública + salt cadastrado no banco), pois ele não vai ter acesso à chave pública.

          Segurança é uma área bem complexa, he he he. Isso que eu ainda devo estar esquecendo de algum detalhe. Meu professor de Introdução a TI na faculdade é consultor e pesquisador de segurança no CPqD, nas aulas dele ele levantava vários pontos assim, coisa de louco! Ele que me recomendou o site da OWASP. :)

          • Respondi no lugar errado. :/

          • acustodioo
            1c

            Posso está sendo meio chato, mas se for só este o ponto, não vejo muita diferença, quem consegue uma senha consegue duas com a mesma facilidade, se tratando do mesmo sistema.

            Mesmo se fazer uma tabela separada para chaves, não sei se seria uma grande barreira para o invasor, mas se você disse que deve ter mais coisas, pode ser interessante mesmo, depois vou pesquisar mais sobre, obrigado. :)

          • É como eu falei: segurança em múltiplas camadas. Isolamento de arquivos críticos, chave pública + salt aleatório na geração de hashes, senhas fortes e diferentes para servidor Web/FTP/banco de dados, proteção contra RFI/LFI, proteção contra XSS, e por aí vai. Você vai criando diferentes barreiras em cada camada, de modo a dificultar a ação de um invasor numa eventual invação por alguma delas (camadas). São muitas ações a serem tomadas, a segurança vem do conjunto delas.

            Recomendo fortemente a leitura dos artigos da OWASP e CERT, ótimos conteúdos:
            http://www.owasp.org/
            https://www.securecoding.cert.org/

          • acustodioo
            1c

            Eu entendi o que você quis dizer.

    • Esse lance loco ainda é usado?

      • Precisa, né? :P

        A OWASP, no entanto, recomenda o uso de HMAC no teste de integridade, preferencialmente com uma função de hash mais segura que o SHA-1, que já possui falhas de segurança conhecidas.

        Citando:

        Rule – Only use strong cryptographic algorithms

        Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a “strong” cryptographic algorithms change over time.

        [...]

        Use salts when appropriate. Note that integrity should use a MAC such as HMAC-SHA1 or even better, HMAC-SHA256.

        Rule – Store the hashed and salted value of passwords

        Store the salted hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

        [...]

        E por aí vai. Maiores recomendações: Cryptograhic Storage Cheat Sheet

        • acustodioo
          1c

          Não sabia dessa, achava o SHA1 extremamente seguro, pelo que li em vários lugares, mas é assim mesmo as coisas sempre ficam inseguras com o tempo, vou ler este texto, obrigado pela dica.

          • O problema do SHA-1 é que a resistência à colisão dele foi comprometida (assim como o MD5), o que aumenta as chances de um futuro ataque. Diante disso, as autoridades em segurança recomendam o uso dos hashes da família SHA-2, preferencialmente o SHA-256 ou SHA-512.
            Ainda assim, assombra o medo de que a família SHA-2 possa ser comprometida com um possível ataque bem sucedido ao SHA-1, e por conta disso a NIST já lançou uma competição para criar o SHA-3. :)

  • @trovalds
    704c

    Como não tem como editar: http://en.wikipedia.org/wiki/SQL_injection

  • Amadorismo foi pouco nessa, droga por que nao pensei nisso antes!

  • Esse pesadelo me apavora desde que comecei a fazer sites dinâmicos… vou lá dar uma conferida se não sobrou nenhuma falha… ^^

    • Ah tá né… dai sim. Vou fingir que acredito.

  • Já pode se desmanchar de rir? KKKKKKKKKKKKKKKKK

  • Marcoscs
    930c

    sql injection é coisa de script kid, fala sério…

    • SQLI pode até ser muito usado por script kid por ser uma vulnerabilidade com programinhas prontos, mas não interessa, vuln é vuln… Provavelmente o cara que descobriu onde estava essa vuln, talvez em um cookie, nao foi kiddie.

  • Alexandre
    3968c

    /FACEPALM

  • @brunogdb
    4239c

    SQL invadido pelo SQL é foda ‘-’

    • Rafael The Mist
      670c

      Quase a mesma coisa que o filho roubar a loja do pai. hehehehe.

      • @brunogdb
        4239c

        kkkk, é mesmo!

    • LOL, kkkkkkkkkk

    • É isso que me deixa desconformado… é coisa de funcionário demitido descontente que sabia da falha e guardou o gatilho… por que foi anos e anos sem dá uma tetinha no site da SUN… ORACLE chegou faz quanto tempo?

  • FAIL!!
    isso ai é uma falha de segurança do banco e falha eterna (espero estar errado) do php.

    • Adriano
      318c

      Isso não é falha do PHP e sim do desenvolvedor

    • O PHP só dá uma mãozinha, apenas isso. :P

    • Nada a ver com o PHP ou com o MySQL…

      Pura burrice do desenvolvedor.

      Ele não explorou uma falha da linguagem e sim do amadorismo do programador.

    • PHP não tem falha de banco, só de procedural interno de classes ou de bibliotecas. E outra, além de filtros que podem ser criados contra SQL Injection… PHP tem uma coisinha chamada PDO, que pode não resolver todos os problemas, mas elimina uma barra.

  • Unbelievable! A imagem diz tudo!

  • e.ricardo
    217c

    Tenso isso cara espero que os caras da MySQL arrumem o quanto antes isso e que sirva de lição para todos não existe um ambiente 100% seguro !

  • todos ri.

  • Epic Fail….

    #SemMais

  • Realmente foi infeliz eles terem que passar por isso, mas só demonstra que ninguém está livre de “bugs”

  • Desculpa, foi eu =D

  • ahuhauhauhauha EPIC FAIL FOREVER

  • Gabriel /o/
    24c

    [POULTZ!@@] http://www.edurebecca.com/poultz/img-poultz.jpg

  • A façanha foi obtida por Blind SQL Injection ainda por cima, o que em teoria é ainda mais difícil.

    Curioso. Cadê as prepared statements ou stored procedures?

    Li que o site da Sun também foi explorado. Logo, um presente de grego da Sun para a Oracle. :)

    • Exatamente o que pensei e escrevi antes.

  • EMS

    seus nerds

  • Pura incompetência de quem programou o site. Já me deparei com um servidor de SQL de uma grande empresa no Brasil que o usuário da conexão do banco era o “sa”. Logo, era possível no Sql Injection passar o comando “;shutdown” que simplesmente desligava o servidor sem nenhum aviso.

  • Turdin
    3346c

    Epic Fail completo!

  • Leonardo

    Acho que um estagiário perdeu a cabeça na guilhotina hoje…

  • fail total, hehehe!

  • SQL Inception.

  • Ironia do destino… Não esperei que o MySQL fosse capaz de dar uma bandeira dessas. O pensamento devia ser “ah, somos o MySQL, ninguém vai achar que a gente é vulnerável a uma SQL Injection, então não precisamos nos dar o trabalho de proteger o sistema contra isso”, só pode.

    • Cara, quantos anos com essa falha de mirim e só agora alguém chama eles na guavirova.

  • Não esqueçam que pode existir conspiração por trás disto tudo:
    MySQL fraco? Mais um motivo pra usar SGBD pago… tipo assim, Oracle!
    Business is business!

    • Que isso, a ora que a ORACLE engolir o MySQL, ninguém vai sentir, só mudam uma letrinha e fica tudo a mesma b&%@#4

  • Adorei o godzilla facepalm. Eu vinha usando o tactical facepalm para coisas épicas como essa. http://shadowgod55563.deviantart.com/art/Tactical-Facepalm-172492051

    SQL Injection foi o mesmo truque usado pelo grupo Anonymous para hackear os servidores da HBGary Federal, empresa que presta serviços de segurança para o governo dos EUA, e fazer o CEO Aaron Barr tomar um pwn épico e ser demitido. Procure por “How one man tracked down Anonymous—and paid a heavy price”

  • O mais legal é que a MySql foi comprada a pouco tempo pela Oracle

    sim, a maior empresa de database!

  • Gustavo
    7c

    Certeza que a senha do diretor era: 1234

    • Quase. A senha do MySQL’s Director of Product Management era 6661: http://pastebin.com/raw.php?i=BayvYdcP

      Haviam senhas como phorum5, qa e até abracadabra. Pois é.

  • Fabio

    Isso serve para baixar um pouco a bola da Oracle,, que comprou a SUN pensando que com isso iria comprar junto a comunidade,, essa nova agressividade comercial, solaris pago, descontinuidade do opensolaris, intrigas no openoffice,e outras coisinhas mais não foram bem vistas ,aliás arrogância nunca é bem vista… Aparentemente a Oracle simplesmente não sabe para onde ir, pensou que abafaria a concorrencia simplesmente comprando..? Simplesmente se enganou. O mundo hoje dos grandes é software Livre,, aliás parabéns IBM com o Watson rodando Linux.

  • É! Amadorismo foi pouco!

    a minima proteção contra SQL Injection qualquer iniciante acha em tutoriais pela web e implementa sem dificuldades! Ainda bem que as criaturas responsáveis pelo site não são os mesmos por trás do desenvolvimento do MySQL…

    E nõ adianta jogar a culpa no PHP ou no próprio MySQL pelo fato de que a falha foi humana, não foi explorada nenhuma falha de sistema, foi só burrice mesmo!

  • Há certamente uma grande variedade de detalhes , como que para ter em consideração. Que poderia ser um bom nível para entregar -se. Eu ofereço as idéias acima como inspiração comum no entanto claramente há questões como o que você transmitir até onde o fator decisivo pode estar trabalhando de boa fé, honesto. I don t sei se melhores práticas têm surgido em torno de questões como essa, mas tenho certeza de que seu trabalho é claramente reconhecido como um jogo justo . Meninos e meninas realmente sentir o efeito de apenas um segundo de prazer , para o resto de suas vidas.

  • Posso apenas dizer que é um alívio para procurar alguém que realmente sabe o que eles estão falando na internet. Você sabe , sem dúvida, métodos fáceis para trazer uma dificuldade para suave e torná-lo importante. Mais gente tem que ler isso e entender esse lado da história . Eu não posso imaginar você não está mais comum, porque você definitivamente tem o dom .

Deixar comentário:

Leia | Política de Comentários.