Archive for Pentesting

iOS Hacking: Introducción al análisis dinámico de aplicaciones con Frida

En este artículo pretende ser una breve introducción a LA HERRAMIENTA por excelencia en iOS usada en las auditorias de aplicaciones para el análisis dinámico. Como ejemplo básico, usare la aplicación de una conocida franquicia de comida rápida y de paso obtendremos algún que otro descuento “by the face”.

 

¿Qué es Frida?

 

Frida es un poderoso y flexible set de herramientas de instrumentación dinámica creada por Ole André V. Ravnås (@oleavr). Este set de herramientas permite, entre otras cosas, visualizar y manipular “on-the-fly” procesos en ejecución en múltiples plataformas (Windows, macOS, GNU/Linux, iOS, Android y QNX).

El núcleo de Frida funciona en C, pero la instrumentación se da a través del motor JavaScript que inyecta en el proceso. Inicialmente fue el conocido V8 de Google pero en la actualidad se usa por defecto Duktape. Básicamente Frida nos da una interfaz JavaScript para interactuar con la memoria del proceso en ejecución interpretándolo y permitiéndonos inspeccionar el estado de los objetos, variables e hilos que nos permite, por ejemplo, capturar un determinado parámetro pasado a una función o editar el valor devuelto por ella. Esta interacción la podemos desarrollar en diversos lenguajes (Python, Node.js, .NET o Qml, pudiendo extenderse a otros) y nos permite automatizar todo el proceso con unos simples scripts. ¡Casi ná!

Read more

Auditando la red wifi de mi universidad

Dentro de este pequeño mundo de la seguridad informática he tenido la suerte de conocer a grandes personas, con las cuales he compartido más de un año de trabajo dentro del equipo de SVT y a los que estoy más que agradecido por el buen hacer que han tenido conmigo. Así que, queridos lectores, permitidme dedicar el post de hoy a esta familia, que se lo merecen en toda regla.

Hoy, como veremos, tenemos por delante un artículo un poco diferente de los que estamos acostumbrados, ya que el contenido relevante es un vídeo que grabé para la defensa de mi trabajo de final de grado. Éste, tiene por objetivo demostrar como era posible extraer las credenciales de los usuarios (alumnos y profesores) de la red eduroam de la Universidad de Lleida, mi antigua universidad.

En este caso, se trata de un hecho muy importante en referencia a los términos de seguridad, ya que la misma contraseña que se emplea para acceder a la red inalámbrica también se utiliza para acceder al correo, al campus virtual y a todo lo que deriva de éste, como puede ser el expediente o todo lo relacionado con las asignaturas, la entrega de prácticas y las notas e incluso, permite iniciar sesión en nombre de la víctima en cualquier máquina puesta a disposición del público. En breves palabras, la misma contraseña no simplemente permite acceder a los datos privados del usuario sino que también permite robar la identidad de la persona afectada, en todos los ámbitos.

Desde el punto de vista técnico, la red eduroam en cuestión, está configurada con cifrado CCMP (WPA2) y con una autenticación 802.1x, conocida coloquialmente como Enterprise, que en este caso emplea la propia autenticación a través del protocolo PAP dentro de un túnel TLS (TTLS/PAP).

Los puntos principales que se tratan en el vídeo son los siguientes:

  • Configuración del terminal Android para dicha red.
  • Motivo por el cual podemos realizar la suplantación de un punto de acceso legítimo.
  • Herramientas que podría utilizar un atacante y su correspondiente aplicación.
  • Análisis del entorno real.

Aquí tenéis el enlace del video:

Una vez publicado el vídeo, significa que el Departamento de Sistemas de la universidad me ha dado autorización para hacerlo. Esto es debido a que ya ha tomado las medidas oportunas para solventar la inconveniencia.

Sin más, espero que haya sido de vuestro agrado. Y recordad, averiguar la contraseña es simplemente un daño colateral. ¿Qué pasaría si nuestro punto de acceso falso diera por válida la autenticación del usuario, le ofreciera servicio DHCP y acceso a Internet? El usuario no lo notaría, ya que creería que está en la red legítima, pero nosotros tendríamos comunicación directa con su dispositivo, sin ningún tipo restricción, y además, sobre un escenario man in the middle (MitM). ¿Lo dejamos para otro vídeo? 😉

¡Saludos!

Ferran Verdés

Enlace del vídeo: https://youtu.be/XmKokmOYdV0

OWASP Mobile Security Project

