¿Cómo fue hackeado Matasano?


10

de: http://seclists.org/fulldisclosure/2009/Jul/0388.html

Si lo entiendo mejor de las publicaciones de: http://news.ycombinator.com/item?id=723798, los chicos de Matasano dejaron sshd internet accesible: ¿alguna solución propuesta para esto (desde un punto de vista de programación)?


Bueno, si los registros son verdaderos, entonces es un problema de configuración de los servicios expuestos y nada que ver con la programación.
blowdart el

Respuestas:


34

¿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. :)


2
Requerir una clave pública válida para poder iniciar sesión a través de OpenSSH. No es a prueba de tontos, pero ayuda. Buena publicación por cierto.
Andrioid

Buen punto, añadido :)
Cawflands

1
Vale la pena señalar que la cadena de la versión OpenSSH está lejos de ser una guía confiable sobre si los vunerabilites han sido parcheados, debido a varias versiones de Linux que soportan correcciones. Además, es probable que ninguno de los errores aquí permita que un usuario inicie sesión sin otros infractores bastante serios.
Cian el

3

A la gente le encanta crear FUD sobre eso, pero parece que sabían que el usuario Adam ya estaba allí y también sabían su contraseña (tal vez a través de la fuerza bruta u otros métodos). Sin embargo, quieren verse bien y crear todo este alboroto.

Otra cosa interesante a tener en cuenta es que el usuario adam no ha iniciado sesión en ese cuadro durante más de un año:

(salida de lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Así que probablemente mantuvo esa contraseña (tal vez una mala) por un tiempo.

* Si realmente tuvieran una herramienta para descubrir nombres de usuario a través de SSH, podrían haber utilizado a todos los demás usuarios para obtener acceso remoto, pero usaron el nombre de usuario más común en ese cuadro (es fácil de adivinar).


2

¿Por qué tratarías de resolver esto desde un punto de vista de programación?

En su lugar, debe resolverlo desde el punto de vista del servidor inteligente-administrador. Hay algunas sugerencias excelentes en los comentarios de los enlaces que ha publicado, como el uso de una lista blanca.

También me gustaría agregar eso, porque usted pregunta aquí, lo más probable es que de ninguna manera sea un experto en seguridad, y cualquier cosa que se le ocurra escribir solo agregaría más agujeros. Esto realmente no es una pregunta de programación en absoluto.


Una sugerencia era una lista blanca?

que todavía no es un problema de programación, es un problema de configuración
blowdart el


@Sneakyness No soy un experto en seguridad de ninguna manera, pero gracias por señalarlo, es por eso que hago estas preguntas, para que pueda aprender, y gracias por intentar impedir que escriba sobre algo sobre lo que me gustaría saber si es una pregunta de programación o no de programación. Dejaré que respondan los expertos en seguridad. USTED incluido (supongo que es uno basado en su comentario educativo)
user14898

2

Proteja su software de ataques de 0 días ... lo cual es imposible.

Quizás un buen enfoque es afirmar que su software es inquebrantable, lo que hará que los whitehats lo prueben y lo revelen por completo, dejando menos agujeros. Oracle 10 tenía este reclamo, luego al día siguiente se encontraron 9 nuevos agujeros. Es bastante seguro ahora.

Lo más probable es que el hacker haya abusado de la configuración de un software perfectamente bueno


¿Estamos seguros de que este fue incluso un día cero?
Josh Brower

2

me sorprende que tuvieran tantos usuarios con proyectiles en esa máquina. así es como se hicieron dueños, todo lo demás es arenque rojo destinado a distraer. uno de ellos consiguió que su cliente ssh se retrasara en alguna otra máquina shell y probablemente se acabó el juego. dar cuentas de shell a todos y hacer que el mundo sshd sea accesible es simplemente vago y estúpido.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.