5º Aniversario de Pentester.Es

Como ya anuncié en su momento, hoy hace exactamente 5 años que se publicó el primer post de Pentester.Es, un 11 de Diciembre de 2007: http://www.pentester.es/2008/08/nace-wwwpentesteres.html

El blog empezó como una idea entre tres amigos de publicar la información que obteníamos en nuestros "trasteos". De retribuir al mundo algo del conocimiento que habíamos adquirido de él. Luego, con el paso del tiempo, se ha convertido practicamente en un proyecto individual, aunque las contribuciones siempre han sido bien recibidas.

La frecuencia de publicación ha ido variando con el paso del tiempo, en función de la disponibilidad del editor (que no ha sido mucha), pero intentando siempre poner artículos interesantes, aunque fueran pocos.

Durante estos 5 años hay a mucha gente a la que agradecer que este blog que yo en un principio pensé que acabaríamos leyendo 4 amigos se haya convertido en un blog con muchos más lectores de lo que hubiera llegado a imaginar.

Me gustaría darles las gracias desde aquí a todas las personas que han contribuido con artículos, porque libera un poco de la carga de trabajo que supone la publicación de contenido de forma regular. También me gustaría agradecer a Yago Jesús, del blog SecurityByDefault (conocido por todos), porque fue el precursor del salto de este blog del estatus de "blog de amigos" a "blog público" gracias a un post titulado "Blogs interesantes de Seguridad" que publicó allá por el 2009 y que podéis leer AQUÍ.

Y por supuesto, y por encima de todo, gracias a todas las personas que leéis este blog y que comentáis los artículos, a pesar de que la frecuencia de ellos sea menor de la que nos gustaría, pero que seguís leyendo detenidamente cada cosa que escribimos.

Dicho esto, como sabéis y os comenté EN ESTE POST, este sábado es la celebración del cumpleaños. Las plazas ya están cerradas pero os dejo aquí el orden final de las charlas y sus títulos para los que ya estáis apuntados:

10:30 - 11:30 - "Un laboratorio GSM por menos de 100€" (José Picó & David Pérez).
11:30 - 12:30 - "What lies Internet beneath?" (Juan Garrido & Pepelux)
12:30 - 13:30 - "Criptografía en CTFs" (Dani Kachakil)

Tras estas charlas, nos iremos a comer una paellita con algún que otro picoteo como celebración, y después... estamos abierto a cualquier propuesta :)

Gracias a todos los que venís, y a los que no venís... con un poco de suerte nos veremos en el 10º aniversario ;)

Análisis de Tráfico SSL en Android 4.x

El post de hoy no trata de ninguna nueva técnica ni nada excesivamente sofisticado, sino más bien de algo que es conocido pero que la gente con memoria de pez como yo se ve obligado a buscar una y otra vez cuando necesita hacer algo.

Cuando queremos analizar una aplicación de Android, ya sea para hacer una auditoría o para analizar si tiene algún componente malicioso (en mi caso suele ser lo primero), una de las cosas que tenemos que mirar son los puntos de comunicación con el exterior. Uno de los medios de comunicación más habituales es el uso de HTTP para comunicarse con aplicaciones web externas o web services. Hasta aquí ningún problema, podemos suplantar el nombre empleando el módulo fakedns de Metasploit ([1] [2] [3]) e interceptar las comunicaciones empleando Burp Proxy, ZAP o cualquier otro a vuestra elección.

El principal problema ocurre cuando esta comunicación es HTTPS, ya que estos proxies lo que hacen es crear una CA interna y van generando certificados firmados por esta CA para cada web que visitas (el funcionamiento puede cambiarse, pero este es el que viene por defecto con Burp). Esta CA creada por Burp, evidentemente, no es de confianza para nuestro Android, así que se nos muestra un mensaje de advertencia como el que vemos arriba o, sencillamente, la aplicación que estamos auditando rechazará la conexión por no estar firmado el certificado por una CA de confianza.