Introducción

OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles, tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.

Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).

Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas para evaluar la seguridad de las aplicaciones móviles.

OWASP Objetivos

OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima seguridad posible. Para ello OWASP nos propone su Mobile Security Project.

owasp-msp-logo

La imagen anterior es el logotipo oficial del proyecto OWASP Mobile Security Project.

OWASP ProcesosAl igual que en las aplicaciones web, para conseguir el nivel máximo de seguridad posible es imprescindible que todos los factores se alineen; personas, procesos y tecnología.

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.

Developer Cheat Sheet: Una “chuleta” con consejos para el desarrollador para evitar errores que puedan dar lugar a vulnerabilidades en su aplicación.

App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información interesante para llevar a cabo la evaluación de la seguridad de la aplicación.

Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el ciclo de desarrollo de software seguro (S-SDLC).

Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también podemos encontrar una guía de test para ayudar al auditor durante sus tareas de evaluación de los controles de seguridad de la aplicación.

Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles para las diferentes plataformas (Android, iOS o Windows Phone).

Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el top 10 de los controles de seguridad a evaluar.

owasp-msp-resources

En próximos artículos en el blog hablaremos de los distintos recursos que acabamos de comentar. Como siempre, esperamos que sean de vuestros interés y esperamos vuestro feedback.

¡Saludos!

@miguel_arroyo76

 

 

Desactivando ASLR en una app iOS con Radare2 – Parte 2

Introducción

Continuamos con la segunda y última parte de este artículo acerca de cómo desactivar ASLR en una aplicación iOS con Radare2. En la primera parte, que podéis consultar aquí, vimos cómo comprobar si un binario de tipo Mach-O tiene activado o no la protección PIE (Position-Independent Executable). PIE permite el uso de Exec Shield o PAX que utilizan técnicas de direccionamiento aleatorio como ASLR (Address Space Layout Randomization).

También vimos que dependiendo de la arquitectura, ARMv7 o ARM64 tendríamos que buscar una cadena u otra. Además vimos que esa cadena a buscar en nuestro binario estaría cerca de la cadena _PAGEZERO, que nos puede servir de referencia.

Manos a la obra

Vamos a “parchear” nuestro binario para modificar unos bytes que nos permitirán desactivar el PIE. Para ello abriremos el binario en modo escritura con Radare2. Para abrir un binario en modo escritura utilizaremos el parámetro -w (write).

Radare2 - Write modeEn la imagen anterior podemos ver que hemos abierto ya no está cifrado (aplicado Clutch en la primera parte), y que tiene habilitado PIE.

Localizamos la cadena a buscar, tal y como hemos visto en la primera parte de este artículo, y pasaremos a explorar el binario para hacer el “parcheo“.

Con la tecla v (visual mode) de Radare2 podemos entrar en modo visual, lo que nos va a permitir a ver las distintas direcciones relativas y sus contenidos. Con la tecla c (cursor mode) activamos el cursor y podremos desplazarnos por los contenidos mostrados.

Una vez localizados los bytes a modificar, 850020 (recordad que varía según la arquitectura), procedemos a activar el modo insertar, para lo que pulsaremos la tecla i en Radare2.

Radare2 - Insert modeEn este modo de inserción, podremos modificar los bytes, dejándolos como vemos en la siguiente imagen.

Radare2 - Insert mode

Salimos de Radare2, los cambios se guardarán automáticamente porque hemos “escrito” directamente en el binario.

Comprobación

Comprobamos nuevamente con la herramienta otool si PIE sigue activado o no.

otool - iOS PIE

Podemos comprobar como efectivamente en el binario cuyo nombre acaba en _NoPIE hemos conseguido deshabilitar PIE.

Para finalizar, con otra herramienta del framework de Radare2, como es radiff2, podemos buscar diferencias entre dos binarios. Si lo aplicamos a los dos binarios con los que hemos estado trabajando, uno con PIE activado y el otro con el PIE desactivado con Radare2, podemos ver la diferencia en el byte modificado.

A continuación se puede ver un ejemplo de radiff2 con estos archivos.

Radiff2 - PIE

Hasta aquí este artículo que, como siempre, esperemos haya sido de vuestro interés. Todos los comentarios y sugerencias serán bienvenidos. Gracias de antemano.

¡Hasta pronto!

Miguel A. Arroyo – @miguel_arroyo76

Desactivando ASLR en una app iOS con Radare2 – Parte 1

Introducción

