21 diciembre 2010

Cuando "read" implica "write"

En este artículo voy a hablar de una experiencia que he tenido hace poco con una de las redes de mi universidad, a la que tuve acceso y al ver ciertos temas que no me convencieron me dispuse a ver cómo de fácil podría llegar a ser hacerse con el control de la misma. Lo más interesante es hacerlo sin necesidad de tener ya una cuenta del sistema (que era mi caso), a pesar de que ya se ha dicho innumerables veces que un porcentaje más que considerable de los ataques a una red provienen del interior y que por tanto, cada usuario ha de tener sólo los privilegios que le corresponden, ninguno más.

Normalmente suelo dar todos los datos, pero en este caso no diré exactamente qué red se veía afectada pues aún no se han tomado todas las medidas que deberían y sigue estando expuesta. Aun así, por describir la red un poco, decir que es un servicio para los estudiantes, en la cual hay registrados muchos datos confidenciales (como nombres y DNIs, becas otorgadas), un servicio de impresión prepago, etc. Todos sus servicios se llegaron a ver comprometidos, sin excepciones.

¡Comencemos!

Disclaimer:

No me hago responsable del mal uso que pueda darse a esta información.
En ningún momento la intención del artículo es el incitar a que se produzcan ataques sobre dicha red siga estando, o no, vulnerable al ataque que se expone a continuación.

1. Introducción

La finalidad del ataque es conseguir la contraseña del usuario root para poder acceder a todos los host (lo normal es que se comparta) y por tanto comprometer todos los servicios de la red.

Como he dicho anteriormente, el ataque se va a realizar sin una cuenta de acceso, por lo que habrá que comprometer de algún modo uno de los servidores con acceso desde el exterior para poder empezar.

Cabe decir que, como se irá viendo a lo largo del artículo, se irán consiguiendo progresos debido a una mala administración, es decir, que nos aprovecharemos de las malas asignaciones de permisos y de sistemas de backup mal configurados.

El proceso que más tiempo nos llevará será el data mining, es decir, explorar concienzudamente una serie de directorios en busca de la información que nos interesa, en nuestro caso cualquier tipo de credencial que nos permita avanzar y/o obtener datos interesantes.

Por lo tanto, ya queda explicado el título del artículo ‘cuando read implica write’ que quiere dejar patente que si no nos preocupamos seriamente de los permisos y pensamos que la lectura (read) no constituye un problema si la información no es “crítica”, podemos encontrarnos con un serio peligro
pues dejamos abierta cierta información para que alguien la encuentre, explote y obtenga los privilegios suficientes para hacerse con el control (implica write).

2. Obteniendo los usuarios de la red

En nuestro caso obtendremos la lista de usuarios de la red a través de un LDAP mal configurado que tiene permitido el acceso (en modo lectura) al usuario anónimo. También hubiéramos podido conseguir los usuarios de otro modo (tienen un listado de los usuarios como contacto en los que se publica su nick, o a través de la cuenta de correo, también pública, etc). Aun así, es más cómodo el LDAP porque podremos ver que hay cuentas de prueba que seguramente sean más fáciles de comprometer.

¿Cómo accedemos a LDAP?
Si escaneamos los host públicos veremos que ninguno tiene LDAP de cara al exterior pero siempre podremos comprobar si tienen un manager para administrarlo.
Probando con los dos más conocidos (LAM y PHPLDAPADMIN) nos topamos con que tienen accesible sin ninguna restricción el phpldapadmin. Por lo tanto, nos conectamos como usuario anónimo y accedemos cómodamente al listado (y más información, como hosts, etc).


Una vez dentro, al menos nos percatamos que el usuario anónimo tendrá el access en auth puesto que no podemos ver las contraseñas de los usuarios. Simplemente nos interesará exportar los nombres/nicks de los usuarios para poder ejecutar el ataque, destacando las cuentas de prueba. Además, podemos comprobar que hay otros dos cn, además del admin, que tienen pinta de tener más privilegios.

Aprovecho para enlazar al último artículo que publiqué sobre servidores VPN PPH en el que adjunté algunos consejos para securizar LDAP. Podéis acceder al PDF aquí o al post aquí.

