Como hackeei 40 sites em 7 minutos by Konstantopoulos

Como hackeei 40 sites em 7 minutos

Georgios Konstantopoulos

·

·

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-icecap

A 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).

Da Arte da Guerra. Enumerar é fundamental.

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.php

Tento 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.

Obtenha a localização da exploração

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.php

Parece 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: pwned42

E estamos no banco de dados com privilégios de root.

“usar nome do banco de dados;” nos permite acessar qualquer um dos 35 bancos de dados e visualizar e modificar seu conteúdo

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:

1. 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.
2. Elimine todos os bancos de dados, excluindo efetivamente os dados das 35 empresas
3. 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:

1. 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
2. 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.

Isso te lembra alguma coisa? Se não, leia aqui (dica: é MUITO sério)

Encontrei esta postagem do blog que me indicou para testar se o Kernel estava vulnerável com o script encontrado aqui.

Carimbos de data e hora e sites restaurados do Firefox redigidos

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:

1. Ler/modificar TODOS os arquivos no servidor
2. Deixe um backdoor persistente (como feito com o Apache)
3. Instalar e potencialmente espalhar malware na intranet do servidor
4. 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)
5. Use o servidor como um minerador de criptomoedas
6. Use o servidor como proxy
7. Use o servidor como um servidor C2C
8. Use o servidor como parte de uma botnet
9. … (use sua imaginação)
10. 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:

1. Um aplicativo da web com uma vulnerabilidade de upload irrestrito de arquivos, que levava a um shell com poucos privilégios.
2. Credenciais para banco de dados mysql, o que levou ao acesso de leitura/gravação a 35 bancos de dados
3. 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