21 septiembre 2014

Enlaces de la SECmana - 242



Leer más...

20 septiembre 2014

Publicada la OWASP Testing Guide v4

Han pasado ya 6 años desde la última versión estable de la Guía de pruebas OWASP, la v3. Esta semana, se ha anunciado por fin la OWASP Testing Guide versión 4 (por el momento únicamente en inglés). Así lo ha anunciado Mateo Mucci, uno de los líderes del proyecto en un post del blog MindedSecurity.


Como os hemos hablado en multitud de ocasiones en Security By Default, la guía de pruebas OWASP contempla un conjunto de puntos de control que engloban las buenas prácticas de seguridad en aplicaciones web, convirtiéndola en una metodología muy completa y utilizada por los profesionales de la seguridad.

Como principales novedades, además de la reorganización de categorías y subcategorías de algunas pruebas, se ha puesto especial hincapié en los siguientes puntos:

Además, se ha modificado y mejorado el contenido de los puntos de control habituales, haciendo un total de 87 puntos de control (frente a los 64 de la versión anterior). Se ha incluido información con referencias a otros proyectos importantes de OWASP, como son las guías de programación segura y para desarrolladores.

Para esta versión 4 de la guía, encontraremos las siguientes categorías (en inglés):
  1. Information Gathering (OTG-INFO)
  2. Configuration and Deployment Management Testing (OTG-CONFIG)
  3. Identity Management Testing (OTG-IDENT)
  4. Authentication Testing (OTG-AUTHN)
  5. Authorization Testing (OTG-AUTHZ)
  6. Session Management Testing (OTG-SESS)
  7. Input Validation Testing (OTG-INPVAL)
  8. Testing for Error Handling (OTG-ERR)
  9. Testing for weak Cryptography (OTG-CRYPST)
  10. Business Logic Testing (OTG-BUSLOGIC)
  11. Client Side Testing (OTG-CLIENT)
Cabe destacar la gran revisión que se la ha dado a la categoría "Business Logic" (Lógica de negocio), que ha pasado de tener una única subcategoría general en la versión 3 a 9 subcategorías en la versión 4.

Como es habitual, la guía esta disponible tanto en PDF para su descarga, como en versión navegable dentro de la wiki del proyecto.

Nos queda esperar a la versión en castellano.
Leer más...

18 septiembre 2014

Tinfoleak, stalkeando twitter en línea de comandos




Gracias a un RT de Yago, me picó la curiosidad de echar un vistazo a una herramienta: Tinfoleak. Se trata de un sencillo script en python, hecho por Vicente Aguilera, que permite, a través de línea de comandos “preguntar a twitter” por diversa información de un nick en concreto.
Entre otras opciones, podemos saber:

  • Información básica del usuario, según aparezca en twitter (Nombre, ubicación, followers, foto, etc,…)
  • Dispositivos, sistemas operativos y algunas redes sociales utilizadas por el usuario
  • Hashtags a los que ha hecho referencia el usuario
  • Quién lo ha mencionado
  • Búsqueda de palabras clave dentro de los tweets en concreto
  • Filtrado por fechas y hora inicio/fin, etc....
  • Geolocalización de los tweets, generando un mapa de las localizaciones visitadas 

Todas estas opciones pueden ser utilizadas en combinación con otros flags que permiten filtrar por fechas, indicar la muestra de los últimos N tweets a buscar (por defecto N = 100), lo que hacen que sea muy potente y que no requiera la utilización de un entorno gráfico para la mayoría de las opciones.

Para su utilización, la descargamos desde Google Code, enlazado desde la página de herramientas del autor, y la descomprimimos.

Tiene como dependencia el módulo “tweepy”, que si no lo tienes ya instalado en el sistema, se resuelve rápidamente con un “sudo pip install tweepy”

Una vez está esto resuelto tendremos que registrarla como aplicación válida en Twitter y obtener una Consumer Key y Consumer secret, así como un Token Key y Token Secret, que deberemos rellenar dentro del script .py.

Para ello, loggeados desde una cuenta twitter, nos vamos a https://apps.twitter.com/app/new, y le damos un nombre  (Ojo, que el nombre de la app no tiene que existir aún,… obviamente tinfoleak existe, por lo que podéis poner el ID que queráis), descripción y website (para que no de error, en formato URL con http://www.loquesea.com). 

Una vez esté creado nos aparecerá una pestaña llamada API Keys, en la que podremos obtener ya  los valores API Key y API Secret (que son el Consumer Key y Consumer Secret, respectivamente, a rellenar en el script).



