miércoles, 24 de octubre de 2012

From JailBreakMe to Jail0wnMe

Tal y como le comentaba a Chema Alonso en la entrevista que me ha hecho en su blog con motivo del quinto aniversario de Pentester.Es, pensé en liberar el "exploit" (por llamarlo de alguna manera) del Jail0wnMe que presenté en las Conferencias No cON Name el año pasado, pero fue una de esas cosas que te quedas con que ya lo has hecho, y en realidad solo pensaste hacerlas :P

Como más vale tarde que nunca, acabo de colgar en TOOLS.PENTESTER.ES los scripts que utilicé. No solo el que convierte el PDF de JailBreakMe a Jail0wnMe, sino también los Payloads que utilicé. Ahora hay más Payloads por ahí, pero en su momento, cuando lo tuve que hacer, no encontré ninguno que me encajara, así que me los programé yo mismo. Os los dejo para que podáis reaprovechar el trabajo: PINCHA AQUÍ.

Además de colgar los scripts como tal, os voy a explicar un poco qué es lo que hacen ¿Por qué? Pues porque siempre es útil saber como funcionan las herramientas por debajo, y porque lo que he colgado no es una herramienta como tal, sino un script que me hice parar solucionar un problema que me surgió durante un Pentest, así que no está probado más que con los dispositivos que me encontré. Si os encontráis con algún problema en algún otro dispositivo, quizá tengáis que hacer pequeños cambios.

¡VAMOS ALLÁ!

Lo primero de todo es conseguir el PDF de JailBreakMe para el dispositivo y versión que queremos explotar. Parar ello únicamente hay que visitar la web de JailBreakMe 3.0 y descargarlo, pero... tenemos un problemilla, y es que la web nos va a dar el PDF adecuado en función de la versión que detecte en nuestro User-Agent, con lo cual no vamos a poder descargarlo empleando un navegado "normal", y tampoco usando un iPhone o iPad de la versión adecuada (si disponemos de uno) porque se ejecutaría el exploit, así que la solución que empleé fue usar la extensión de Firefox User Agent Switcher, con la que podemos hacer creer a la web que somos la versión del dispositivo que queremos explotar:


Una vez que hemos conseguido bajar el PDF, si le pegamos un vistazo dentro con cualquier editor, veremos que mayoritariamente es texto, pero que hay un stream que está encodeado. Si lo extraemos y decodificamos tendremos algo así:


$ file pfb.raw 
pfb.raw: PostScript Type 1 font program data

¡MUCHO OJO! No hagáis un "cat" del fichero, porque dentro el cachondo de Comex (el autor del exploit original) ha puesto esto:


En otros sistemas no sé que pasará, pero en mi MacBook son dos combinaciones que hace que la ventana se minimice y se maximice, por eso lo llama "Terminal Fun" el muy .... xDDDD Cuidado con esto si no queréis terminar matando vuestro terminal o esperando un par de horas a que acabe de divertirse :P

Volviendo a nuestro caso, como sabéis la vulnerabilidades está en el parseo de las fuentes, así que vamos por buen camino. Si miramos dentro de la fuente veremos que tenemos texto y trozos que, al igual que estaba la fuente antes, están comprimidos. Si buscamos entre ellos (los scripts que os he pasado ya van a por el adecuado) nos encontramos uno que, al descomprimirlo, es algo así:



$ file binary.raw 
binary.raw: Mach-O executable arm


¿Un binario de Apple para plataforma ARM DENTRO de un PDF? ¡Eso tiene pinta de ser algo!
Efectivamente, es un binario que se ejecuta en nuestro dispositivo iOS y que se trae de la web de JailBreakMe todo lo necesario para realizar el JailBreak.

¿Qué pasa ahora si cambiamos este binario por uno de nuestro elección? Pues básicamente es lo que hacen los scripts que acabo de colgar:

  1. Coge el binario que le hayáis pasado.
  2. Lo comprime y lo rellena de basura para que ocupe el mismo espacio que el original.
  3. Lo coloca substituyendo al original y vuelve a construir el PFB.
  4. Lo comprime y lo vuelve a colocar substituyendo al PFB original dentro del PDF.
  5. Os crea un PDF nuevo con estas modificaciones.