3. Obteniendo acceso a la red

Una vez que tenemos el listado de acceso a la red podríamos realizar el ataque sobre el servicio SSH, pero es muy probable que tengan instalado denyhost/fail2ban o algún otro que nos bloquee en cuanto hagamos un número determinado de intentos. Por lo tanto sería interesante encontrar alguna forma más transparente de ataque.

Siempre he dicho que las autenticaciones de un servicio web son la mejor forma de atacar pues rara vez registran los intentos fallidos, como mucho queda constancia en los logs de conexiones. En nuestro caso tenemos varios frentes, uno podría ser el correo pero si investigamos un poco más veremos que hay más servicios que requieren autenticarse, por lo que atacaremos a estos otros.


Como comprenderéis, todo depende de la fortaleza de las contraseñas de los usuarios. En este caso concreto, siendo estudiantes y con escasos conocimientos de seguridad o buenas prácticas, sabía que las contraseñas iban a ser fáciles de comprometer (del estilo fechas de nacimiento, DNIs, palabras fáciles de recordar) y por tanto que estén en wordlists, etc. Además, recordar que teníamos cuentas de prueba.

Para el ataque, programé un pequeño script que iba autenticándose y procesando la respuesta. En el momento en el que el hash de la respuesta cambiara se daría por correcto el par usuario/contraseña. El script era capaz de realizar algo más de 35 peticiones por segundo (con 10 threads activos) por lo que era capaz de procesar 126k contraseñas por hora y usuario. Aprovechando el cloud computing, utilicé
25 instancias durante 2 horas cada una para cubrir el mayor número de usuarios, dando a cada uno más de una instancia. Por lo tanto por 50 céntimos logré comprometer relativamente rápido una cuenta, aunque las instancias no se lanzaron todas a la vez para evitar que saltara alguna alarma (no en el servicio atacado sino en algún mecanismo de protección de la universidad).

Por lo tanto, como podéis ver, fue relativamente sencillo hacerse con los credenciales de una cuenta del sistema y no levantamos muchas sospechas al utilizar un servicio web. Ya utilicé algo parecido para las cuentas de usuario de la UPM (el artículo lo podéis encontrar aquí) y también pasó inadvertido (no se dieron cuenta hasta que se les reportó).

4. Data mining

Una vez que nos encontramos en la red (en el host al que podemos conectarnos por SSH) procedemos a buscar cualquier información que nos sea de utilidad para poder ir escalando privilegios.

En este caso, una vez que estamos dentro podríamos ver si podemos utilizar algún exploit para la escalada de privilegios. En este caso podíamos haber utilizado este, pero supondremos que todos los servicios que corren en él están parcheados y por tanto es necesario el data mining (pues fue el procedimiento que utilicé).

En primer lugar, lo que hice fue comprobar si podía acceder a las carpetas home de los demás usuarios (muchas veces se permite la lectura por cualquiera). Hice la prueba y funcionó por lo que uno de los toDo’s serán las homes. Además, siempre es interesante buscar en la carpeta etc (en concreto en las configuraciones de los servicios/aplicaciones a ver si alguna tiene mal asignados los permisos y podemos ver credenciales en texto plano) y en la carpeta /var/www por si desde ese servidor se está sirviendo la página web y, por tanto, ver también los archivos de configuración o de conexión a bases de datos.

Mirando en la carpeta /var/ no encontré ninguna información interesante aunque cual fue mi sorpresa al encontrarme una carpeta con nombre backup en la que se encontraban copias periódicas (cada 10 días) del servidor web y de todas las bases de datos. Claramente los permisos estaban mal asignados y podía leer la mayoría de la información.


Tras unas horas haciendo el barrido de todos los directorios (esta vez manualmente), me hice con credenciales de LDAP (era de solo lectura aunque ya podía ver los hashes de las contraseñas de todas las cuentas) y de muchas bases de datos.

En realidad los credenciales de las bases de datos no me hacían falta (salvo que quisiera alterarlas) pues en la carpeta de backup teníamos exportadas todas en formato SQL y con acceso de lectura.