En este artículo explicaremos cómo podemos desactivar ASLR (Address Space Layout Randomization) en una app iOS. Ya vimos en un artículo anterior cómo podemos comprobar con la herramienta otool si una aplicación iOS tiene activada esta protección o no. Podéis leer el artículo en este enlace.

ASLR, PIE, PAX y Exec Shield

En realidad lo que se comprueba es si el binario ha sido compilado con PIE (Position-Independent Executable). Los binarios de tipo PIE permiten en algunas distribuciones GNU-Linux orientadas a seguridad a hacer uso de PAX y Exec Shield, que son unas implementaciones realizadas a nivel de kernel. Estas implementaciones aumentan la seguridad del sistema, permitiendo por ejemplo el direccionamiento aleatorio de los objetos del programa en memoria, dificultando así posibles explotaciones de vulnerabilidades de tipo buffer overflow, entre otros. Aquí es donde ASLR entra en juego.

La siguiente imagen corresponde a la versión PAX de Tux. 😉

170px-pax_tux

Para evitar confusiones, aunque la finalidad es deshabilitar el direccionamiento aleatorio (ASLR), nos referiremos a PIE, ya que así es como se refleja el flag en el binario que vayamos a analizar. De hecho, con otool el resultado del análisis se muestra de la siguiente forma.

Comprobar PIE con otool

Se puede observar a la derecha de la imagen que el binario analizado muestra el flag PIE activado.

Radare2

Este magnífico framework de ingeniería inversa creado por Sergi Álvarez (@pancake), que surgió como una herramienta de forense, actuando como un editor hexadecimal capaz de abrir archivos de disco. A día de hoy cuenta con un interesante arsenal de utilidades que permiten analizar binario, desensamblar código, depurar programas o hacer depuración remota a través de servidores gdb.

Podéis encontrar toda la información en el siguiente enlace: https://github.com/radare/radare2

A título personal decir que, aunque la curva de aprendizaje es alta, es un framework que merece la pena conocer, estudiar y usar, sobre todo si te dedicas a ingeniería inversa, o estás pensando en dedicarte. Yo soy un auténtico novato de esta herramienta, pero lo poco que he aprendido hasta ahora quería compartirlo vosotros, y qué mejor manera que hacerlo de manera práctica con este ejemplo que estamos viendo.

¿Qué buscamos exactamente?

Después de analizar varios binarios de aplicaciones iOS de diferentes arquitecturas (ARMv7 y ARM64), he llegado a la conclusión que el volcado en hexadecimal que hay que buscar con Radare2 son los siguientes:

Hex bytes: 858021 para la arquitectura ARMv7

Después de abrir Radare2 con el binario a analizar (thin_binary), para lo que usaremos la sintaxis “r2 thin_binary“, haremos una búsqueda (seek) con el comando “s“, especificando que estamos buscando un volcado en hexadecimal, de ahí la “/x” y a continuación lo que queremos buscar (858021).

PIE hexdump in Radare2

Si estamos analizando una app de iOS de ARM64, los hex bytes a buscar serían 850020.

PIE flag in Radare2

Observad que en ambos casos, cuando encuentra el patrón buscado, es decir hace 1 hit, Radare2 automáticamente nos posiciona en el offset donde los ha encontrado (0x00000018, en el último ejemplo). Finalmente mostramos un volcado de 16 bytes con el comando “px” donde podemos ver que se muestran los hex bytes que estábamos localizando.

También podemos localizar fácilmente el offset donde encontrar estos hex bytes buscando la sección / segmento _PAGEZERO, que suele estar siempre muy cerca de estos bytes. Pero sin lugar a duda, lo más certero es utilizar el comando “s/x [hexbytes_armx]” para localizarlo y ubicarnos.

Hasta aquí esta primera parte de este artículo. En el siguiente artículo veremos qué bytes hay que modificar, cómo abrir el binario en Radare2 en modo escritura, cómo buscar diferencias enter el binario original y el parcheado con rabin2 y finalmente comprobar nuevamente con otool que hemos conseguido deshabilitar el flag de PIE.

Como siempre, espero que sea de vuestro interés y nos vemos pronto en la segunda parte de este artículo.

PD: Cualquier comentario, consulta y recomendación será bienvenido, sobre todo si es de Radare2, donde me tenéis que disculpar, pero soy muy novato. Eso sí, con muchas ganas de seguir aprendiendo y compartiendo. 🙂

 

La seguridad actual de la autenticación inalámbrica PSK (III)