Si miráis el código veréis que "la búsqueda" de todo esto es un poco rudimentaria, pero creo que con lo que os explico en este post tenéis suficiente para rehacerlo si fuera necesario.

También tenéis, como os he dicho, ejemplos de Payloads y un par de shellscripts con los comandos GCC que utilicé yo para compilar desde mi MacBook.

Por último, os dejo el video de la demostración que hice en NcN el año pasado.
Disfrutadlo con salud ;)


lunes, 22 de octubre de 2012

Paella y Charlas para el Cumpleaños de Pentester.Es

Algunos de vosotros ya os habéis dado cuenta de la presencia desde hace unos meses de un contador en la parte derecha del blog al que en este momento le quedan unos 50 días para llegar a cero. Ha habido gente que me ha preguntado si iba a ser padre y este es un contador de lo que falta, pero no, eso lo dejaremos para un poco más adelante, aunque me ha gustado la idea :D

El contador llegará a cero el día 11 de Diciembre de 2012, momento en el cual hará 5 años que este blog puso su primer post. Puede parecer una tontería romántica, pero en el momento que lo monté me causó mucho esfuerzo y muchos problemas (que no entraré a mencionar), y en este momento me siento muy contento de que esté perdurando hasta hoy (aunque sí, lo sé, hay que escribir más :P).

El caso es que el siguiente sábado, el 15 de Diciembre de 2012, organizo en Valencia una Fiesta de Cumpleaños de Pentester.Es, pero en lugar de gorritos de fiesta y matasuegras, que no nos pegarían nada de nada, he invitado a varios amigos del mundo de la seguridad para que nos den unas charlas, y luego rematar comiendo una Paella Valenciana (como no podía ser de otra manera). Por lo tanto, entre las 10:30 y las 14:30 de ese día 15 de Diciembre, los asistentes podrán disfrutar de las charlas de (en orden alfabético):


Dani Kachakil es Ingeniero Informático y Máster en Ingeniería del Software por la UPV. Desde el año 2003 dirige el departamento de desarrollo de Electronic Dreams, empresa de la que es cofundador y copropietario.

Es participante habitual en numerosos retos de hacking ético a nivel nacional e internacional, online y presenciales, de forma individual y en equipo (int3pids), habiendo ganado u obtenido puestos destacados en la mayoría de ellos. También ha sido ponente en varias conferencias y cursos relacionados con la seguridad informática.
David Pérez es analista de seguridad de Taddong, una compañía dedicada a la investigación y servicios de seguridad, la cual cofundó en 2010. David tiene más de 10 años de experiencia proporcionando servicios avanzados de seguridad a clientes nacionales e internacionales, incluyendo varias compañías que se encuentran en la lista "Fortune Global 500". Está totalmente involucrado en las actividades de investigación de Taddong en áreas de seguridad como comunicaciones GSM/UMTS o seguridad en Windows. Además, es una de las tres personas que en este momento ostentan en España el certificado GSE (GIAC Security Expert) del SANS Institute.


Jose Luis Verdeguer (aka Pepelux) es Ingeniero Técnico de Sistemas Informáticos y Master en Desarrollo de Aplicaciones Web.
Lleva cerca de 20 años dedicado a diferentes campos dentro del mundo de las TI. En la actualidad es Director de Sistemas en el operador de VoIP Zoonsuite, donde realiza tareas de administración de Linux y sistemas de VoIP.

Pepelux también es gran apasionado de los retos de seguridad y participa activamente en tantos como puede.


Juan Garrido es un apasionado de la seguridad. Consultor especializado en análisis forense y test de intrusión, trabajando en proyectos de seguridad desde hace más de 8 años. Autor del libro “Análisis forense digital en entornos Windows” así como de artículos técnicos publicados en prensa especializada y medios digitales.

Juan es un ponente común en muchas de las conferencias más importantes a nivel nacional y del panorama internacional, como bien pueden ser NoConName, RootedCon, Defcon, Troopers, etc…



Las charlas tendrán lugar en el aula de formación del Colegio de Ingenieros en Informática, situada en la Avenida Baron de Carcer 48, 3ºO (también llamada "Avenida del Oeste"). El sitio está a unos 15 minutos andando de la estación de tren, como podéis ver AQUÍ. Una vez charloteados, nos desplazaremos POR ESTE CAMINITO hasta el casal de la Falla Plaza del Pilar, donde nos comeremos esa paellita de la que hemos hablado.

