Cómo conseguir hackeado Matasano.

¿Cómo Matasano hackeado?

Eso es imposible de contestar, a partir de la información en el post a la Divulgación Completa. Sin embargo, siempre es interesante especular, como que dan un poco de info de distancia -

# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Conexión a 69.61.87.163:22..
[/] Buscando válido usuario no-root.. adam
******** R3D4CT3D h4h4h4h4********

Su binario "th3_f1n41_s01ut10n" en contra de Matasano del servidor, que conecta con el puerto ssh. Encuentra un válido usuario no-root a través de algunos medios inéditos, y el resto de la producción está redactado.

# ./th3_f1n4l_s0lut10n-u adam-t 3 www.matasano.com
[*] Connectback de escucha en la 209.112.118.10:3338..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8 g 19 Oct 2007] 

El binario se ejecute de nuevo utilizando el nombre de usuario que inicia la sesión y se conecta a su servidor en el puerto 3338 (espero que no registradas a su nombre...).

adam_at_www:~$ uname-a
Linux www 2.6.20.1-1-686 #1 SMP Sol Mar 4 12:44:55 UTC 2007 i686 GNU/Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3 !0D4Y! H4H4H4H4H4H4H4****

Que podría ser lo que implica que tienen un 0-day en contra de este núcleo, que es muy viejo cuando se considera que las acciones de la compañía en el comercio.

adam_at_www:~$ cd /tmp
*********** B0R1NG***********
root_at_www:~# cat /etc/shadow 

¡Ay, de repente, ahora el usuario root. Tienen una escalada de privilegios locales explotar en /tmp que podría ser el 0-day que se refiere.

Así que hay al menos dos hazañas pasando aquí - el OpenSSH explotar para obtener una válida usuario no root en el sistema, y el inicio de sesión como ese usuario y, a continuación, la escalada de privilegios locales.

Teniendo en cuenta que OpenSSH tiene un par de problemas de seguridad conocidos desde la versión 4.5:

De OpenSSH de seguridad página:

• OpenSSH antes de la versión 5.2, es vulnerable a la del protocolo de debilidad se describe en la CPNI-957037 "Plaintext Recuperación Ataque Contra SSH". Sin embargo, basándose en la limitada información disponible parece que esta descrito el ataque no es factible en la mayoría de las circunstancias. Para obtener más información, por favor consulte el cbc.adv asesor y el OpenSSH 5.2 notas de la versión.
• OpenSSH 4.9 y los nuevos no se ejecute ~/.ssh/rc para las sesiones cuyo dominio ha sido reemplazado con un sshd_config(5) ForceCommand directiva. Esta fue una documentada, pero la conducta insegura (descrito en OpenSSH 4.9 notas de la versión).
• OpenSSH 4.7 y los nuevos no caer de nuevo a la creación de confianza X11 las cookies de autenticación cuando no son de confianza cookie generación de falla (por ejemplo, debido a deliberar el agotamiento del recurso), como se describe en el OpenSSH 4.7 notas de la versión.

Supongo que tiene esta antigua del kernel de Linux y mayores demonio SSH hizo por ellos. También, se ejecuta en su servidor de www, que está disponible para el Internet, que es bastante seguro de una cosa que hacer en mi opinión. Las personas que se rompió en, obviamente, quería avergonzar a nadie.

Cómo evitar estos ataques?

Esto podría haber sido prevenida por la administración pro activa - asegurándose de que ninguna de internet servicios están revisados, y limitar el número de personas que se pueden conectar en lugar de permitir que la gente se conecte desde cualquier lugar. Este episodio de los compuestos de la lección que fijan la administración del sistema es difícil, y requiere de la dedicación de la empresa para dar tiempo a mantener las cosas patched - en realidad, algo que no ocurre fácilmente, al menos en las empresas más pequeñas.

El uso de un cinturón y los tirantes enfoque es el mejor de los públicos de la autenticación de clave, la creación de listas blancas en el demonio ssh, la autenticación de dos factores, restricciones de IP, y/o poner todo detrás de la VPN son posibles rutas de bloqueo.

Creo que sé lo que voy a hacer mañana en el trabajo. :)