En esta tercera entrega, llega el momento de extraer nuestras propias conclusiones sobre la seguridad actual de la autenticación PSK. Resulta que con la ejecución de Pyrit en una instancia g2.8xlarge del Cloud de Amazon, se obtiene un rendimiento interesante en el cómputo de claves:

011 - pyrit benchmark AMAZON

Tal y como se puede observar en la ilustración anterior, se cuenta con un cálculo de 115.265 claves/segundo, un incremento más que considerable en referencia a las 836 claves/s iniciales de mi máquina virtual.

Pero esto no termina aquí. Aún podemos mejorar la capcidad de cómputo y de una forma más que considerable. Existen dos opciones:

  • Ejecución de Pyrit en modo distribuido.
  • Utilizar tablas PMK precomputadas.

Una vez más, debido a la magnitud que debe respetar el artículo, es necesario focalizar nuestros esfuerzos en una de las opciones anteriores y, en este caso, se ha optado por mostrar la velocidad extrema que se consigue con las tablas PMK precomputadas.

Read more

La seguridad actual de la autenticación inalámbrica PSK (I)

Han pasado ya algunos años desde que el estándar 802.11i fue ratificado en Junio de 2004, y algunas cosas han cambiado desde aquel entonces, dando énfasis en la capacidad de computación de las máquinas. No obstante, sobre la misma línea, nada nuevo está presente en la autenticación WPA, que como ya sabemos se encuentra dividida en dos bloques:

  • WPA Enterprise Authentication: donde se utiliza el estándar 802.1x y normalmente un servidor Radius para efectuar Authentication, Authorization y Accounting (AAA).
  • WPA Personal Authentication: donde se emplea una passphrase precompartida por todos los integrantes de la red (similar a WEP).

En esta secuencia de artículos, primeramente veremos los fundamentos del ataque sobre la autenticación PSK (Pre Shared Key), también conocida como autenticación “Personal”, y posteriormente lo pondremos en práctica sobre el Cloud de NIMBIX y de Amazon para extraer nuestras propias conclusiones.

Partiendo de la base de tener en posesión un handshake, sólo nos queda por dar una pequeña pincelada a la generación de la PTK (Pairwise Transient Key):

Diagrama generación PTK

Como podemos ver, la clave precompartida, denominada passphrase, se pasa a una función conocida como PBKDF2, utilizada en PKCS#5, conjuntamente con los siguientes parámetros:

  • El SSID y su longitud.
  • El número de iteraciones a realizar, 4096.
  • La longitud de la clave resultante, 256.

Read more

Skipfish, Escaner Web

Hoy en día existen infinidad de aplicaciones, scripts, frameworks, etcétera para auditar sistemas, ya sean de infraestructura de red, Web, Web basado en OWASP, Wireless, etc… Suelen aparecer software con versiones gratuitas, gratuitas con limitaciones y versiones de pago con diferentes de modalidades.

Las de pago las vamos a obviar porque evidentemente, se necesita una inversión bastante potente en muchas de ellas y para algo “casero” pues no es demasiado lógico gastarse miles de euros.

Las versiones libres o scripts subidos a la red (GitHub por ejemplo), suelen tener la ventaja que son personalizables y puedes editarlos a tu gusto, que es lo que se estila para adaptar los resultados a gusto o necesidad de auditores o meros curiosos.

Hoy nos vamos a centrar en mostrar un escaner Web bastante potente que tiene sus pros y contras pero que es otra herramienta más que puede ayudarnos enormemente en labores de buscar agujeros de seguridad en plataformas Web ya sean en pre-producción o producción. Hablamos de Skipfish

skipfish2

Read more

Seguridad en las impresoras

Introducción

Cuando hablamos de seguridad en las empresas y qué activos proteger, enseguida se nos vienen a la cabeza los distintos vectores de ataque de nuestros sistemas de información y cómo protegernos de esos posibles ataques. Pero, ¿qué ocurre con la seguridad en las impresoras?

Seguridad perimetral, seguridad en las comunicaciones, seguridad en el puesto de trabajo, seguridad en los dispositivos móviles… son algunos de los ejemplos de protección de activos de la empresa.

Pero estamos pasando por alto un tema importante de seguridad en este planteamiento, y se trata de las impresoras. ¿Existen posibles vectores de ataque a este tipo de dispositivos? Si es así, ¿cuáles podrían ser? Quizás el problema radique en que vemos a la impresora como una “simple” máquina cuya función es imprimir lo que desde un ordenador enviamos.