5. Comprometiendo una cuenta con privilegios

A través del data mining realizado a las carpetas home y a los usuarios que aparecían en los archivos de los servicios web, etc pude hacerme una idea de quienes eran los que podrían estar incluidos en el sudoers y por lo tanto el que sus contraseñas fueran el principal objetivo.

¿Cómo podría obtener sus contraseñas?
Una de las bases de datos era la de la página web, por lo que la aproveché para cruzar los que tenían en ella más privilegios con los usuarios que yo creía administradores, y sacar los hashes de sus contraseñas.

En principio iba a utilizar las GPU de Amazon para crackear los hashes pero como vi que iba a tardar demasiado me hice un script, por quemar todas las posibilidades sencillas antes, que me comprobaba en Google los hashes a ver si ya alguien los había crackeado. En la mayoría de los casos no hubo resultados y en otros la contraseña de la web no era la misma que la de la cuenta de la red, por lo que lo dejé ahí y empecé a montar lo de Amazon. Me acordé que había una página que te comprobaba los hashes en muchas bases de datos y además estaba enlazada con opencrack, así que decidí crear un script que comprobara en ella todos los hashes y cuál fue mi sorpresa cuando fue capaz de comprometerme más de los que pensaba y
algunos de 10 caracteres alphanuméricos con especiales, increíble. Por cierto la página es
HashKiller, ha estado caída una semana pero es altamente recomendable.


En el caso de que no hubiéramos tenido la suerte de obtener los hashes de la base de datos, recordar que había conseguido un usuario de LDAP con lectura del campo contraseña, por lo que de ahí podía obtener los hashes, más incómodos pero igualmente válidos.

6. Obteniendo la contraseña de root

Una vez que hemos conseguido comprometer una cuenta incluida en el sudoers podemos terminar el data mining leyendo aquellos archivos que tenían los privilegios bien asignados además de ver el historial por si había utilizado alguna contraseña en claro o la carpeta de .mozilla (entre otras muchas posibilidades) para acceder a sus contraseñas guardadas.

A partir de este momento ya me había hecho con los credenciales de todas las bases de datos y podía acceder a la gran mayoría de la información. El problema era que necesitaba la contraseña de root para acceder a otros host donde se encontraban servicios más interesantes como las impresiones, los datos personales, etc.

Como podéis ver en ningún momento utilicé ningún exploit ni nada, simplemente data mining y cracking de hashes (que por suerte fue muy cómodo).

¿Cómo podemos obtener la contraseña de root?
Lo primero que hice fue acceder a los archivos shadow/passwd y utilizar el John para crackearlos. Al ver que tardaba demasiado me decidí por echar un vistazo a todas las contraseñas que había obtenido y me percaté que una de las que tenía era del cn=admin de openLDAP. Normalmente suelen compartirse así que la probé haciendo un simple "su" y funcionó, ya tenía la contraseña de root.
Para comprobar que tenía acceso a los demás host fui conectando a cada uno de ellos sin fallo alguno. Además en cada uno hice un pequeño data mining para determinar cuántos credenciales se podían ver comprometidos.


¡Hasta aquí todo! Ya para terminar...

Como podéis ver, ha sido extremadamente sencillo acceder a la red y en poco tiempo obtener el control total de la misma.

Independientemente de la facilidad que haya tenido por los descuidos de los administradores quería que con este artículo quedara claro lo importante que es el control de los permisos y que un par de descuidos (en este caso todo ha sido, principalmente, por la carpeta backup) hacen que sea extremadamente sencillo comprometer toda la infraestructura.

Como dije al principio del tema, ya ha sido reportado pero al no disponer de ningún tipo de mecanismos de seguridad (ni un simple "generador de alertas de logs" como explicó hace poco tiempo Lorenzo aquí), no quiero pensar que exista la posibilidad de que yo no haya sido el primero y que alguien haya podido acceder de una forma tan sencilla a nuestros datos.

Artículo cortesía de: Luis Delgado J.

14 comments :

n0.more dijo...

Buen post, muy buen post.

