Não estou há muito tempo em TI, mas recentemente me empolguei com o tópico de segurança cibernética. A profissão de pentester é especialmente interessante. Enquanto navegava, vi um artigo legal "Como um banco de dados mal configurado nos permitiu possuir uma nuvem inteira de mais de 25 mil hosts" , escrito pelo Security Shenanigans. Tradução de ambas as partes e chame sua atenção.
Introdução
Neste artigo, você aprenderá como conseguimos realizar uma conexão sqlmap direta com o banco de dados usando BMC / IPMI para comprometer um grande cliente.
fundo
Há alguns anos, nossa equipe recebeu uma tarefa: conduzir um teste de penetração de infraestrutura na rede Openstack. Ele consistia em cerca de 2.000 servidores físicos que hospedavam mais de 25.000 máquinas virtuais. Começamos nosso trabalho em uma pequena sub-rede, na qual havia um limite na quantidade de tráfego de saída. Após uma varredura rápida, o Nmap não conseguiu encontrar nenhuma vulnerabilidade óbvia que pudesse ser explorada. Portanto, começamos a estudar os serviços disponíveis para nós. Entre eles, encontramos um servidor PostgreSQL indefeso hospedado em um servidor de desenvolvimento. Depois de criar uma lista de palavras personalizada com vários derivados do nome da empresa, fomos capazes de entrar no sistema usando dados relativamente simples da conta. O nome de usuário era Postgres e a senha era "admin".
Em seguida, decidimos usarsqlmap . Esta ferramenta foi construída para usar injeção SQL, mas também pode fornecer várias opções ao estabelecer uma conexão direta com o banco de dados (quando você tiver suas credenciais). Uma dessas opções é lançar um shell de comando no banco de dados em produção.
Depois de testar o shell, decidimos construir uma carga útil personalizada (carga útil) para obter uma conexão reversa. Isso tornaria possível trabalhar com mais conforto.
Construímos a carga útil usando msfvenom. A carga útil neste caso era um shell TCP reverso para uma máquina Linux x64. Na imagem anterior, você pode ver que precisamos escolher a arquitetura do banco de dados.
Coletando a carga útil com msfvenom
A vantagem dessa carga útil é que ela pode ser usada para conectar novamente usando o Netcat simples. A maioria das outras cargas requer algo como Metasploit (escolha exploit / multi / handler) para as mesmas tarefas.
Depois de executar a carga útil com o wrapper sqlmap, obtivemos nossa conexão com o servidor.
Lançamento de carga útil, conexão de volta
e teste de acesso
Usando dispositivos BMC
Sempre que você executa um teste de penetração de infraestrutura e compromete uma máquina em um novo segmento de rede, você deve verificar novamente para ver se algo novo está surgindo. Esse banco de dados nos permitiu conectar à rede em nuvem da empresa, incluindo a maioria das máquinas virtuais e hosts. Ficamos muito felizes com os resultados da nova varredura, pois encontramos vários dispositivos BMC.
Um dos três dispositivos BMC
O BMC (Baseboard Management Controller, processador de serviço) é um dispositivo incorporado preferencial conectado ao servidor principal que fornece monitoramento e controle fora de banda. Ele funciona independentemente da CPU, BIOS e sistema operacional. Erros ocorridos em qualquer um desses elementos não são capazes de afetar seu funcionamento. O microcontrolador possui seu próprio processador, memória, interface de rede, portanto, está disponível mesmo se o próprio servidor estiver desligado. Todos os principais fornecedores de equipamentos têm BMCs específicos para seus produtos:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Outro termo com o qual você precisa se familiarizar, IPMI (Intelligent Platform Management Interface), é basicamente o protocolo que você usa para se comunicar com esses dispositivos. Sua finalidade é monitorar e gerenciar o hardware do servidor, independente do sistema operacional, mesmo quando o servidor está desligado, mas conectado a uma fonte de alimentação.
Digamos que o IPMI é de longe um dos protocolos mais inseguros que você pode encontrar. Para se ter uma ideia, o IPMI 2.0 foi projetado de forma que você possa solicitar diretamente um hash personalizado do servidor durante a etapa de autenticação. Outra vulnerabilidade existe quando você solicita autorização no modo "cifra 0", o que permitirá que você faça o login com qualquer senha.
Arquitetura de bloco IPMI Os
dispositivos BMC que você pode encontrar geralmente estão mal protegidos, pois são um tipo de dispositivo que é configurado uma vez, na fase de montagem do data center, e então usado apenas quando o servidor não está disponível por meios convencionais.
Conseguimos autenticar facilmente em alguns dispositivos que tinham a cifra 0 ativada .
Aqui você pode ver como estamos logados com uma senha aleatória. Preste atenção na parte "-C 0". Conectado
com sucesso ao dispositivo com uma senha aleatória
Informações de rede para o dispositivo
Mesmo que a cifra 0 não esteja habilitada em alguns dispositivos, você ainda tem outras maneiras de fazer login. Os dois mais famosos estão usando credenciais padrão (que os administradores de sistemas geralmente não tentam alterar) ou explorando uma vulnerabilidade de divulgação de hash (e quebrando os hashes). O último teve que ser feito para a maioria dos dispositivos.
Pares padrão banais de nome de usuário / senha para a maioria dos usuários
Uma lista de palavras contendo hashes de usuários que solicitamos do servidor
Expandindo hashes personalizados usando metasploit
Imediatamente obtemos dados sobre hashes típicos.
Depois de passar por todos os hashes, começamos a quebrá-los.
Hackeando os primeiros hashes
Em alguns minutos, obtivemos acesso a cerca de 600 BMC.
609 hashes rachados com sucesso
Alguns dispositivos HP ILO não foram quebrados . Felizmente para nós, o HP iLO 4 1.00 a 2.50 também tem um bypass de autenticação. Isso permite que você crie uma conta de administrador por meio de um estouro de buffer no cabeçalho de conexão HTTP processado pelo servidor web. O exploit usa isso para obter acesso privilegiado ao resto da API, que por sua vez lhe dá permissão para criar contas.
Usando CVE-2017-12542
Após essas etapas, obtivemos controle total sobre 90% dos dispositivos BMC da empresa. Se você leu sobre dispositivos BMC, agora você sabe que eles permitem que você:
- Monitor
- Reiniciar
- Reinstalar
- KVM (virtualizar)
dispositivos conectados. Isso é ótimo e tudo, mas eles apenas simulam o acesso físico ao servidor, você ainda precisa entrar. Sim, você pode brincar desligando os aparelhos, mas pensamos que não era o suficiente, então continuamos pesquisando.
Uma das maneiras mais comuns de hackear hardware que possui um endereço físico é reinicializá-lo e controlar a execução automática do shell do root. Você pode fazer isso no Unix, Mac e Windows.
A dificuldade dessa abordagem é que cada servidor normalmente hospeda cerca de 2.000 hosts virtuais. Portanto, precisávamos encontrar um servidor não utilizado. O plano era desligá-lo (ou apenas iniciá-lo se já estivesse desligado) e editar a execução automática para nos dar acesso root. Depois disso, queríamos examinar a configuração para encontrar quaisquer bugs / cargas que nos permitiriam comprometer outros servidores também.
O Openstack permite que você consulte a infraestrutura local e os parâmetros específicos da consulta. Um deles é o estado da máquina virtual, que no caso desta empresa local foi definido como a disponibilidade da VM (lista branca / negra para recebimento de tráfego) + estado operacional (iniciado / desativado).
Precisávamos encontrar um servidor na lista negra (o estado de funcionamento não importava) e encontramos um que não estava funcionando devido a problemas no disco. Felizmente, conseguimos inicializar, mas algumas partes do sistema de arquivos acabaram no modo somente leitura.
Solicitação do Openstack para um servidor de hacking adequado Assim
que o encontramos, efetuamos login com as credenciais que encontramos anteriormente.
Usando os acessos obtidos anteriormente
Acesso à interface KVM A
interface KVM simula uma conexão direta ao servidor através do BMC. Na inicialização, você precisa editar o carregamento automático do Grub e adicionar
ro init = / bin / bashà linha apropriada para inicializar no shell do root... Normalmente, o sinalizador de leitura / gravação (rw) é usado, mas tivemos que usar o sinalizador somente leitura (ro) para evitar quaisquer problemas com o disco com falha.
Editando o menu grub
Após o login, examinamos as interfaces de rede para testar a conectividade com o servidor. Como você pode ver, o ifconfig mostra mais de 10 interfaces ativas.
Depois de analisar a estrutura da rede e entender onde estamos, começamos a estudar o servidor.
Em alguns minutos, encontramos um meio-termo com bash_history (uma das melhores fontes de informações valiosas que você pode encontrar em uma máquina Linux)
credenciais de novadb em bash_history
Para aqueles que não estão familiarizados com a arquitetura Openstack, Nova é um banco de dados de gerenciamento que armazena informações administrativas para toda a nuvem, como certificados, cotas, nomes de instâncias, metadados e informações muito mais importantes .
Verificando as credenciais
Após o login, verificamos o acesso do administrador usando grant_MySQL.
Feito isso, podemos ver a estrutura interna do NovaDB.
Tabelas no banco de dados Novadb
Olhando as informações sobre a VM, pudemos ver cerca de 34 mil dispositivos. No entanto, cerca de um terço deles não estavam disponíveis / não funcionavam. O valor exato pode ser visto na linha de entrada float_ips.
Deixe-me explicar por que esses dados do banco de dados são tão importantes.
Se você deseja encerrar a empresa inteira, pode encerrar cada servidor virtual por meio da interface do BMC. Eles não funcionarão até que os administradores de sistemas liguem as coisas novamente.
Você pode escrever seu próprio malware para infectar todos os servidores, mas a implantação em massa nos canais BMC não é fácil (lembre-se de que tivemos que iniciar um servidor não utilizado para editar a execução automática do Grub antes de acessá-lo).
No entanto, com acesso ao NovaDB, você pode simplesmente corromper o banco de dados e todo o ambiente de nuvem deixará de funcionar. Mesmo supondo que o administrador do sistema fosse inteligente o suficiente para examinar imediatamente o banco de dados, é muito mais difícil solucionar problemas de um banco de dados corrompido do que ausente.
Além disso, o administrador do sistema pode descobrir que algo está errado e simplesmente sobrescrever tudo com o backup mais recente, certo? Nós também pensamos nisso. É por isso que seguimos em frente e comprometemos os backups.
A princípio tentamos consultar o banco de dados principal com algo parecido
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , mas a empresa usava sua própria solução de backup que funcionava de forma irregular e não usava um esquema mestre / escravo. Portanto, continuamos a varredura de sub-redes vizinhas, apenas para encontrar os bancos de dados de backup em execução na mesma porta que o principal.
Como conseguimos encontrar os backups
Verificamos a possibilidade de usar as credenciais existentes e, claro, elas surgiram.
Verificando o acesso a um backup
Com nossos próprios backups, pudemos comprovar o comprometimento total da infraestrutura de virtualização, bem como uma forma de finalizar as operações em minutos.
Sempre gosto de encerrar uma revisão / relatório com possíveis soluções para os problemas encontrados. Além disso, havia muitos deles, por exemplo:
- Reutilizando credenciais
- Não há segmentação de rede
- Senhas banais
- Estrutura de backup insegura
- Firmware desatualizado
Um problema crítico que não era fácil de corrigir eram as falhas no protocolo IPMI.
A solução mais bem-sucedida seria colocar servidores habilitados para BMC em um segmento de rede diferente com uma lista limitada e controlada de endereços IP. Isso é o que essa empresa fez no final.
Espero que você tenha gostado da nossa história. Por mais que tenhamos nos divertido aprendendo esse tópico.