Si nos detenemos en qué es una impresora, enseguida entenderemos que, además de la electrónica y mecánica pura de una impresora, está dotada de una serie de puertos, interfaz de red, controladores, disco duro y un pequeño ordenador, con su BIOS y con su sistema operativo, que maneja estos recursos.

OK, ahora más o menos nos hacemos una idea, pero ¿qué riesgos hay realmente? Vamos a dividirlos en varios apartados:

Vectores de ataque

Confidencialidad del documento impreso

En entornos corporativos es muy normal que se utilicen impresoras de red que está ubicadas en un lugar remoto de la oficina. ¿Qué ocurre si mandamos a imprimir un documento con información sensible? Desde que nos levantamos del puesto de trabajo hasta que recogemos el documento de la bandeja de la impresora, ¿quién ha podido ver o fotocopiar ese documento?

Las impresoras suelen incluir una funcionalidad llamada impresión privada, que permite proteger con un PIN la impresión del documento. Éste queda en cola hasta que el usuario, después de enviar el documento a imprimir, introduce su PIN de seguridad en la impresora para que ésta imprima el documento.

Vulnerabilidades

La impresora ejecuta una serie de servicios que se publican en unos puertos, por ejemplo para su administración. Hoy en día es bastante habitual que las impresoras puedan ser gestionadas vía Web, por lo tanto disponen de su propio servidor Web que permite esta administración.

El software que gestiona dicho servicio puede estar afectado por algún tipo de error que pueda dar lugar a una vulnerabilidad que podría ser aprovechada por un posible atacante y explotada para, por ejemplo, provocar una denegación del servicio.

Modificación de firmware

Las impresoras para mejorar sus funcionalidades o corregir posibles errores de sus software, permite la actualización de su firmware. Este firmware normalmente está disponible en la Web del fabricante. Un posible ataque podría ser la alteración de este firmware para tomar el control de la impresora de forma remota, capturar tráfico o para lanzar ataques a otros dispositivos de la red.

Robo de información

Ya existen muchas impresoras que incluyen un disco duro para el almacenamiento de información, como pueden ser trabajos, históricos de impresiones, documentos escaneados, etc. Al final ese disco duro podría ser extraído de la impresora, y si no hay un cifrado en la información de éste, se podría consultar sin ningún problema información sensible de los trabajos realizados en la impresora.

Indexación de impresoras en Internet

Muchas impresoras, por razones extrañas, son publicadas directamente en Internet. Esta publicación da lugar a que motores de indexación de dispositivos como Shodan acaben añadiendo a su base de datos información de la impresora como puede ser su banner del servidor Web, dirección IP pública, servicios publicados, localización… Si además, la administración Web no ha sido protegida de forma adecuada, se podría dar el caso de que algún atacante tuviera fácilmente acceso a ella.

Instalación de aplicaciones maliciosas

Por último, y no menos importante, es la mención a la posibilidad de instalar aplicaciones en las impresoras. Aplicaciones que pueden ser potencialmente peligrosas y pueden ser usadas de forma maliciosa para controlar la impresora con fines fraudulentos, como puede ser la captura de tráfico de la red o acceder a trabajos de ésta. Se han dado casos muy curiosos como la instalación del juego Doom en una impresora. Otro vector de ataque a tener muy en cuenta.

Conclusión

Con los posibles vectores de ataque que acabamos de comentar, creemos que son lo suficientemente relevantes para que a dispositivos como impresoras le demos la importancia que realmente tienen, y se apliquen una serie de políticas de seguridad para mitigar o reducir los posibles riesgos que estos vectores puedan suponer para la empresa. Resumiendo, no nos podemos olvidar de la seguridad en las impresoras.

Auditando Aplicaciones en Android

Vamos a ver algunos ejemplos de controles que se llevan a cabo en un Pentesting de Aplicaciones en Android. Lo más importante en un proceso de auditoría será el hacer uso de una metodología, de tal forma que podamos llevar a cabo una serie de pasos de manera ordenada.

Os propongo que hagamos uso de la metodología OWASP, concretamente en su apartado de OWASP Mobile Security Project podemos encontrarnos con muchos recursos: herramientas, guía de desarrollo seguro, plantilla de controles, guía de testing de Apps… Centrándonos en esta última podemos dividir nuestra auditoría en tres partes: recopilar información, análisis estático y análisis dinámico. Read more