Archive for Desarrollo seguro

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

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

Sockets SSL en Python

Recientemente un lector del blog me contactó para pedirme, muy amablemente, si podía ayudarle a comprender los conceptos de implementación de sockets SSL en Python. ¡Por supuesto! Y como siempre, fiel a la humilde ideología de este blog, quedará aquí todo expuesto con el fin de compartirlo con todos vosotros e intentar ayudar a alguien más.

En primer lugar, vamos a ver un breve resumen del concepto de socket.

Dentro del ámbito de la programación, se utiliza el término socket para hacer referencia, principalmente, a las siguientes definiciones:

  • Socket (def. [1]): concepto abstracto por el cual dos programas, normalmente situados en computadoras diferentes, pueden intercambiar un flujo de datos a través de un canal de comunicación.
  • Sockets (def. [2]): en muchos casos la Network Application Programming Interface (NAPI) denominada BSD Berkeley Sockets se abrevia a Sockets. Se trata de una interfaz de trabajo que se utiliza para relacionar la capa de aplicación con la capa de transporte. Normalmente, este tipo de interfaces las proporciona el sistema operativo. A continuación, siguen otras NAPIs conocidas:
    • TLI, XTI (de AT&T UNIX System V)
    • Winsock (de Microsoft)
    • MacTCP (de Apple Computer)

Veamos una imagen representativa de estas:

NAPI en el Modelo TCP-IP Read more

Web Hacking : Una línea para manejarlos a todos

¿Podría darte una línea de código acceso a un sitio Web completo? ¿Qué información obtendría un atacante si consiguiera llegar al nivel más bajo de tu página Web? es decir, a tu BBDD o SSOO. Dependiendo del objetivo de la misma podría encontrar seguramente información sobre la identidad de los usuarios, transacciones bancarias, compras online, usuarios, contraseñas y mucho más.

¿Cuánto vale tu información? Debemos de establecer unos controles de seguridad mínimos a nuestro sitio Web, llevar a cabo una serie de auditorías de seguridad que garanticen el buen funcionamiento de la misma. No sólo tener en regla la política de cookies y poco más, sino os puede ocurrir como la Web con la que me encontré hace unas semanas a la hora de preparar una charla. Antes de nada os muestro un disclaimer.


Aviso Legal y Descargo de Responsabilidad

  1. El objetivo de lo mostrado a continuación tiene fines educativos para aprender a mejorar la seguridad de nuestros sitios Web.
  2. No nos hacemos responsables del mal uso que se le pueda dar a las herramientas mostradas.
  3. Toda la auditoría Web mostrada a continuación se ha llevado a cabo con permisos de sus administradores según lo acordado en documento legal.

Vamos a llevar a cabo la auditoría de un sitio Web siguiente la metodología OWASP, concretamente seguiremos la OWASP Testing Guide V4. Los diferentes puntos que abarca dicha metodología los podéis ver detalladamente en el enlace anterior. A continuación nombramos los aspectos generales a tratar.

Read more

DLL Hijacking – Comprobando la vulnerabilidad

En el anterior artículo de esta serie sobre DLL Hijacking, vimos cómo podríamos descubrir posibles aplicaciones vulnerables a DLL Hijacking. En esta segunda parte daremos un paso más y veremos cómo comprobar la vulnerabilidad en una aplicación que estemos auditando.

Una vez que ya tenemos DLL candidatas a ser usadas, que previamente hemos descubierto con nuestro Procmon, procederemos a crear nuestra propia DLL que suplantará a la que la aplicación está buscando, con la idea de que se ejecute el código que nosotros indiquemos.

En este caso, nuestro objetivo para esta fase de comprobación, es que al ejecutar la aplicación vulnerable nos muestre una ventana con el mensaje “DLL Hijacked!“.

Tenemos varias opciones a la hora de crear nuestra DLL pero lo haremos de la forma más práctica y sencilla. Es aprovechando un código ya creado por LiquidWorm y que está publicado en la Web de exploit-db. Se trata de una DLL muy sencilla que utiliza la función DllMain() para ejecutar código.

La URL donde podéis ver y descargar el código es la siguiente:

https://www.exploit-db.com/exploits/14789/

Como podéis observar al final del código, si se ejecuta correctamente nuestra DLL, por lo tanto la aplicación es vulnerable a DLL Hijacking, se abrirá una ventana de MessageBox:

MessageBox(0, "DLL Hijacked!", "DLL Message", MB_OK);

DLL Hijacking

Read more

DLL Hijacking – Descubriendo posibles aplicaciones vulnerables

Este artículo será el primero de una serie dedicada a la vulnerabilidad conocida como DLL Hijacking. Haremos una breve introducción y veremos cómo llevar a cabo una primera fase de descubrimiento de posibles aplicaciones candidatas a ser vulnerables a DLL Hijacking.

Para entender bien en qué consiste esta vulnerabilidad tenemos que tener claro cuál es la funcionalidad de estos ficheros en nuestros sistemas Windows, de los cuales encontraremos muchos repartidos por nuestro sistema de ficheros.

El uso de DLL, Dynamic Link Library, es el método más utilizado por Windows y aplicaciones para compartir funciones, haciendo que las aplicaciones sean más modulares y permita reutilizar funciones comunes que ya están desarrolladas y que son exportadas por estas librerías.

DLL Hijacking - Parte 1

La idea es que cualquier ejecutable pueda cargar funciones de estas librerías, aprovechando el desarrollo ya realizado. Por ejemplo, hay funciones comunes que testean la disponibilidad de la red, la conexión a Internet o la presencia de una impresora.