¿Os apetece? ¡Genial! La celebración está abierta a cualquier lector del blog, la única pre-condición es que, al ser las plazas tan limitadas, es necesario dejar la comida pagada (10€) a modo de señal, para no encontrarme con que haya gente que se apunte sin tener claro si va a poder venir o no y luego encontrarme con una paella encargada para tropocientos donde al final se presenta la mitad de gente. Seguro que me entendéis :P

Al que le interese asistir que debe escribir un correo a XXXXX (ocultado tras el evento) dando sus datos (nombre y DNI) y la cantidad de personas que van a ser y os mandaré una solicitud de pago por PayPal (se puede pagar con tarjeta de crédito sin tener cuenta de Paypal). Si alguien viene con pareja y esta se va a quedar dando una vuelta por Valencia mientras estamos de charla, que me lo diga para tener en cuenta las plazas de charla y de comida, ya que las primeras son un poco más limitadas. Recordad que la plaza no estará confirmada hasta que el pago no se haga efectivo.

En principio las horas de las charlas y la comida se han puesto de tal forma que la persona que quiera pueda ir y volver en el día por si a algún lector no le viene bien hacer noche en Valencia, pero al que le apetezca puede aprovechar la escusa para quedarse una o dos noches y ver la ciudad.

Según las estadísticas de visitas de este blog, la mayoría de lectores se encuentran en Madrid y en Barcelona, así que he creado tres grupos de Google: MADRID, BARCELONA y RESTO ¿Por qué? Pues porque es mucho más barato viajar en grupo que de forma individual. Podéis quedar varias personas para venir en coche, o comprar entre cuatro uno de esos billetes de tren que coges los cuatro asientos de la mesa y pagas solamente dos. Simplemente los he creado para que tengáis un medio para coordinaros si consideráis oportuno hacerlo.

Por último, pero no por ello menos importante, Miguel Gesteiro ha sido tan amable de ofrecerse a montar un CTF para la ocasión, empleando su conocido H4ckC0nt3st. Aún tenemos que ver como lo vamos a montar, pero seguramente estará on-line durante unos días antes del día de las charlas/paella.

¡Seguiremos informando! Mientras tanto, ya sabéis, los interesados podéis ir usando las listas y apuntaros si os apetece pasar este quinto cumpleaños con nosotros.

lunes, 15 de octubre de 2012

Luchando contra Mimikatz/WCE

Sin duda, uno de los descubrimientos de más trascendencia de este año fue la publicación primero por parte de PentestMonkey y posteriormente por PaulDotCom de la existencia de una herramienta llamada Mimikatz mediante la cual era posible obtener las contraseñas en texto claro de los usuarios de Windows directamente desde la memoria, y de la que ya hablé en este mismo blog AQUÍ.

Desde que apareció esta nueva técnica, tanto yo como cualquier Pentester, la hemos usado ampliamente durante nuestras auditorías, ya que conocer la contraseña en texto claro nos da la oportunidad de usarla en sistemas o aplicaciones no-Microsoft, algo que con otras técnica como el Pass-the-Hash o el Pass-the-Token no sucede. Esto ha llevado a dos cosas, la primera es una gran sorpresa por parte de los clientes cuando ven en el informe de auditoría que se pueden recuperar las contraseñas en texto claro, con una conversación que suele ser algo así:

Pentester: ... Y entonces volcamos esta contraseña en texto claro y la utilizamos para entrar en la aplicación XXX y...
Cliente: Espera, espera, espera ¿Windows se guarda mi contraseña en texto plano en la memoria?
Pentester: Sí, exactamente.
Cliente: Uffff.... ¡Menuda cagada!

 Pues sí, menuda cagada... pero a continuación viene la pregunta obligada:

Cliente: Y qué hacemos?

Esta es una pregunta que me han hecho en numerosas ocasiones ya, tanto clientes como amigos del mundo de la seguridad, ya que esto, como ocurre con el Pass-the-Hash, se considera una feature y no un bug, así que en principio Microsoft no va a sacar ningún tipo de parche de seguridad que lo corrija.

Ya que parece que vamos a tener que vivir con ello mucho tiempo, vamos a ver algunas aproximaciones que nos pueden ayudar a luchar contra esta técnica:

Deshabilitar los Security Packages