No se que universidad sea, pero vamos, yo conozco alguna en la que los sistemas no están "a la vista", sus sistemas de seguridad están concienzudamente instalados y revisador y creeme, una exploración desde fuera resulta muy básica, pues no exponen información critica.


Un saludo y enhorabuena de nuevo.

Anónimo dijo...

Hola, un artículo interesante, pero yo de tí tendría cuidado, ya que excepto que te hayan contratado para auditar eso, te puedes meter en un lio. Todo depende de quien pilles de admin y el dia que tenga...

Y si quieres hacer lo mismo, pero legalmente y remunerado, contacta con Pentest Consultores. Verás que es mucho más estresante/emocionante cuando lo que te juegas es el sueldo...

;-)

Anónimo dijo...

Enhorabuena por el artículo pero verdaderamente no creo que tenga mucho mérito acceder a una red de cierta Universidad, en la que -en mayor media, siempre existen honrosas excepciones- trabajan personas con una cualificación muy justa para desempeñar su rol como administrador de Sistemas. Un saludo.

Luis dijo...

@Ultimo_anonimo:
Estoy de acuerdo.
Aun asi, dejar claro que los administradores de sistemas de la universidad no se encargan de esta red en concreto.
Y si, no es nada complicado colarse, por lo que es aun mas preocupante pues los datos a los que se accede no son una tontería.

Shyish dijo...

Muy buen post, sin duda. Da miedo ver todo lo que se puede hacer con pocos descuidos por parte del administrador. Esperemos que lo solucionen pronto no sea que alguien con malas intenciones se cuele.

Un saludo!

Anónimo dijo...

muy buena contribución

Anónimo dijo...

Excelente artículo

Adama dijo...

Buen post!

A raiz del comentario del primer anónimo me asalta la duda de las posibles implicaciones legales. Yo creo que en todo caso tendrían que ser para los administradores de la red por exponer información sensible.

¿Qué opináis?

Mario dijo...

Excelente articulo :)

Sólo porque soy un tipo molesto voy a comentar un detalle: "data mining" no significa lo que crees que significa (búsqueda y recoleccion de datos) sino que es el nombre específico de una disciplina de las ciencias de la computación, dedicada a la extracción de datos mediante análisis estadístico e inteligencia artificial.

En todo caso habría que usar el término "information gathering" (recoleccion de informacion, creo que el Hacking Exposed lo usaba), o bien simplemente "recon" (abreviatura de "reconnaissance", reconocimiento, que es el término militar).

Nada de esto desmerece el post, por supuesto! Es que soy un poco obsesivo con ciertos detalles, nada más xD

Luis dijo...

@Mario:
No pasa nada ;)
Estuve por ponerdata gathering pero luego se me pasó por la cabeza minería de datos (web semántica y demás) y me pareció un nombre curioso. Pero vamos, rara vez será la que no me invente un nombre :)
Igualmente, gracias por tu aportación, siempre son bien recibidos los términos correctos.

Ladon dijo...

Muy buen artículo, me gusta sobretodo el enfoque que le has dado.
Enhorabuena.

aabilio dijo...

Muy buen artículo, como siempre. Aunque quería hacer un apunte. Puede que esté equivocado, pero si tienes las credenciales de alguien incluido en sudoers, con un simple "sudo su" ya bastaba, ¿no?
Aunque también es bonita la forma de encontrar la pass de root relacionando admin openLDAP con root del sistema mientras estás trabajando John.
Saludos ;)

Luis dijo...

@aabilio:
Efectivamente, bastaba con hacer "sudo su" para autenticarse como root, pero seguía sin poder acceder a los demás host de la red (que era el objetivo final), por ese motivo necesitaba la contraseña (otra cosa sería que pudieses conectarte por ssh a través de cert, pero en este caso no lo tenían configurado).

Luis dijo...

@Mario:
No pasa nada ;)
Estuve por ponerdata gathering pero luego se me pasó por la cabeza minería de datos (web semántica y demás) y me pareció un nombre curioso. Pero vamos, rara vez será la que no me invente un nombre :)
Igualmente, gracias por tu aportación, siempre son bien recibidos los términos correctos.