OAuzz, el fuzzer de OAuth

OAuzz, el fuzzer de OAuth

Hace unas semanas explicábamos en qué consiste OAuth y por qué es tan necesario a día de hoy. Desde su nacimiento, el número de servicios web que se ofrecen basando la autenticación en OAuth ha aumentado considerablemente. Por este motivo, hablar de seguridad en este tipo de aplicaciones no podía retrasarse mucho más.

El problema que presenta OAuth, es que al ir todas las peticiones firmadas, ninguna herramienta automática actual que pueda servir tanto para detectar como para explotar vulnerabilidades (AppScan, Sqlmap, ProxyStrike, etc.) puede utilizarse contra estas aplicaciones.

Por este motivo, hemos desarrollado OAuzz.


OAuzz no pretende ser un analizador de vulnerabilidades. Tan sólo es un fuzzer que, a partir de un diccionario de payloads e indicando un punto de inyección, realizará peticiones a la aplicación basada en OAuth utilizando diferentes codificaciones y firmando automáticamente cada petición.

OAuzz implementa completamenteOAuth versión 1.0 además del borrador OAuth Request Body Hash 1.0, que consiste en un parámetro añadido por Google al protocolo para ofrecer integridad a toda aquella petición cuyo cuerpo del mensaje no sea de tipo "application/x-www-form-urlencoded".

La herramienta es altamente configurable y presenta los resultados en diferentes formatos para que sean fácilmente analizados.

Ha sido probada contra diferentes servicios web con excelentes resultados, pero ahora es el momento de que sea la comunidad de expertos la que pruebe y juzgue la herramienta.

OAuzz puede ser descargado desde el siguiente enlace, que poco a poco se irá completando con manuales y anotaciones sobre su uso:
http://code.google.com/p/oauzz/

Fuente:http://blog.s21sec.com/2012/06/oauzz-el-fuzzer-de-oauth.html

Solución al reto 15 de las ovejas negras - Hack-players

Buenas tardes.

Esta entrada es la solución al reto 15 de estenografía de la comunidad hack-players.

__________________________________________________________________________________

Si obviamos el enunciado, lo primero que llama la atención de nuestro reto esteganográfico nº 15 es que el rebaño de ovejas es realmente un mosaico formado por 6 imágenes:

 style="font-size: small;"> />
 class="prettyprint" style="overflow: auto;"> style="font-size: small;">
 class="reto15">
 class="nobr">
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja1.png" width="200" />
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja2.png" width="200" />
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja3.png" width="200" />
 class="nobr">
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja4.png" width="200" />
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja5.png" width="200" />
 border="0" height="188" src="https://sites.google.com/site/h4ckpl4y3s/oveja6.png" width="200" />

Por lo que procedemos a descargar las imágenes para analizarlas. Para ello y tal como indicamos en el tip del reto, añadimos a cada URL '?attredirects=0' para obtener cada original. Por ej. https://sites.google.com/site/h4ckpl4y3s/oveja1.png?attredirects=0.

El siguiente paso es observar atentamente las imágenes. Si aumentamos el zoom vemos que en la parte superior de la primera imagen se han modificado algunos píxeles. 

Si observamos el resto veremos que en cada una de ellas también existen píxeles modificados: ¡el mensaje secreto se encuentra repartido en todas las imágenes del mosaico!

Ahora bien, ¿qué método o herramienta han sido utilizados?
Sabiendo que se trata de múltiples portadoras en imágenes, si realizamos una búsqueda rápida (https://www.google.es/search?q=stego+multiple+png+images) pronto daremos con ello: el artículo Steganography II - multiple key and carrier files en CodeProject nos enseña un método sencillo para ocultar datos a lo largo de varias imagenes.

El procedimiento resumido es el siguiente:
- la CLAVE se obtiene mediante una operación XOR entre los bytes de un fichero clave y la repetición de una contraseña a nuestra elección
- se añaden las IMÁGENES del mosaico a un array (CarrierImages)
- se escribe la longitud del MENSAJE SECRETO en el primer pixel de la primera imagen
- se realiza un XOR entre un byte de la CLAVE y un byte del MENSAJE SECRETO y se calculan las coordenadas del pixel donde se almacenará el byte del mensaje
- se reemplaza uno de los componentes R, G o B del pixel con el byte del MENSAJE SECRETO
- se repite el procedimiento con los siguientes bytes del MENSAJE SECRETO y a través de las IMAGENES en el array

Tenéis mayor detalle y el código en los artículos de CodeProject. Para extraer el MENSAJE SECRETO tendremos que leer cada byte del stream de la CLAVE, calcular la posición del siguiente pixel, obtener el color e ir escribiendo el valor de R, G o B en el stream del MENSAJE SECRETO. Pero, ¿donde puedo conseguir la CLAVE (fichero clave y contraseña) para extraerlo?

                                              

Si habéis analizado las imágenes con otras herramientas, seguro que os habréis dado cuenta que la de la oveja negra es particularmente especial. 

Tiene un chunk diferente que podremos analizar por ejemplo con Tweakpng o, más fácil aún, si observamos los metadatos obtendremos lo que buscamos rápidamente:

C:\Users\vmotos\Desktop\Reto15>"exiftool(-k).exe" -l oveja5 
... 

Document Name       

hax0r5

Software       
https://sites.google.com/site/h4ckpl4y3s/key15.txt 
 ...  

Donde la URL en 'Software' contiene la ruta hacia la clave y el 'Document Name' indica la contraseña (hax0r5) (ojo también a las coodernadas GPS ;) ).  

