Proponha uma correção, faça uma sugestão
MySQL permite acesso mesmo com passwords erradas
O MySQL é provavelmente a base de dados mais usada no mundo, dando suporte aos mais diversos serviços. Por norma, tudo o que é credenciais de utilizadores, configurações e outros dados sensíveis, ficam armazenamos nas base de dados associadas aos serviços e espera-se que o nível de segurança seja inquestionável.
No entanto, soube-se entretanto que especialista de segurança descobriram graves vulnerabilidades no MySQL e MariaDB (variante do MYSQL), que permite a um atacante aceder a um servidor MySQL e entrar até com uma password errada!
De acordo com Sergei Golubchik, coordenador da área de segurança do projecto MariaDB, esta vulnerabilidade está presente nas versões 5.1.61, 5.2.11, 5.3.5, 5.5.22 e inferiores, e afecta várias distribuições Linux. (Ubuntu, openSUSE 12.1, Arch Linux, Fedora 16, entre outros). Segundo Golubchik, esta vulnerabilidade pode também ser explorada no MariaDB.
Mas o que causa tal bug?
Numa pequena informação publicada já online (ver aqui), Golubchik refere que o MySQL guarda apenas o hash das passwords dos utilizadores, adicionando também uma sequência de caracteres aleatórios que dificultam outro tipo de ataques (ex. força bruta ou ataques dicionário). Na prática o que acontece é que, em determinadas situações, no processo de comparação entre a password introduzida pelo utilizador e a password armazenada, a validação dá um OK, mesmo as passwords não sendo iguais.
“When a user connects to MariaDB/MySQL, a token (SHA over a password and a random scramble string) is calculated and compared with the expected value. Because of incorrect casting, it might've happened that the token and the expected value were considered equal, even if the memcmp() returned a non-zero value”
Assim sendo, o atacante apenas necessita de saber o nome dos utilizadores registados para acesso ao MySQL (incluindo o utilizador root) e tentar assim o acesso à base de dados.
Golubchik fez também saber que a probabilidade de acesso com sucesso é de 1 em 256 tentativas, isto porque, como referido, são adicionados um conjunto de caracteres aleatórios que dificultam outro tipo de ataques.
Uma vez detectada a vulnerabilidade que foi registada com o código CVE-2012-2122, estão já disponíveis os patchs para MySQL (aqui) e MariaDB (aqui), que permitem minimizar os riscos de segurança.
Joshua Drake, um programador da Accuvant Labs, disponibilizou também um pequeno script que permite verificar se os nossos servidores estão vulneráveis. Esse script pode ser descarregado aqui.
Download: Patch CVE-2012-2122 MySQL | MariaDB
Download: Script para verificar se o seu sistema é vulnerável (aqui)
Este artigo tem mais de um ano
Loading ...
UPS
De que forma é que isto pode afectar e comprometer a segurança de um utilizador comum de uma distro Linux?
Para um utilizador vulgar…nao é grave. Para um linux em produção, pode ser gravíssimo!
UPS #2#
e por isto (e por outras) q nao se usa mysql em sistema importantes
Não? Então usa-se o quê?
PostgreSQL, Oracle, SQL Server…
Ah..são mais seguros. Pois tá bem
Não disse que concordava, pensei que estivesses à procura de outras bases de dados, e como tal dei exemplos de outras.
Falhas existem em todos, agora que uma bd Oracle ou Sql Server não é a mesma coisa que MySql isso não é com toda a certeza. Alem de acabarem por ter públicos alvos diferentes e tudo.
Hombre, tás parvo?
Sabes quantas falhas de segurança foram descobertas no SQL Server 2008 desde que foi lançado?
Que tal nenhuma!
(As 2 falhas que estão lá no site da Secunia não são do SQL Server 2008, são de componentes auxiliares que o SQL Server 2008 instala mas não precisa para funcionar)
Nenhuma?? Então queres dizer que os Service Packs que lançam para o SQL Server apenas metem os botões e menus bonitos??
bem e que tal… recuar mais um pouco para as versões anteriores?
FORAM detectadas várias falhas.. depois eles descontinuam os produtos, e passam para nova versão… estamos agora a migrar para o 2010.. 2012 e os anteriores deixam de ser “comparticipados” … já para não falar das licenças caríssimas.
Eu recomendo em ambiente de produção MySql… agora é preciso é saber mexer num servidor e proteger o mesmo para vários (e não digo todos) os tipos de ataques.
Perhaps Oracle
Então e quando surgirem falhas/bugs nos sistemas concorrentes? Também se deixa de usar?! Mas que resposta mais idiota. Falhas, bugs, existem em todos os sistemas. O mais importante é resolver o mais rapidamente possível.
Do not feed the trolls…
Provavelmente a personagem nem sabe o que é uma base de dados…
O Facebook PHP também 🙂
Não é verdade. O Facebook MySQL se não estou em erro!
*usa MySQL
100% correcto sobre o FB. As falhas acontecem em qualquer sistema e claro a gravidade depende de como se configura o servidor (acesso root, restrições IP, etc). O mesmo se aplica aos outros grandes players.
Todos os “mais mediáticos” à muito que abandonaram o MySQL em favor de sistemas do tipo NoSQL.
Google it!
Ou melhor, “DuckDuckGo” it! 😛
Ou então fazes o que se deve realmente fazer, que é manter uma infraestrutura de redes muito segura e bem configurada e optimizada. Aí deixas de te preocupar com este tipo de falhas.
Não digam barbaridades, quantas mais falhas se descobrir melhor, mais falhas se corrige, é como o Windows, quer queiram, quer não, o Windows é o sistema operativo mais seguro do mundo por enquanto.
Ena tanta ignorância numa só pessoa…
não é o mais seguro mas percebe-se o que ele queria dizer….. devido a tantos ataques sofridos pelo windows ao longo dos anos ele amadureceu para o que é agora um sistema bastante seguro… pelo menos bem mais do que o mac os
@Jose Estragas-te tudo quando disseste windows aí pelo meio. Se tivesses dito Linux, não te tinha calhado tão mal, mas mesmo assim linux não é perfeito.
Bingo
Serva
Isso só pode ser uma piada…
É por isso que é habitual em mainframes usar todo o tipo de sistemas que não o windows! Ou por exemplo…. que tal a bolsa de Londres que mandou tirar tudo o que era windows!
Tem Juízo…
Se disseres que o Windows é dos melhores sistemas para a jogatana aí estamos todos de acordo!
Ai mandou? Quando?
Olha que recentemente fizeram um novo acordo… se não sabes… google it. Isto de falar sem bases concretas já chateia. Deixa de ser fanático.
E olha, em mainframes, nem linux nem unix, se não sabes… google it…
Que eu saiba pelo menos nos mainframes da IBM podes usar linux
Como podes ver aqui :
http://www-03.ibm.com/linux/
a ibm certifica o Linux para TODOS os sistemas.
E aqui podes ver que SIM o linux corre nos mainframes da IBM pelo menos
http://www-03.ibm.com/systems/z/os/linux/
Quanto a bolsa de londres a informação que se obtem googlando confirma o que o colega disse , migraram para Linux
Este é apenas um exemplo :
http://www.information-age.com/channels/information-management/news/1602213/london-stock-exchange-migrates-to-linux-platform.thtml
A resposta ao Quando …
esta por ex aqui http://www.computerweekly.com/feature/London-Stock-Exchange-completes-15-month-system-replacement
14 February 2011
e sim o sistema é baseado em linux
ou aqui :
http://www.zdnet.com/blog/open-source/the-london-stock-exchange-moves-to-novell-linux/8285
Gostei da parte em que é dito :
“The LSE is far from the only one stock exchange to switch to Linux. More and more stock exchanges are realizing that when you really need speed, security, and stability, Linux is the operating system you need”
Tens razão Rui Moreira, errei, estava desactualizado na informação da transição da bolsa. Confundi o novell com a microsoft.
Nos sistemas operativos não estava a dizer que não podiam correr linux, estava sim a falar dos sistemas z da ibm, por exemplo: o z/OS.
Cumps.
É por isso que eu adoro este espaço…trocam-se ideias, aumenta-se o know how e aprendemos uns com os outros. Assim é que devia ser sempre
Este senhor não deve saber que existe mysql para windows.
Perdoai-lhes senhor, eles não sabem o que dizem!!
como é que se usa o script?
Esse script não está completo, faltava o include time.h
http://pastie.org/4073708
Oi David,
Obg pelo update o script
tambem nao sei como executar o script, podes ajudar sff?
a mim parece-me ser script em C.. mas como é que executo no servidor que está a correr no Ubunto ?
Obg
gcc -o younameit code.c
younameit – o nome que queres dar ao bin
code.c – a source do script neste caso
Oi Guilherme,
muito obrigado, correu na perfeiçao 😉
felizmente os meus seridores nao estao sugestos a esse bug =) uuufaaa
bem… “*probably* not vulnerable..”
Também se pode testar rapidamente com:
for i in `seq 1 1000`; do mysql -u root –password=qqtreta -h 127.0.0.1 2>/dev/null; done
Thanks
Serva
e como se usa, por exemplo num site com joombla ?
não é preciso, o joomla é um buraco muito maior. primeiro é preciso apagar o joomla e meter algo decente. tipo drupal. depois sim, corrige-se o problema do mysql
lololol
ou wordpress com os plugins correctos…
Bem será que as nossas contas do facebook estão a salvo?
Nada no facebook está a salvo, desengane-se que assim pensar…
😀 lololol
Nada na internet está a salvo , nem na realidade.
Se a segurança do facebook depende-se só da segurança da sua base de dados, todos os dias era hackeado!
se estão no facebook, não estão a salvo, visto já estarem nas mãos do facebook. 😉
A notícia apenas dada desta forma, soa-me a pouco. Mas, com milhares de programadores, tenho a certeza que já há ou houve correcções de falhas entre outros problemas.
Aliás… é mais habitual a descoberta de falhas em sistemas open-source do que em sistemas proprietários ao contrário do que muita malta pensa. E, obviamente é despoletada uma solução adequada.
Sem dúvida , bom comentário @Hal .
Cumprimentos
Serva
Eu estou a salvo dessa vulnerabilidade, estou a usar InnoDB. :-p
Obrigado por este artigo! Não sabia mesmo desta falha e pelo que vi, tenho alguns servidores vulneráveis, vou ver essa questão 🙂
Aproveito para fazer uma questão relacionada com o assunto. Que fontes vocês utilizam para informações sobre vulnerabilidades deste tipo? Se possível, apenas relacionadas com OpenSource, Linux, etc.
Abraço e obrigado.
Oi
umas das que uso para este tipo de testes é o OpenVAS
Os meus sistemas estão uptodate, como tal isto já é passado!
wtf..
Não é preciso ser-se muito inteligente para perceber que as funções de HASH, tanto MD5, como SHA-1, etc, não são perfeitas. Existe uma infinidade de combinações. Se o algoritmo não for muito bom (não há algoritmos perfeitos), existem várias combinações que originam a mesma HASH. Uma das soluções seria guardar a própria password, com uns caracteres pelo meio, também. Deste modo comparar-se-ia a HASH e a password devidamente tratada.
Quem fala no MYSQL, fala também de sites pessoais/empresariais desenvolvidos por pessoas que não estuda bem todas as decisões antes de os realizar.
O problema não é o algoritmo de hash não ser bom, o problema é que quando é feita a validação do retorno da função memcmp().
Até porque, estatisticamente, a probabilidade de duas strings pequenas gerarem a mesma hash SHA-1 é muito menor que 1 em 256. Ainda para mais se se considerar que o MySQL usa sal nas hash (e é por isso que a probabilidade de se “acertar” na senha é 1 em 256, se não fosse isso era 1 em 1)
Ou pelo menos é isso que o sr. Golubchik diz…
Concordo , eu fui um deles no fim de semana passado , mas nada de grave aconteceu entretanto , vou é sacar já as patches que o Pedro Pinto teve a amabilidade de colocar as hiperligações , no entanto o que li é que estas Patches podem resolver , não que resolvem .
Abraço a todos
Serva
Como se pode verificar esta vulnerabilidade no MAMP Pro?
Grato.
Primeiro, não deverás estar preocupado com o mamp pro, porque isso é para uso de desenvolvimento nunca deverá ser para uso de produção. Se estiveres a usar isso para produção só te posso dizer “Shame on you!”
sim só uso em testes. Shame one me! por não me ter lembrado disso. A cabeça não dá para tuso. Obrigado César.
onde se lê «tuso» deve ler-se «tudo» nem para escrever hoje estou bom!
Cheira-me a grande aldrabice. Só dizem que pode haver colisões na hash que é gerada mas isso não quer dizer que se pode aceder com quelquer password. As colisões existem mas quem descobre a password errada para entrar também descobre a correcta! E não digam mal do MySQL que a Oracle é a mesma coisa ou pior. Ainda me recordo de um bug na 10gR1 que se alguem se tentasse conectar com um cliente OCI8 mandava a instancia abaixo mesmo com a password errada! Se isso não é grave….
Oi?!…xiii :S que mau… :S
Então estamos feitos?! :S
Pelos vistos quem tiver o Arch Linux actualizado também não será afectado por este problema:
$ mysql –version
mysql Ver 14.14 Distrib 5.5.24, for Linux (i686) using readline 5.1
$ ./a.out
Not triggered in 10 seconds, *probably* not vulnerable..
Como se usa esse script para verificar a vunerabilidade do mysql em Windows?
Primeiro experimenta na consola.. Format c:
Depois pôe o Linux 🙂
Por um lado isto é bom, quer dizer que o problema esta detectado e que vai ser corrigido.
O que não nos mata torna-nos mais fortes.
Hmmm, a parte mais técnica do artigo está mal explicada… Da primeira vez q li o artigo não percebi a falha. Depois de ler o original (em inglês) percebi.
No parágrafo explicativo é usado o termo password de forma errada. Não são as passwords q são comparadas mas sim, como o autor diz em inglês, “token and the expected value”.
Pronto se calhar tmb nao me expliquei mto bem xP e percebo q queiram simplificar as coisas… Só queria dar o meu input 😉
A pergunta óbvia é…
Porque é que alguém tem um servidor com o MySql (ou qualquer outro) exposto na Internet?
Não duvido que haja razões válidas para isso, mas quais?
Nem sempre o perigo vem da internet… um utilizador de uma rede local pode ganhar acesso ao servidor mysql.
Talvez seja possível até que esta técnica funcione também com um simples script PHP.
+1
ainda pior se for na porta default 😐
Ai quer dizer que um SQL Server é mais robusto e seguro é, ou não será mais fácil ainda penetrar estes serviços? A resposta é simples… SE ESTÃO NA NET estão inseguros, cabe ao administrador assegurar a proteção e manutenção do servidor.
Nada como verificações extra no servidor para autenticação, para por exemplo banir o utilizador durante X tempo depois de 3 tentativas falhadas em qualquer serviço.
Isto que sirva de lição para os que usam a cloud para armazenar informação sem saber o que por lá se passa.
Facebook?? Hello 😛
apt-get update
isto faz milagres e corrige os vossos servidores
Não sabes nada do mercado enterprise, pois não?
Tens noção da asneira que acabaste de dizer?
Updates em servidores faz-se apenas quando há bugs ou correcções ou features necessárias nas novas actualizações.
Em caso algum se faz update ou upgrade ao sistema operativo inteiro. É esperar que tudo o que foi instalado/compilado comece a falhar…
Boas
Percsava de uma ajuda,tenho um servidor com o CentOS 6.2 que tem o MySQL version 5.1.61 e gostara de atualizar para este e nao estou a conceguir!
Algem da umas dicas?
Agradecido
Ja para não dizer que qualquer administrador que se preze , vai fazer das 3 uma :
1 – colocar o mysql a correr agarrado ao localhost
2 – restringir o acesso por user/IP
3 – Não export a porta do mysql para “fora”
Mais sobre o assunto em :
https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql
Bom, este artigo não está bem explicado.
Praticamente todos os sistemas, pelo menos os que tenho conhecimento, guardam apenas um hash da password de um utilizador, nunca sendo o hash unívoco. Aliás, só podia ser desta forma, senão um administrador do sistema poderia simplesmente ver as passwords de toda a gente…
Logo, o problema de passwords diferentes gerarem o mesmo hash está presente na vasta maioria dos sistemas. No entanto, isto não é um problema em si dado que a probabilidade de isso acontecer é uma em um trilião ou mais (valor apenas demonstrativo de um número muito grande)…
O problema neste bug tem a ver mais com “Because of incorrect casting, it might’ve happened that the token and the expected value were considered equal…”, o que faz com que a probabilidade da geração do mesmo hash com a password errada baixe de um em um trilião para 1 em 256, ficando este último valor abaixo do número de tentativas de acesso que o mySQL permite até bloquear o acesso, que é 300.
E é aqui que está o problema…
Boa explicação mas que de facto, por consequência, vai bater naquilo que foi referido.
Olha, na minha maquina diz:
“Vulnerable! memcmp returned: -189”
🙁