DLL Hijacking - Parte 1

Pero, ¿qué pasaría si la aplicación no encuentra una DLL que intenta cargar? ¿Podría un atacante suplantar esa DLL creando una personalizada con código malicioso? Aunque existen métodos para evitar esto, la respuesta más correcta sería que si.

Read more

GDB orientado a Pentesting – Parte 3

Continuamos con esta serie de artículos sobre depuración de programas orientados al pentesting y la ingeniería inversa. En los artículos anteriores de esta serie GDB orientado a Pentesting vimos cómo podíamos depurar simples programas hechos en C que contenían sus símbolos de depuración, lo cual facilita mucho la depuración, así como programas que no incluyen estos símbolos, algo bastante más habitual cuando estamos realizando una tarea de pentesting o reverse engineering.

Si no has leído esos artículos, antes de leer este te aconsejo que le eches un vistazo. Los podrás encontrar en los siguientes enlaces:

GDB orientado a Pentesting – Parte 1

GDB orientado a Pentesting – Parte 2

En esta ocasión vamos a ver cómo podríamos “crackear” un simple programa desarrollado en C. El programa es muy simple; se le pasa como argumento un código, si es correcto mostraré un mensaje diciendo que el código secreto es correcto, en caso contrario indicaré que es erróneo.

Aquí podemos plantear dos opciones; hacer un simple “bypass” del programa, para que introduciendo cualquier cosa obtengamos el mensaje correcto, o intentar localizar el registro donde se almacena temporalmente el código correcto con el que compará lo que nosotros hayamos introducido como argumento.

En esta tercera parte de la serie haremos un bypass, de forma que da igual el valor que introduzcamos, siempre pasaremos con éxito la autenticación. El programa lo he llamado codigoSecreto y su sintaxis es la siguiente:

./codigoSecreto 123456

GDB orientado a Pentesting

Podemos observar que con los distintos código, al ser incorrectos, obtenemos el mensaje correspondiente de error.

Veamos esto mismo pero ya con nuestro GDB depurando el programa.

GDB orientado a Pentesting

Read more

Usando OTP en WordPress y Gmail

Hoy retomo la publicación en el blog con un tema sobre contraseñas. Como sabéis, usamos contraseñas para todo, y es que los servicios Web como correo, redes sociales o banca online, así nos lo exigen. Por ello, el uso de contraseñas está muy masificado. Usamos contraseñas para todo. Menos seguras de lo que creemos pero se utiliza ese método que impide que cualquiera pueda entrar libremente a tus servicios de redes sociales, de banca, portales Web, equipos, etcétera…

No obstante, hay una falsa creencia de que usar contraseñas sean como sean, es estar seguros.

Evidentemente este pensamiento es erróneo y ocasiona muchos problemas de confidencialidad, suplantación de identidad, etcétera… Puestos en la piel del “pasota”, como me encuentro muy a menudo podríamos pensar “Es que nadie tiene que entrar en mi cuenta…” toma ya. Esto no es una ocurrencia mía para complementar el artículo sino que son palabras textuales que me han dicho en persona. Claro, y nadie tiene que robar coches, ni casas, ni negocios ni nada y sin embargo pasa. Pongamos la cosa difícil y al menos, cuando vean las dificultades, la tomen con otro ¿no?. Probemos pues  “Usando OTP en WordPress y Gmail”

2factor copia  Read more

iOS Hacking: Comprobando ASLR con otool

Continuando esta serie de artículos sobre iOS Hacking, veremos en este post qué protecciones en tiempo de ejecución podemos implementar a nuestra aplicación iOS para que sea más segura. Algunas de estas medidas son usadas también en otros tipos de aplicaciones de diferentes arquitecturas, como el que vamos a tratar en este artículo, ASLR.

Antes de empezar destacaremos la herramienta otool que nos permite extraer información importante de un binario en iOS. Los binarios en iOS usan el formato Mach-O, que a su vez se divide en cabeceras, comandos de carga y datos (segmentos y secciones). Con la herramienta otool podremos visualizar detalles de la compilación, para qué arquitectura se ha compilado, cabeceras, comandos y lo que nos ocupa en esta ocasión, parámetros de algunas de las medidas de protección en tiempo de ejecución que podemos utilizar.

iOS Hacking - Mach-O

ASLR (Address Space Layout Randomization): al igual que en otras arquitecturas, esta técnica dificulta la explotación de alguna vulnerabilidad asignando localizaciones aleatorias de los objetos en memoria. Para usar la protección completa ASLR, y no de forma limitada como lo hacen las aplicaciones iOS por defecto, hay que compilar desde Xcode con el flag PIE activado.

Con otool podremos verificar si una aplicación está protegida completamente con ASLR ejecutando el comando con la siguiente sintaxis:

otool -Vh binario_de_la_app

iOS Hacking - otoolPodemos ver en la imagen anterior cómo la aplicación que hemos tomado como ejemplo, Messenger de Facebook, ha sido compilada con el flag PIE, por lo tanto está protegida totalmente con ASLR, y aunque se conocen técnicas para hacer “bypass” a estas protecciones, nunca viene de más poner obstáculos a posibles atacantes.

En siguientes artículos veremos qué otras protecciones podemos implementar y qué técnicas y herramientas utilizar durante el pentesting de una App iOS para verificar si la aplicación implemente o no estas protecciones.

¡Hasta la próxima!