Site do MySQL atacado via SQL Injection
Parece que o feitiço se virou contra o feiticeiro, mas segundo informação disponibilizadas no site Techie Buzz, a página oficial do projecto MySQL (motor de base de dados bastante popular) foi atacado através de um mecanismo denominado de SQLInjection (alguns sites referem que foram utilizados mecanismos mais elaborados como XSS e blind SQLi).
Ao que tudo indica, além do ataque ter sido efectuado com sucesso foram ainda “roubados” dados importantes da empresa. O ataque ao que consta foi realizado através de uma página de consulta de cliente, tendo já sido divulgadas algumas passwords, inclusive a de um Director de produtos do MySQL com apenas 4 dígitos. Algumas passwords de administradores do serviço blogs.mysql.com foram também já tornadas públicas.
Mas como funciona um ataque de SQL Injection?
O SQL injection tal como o nome indica é um mecanismo que permite “injectar” instruções SQL dentro de uma consulta (query) realizada à base de dados. Desta forma, o hacker pode “construir” a query SQL e obter informações privilegiadas que se encontram guardadas na base de dados (ex. passwords de utilizadores).
Imaginem por exemplo um formulário HTML para autenticação de um utilizador num determinado site. Depois do utilizador carregar no botão enviar, é executado no MySQL a seguinte query SQL:
SELECT user,passwd FROM users WHERE user = 'pplware' AND passwd='123456' |
Os dados user e passwd são passados via POST numa query do tipo:
SELECT user,passwd FROM users WHERE user = '$user' AND passwd='$passwd'; |
Agora imaginem que é um hacker e que no campo password colocou:
'123456';DROP TABLE users; |
Neste caso a query ficava algo do tipo:
SELECT user,passwd FROM users WHERE user = 'pplware' AND passwd='123456';DROP table users; |
Veja uma demonstração de como funciona o mecanismo SQL Injection:
Caso seja um utilizador com conta no site mysql.com é aconselhável que proceda rapidamente à alteração da sua password.
Este artigo tem mais de um ano
No php.ini basta colocar esta directiva magic_quotes_gpc = on, que aliás já vem por defeito. Ainda dizem que o php é pouco seguro…
PHP pouco seguro??? na na :), Todas as linguagens implementam segurança, no entanto a forma como se desenvolvem certos sites pode não ser a mais correcta.
E usar prepared statements?
ah…espera…é algo muito novo no PHP 😛
muito novo?? lol
mysqli….
Exactamente, para isso o MySQLi foi criado, para além de ser mais rápido e mais seguro que o MySQL.
MySQLi e PDO. 😉
Cuidado com o excesso de sabedoria.
Há formas de fazer bypass a isso.
Aliás, as coisas bem vistas, a única forma de ser +/- seguro é não permitir input do utilizador. O SQL é muito vulnerável, sendo que há técnicas de topo que conseguem contornar a maior parte dos controlos de segurança.
Excesso de sabedoria?!?!? Isso existe? Algum hype?
o php é seguro, os programadores é que nao sao
Tudo dito.
Não sei que servidor web usas, mas se usas o Xampp, Lamp ou Wamp, o magic_quotes_gpc vem por defeito desactivado, mas já desde que descobriram as suas grandes falhas.
Agora usa-se o mysql_real_escape_string e outras formas seguras.
Ninguém está a salvo.
Sou só eu ou a imagem to topico faz um efeito esquisito na pagina inicial se andares para cima e para baixo
Ilusão de óptica, da a sensação de estar a fazer zoom 🙂
É o efeito “SQL Injection” 🙂
por acaso faz… é mais uma ilusão óptica..
eheh.. reparei exactamente no mesmo, e diverti-me com o scroll do rato ainda 5 segundos 😀
O exemplo que está assim não me parece totalmente correcto, porque tendo esta query para consulta:
SELECT user,passwd FROM users WHERE user = ‘$user’ AND passwd=’$passwd’;
e ao introduzir como password => 123456;DROP TABLE users;
ficaria assim SELECT user,passwd FROM users WHERE user = ‘pplware’ AND passwd=’123456;DROP table users;’;
e não assim
SELECT user,passwd FROM users WHERE user = ‘pplware’ AND passwd=’123456′;DROP table users;
Acho eu, mas posso estar enganado, mas penso que o correcto é ficar tudo entre plicas e nesse caso já não se consegue SQLInjection, correcto?
É uma questão de pelicas 🙂
Pois…mas as plicas distinguem o código SQL da String o que faz toda a diferença 😀
mas aqui o objectivo é dar a entender o que é SQL injection e não são precisos muitos pormenores…se não, quem ler isto fica expert em injectar SQL e o número de casos aumenta 😀
123456′;DROP TABLE users;–
Não se percebe bem. A ideia é fechar as plicas e no fim comentar o que vem a seguir com dois hífens.
Este problema é tão antigo será que é assim tão difícil de resolver?????
Comentário de alguém, que percebe mesmo pouco de programação e BD’s…
É antigo, mas as vulnerabilidades de SQL injection e XSS estão mesmo assim no top de vulnerabilidades em aplicações web.
Tens este estudo da OWSAP, para teres uma ideia.
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
A culpa é mesmo quem desenvolve as aplicações, preocupado mais em funcionalidades que propriamente em pormenores de segurança das suas aplicações. Sem falar que há também muita falta de preparação para mitigar estas vulnerabilidades de algumas pessoas que programam.
Até pode ser fácil de resolver, o problema é a formação que nos dão (ensino fraco e antigo).
Falo por mim, antigo aluno ensino profissional. Nunca tive aulas sobre segurança e os exercícios que tinha, maior parte, eram de caca… O que me preparou para o mercado foi o projecto final de curso e o estágio, que é uma coisa mais a sério…
O resto se quis saber tive que estudar em livros (que não da escola) e na net…
há muita informaçao. é procurar. os professores nao vao ensinar isso.. maioria nem o sabem.
http://codeassembly.com/How-to-sanitize-your-php-input/
O engraçado aqui não é fazer Drop Tables, é conseguir o retorno de dados apresentado na página
o exemplo nao ia funcionar ( no PHP )
mysql_query() nao suporta queries multiplas.
o DROP table é mesmo só para “divertimento” (go:evil)
Será que não?
Eu assim sem testar, era capaz de dizer que é possível fazer o drop table dentro de uma query. O que resultaria em 2 querys inseridas numa.
Não sei se estarei correcto.
Já ouviram falar do mysqli????
Bruno,
Queres escrever? 🙂
ninguem está a salvo, mas ha sempre a hipotese de dificultar as coisas e tornar um sistema de login mais seguro.
Escapar os dados enviados para o mysql : mysql_real_escape_string(),
e Validar os dados retornados pelo mysql com os dados inseridos pelo utilizador.
Para não falar em limites de tentativas /tempo, origem do request (brute force)
Não é mt dificil pois não?
cumpz.
Sobre o ataque e as observações que leio limito-me a citar uma passagem bíblica “aquele que não tiver pecado que atire a primeira pedra”
Estive a reler os comentários e aproveito para “traduzir” o meu. Há aqui comentários bastante parvos que indiciam que poderá haver quem não perceba a mensagem. Tradução: “aquele que nunca deixou um bug, e/ou muito menos buracos de segurança no seu código que avise, certamente será um caso de estudo e haverá empresas a contratarem-no por valores milionários”
P.s.: Sr. readctor do artigo: Não me parece que o feitiço se tenha virado contra o feiticeiro. Seria verdade se eles (MySQL) alegassem ser impossível ataques de injecção de SQL e/ou eles próprios andassem por aí a promove-los. A primeira não é verdade, até porque qualquer motor de base de dados está sujeito a eles. É uma consequência das opções de design das API / SQL. A segunda também não. Uma possibilidade para combater estes problemas são os prepared statements como “jesus” mencionou no seu post aos leitores 🙂 (de qualquer forma podem haver implementações sujeitas a problemas também)
Sinceramente, nem sei o que dizer.. invasão por SQLInjection num campo de “consulta de cliente”.. custa acreditar.
Como é possível acontecer uma invasão tão simples num site de tal importância.
Será que foi isso mesmo que aconteceu? A antiga equipe do MySQL não tem nada haver com essa história? Uma pequena vingança contra Oracle = Sun Microsystems?
Muito estranho!
Simples? O exemplo citado no artigo é simples, no entanto há SQL injection de vários níveis.
Eu não entraria em teorias de conspiração, parece-me mais que alguma team quis ganhar créditos no IRC, há quem faça destas habilidades só para ter reputação, e SQL injection no mysql.com é do melhor…
As vezes pensamos que os ataques são altamente “elaborados” mas na prática são coisas simples.
Pedro, quando falo, por norma tenho algum conhecimento da situação. E blind sql injection, uso de chars especiais não é tão simples como isso. Por norma, os ataques são simples, ao site do mysql não me acredito que o tenha sido…
FAIL ‘xD
lool para se fazer isso tem de ser ter a pass
bem mais grave do que isto foi o que se passou com uma filial da Comodo que em Portugal nem se ouviu falar mas que pôs em causa toda a estrutura de como é feita autenticação na web
Para os que estão espantados: a falha não foi explorada assim tão directamente como no exemplo apresentado. Até porque o exemplo apresentado de simples SQLi não tem quase nada a ver com o ataque de BLIND SQLi e XSS que foi realmente efectuado.
Ia mesmo dizer isso. 🙂
Além disso, o exemplo apresentado não funcionaria, pois para fazer drop a uma tabela ela não pode estar a ser usada…
Há ainda a técnica ‘or 1=1’.
O impressionante mesmo foi o uso de Blind SQL Injection. Enfim, é como trancar a porta e abrir a janela. xD
Este ataque já foi mais que dissecado por várias fontes, é só pesquisar. 🙂
Abraço.
Se permite XSS, nem quero imaginar o que estes h@ck3rs poderiam ter feito…
Para além de terem drupado umas tabelas, só não fizeram mais porque não quiserem, ou porque não tiveram tempo para o fazer…
Quando um site está vulnerável a XSS, as coisas podem ir bem mais além do que só apanhar dados em forms… Por norma o PHP tem protecções contra o XSS e SQLi, só deixam o site vulnerável a estas coisas só porque querem… se as seguranças existem, que as usem.
Este ataque não foi feito de um dia para outro, quem fez isto já devia andar a sondar o site à muito tempo, e descobriu sítios por onde injectar javascript e SQL sem que dessem logo conta.
Pode ser que com isto, muitos outros programadores pensem mais em seguranças do que só na apresentação do site e em funcionalidades.
Não levem a sentido inverso do que queria dizer, eu sou contra o cibercrime e espero que sejam inovadas os meios de seguranças que existem de forma a combater o cibercrime.
Programadores e web developers existem muitos, agora os que programam a ter em conta a segurança são muito poucos.
Maior parte das empresas que desenvolvem sites, pensam so’ em:”Esta’ a funcionar, esta’ bom.”.
Ja vi sites, em que se mudava o cookie de login, para ‘admin’ e tínhamos acesso de admin… nem uma verificação de pass fizeram, nem um hash, nada…
É sempre bom alertar para este tipo de problemas que afectam a grande maioria das aplicações web. Todos os programadores devem estar alerta e ter muito cuidado com as entradas de dados na aplicações. Os dados de entrada devem ser sempre validados, os de saída também (para evitar XSS, por exemplo). Mas isso não é tudo, também não se deve esquecer a lógica do programa, por exemplo.