Ya tenemos todo, la clave, la contraseña y las imágenes para obtener el mensaje secreto, así que podemos compilar el código o usar el binario que nos regala el autor de la herramienta:
 

 
Y finalmente se obtiene la respuesta: "vivire contra". 

Eso es todo, espero que os haya gustado el reto. Muchas gracias a todos los que hayáis intentado resolverlo y enhorabuena al ganador Daniel Correa, ya un asiduo de nuestra sección que nos recomienda también echar un vistazo a OpenPuff que soporta múltiples portadores, formatos y configuraciones.

¡Hasta la próxima!

Fuente:http://www.hackplayers.com/2012/07/solucion-al-reto-15-de-las-ovejas.html

3 Herramientas para testear un nuevo sitio web

Ya tenemos la nueva web en marcha, las extensiones de caché bajo control, el servidor configurado, la aplicación perfecta… ahora solo falta comprobar si funcionará en el día a día, y para eso existen varias herramientas que pueden ayudarnos en los tests.
En la categoría de Utilidades para Blogs y Sitios web hemos comentado muchas, pero quiero destacar 3 que llevamos usando bastante en las últimas semanas.

loadimpact.com

Comenzamos con un poco de estrés, simulando el acceso simultáneo de varios usuarios para ver si el servidor soporta el ritmo, tanto de carga como de ancho de banda.
La versión gratuita es suficiente para comprobar su funcionamiento, existiendo una url pública con los resultados del test realizado.

browsermob.com

Para probar el acceso desde distintas ciudades, mostrando el tiempo que tarda en caragar cada componente de nuestra web.

websiteoptimization.com

Ofrece análisis y recomendaciones para mejorar la carga de la web, basándose en la cantidad de scripts, imágenes, frames, etc.
Esta ultima herramienta puede ser sustituida por otras ya comentadas, como PageSpeed.

 Mas herramientas para testear las pueden encontrar en las rutas:

https://translate.googleusercontent.com/translate_c?hl=es&prev=/search%3Fq%3DRIPS%2Bphp%26hl%3Des%26safe%3Doff%26biw%3D1280%26bih%3D696%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&twu=1&u=http://sourceforge.net/directory/development/development-testing/os:windows/freshness:recently-updated/&usg=ALkJrhgm7xuZinmTeCP_LZDEQF3TvQzmPw

https://translate.googleusercontent.com/translate_c?hl=es&prev=/search%3Fq%3DRIPS%2Bphp%26hl%3Des%26safe%3Doff%26biw%3D1280%26bih%3D696%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&twu=1&u=http://sourceforge.net/directory/development/quality-assurance/os:windows/freshness:recently-updated/&usg=ALkJrhh8JbZxBIQOTYIACrk9xPAOmHPUrg


Fuente:

http://wwwhatsnew.com/2011/08/24/3-herramientas-para-testear-un-nuevo-sitio-web/

Los cinco y el misterio de la doble tilde

Les comparto esta entrada que me parecio excelente.

________________________________________________________________________________

A mediados de 2011 el código fuente del troyano bancario ZeuS fue filtrado en Internet. Esto supuso que empezaran a aparecer forks del mismo, entre ellos Citadel y Ice IX.

ZeuS es conocido, dentro de ámbitos profanos de la seguridad informática de habla castellana, como el virus del doble acento o de la doble tilde. La causa reside en el efecto que provoca en aquellos equipos que utilizan la distribución hispana del teclado:

Cuando se intenta escribir una letra con tilde, en vez de incluirla en la letra de manera correcta hace algo como a´´ e imposibilita el escribir correctamente.

Sabiendo que Citadel y ICE IX son evoluciones de ZeuS, quisimos comprobar si seguía ocurriendo.

Windows utiliza mensajes para las comunicaciones entre aplicaciones, como por ejemplo:

WM_SYSCOMMAND	Relacionado con ventanas (se maximiza, se minimiza, se elige algo en el menú, etc.)
WM_DESTROY	Cuando una ventana está a punto de cerrarse.
WM_KEYDOWN	Cuando una tecla se pulsa
WM_KEYUP	Cuando una tecla se suelta.
WM_MOUSEMOVE	Cuando se haya movido el ratón.