Como muchas veces la aplicación no nos va a dejar que aceptemos este certificado, vamos a tener que hacer algo para que nuestro Android confíe en la CA de nuestro Burp, así que lo primero que vamos a hacer es obtener la clave pública de esa CA. La manera más sencilla es hacer que nuestro navegador estandar use el burp y visitar cualquier web por HTTPS. Si vemos el detalle de los certificados veremos que podemos exportarlos en varios formatos. Hagámoslo en PEM:

Ahora que tenemos el certificado habrá que subirlo de algún modo a nuestro dispositivo. Se puede hacer de varias formas, pero una de las más cómodas es usar el comando "adb" que viene con el SDK de Android:

$ adb push PortSwiggerCA.pem /sdcard/
107 KB/s (1038 bytes in 0.009s)

Ya lo tenemos subido ¿y ahora dónde lo metemos? En versiones anteriores de Android los certificados de las CAs de confianza se encontraban en un único fichero que debíamos bajar a nuestro equipo, añadir la nueva CA y posteriormente volverlo a subir. En el caso de Android 4 la cosa ha cambiado un poco, ahora tenemos una serie de ficheros en /system/etc/security/cacerts/ que contienen cada uno de ellos un certificado de una CA:

$ adb shell
shell@android:/ $ su
shell@android:/ # cd /system/etc/security/cacerts/

shell@android:/system/etc/security/cacerts # ls -la

-rw-r--r-- root     root         4767 2012-09-28 14:15 00673b5b.0

-rw-r--r-- root     root         4573 2012-09-28 14:15 03e16f6c.0

-rw-r--r-- root     root         5292 2012-09-28 14:15 08aef7bb.0

-rw-r--r-- root     root         4540 2012-09-28 14:15 0d188d89.0

-rw-r--r-- root     root         4614 2012-09-28 14:15 10531352.0

-rw-r--r-- root     root         4686 2012-09-28 14:15 111e6273.0

-rw-r--r-- root     root         5027 2012-09-28 14:15 1155c94b.0

-rw-r--r-- root     root         5345 2012-09-28 14:15 119afc2e.0

-rw-r--r-- root     root         5844 2012-09-28 14:15 11a09b38.0

[...]

Parece que, si disponemos de acceso root, debería ser tan fácil como colocar nuestro fichero PEM en este directorio ¿Con cualquier nombre? Pues no, cualquier nombre no vale. Esos números que vemos no son más que un hash del subject del certificado, y se usan como si fuera una tabla hash, es decir, cuando se obtiene un certificado que está firmado por una CA, se realiza el hash del subject de esta CA y se busca el fichero con este nombre. Si se producen colisiones en el hash se va incrementando el número de la extensión (.0 .1 .2 ...). Para obtener ese hash lo podemos hacer con openssl de la siguiente forma:

$ openssl x509 -noout -subject_hash_old -in PortSwiggerCA.pem
9a5ba575

Ahora solo nos quedará meter el certificado en el lugar indicado con el nombre adecuado. Para ello, depende del rooteo que hayamos hecho, es probable que tengamos que remontar en lectura/escritura la partición /system:

shell@android:/system/etc/security/cacerts # mount -o rw,remount /system
shell@android:/system/etc/security/cacerts # cat /sdcard/PortSwiggerCA.pem > 9a5ba575.0
shell@android:/system/etc/security/cacerts # mount -o ro,remount /system

Hecho esto ya solo tenemos que reiniciar el terminal y volver a repetir el proceso. Ahora cuando visitemos una página HTTPS a través de Burp, el navegador va a aceptar el certificado que éste le proporciona, y por tanto va a poder inspeccionar y modificar este tráfico.

Lo mismo va a ocurrir con las aplicaciones en las que no podíamos simplemente darle a "aceptar certificado", con lo que ya tenemos resuelto el problema de inspeccionar este tráfico.

Ahora quedaría mirar si, dentro de ese tráfico, podemos manipular la información o hacer algo con lo que vulneremos la seguridad de la aplicación, pero eso ya... es otra historia.

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 ;)