Sabemos que la causa de que Windows se guarda nuestras credenciales en texto plano (en realidad, con un cifrado reversible, pero a efectos prácticos da igual) es que la emplea para algunos servicios de SSO a través de los llamados Security Packages:

Imagen "prestada" del artículo que escribió mi compañero Ramón Pinuaga en el blog de S21sec

Estos Security Packages pueden ser desactivados editando el registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, por lo que la mejor opción para protegernos de esta técnica sería deshabilitarlos todos. No obstante, yo no soy sysadmin ni security admin y no tengo acceso a una red REAL en la que probar si esta solución puede ocasionar problemas de funcionamiento, por lo que recomiendo aplicarlo con cautela y con las pruebas previas adecuadas.

Como esto no va a ser siempre posible, y además no tenemos la certeza de que solo almacenen las contraseñas estos módulos, vamos a ver algunas otras mitigaciones.

Borrarlo de la Memoria

Una opción "para valientes" es, igual que estas herramientas se van a la memoria y recuperan la información, modificar el código fuente para que la sobreescriban. En el caso de WCE tendríamos que hacer Ingeniería Inversa de la herramienta, pero en el caso de Mimikatz, su código fuente está disponible AQUÍ, así que podemos cogerlo e intentar hacer nuestra propia versión que lo que haga sea sobreescribir las credenciales encontradas. Os adelanto que el código de donde se obtiene la información está en el directorio "sekurlsa/Security Packages":


Los offsets de donde está la información están referenciados dentro de la función "searchWDigestEntryList", según he podido ver. Esta es una solución que no me he metido a fondo a probar, ya que me parece aún más arriesgada que la primera, por aquello de sobreescribir repetidamente la memoria de un sistema en producción, además de que solo nos protege de que se obtengan las credenciales de aquellos lugares en los que se conoce que están, pero no tenemos la certeza de que existan en más sitios. En cualquier caso, es una alternativa que se podría estudiar más en profundidad si fuera necesario, a ver si tiene repercusiones de estabilidad en las máquinas o no, y si tiene ventajas con respecto a la primera.

 Reiniciar los Equipos de Usuario

Uno de los sitios donde no merece mucho la pena centrar esfuerzos en mitigar estas técnicas es en los equipos de usuario ¿por qué? Porque generalmente en los equipos de usuario... suele haber usuarios, y los usuarios tienen la fea costumbre de teclear sus contraseñas, con lo que al final vamos a poder obtener su contraseña en texto claro de todos modos. La única diferencia va a ser que con Mimikatz/WCE las obtendremos directamente, y si no podemos usar esta técnica tendremos que "motivar" al usuario a que la vuelva a teclear, cerrándole la sesión o poniéndole delante una ventana que parezca un bloqueo de sesión para que introduzca su contraseña, pero al final la contraseña se obtendrá.

El único peligro extra con los equipos de usuario es que obtengamos más credenciales además de la del usuario que lo está utilizando, por ejemplo un administrador que conectó para tareas de mantenimiento. Por esto es recomendable que el administrador, después de realizar sus tareas de mantenimiento, no cierre sesión y deje que el usuario continue trabajando, sino que realice un reinicio del equipo. No estaría de más tampoco que los equipos de usuario tuvieran programado un reinicio periódico nocturno, que por otra parte es necesario para que se apliquen los parches de seguridad, así que es una medida muy recomendable.

Reiniciar los Servidores

Como comentábamos, uno de los mayores peligros de esta técnica es que las credenciales permanecen en la memoria todo el tiempo que el sistema esté sin reiniciarse. Esto puede provocar que encontremos en ella credenciales de usuarios que accedieron al sistema meses antes de producirse la intrusión:


Evidentemente, un sistema servidor no es lo mismo que un equipo de usuario, y no podemos reiniciarlo cada vez que realizamos una tarea de administración, ya que ofrece servicios al resto de la empresa que en la mayoría de los casos no se pueden detener. Aún así, planificar reinicios periódicos (manuales o automáticos) minimizaría la cantidad de información que se puede obtener con estas técnicas. Si reiniciamos cada semana, pues solo se podrán obtener las credenciales de los usuarios que accedieron esa semana. No es una corrección definitiva pero es una manera de mitigar los efectos del uso de estas técnicas.

Usar Autenticación por Red

