Como hackeei 40 sites em 7 minutos by Konstantopoulos
Como hackeei 40 sites em 7 minutos
No verão passado, comecei a aprender sobre segurança da informação e hacking. Durante o último ano, joguei vários jogos de guerra, capture a bandeira e simulações de testes de penetração, melhorando continuamente minhas habilidades de hacker e aprendendo coisas novas sobre 'como fazer os computadores se desviarem de seu comportamento esperado'.
Resumindo, minha experiência sempre foi limitada a ambientes simulados e, como me considero um hacker de chapéu branco (também conhecido como um dos mocinhos), nunca meti o nariz nos negócios de outras pessoas — literalmente.
Até agora. Esta será uma história detalhada sobre como invadi um servidor que hospedava 40 (este é um número exato) sites e minhas descobertas.
Nota: É necessário algum conhecimento prévio de CS para acompanhar as partes técnicas do artigo.
Um amigo me enviou uma mensagem informando que uma vulnerabilidade XSS foi encontrada em seu site e que ele quer que eu dê uma olhada mais detalhada. Esta é uma etapa importante, pois estou inclinado a pedir que ele expresse formalmente que tenho sua permissão para realizar um teste completo em sua aplicação web e no servidor que a hospeda. A resposta foi positiva.
No restante da postagem, me referirei ao site do meu amigo como http://example.com
O primeiro passo é sempre enumerar e encontrar o máximo de informações possível sobre seu inimigo – enquanto tenta alarmá-lo o mínimo possível.
Nesta fase acionamos nosso cronômetro e iniciamos a digitalização.
$ nmap --top-ports 1000 -T4 -sC http://example.com
Relatório de varredura Nmap para example.com {redigido}
O host está ativo (latência de 0,077s).
Registro rDNS para {redigido}: {redigido}
Não mostrado: 972 portas filtradas
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
| chave de host ssh:
| {redigido}
80/tcp http aberto
| métodos http:
|_ Métodos potencialmente arriscados: TRACE
|_http-title: Site da vítima
139/tcp open netbios-ssn
443/tcp open https
| métodos http:
|_ Métodos potencialmente arriscados: TRACE
|_http-title: O site não possui título (text/html; charset=UTF-8).
|_{redigido}
445/tcp aberto microsoft-ds
5901/tcp aberto vnc-1
| informações vnc:
| Versão do protocolo: 3.8
| Tipos de segurança:
|_ Autenticação VNC (2)
8080/tcp open http-proxy
|_http-title: 400 Bad Request
8081/tcp open blackice-icecapA verificação foi concluída em cerca de 2 minutos.
São muitas portas abertas! Observando que as portas FTP (porta 21) e SMB (portas 139/445) estão abertas podemos adivinhar que o servidor é usado para hospedagem e compartilhamento de arquivos, além de ser um servidor web (portas 80/443 e proxies em 8080/8081).
Fazer uma varredura de porta UDP e varrer mais do que as 1.000 portas principais seria considerado se as informações da varredura acima não fossem suficientes. A única porta com a qual podemos interagir (sem credenciais) é a porta 80/443.
Sem perder tempo, começo gobustera enumerar quaisquer arquivos interessantes no servidor web enquanto procuro informações manualmente.
$ gobuster -u http://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100/admin
/login
Acontece que o caminho /admin era uma “ferramenta administrativa” que permitia que usuários autenticados modificassem coisas no servidor web. Exigia credenciais e como não temos nome de usuário nem senha, seguimos em frente. (spoiler: gobuster não encontrou nada de valor)
Até agora estamos em cerca de 3 minutos. Nada útil ainda.
Navegando até o site, vemos que ele nos pede para fazer login. Não tem problema, criamos uma conta com um e-mail fictício , clicamos no e-mail de confirmação e fazemos login após alguns segundos.
O site nos dá as boas-vindas e nos solicita que naveguemos até nosso perfil e atualizemos nossa foto de perfil. Que gentil.
Vendo que o site parece personalizado, estou inclinado a testar uma vulnerabilidade de upload irrestrito de arquivos . No meu terminal eu executo:
echo "<?php sistema(\$_GET['cmd']); ?>" > exploit.phpTento enviar a “imagem” e bingo! O uploader permite que o arquivo exploit.php seja carregado. É claro que não tem miniatura, mas isso significa que meu arquivo foi carregado em algum lugar.
Aqui, esperamos que o uploader faça algum tipo de processamento no arquivo enviado, verifique sua extensão de arquivo e substitua pela extensão de arquivo aceita, como .jpeg, .jpg, a fim de evitar a execução remota de código por um invasor que envia código malicioso, como o seu verdadeiramente.
Afinal, as pessoas se preocupam com a segurança.
certo? Certo? …CERTO?
`Copiar endereço da imagem` resulta na cópia do seguinte URL para nossa área de transferência:
http://www.example.com/admin/ftp/objects/XXXXXXXXXXXX.phpParece que temos nosso webshell pronto e funcionando:
Vendo que o servidor web executa scripts perl (sério, perl?), pegamos um shell reverso perl de nossa cheatsheet favorita , definimos o IP/Porta e somos recompensados com um shell de baixo privilégio - desculpe, sem captura de tela.
Cerca de 5 minutos na avaliação e já temos um shell de baixo privilégio.
Para minha grande surpresa, o servidor não hospedava apenas 1 site, mas 40 sites diferentes . Infelizmente, não guardei capturas de tela de todos os detalhes, mas o resultado foi mais ou menos assim:
$ ls /var/wwwaccess.log site1/ site2/ site3/ {... a lista continua}
Você entendeu. Surpreendentemente, o acesso de leitura a TODOS os sites hospedados estava disponível, o que significava que eu poderia ler o código de back-end de todos os sites. Limitei-me ao código de example.com.
Notavelmente, dentro do cgi-admin/pagesdiretório, todos os scripts perl estavam se conectando a um banco de dados mysql como root . As credenciais do banco de dados estavam em texto não criptografado. Sejam estes root:pwned42
Com certeza, o servidor estava rodando MariaDB e tive que recorrer a esse problema antes de poder acessar o banco de dados. Depois executamos:
mysql -u root -p -h localhost nome do banco de dados da vítima
Senha: pwned42E estamos no banco de dados com privilégios de root.
Após apenas 7 minutos, temos acesso total de leitura/gravação ao conteúdo do35 (!) bancos de dados
Aqui estou moralmente obrigado a parar e divulgar minhas descobertas até agora. O dano potencial já é enorme.
O que um invasor poderia fazer:
- Despejar o conteúdo de todos os bancos de dados, conforme descrito aqui , resultando no vazamento dos dados de todas as 35 empresas para domínio público.
- Elimine todos os bancos de dados, excluindo efetivamente os dados das 35 empresas
- Deixe um backdoor para acesso persistente como apache com um cronjob, conforme descrito aqui , caso queiram uma viagem de volta.
Devo observar aqui que o processo mysql estava sendo executado como root, então decidi tentar executar \! whoamina esperança de obter root. Infelizmente eu ainda era apache.
É hora de fazer uma pausa. Pare o cronômetro.
O que mais pode dar errado?
Depois de divulgar minhas descobertas, recebo mais permissão para me aprofundar.
Antes de procurar maneiras de aumentar meus privilégios de root e causar danos potenciais massivos, eu estava analisando quais outros arquivos interessantes eu poderia ler com meu usuário limitado.
Nesse ponto, lembrei-me das portas SMB abertas. Isso significa que deveria haver alguma pasta em algum lugar que estivesse sendo compartilhada no sistema entre os usuários. Após uma pequena enumeração, o seguinte aparece no diretório /home/samba/secured (desculpem-me pela censura em massa):
Dentro de todos esses diretórios, estavam os arquivos de cada usuário da empresa de hospedagem. Isso incluía todos os tipos de dados confidenciais, entre outros:
- Arquivos .psd/.ai (os designers sabem o quanto é importante mantê-los privados, afinal é seu trabalho e suas técnicas)
- Arquivos sqlite de cookies
- Faturas
- E-books piratas (ri quando vi isso)
- Credenciais para seus SSIDS WiFi
O que um invasor poderia fazer:
- Acampe fora dos escritórios da empresa, faça login na intranet e execute todos os tipos de ataques divertidos que você pode fazer em redes locais
- Despeje todos os dados confidenciais listados acima para o domínio público
Demorou algum tempo para examinar as pastas e perceber a gravidade desse problema.
Mais uma pausa.
O golpe final
Depois de olhar um pouco mais como apache , decido que é hora de procurar os peixes grandes, infelizmente, obter acesso root. Refiro-me a uma folha de dicas popular e começo a enumerar o sistema em busca de arquivos interessantes.
Devido à minha escavação até agora, eu já havia passado pela maioria dessas técnicas e não parecia ser capaz de encontrar algo que aumentasse minha posição.
Foi quando me dei conta. Nos desafios Capture the Flag que estou acostumado a jogar, o sistema operacional geralmente é corrigido e é algum serviço intencionalmente mal configurado que eventualmente lhe dá o tão procurado privilégio de root. No mundo real, entretanto, as pessoas não consertam.
Quer dizer, olhe para Equifax (não resisti).
Que tipo de Linux o servidor está executando?
$ cat /etc/issue
CentOS Linux versão 7.2.1511 (núcleo)Qual versão é o kernel?
Parece uma versão antiga do Kernel.
Encontrei esta postagem do blog que me indicou para testar se o Kernel estava vulnerável com o script encontrado aqui.
Seguido pela:
Game Over.
Imediatamente escrevi um e-mail divulgando completamente os detalhes e o impacto potencial de cada etapa descrita acima e encerrei a noite. Ufa.
O que um invasor poderia fazer:
- Ler/modificar TODOS os arquivos no servidor
- Deixe um backdoor persistente (como feito com o Apache)
- Instalar e potencialmente espalhar malware na intranet do servidor
- Instalar ransomware (tomar os bancos de dados de 35 empresas e todos os dados da empresa de hospedagem como reféns não é pouca coisa)
- Use o servidor como um minerador de criptomoedas
- Use o servidor como proxy
- Use o servidor como um servidor C2C
- Use o servidor como parte de uma botnet
- … (use sua imaginação)
- rm-rf/(nem estou brincando)
No dia seguinte, fui contatado por meu amigo (que entrou em contato com a empresa que opera o servidor) e fui informado que o bug no uploader de arquivos foi corrigido.
Dr.
Resumindo, encontramos:
- Um aplicativo da web com uma vulnerabilidade de upload irrestrito de arquivos, que levava a um shell com poucos privilégios.
- Credenciais para banco de dados mysql, o que levou ao acesso de leitura/gravação a 35 bancos de dados
- Muitos arquivos confidenciais legíveis
Finalmente, abusamos de um kernel sem patch para obter acesso root.
Mitigações – Sugestões
Vamos começar pelo uploader que nos deu a nossa posição inicial. Como todo o back-end da aplicação web foi escrito em perl - e como eu não falo perl - não posso realmente sugerir soluções para isso.
Uma solução que eu sugeriria seria não usar perl em 2017, mas essa é apenas minha opinião, fique à vontade para provar que estou errado.
Em relação ao sistema de arquivos, recomendo tomar muito cuidado ao atribuir permissões de arquivo adequadas aos usuários, de acordo com o princípio do menor privilégio . Dessa forma, mesmo que um usuário com poucos privilégios como o Apache obtenha acesso, ele não será capaz de ler nenhum arquivo confidencial.
Executar todos os sites no mesmo servidor é uma má ideia. Não tenho certeza se uma abordagem dockerizada resolveria o problema.
Ter as mesmas credenciais para todos os bancos de dados é com certeza uma má ideia.
Geralmente não é bom ter pontos únicos de falha.
Finalmente, PATCH TUDO . É literalmente um comando: su -c 'yum update' (específico do CentOS)
Obrigado por ler e por chegar até aqui, desculpe pelo longo post. Queria ser minucioso, essa era uma situação séria 😄
Aperte aquele botão de palmas 50 vezes se você gostou!
Plugue sem vergonha
Sou um estudante do 5º ano de Engenharia Elétrica e de Computação da Grécia. Estou interessado em infosec, pesquisa e aplicações de blockchain em empresas modernas e veículos autônomos. Saiba mais sobre o que faço em gakonst.com
Se você gostou do conteúdo deste post e quer ficar atualizado sobre meu trabalho, me siga no Medium e no Twitter
Comentários
Postar um comentário