Relacionado con el teclado hay un mensaje especial llamado WM_DEADCHAR, generado cuando pulsamos la tecla tilde.

MSDN (Remarks): “A dead key is a key that generates a character, such as the umlaut (double-dot), that is combined with another character to form a composite character. For example, the umlaut-O character (Ö) is generated by typing the dead key for the umlaut character, and then typing the O key.” http://msdn.microsoft.com/en-us/library/windows/desktop/ms646277(v=vs.85).aspx

Una traducción aproximada sería: “Un deadkey es una tecla que genera un carácter que combinado con otro carácter, genera un carácter compuesto.”

Viendo los hooks que utiliza Citadel, sospechamos del hook de TranslateMessage, ya que su función es convertir los mensajes de tecla-virtual en mensajes de caracteres.

Repasamos directamente el código fuente filtrado de ZeuS y vemos la función encargada de establecer el hook en la API TranslateMessage.

Por lo visto, los parámetros de TranslateMessage no son modificados. Sin embargo, hace uso de ToUnicode. Vamos a ver que dice Microsoft.

MSDN (Remarks): “The parameters supplied to the ToUnicode function might not be sufficient to translate the virtual-key code because a previous dead key is stored in the keyboard layout.” http://msdn.microsoft.com/en-us/library/windows/desktop/ms646320(v=vs.85).aspx

Su traducción sería: “Los parámetros enviados a la función ToUnicode, pueden no ser suficientes para traducir el código virtual de la tecla porque la deadkey anterior es almacenada en la capa del teclado.”

Googleando un poco nos encontramos con varios foros donde la gente anuncia problemas relacionados con hooks y el uso de ToUnicode.

http://stackoverflow.com/questions/2604541/how-can-i-use-tounicode-without-breaking-dead-key-support

http://stackoverflow.com/questions/1964614/toascii-tounicode-in-a-keyboard-hook-destroys-dead-keys

http://blogs.msdn.com/b/michkap/archive/2005/01/19/355870.aspx

Así que el problema viene de la función ToUnicode, que al tener una tilde en cola provoca el mal funcionamiento. Tanto Citadel como Ice IX hacen uso de la función, con lo que tampoco están exentos del problema, por lo que si un equipo empieza a mostrar el síntoma de la doble tilde, es muy probable que sea provocado por una infección de Citadel, Ice IX o algunos de los “bichos” de la familia de ZeuS.

Como muchos os habréis dado cuenta, el título de la entrada homenajea a la famosa saga de libros de "los cinco" escrita por Enid Blyton y que nos hizo disfrutar mucho a algunos de nosotros de niños.

Jozsef Gegeny y Mario González

S21sec ACSS

Fuente:http://blog.s21sec.com/2012/07/los-cinco-y-el-misterio-de-la-doble.html

RIPS: un analizador de código estático de PHP

RIPS es un escaner de seguridad para encontrar vulnerabilidades en aplicaciones PHP a través del análisis estático de código. "Tokenizando" y analizando todos los archivos de código fuente, RIPS es capaz de transformar el código PHP origen en un modelo de programa y detectar los sinks sensibles (funciones potencialmente vulnerables) que pueden ser contaminadas por la entrada del usuario durante el flujo de la aplicación (influenciado por un usuario malicioso).

Además de la salida estructurada de las vulnerabilidades encontradas, RIPS también ofrece un marco de código de auditoría integrada para el análisis manual posterior.

Interfaz de auditoría de código:

- Escaneo de vulnerabilidades y estadísticas (XSS, SQLi, descubrimiento de ficheros, LFI/RFI, RCE y más)
- Agrupación de líneas de código vulnerables (de abajo a arriba o de arriba hacia abajo)
- Descripción de vulnerabilidades con ejemplos de código, PoC, creador de parches de exploits
- Lista de archivos y gráficos (conectados por includes)
- Lista de funciones y gráficos (conectados por calls)
- Lista de entradas de usuario (parámetros de la aplicación)
- Visor de código fuente con resaltado de sintaxis
- Saltos activos entre llamadas a funciones
- Búsqueda en el código mediante expresiones regulares
- 8 diseños de resaltado de sintaxis

Esta herramienta se une a varios proyectos que he usado en el transcurso de las auditorias a código php4 , no estoy seguro pero puedo afirmar que estos frameworks no funcionan sobre la versión orientada a objetos lo cual podría ser la principal desventaja.

Los otros frameworks para auditoría de código son:

PHP Security Scanner

Yasca

PHP Security Audit Tool

Fuente del post: http://www.hackplayers.com/2012/07/rips-un-analizador-de-codigo-estatico.html
Fuente del frame:http://sourceforge.net/projects/rips-scanner/