Ahora hay que generar un Token Key y Token secret. En esta misma pantalla, abajo del todo hay un boton que dice "Generate Access Token”, le damos, y tras unos segundos nos generará un par de valores Access Token y Access Token Secret.



Con esto, rellenamos las variables  CONSUMER_KEY = ‘ ‘, CONSUMER_SECRET = ‘’, ACCESS_TOKEN = ‘ ‘ y ACCESS_TOKEN_SECRET = ‘ ‘ del script y está ya listo para funcionar.

Os dejo un ejemplo que muestran la potencia de la herramienta.

Információn básica, sources (dispositivos y clientes), y hashtags usados por el usuario @lawwait en sus 100 últimos tweets: 

python tinfoleak.py -n lawwait -bsh



En la web del autor de la herramienta podéis encontrar más ejemplos con integración hasta con Google Earth, geolocalizando a los usuarios.

Leer más...

17 septiembre 2014

Nmap: Ejemplos de uso

Hace algún tiempo, mi compañero Alejandro publicó un exitoso cheat sheet sobre Nmap, hoy me gustaría compartir unos cuantos comandos útiles a la hora de realizar un pentesting.

Mucha gente asocia Nmap = Scanner de puertos, pero la verdad es qué, Nmap, permite hacer un montón de cosas mucho más avanzadas que únicamente barrer puertos

Scanning básico

# nmap -sP 192.168.1.* (Ping a toda una clase C)

# nmap -sT  192.168.1.179 (Connect)

# nmap -sS  192.168.1.179 (SYN)

# nmap -sF  192.168.1.179 (FIN)

# nmap -sU -p 0-100 192.168.1.179 (UDP)


Scanning avanzado

# nmap -sO 192.168.1.179 (Procotolos)

# nmap -sV 192.168.1.179 (Servicios)

# nmap -O 192.168.1.179 (Fingerprint)

# nmap -sS -T insane 192.168.1.179 (Agresivo)

# nmap -sS -oN resultado.txt 192.168.1.179 (Logging a fichero)

# nmap -n -D192.168.1.5,10.5.1.2 192.168.1.179 (Con hosts fake)

Tipos de scripts NSE

Auth --> (Procesos de autenticación)
Broadcast --> (Descubrir hosts en red local)
Brute --> (Ataques de fuerza bruta)
Default --> (Juego de tests ‘por defecto’)
Discovery --> (Descubrir nuevos hosts con pruebas avanzadas)
Dos --> (Ataques de tipo DoS)
Exploit --> (Sacar partido de vulnerabilidades)
External --> (Uso de servicios externos como ‘Whois’)
Fuzzer --> (‘Fuzzing’ de aplicaciones)
Intrusive --> (Puede causar daños al host remoto)
malware --> (Para detectar equipos infectados)
Safe --> (No hay riesgo para el host remoto)
Version --> (Detectar versiones de servicios)
Vuln --> (Búsqueda de vulnerabilidades explotables)

Ejemplos de Scripts NSE

# nmap --script-help "*"

# nmap -sC 192.168.1.179 (audit default)

# nmap --script "http-*" 192.168.1.179 (tests vulnerabilidades HTTP)

# nmap --script ftp-anon 192.168.1.179 (Test FTP anónimo)

# nmap --script banner 192.168.1.179 (Captura banners de servicios)

# nmap --script "not intrusive" 192.168.1.179 (Audit no agresiva)

# nmap --script "intrusive" 192.168.1.179 (Audit agresiva)

# nmap --script mysql-brute 192.168.1.179 (Fuerza bruta Mysql)

Leer más...

15 septiembre 2014

RootedSatellite: Valencia

Este fin de semana, 19 y 20 de Septiembre, se celebrará la RootedSatelllite: Valencia en la Fundación Universidad-Empresa de Valencia.


Esta edición spinoff de Rooted cuenta con dos jornadas: el 19 de Septiembre se realizarán los Rootedlabs:

El precio de cada uno es de 50€ para estudiantes y 80€ para profesionales, y tienen una duración de 8 horas. Puedes registrarte en cualquiera de ellos a través de la siguiente URL:


Las ponencias ya confirmadas para el Sábado 20 de Septiembre son las siguientes:
  • José Selvi - Adaptando exploits para evitar la frustración
  • Leonardo Nve - Explotando cambio de servidores DNS
  • David Pérez y José Picó (Layakk) - I wanna jam it wid you
  • Pablo San Emeterio - How to protect your hot pics with WHF
  • Lorenzo Martinez - Cooking an APT... in the paranoid way
  • Cesar Lorenzana - PICOLETOS EN RootedLand….. WTF!!!!
