- Vocês são legais! Então, ninguém nos decepcionou ainda!
- Nós tentamos.Sim, a vida dos caçadores de vulnerabilidades é cheia de elogios específicos dos clientes e não de situações menos específicas. No ano passado, concluímos mais de cinquenta testes de penetração em diferentes empresas e, é preciso dizer, já vimos tudo. Uma senha para todas as contas e sistemas, armazenamento aberto de senhas em um banco de dados, os restos da funcionalidade de depuração em um ambiente de combate ... Portanto, quando nossos colegas do JSOC CERT
contaram várias histórias sobre investigações de incidentes cibernéticos, nós no departamento Pentest decidimos acompanhar e mostrar o outro lado da “barricada” »: Infraestrutura do cliente através dos olhos de um hacker. Hoje, falaremos sobre os protestos externos mais interessantes dos últimos tempos, quando tivemos que penetrar no perímetro interno do cliente, tendo apenas uma lista de seus endereços IP externos e nomes de domínio.
Odyn
Segunda:
- Pessoal, comece mais rápido com um pentest - você só tem 3 semanas para nos hackear. Mas lembre-se de que suas chances são mínimas: elas nos verificam todos os anos e não encontram pistas.
Após 4 horas:
"Nós já estamos dentro."
- Vamos lá? Não pode ser assim! Agora vamos verificar os logs ...
Sexta-feira:
- Droga, sério. Como assim ?! Mas como o tempo não deu certo, talvez você procure outra coisa?
Sim, sem dúvida.
E começamos a procurar. Examinando o perímetro da organização, encontramos um host no qual 4 aplicativos da web estavam girando, um servidor FTP e o painel de administração do phpMyAdmin travado. A análise de aplicativos da Web não revelou vulnerabilidades críticas (por exemplo, injeções de SQL, XXE, RCE etc.) que nos permitiriam acessar o servidor. Em algum momento, eles mudaram para o FTP - e aqui já era mais interessante: o acesso anônimo foi aberto no servidor, mas apenas para leitura.
Por vários dias, examinamos o conteúdo do servidor e encontramos algumas linhas estranhas nos logs - algumas senhas inseridas incorretamente para um dos administradores do aplicativo Web.
Com base nas opções erradas, assumimos a aparência da senha e ela surgiu. Decidimos experimentá-lo para o phpMyAdmin e, oh, um milagre, também surgiu. Em seguida, era uma questão pequena: fazer upload do shell, obter acesso à rede interna, ganhar uma posição lá e desenvolver já dentro.
É assim que a preguiça comum (e de que outra forma pode explicar a relutância em inserir senhas diferentes para cada painel de administração?) Abre caminho para hackers na rede interna da organização.
Por que depurar em um ambiente de combate?
A maioria de nossas descobertas ocorre por meio de aplicativos da Web e, frequentemente, encontramos “restos” curiosos dos tempos de desenvolvimento e teste. Muitas vezes, encontramos logs, alguns modos de depuração, mas nem sempre com a ajuda deles conseguimos realizar o RCE (execução remota de código).
Durante um de nossos clientes, descobrimos um sistema de CRM, no qual decidimos gastar um pouco mais de tempo (e, devo dizer, depois valeu a pena). Realizando a análise do aplicativo, encontramos os restos dos testes, que aparentemente foram utilizados no estágio de desenvolvimento. A autenticação ocorreu neles de uma maneira muito milagrosa: apenas o nome de usuário e o fato de passar um parâmetro contendo alguma senha foram verificados. Cinco minutos pesquisando e lendo a documentação padrão - e temos em nossas mãos o nome da conta interna do superusuário. Preencher o shell já era uma questão de tecnologia.
Outro exemplo No início do projeto, lançamos uma força bruta recursiva de subdomínios e a deixamos. Depois de algum tempo, para nossa surpresa, surgiu um subdomínio de quinto nível chamado test.debug.application.client.ru, no qual encontramos um aplicativo Web com o Adminer instalado lá. Este é um aplicativo de administração de banco de dados leve, em versões mais antigas das quais, se configuradas incorretamente, você pode interagir com um banco de dados SQLite sem uma senha.
O fato de não haver dados nesse banco de dados não era importante - afinal, no SQLite, você pode criar um banco de dados em um caminho arbitrário com um simples shell da web, ganhando a capacidade de gerenciar convenientemente o servidor e executar comandos a partir de uma página da web.
Tudo o que restou foi descobrir o endereço completo do aplicativo Web no servidor. Aqui fomos ajudados por todos os "amados" CMS 1C-Bitrix, que, em uma mensagem de erro, compartilharam conosco de bom grado onde estão localizados. Restou apenas preencher a casca e finalizar o projeto.
O trabalho com o SQLite DB pode ser visualizado
aqui .
Registros encontrados? Senhas como presente!
Um cliente nos pediu para realizar um teste de um aplicativo da web. Nos três anos anteriores, ele realizou protestos com outra equipe e provavelmente conseguiu consertar alguns dos buracos no perímetro, por isso não esperávamos sucesso rápido.
Durante a difusão do aplicativo da web, encontramos uma página na qual a autorização do usuário foi registrada. A hora e o login do usuário que efetuou login no aplicativo foram exibidos no log. Escrevemos um script que, uma vez analisado esta página por alguns minutos, analisou a resposta e anotou os logins encontrados em um arquivo. Depois de alguns dias, conseguimos coletar cerca de cem logins. Decidimos iniciar a seleção de senhas - para 5 logins, elas foram encontradas na lista das
500 piores senhas .
Tendo obtido acesso ao aplicativo, continuamos a analisá-lo e encontramos outro arquivo interessante - todas as consultas em tempo real ao banco de dados foram exibidas nele. Com uma ferramenta de depuração tão conveniente, procurar vulnerabilidades e explorar a
injeção SQL baseada em tempo booleano encontrada
se tornou uma tarefa trivial.
Apesar do fato de já ser 2019, as pessoas ainda acreditam que armazenar senhas em um banco de dados de forma aberta é uma boa idéia. Usamos isso e encontramos a injeção de SQL e obtemos uma conta de administrador com a qual preencher o shell da web e abrir o acesso à rede interna da organização não era grande coisa.
Marcas de corte
Primeiro, faça testes de penetração periódicos - eles ajudarão a encontrar pontos finos que você pode ter perdido no estágio de desenvolvimento ou ao alternar dos ambientes de teste para os de combate.
Em segundo lugar, sempre considere o fator humano: as pessoas são muito preguiçosas para alterar senhas e podem até usar uma senha em vários sites. Sim, os administradores também pecam nisso.
Terceiro, remova os modos de depuração em ambientes de combate.
PS
Em geral, a vida cotidiana do departamento Pentest é cheia de todos os tipos de "entretenimentos" e, é claro, testes externos não são os únicos. O cliente pode desejar verificar as vulnerabilidades do perímetro interno (pentest interno) ou analisar a segurança de aplicativos da Web e móveis, bem como redes WiFi, ou providenciar para que os funcionários verifiquem usando métodos de engenharia social.
Em nosso tempo livre de projetos,
compreendemos o Zen, procuramos novas vulnerabilidades, aprimoramos nossas ferramentas e técnicas. E estamos envolvidos em uma recompensa por insetos (onde sem ela).
Você aprenderá sobre a diversidade de nossas "aventuras" nas seguintes mensagens.