En entornos Microsoft, se diferencian básicamente tres clases de autenticación. La primera de ellas es el login en el terminal físico, la segunda de ellas es el login por escritorio remoto/terminal server, y la tercera es el acceso por red. Mucha gente con la que he hablado pensaba que con Mimikatz/WCE era posible obtener las credenciales de cualquier tipo de autenticación, es decir, que si comprometes un servidor de ficheros automáticamente obtienes las credenciales de todos los usuarios que tienen montadas carpetas de red. Esto no es así en absoluto.

Si pensamos de una manera más abstracta... para que estas herramientas puedan extraer mi contraseña en claro, tiene que haber estado en algún momento en la memoria del sistema ¿cierto? ¿Y en cuales de estos mecanismos lo hacemos? En el caso del acceso físico está claro que sí, y en el caso del acceso por escritorio remoto también, porque lo que se nos muestra es una ventana de login que es ofrecida por el sistema al que conectamos, así que pasará lo mismo.

En el caso de la autenticación a través de red, esto es radicalmente distinto. Microsoft utiliza los protocolos NTLM o Kerberos, que están basados en mecanismos de reto-respuesta. Veamos un ejemplo de como sería empleando NTLM:

http://www.defenceindepth.net/

Todos los mecanismos de reto-respuesta consisten, de forma básica, en que el servidor al que quieres generar te envía un número grande y aleatorio (el resto) que tu debes cifrar con algún tipo de clave precompartida. Este resultado del cifrado (la respuesta) se enviará al servidor para que este compruebe, realizando el mismo proceso, si la respuesta que a él le sale coincide con la tuya. Si es así, es porque ambos conocéis la misma clave, y por tanto te autentica. En los sistemas Microsoft, esta clave con la que realiza el cifrado no es la clave en si, sino el Hash de ella, que es lo que se almacena en los sistemas. Entonces... ¿cómo se va a poder obtener en este caso la contraseña en claro? Sencillo, NO se puede, porque esta contraseña en claro NUNCA ha sido tecleada en el servidor, por lo que "solo" podrá obtenerse el hash.


Debido a esto, todas las herramientas de administración que funcionen a través de la red no van a dejar ningún rasto en el sistema, por lo que deberemos usarlas siempre que sea posible para evitar dejar las contraseñas de administración en claro en el servidor. Esta puede ser una de las mejoras soluciones (aparte de deshabilitar los security packages), ya que podemos realizar la gran mayoría de gestiones de administración (usuarios, servicios, disco, ficheros, etc) sin necesidad de hacer login en el equipo:

El Administrator está porque es con el que hice el login físico para hacer el volcado, pero el resto no aparecen

Cambiar las Contraseñas

Hemos estado hablando todo el rato de la aproximación de "que no me puedan capturar las contraseñas en texto claro", pero en realidad existe otra aproximación igual de buena: "que no les sirvan para nada las contraseñas que me capturen". La aproximación más "artesanal" de esta idea es cambiar la contraseña de Administrador con frecuencia, de tal forma que si dejé rastro en un sistema de la contraseña del mes pasado, este mes ya no les sirva esa contraseña. OJO, no vale el famoso truco de usar la misma palabra e ir cambiando el número final, porque es algo que sin duda va a probar un atacante. Tiene que ser una contraseña completamente diferente.

En algunos clientes a los que he tenido la oportunidad de visitar he visto sistemas que cumplen perfectamente esta función. Estos sistemas tienen control sobre una serie de usuarios que se pueden emplear para administrar los sistemas, los cuales se mantienen deshabilitados. En el momento que un administrador, a través del interface web, solicita el acceso al sistema para administrarlo, el sistema le asigna una contraseña aleatoria y se la proporciona al administrador, y habilita el usuario. Pasado el tiempo que éste ha solicitado, el usuario se deshabilita de nuevo automáticamente.

Este tipo de sistemas, aunque fueron diseñados como medio de control sobre los usuarios administradores en entornos donde existe mucho proveedor externo, proporciona una protección muy buena ante el tipo de ataques que comentamos, ya que las contraseñas robadas no van a tener ninguna utilidad.

Estas son todas las contramedidas que se me han ocurrido a mi y que he recomendado cuando me han preguntado sobre el tema, pero si tienes tu propia solución... es el momento de que dejes un comentario :)