Para este evento, el debate (RootedPanel) tendrá como tema principal el "Estado de las TI en la Comunidad Valenciana"

A continuación se presenta la agenda confirmada:

Horario del Sábado 20 de Septiembre de RootedSatellite: Valencia
Como es habitual, para los que viajen en tren/ave desde fuera de Valencia hay disponible un descuento de Renfe de un 30% para el congreso.

El precio para el congreso del sábado es de 15€ para estudiantes y 25€ para profesionales, pudiendo realizar el registro todavía a través de la siguiente URL:


Podéis consultar más información en la página web de este evento: https://www.rootedcon.es/vlc/

¡No te lo pierdas!
Leer más...

14 septiembre 2014

Enlaces de la SECmana - 241



Leer más...

10 septiembre 2014

Solucionando crackmes precargando librerías

Una de las técnicas más utilizadas en sistemas UNIX para analizar o modificar el comportamiento de una aplicación es la de precargar una libreria para hacer que el linker priorize nuestros funciones en vez de las disponibles en librerias externas.

De hecho, en iOS, todo el sistema de MobileSubstrate y la app Flex, se basan en este concepto para extender o modificar las funcionalidades de las aplicaciones de forma bastante cómoda.

La técnica consiste en definir una variable de entorno (LD_PRELOAD o DYLD_INSERT_LIBRARIES en OSX/iOS). La cual es parseada por el linker dinámico del sistema (/lib/ld.so o dyld) y cargará nuestra libreria permitiendonos varias opciones:

  • inspeccionar los parametros y sus contenidos
  • cambiar el valor de retorno de una función
  • extender la funcionalidad
  • reemplazar la implementación
  • volcar los backtraces (desde donde se llama)
  • ...


Para ejemplificar toda esta teoría he escrito un pequeño crackme:

        I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KCgppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpIHsKCWNoYXIgKnBhc3MgPSAoY2hhciAqKWFyZ3ZbMF07CglpZiAoYXJnYzwyKSB7CgkJcHJpbnRmICgiR2ltbWUgYW4gYXJnXG4iKTsKCQlyZXR1cm4gMTsKCX0KCWlmICghc3RyY21wICgiYSIsICJiIikpIHsKCQlwcmludGYgKCJBcmUgeW91IHRyaWNraW5nIG1lP1xuIik7CgkJcmV0dXJuIDE7Cgl9CglpZiAoIXN0cmNtcCAoYXJndlsxXSwgcGFzcykpIHsKCQlwcmludGYgKCJZb3Ugd2luIVxuIik7CgkJcmV0dXJuIDA7Cgl9CglwcmludGYgKCJXcm9uZ1xuIik7CglyZXR1cm4gMTsKfQo=

El desensamblado del crackme en OSX se vé tal que así:




La inyección de librerías sólo es posible en ejecutables no estáticos y que no tengan el bit SUID activado. Esto podemos comprobarlo facilmente con ls y rabin2.

$ isSuid() { ls -l $1 |awk '{print $1}' | grep -q s && echo YES || echo NO; }
$ isStatic() { rabin2 -I $1 | grep ^static | grep -q true && echo YES || echo NO; }     
$ isSuid ./a.out
 NO
$ isStatic ./a.out
NO

Estamos de suerte! el crackme cumple las condiciones para seguir con el post ;)

En este punto debemos saber que símbolos y librerías importa. Para ello utilizaremos rabin2, un programa que forma parte del framework de Radare2 y que nos permite inspeccionar y extraer información de binarios, principalmente ejecutables, librerías, etc.

        $ rabin2 -qi a.out
        printf
        strcmp
        dyld_stub_binder
        $ rabin2 -ql a.out
        /usr/lib/libSystem.B.dylib

