Falhas antigas em sistemas modernos — SQLi
Navegando pelo site de um laboratório da cidade onde moro pude notar que eles possuem uma área para acessar resultados de exames. Ao clicar no link aparece uma tela onde posso escolher acessar uma área do paciente ou uma área do médico, porém ambas me redirecionam para a mesma url com um formulário para login.
Acessando essa nova tela, a primeira coisa que pude notar foi a url com o domínio “zapto.org” que é um dos domínios fornecidos pelo no-ip. Podemos deduzir, então, que o servidor onde são armazenados os exames é local e não remoto, pois necessita de um serviço de dns dinâmico para acessá-lo o que significa que não possuem um ip real para o mesmo. Utilizando o whois para analisar o ip atribuído ao domínio, pude verificar que ele pertence à um provedor da própria cidade, o que comprovou a hipótese acima.
Voltando ao formulário de login, resolvi tentar algumas combinações de usuário e senha comuns. Sem sucesso, resolvi tentar um simples SQLi e fiquei surpreso ao descobrir que estava vulnerável. Utilizei o usuário admin e um simples 'or'1'='1 na senha e pronto, estou logado como administrador.
Já no sistema vemos um novo formulário para consultar os exames. Nele podemos preencher as informações do nome do paciente, modalidade do exame e o ano em que o exame foi feito.
No campo para preencher o nome do paciente pude notar que ele faz a consulta utilizando um LIKE no banco de dados e possui um wildcard % embutido no final do parâmetro.
Quando pesquiso utilizando um nome, a consulta me retorna resultados.
Quando pesquiso pelo sobrenome, nenhum resultado é retornado.
Mas pode ser facilmente burlado inserindo o wildcard % no início da consulta.
Brincando com o formulário, pude notar que a consulta é feita via GET, portanto todos os parâmetros são passados na URL e é aí que a brincadeira começa a melhorar.
Testando alguns payloads na URL, pude descobrir que o parâmetro ‘ano’ estava vulnerável à SQLi e que o banco de dados utilizado é o PostgreSQL, pois função PG_SLEEP passada no payload foi executada com sucesso atrasando o retorno das informações.
Com as descobertas feitas até o momento utilizei a ferramenta Sqlmap e automatizei um pouco as coisas para obter novas informações. Ao final dos testes consegui obter um dump completo de 431 tabelas do banco de dados com o nome dos bancos utilizados, as tabelas, dados das tabelas, usuários, entre outras informações.
A falha foi reportada no dia 21/02/2019 à equipe técnica da empresa para que as devidas correções possam ser efetuadas.
OBS: Nenhuma informação do banco de dados foi alterada e/ou apagada. O acesso foi feito apenas com fins educacionais para mostrar que vulnerabilidades simples e conhecidas ainda são encontradas em sites importantes nos dias de hoje.
