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.

Comentários

Envie uma pergunta

Os mais notáveis

Comentários com a maior pontuação

rockb
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 .
A-soms
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.
@RhubeStrange
É! 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!
acustodioo
Eu entendi o que você quis dizer.
Paulo Freitas
É 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/
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.
acustodioo
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. :)
Paulo Freitas
Respondi no lugar errado. :/
Paulo Freitas
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. :)
acustodioo
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.
Paulo Freitas
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 é.
Paulo Freitas
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
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. :(
Paulo Freitas
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. :)
Paulo Freitas
[...] 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
Exibir mais comentários