Os recomiendo usar siempre la versión de git de radare2, y pasaros por el IRC (freenode canal #radare) si tenéis cualquier duda o idea :)

        $ git clone https://github.com/radare/radare2
        $ cd radare2
        $ sys/install.sh

Bien, parece que este ejecutable está usando printf y strcmp. Es bastante probable, que strcmp se esté usando para comprobar la contraseña suministrada por el usuario. Así que vamos a crear una librería que nos muestre con que parámetros se está ejecutando.

        $ cat mylib.c
        int strcmp(char *a, char *b) { return 0; }
        $ gcc -fPIC -shared mylib.c -o mylib.dylib
        $ rarun2 program=./a.out preload=mylib.dylib arg1=something
        Are you tricking me?

Si cambiamos el valor de retorno el crackme lo detectará. Así que debemos crear algún tipo de filtro para que sólo devuelva correcto desde la llamada que comprueba la contraseña, y no la previa que sirve para verificar que no hemos hookeado 'strcmp'.

En este ejemplo, he optado por reescribir strcmp para no complicar más el ejemplo y evitar explicar el lazy binding y el rtld-next para redirigir la ejecución a la implementación nativa.

Para esto podemos comprobar el caller utilizando esta macro:


        

El número mágico 0x100000ee7 es la dirección de la siguiente instrucción que encontramos después del 'call strcmp' que queremos interceptar, que es la dirección que encontraremos en el backtrace de la pila.



Compilamos la librería y ejecutamos el crackme con rarun2 para que éste nos defina las variables de entorno y todo lo necesario para inyectar la librería al programa, independientemente de estar en OpenBSD, OSX o Linux.

        $ gcc -shared -fPIC mylib.c -o mylib.dylib
        $ rarun2 program=./a.out preload=mylib.dylib arg1=something
        You Win!

Cabe destacar que precargar una librería nos permite introducirnos en la tabla de resoluciones de llamadas a librerías externas. Así que no nos será posible hookear funciones del mismo binario... o sí?

En el caso de tener la posibilidad de modificar el binario podemos parchear las llamadas a la función que queremos interceptar. O sencillamente, si queremos modificar por completo esa función podemos parchear los primeros bytes de esta para redirigir la ejecución con un jmp a la plt.

De esta forma cada vez que el programa llame a esa función interna el flujo de ejecución se redirigirá hacia un símbolo importado de alguna librería externa.

Pongamos un ejemplo para ver la explicación un poco más clara:


        

Compilamos y desensamblamos el programa

        $ gcc test.c
        $ r2 -Aqc 'pD $SS @ $S' a.out



Como observamos, el simbolo sym._test está en la dirección 0x100000e90. Si queremos reimplementar esa función por una externa debemos parchear la primera instrucción para que realize un salto a algún import, que estos a su vez están asociados a un símbolo local del binario, el cual es utilizado por el linker para saltar a la función cargada de una librería con ese nombre.

      $ rabin2 -i a.out
        [Imports]
        ordinal=000 plt=0x100000f38 bind=NONE type=FUNC name=printf
        ordinal=001 plt=0x100000f3e bind=NONE type=FUNC name=strcmp
        ordinal=002 plt=0x00000000 bind=NONE type=FUNC name=dyld_stub_binder
        3 imports
        $ rabin2 -s a.out | grep imp.
        vaddr=0x100000f38 paddr=0x00000f38 ord=003 fwd=NONE sz=0 bind=LOCAL type=FUNC name=imp.printf
        vaddr=0x100000f3e paddr=0x00000f3e ord=004 fwd=NONE sz=0 bind=LOCAL type=FUNC name=imp.strcmp

Una vez obtenida la dirección de los imports podemos proceder a parchear el ejecutable:

        $ r2 -qc 'wa jmp 0x100000f38 @ 0x100000e90' -w a.out

Si desensamblamos ahora la función sym._test veremos como realiza un salto a sym.imp.printf:



Así pues, si ejecutamos el programa ahora veremos como nos muestra que la contraseña que esperaba era el argv[0], es decir, el nombre del ejecutable.

        $ ./a.out
        ./a.out

Volvemos a ejecutar el crackme original:

        $ ./a.out.orig ./a.out.orig
        LE WIN!

Para este simple ejemplo no nos sería necesario inspeccionar mucho más allá de insertar un salto, ya que en este caso solo nos interesaba conocer el primer argumento de strcmp. Pero para otro tipos de análisis de binarios puede sernos de gran utilidad el poder redirigir la ejecución de ciertas funciones internas para reimplementarlas desde fuera.

Este tipo de técnica és utilizada en multitud de casos reales de ingenieria inversa, para analizar comunicaciones de malware, entender como se funciona un flasher, etc.

Si estás interesado en conocer más detalles sobre esta y otras técnicas, os recomiendo que echéis un vistazo al curso de ingeniería inversa y exploiting que vamos a impartir próximamente con Yago, NighterMan, Ricardo, Newlog y un servidor: pancake.


Nos leemos!

Artículo por cortesía de Sergi Álvarez
--pancake
Leer más...