May 07

TOP 10 Fallos de Seguridad en Aplicaciones Web

El proyecto OWASP (Open Web Application Security Project) ha publicado la actualización al año 2010 de su famoso TOP 10 con los mayores riesgos asociados a las aplicaciones web.

4Oc8p TOP 10 Fallos de Seguridad en Aplicaciones Web

En esta nueva edición del TOP 10 se nota como intencionalmente han querido eliminar de la listas algunas vulnerabilidades específicas, para enfocarse más en los riesgos de seguridad que representan estas vulnerabilidades. Este nuevo enfoque sobre riesgos de seguridad en las aplicaciones web tienen por objeto impulsar a las organizaciones, a madurar más la comprensión y gestión de aplicaciones de seguridad a través de su organización.

La OWASP indica que el Top 10 para el 2010 es:

  1. Inyección
  2. Cross-Site Scripting (XSS)
  3. Interrupción de la autenticación y administración de sesiones
  4. Referencias de Objetos Directos Inseguros
  5. Falsificación de Solicitud Cross-Site (CSRF)
  6. La configuración errónea de Seguridad
  7. Cifrado de Almacenamiento Inseguro
  8. Falla al restringir el acceso URL
  9. Insuficiente protección de la capa de transporte
  10. Redirecciones sin validar y hacia adelante.

Más Información:
Anuncio en la Página Oficial de OWASP

FUENTE:

www.dragonjar.org

May 06

Vulnerabilidad en Java Web Start

Hace algunas semanas, en el twitter de Ruben Santamarta, un conocido investigador Español, podíamos ver el siguiente comentario:
Con la liebre correteando por ahí y todos nosotros desinstalando Java de nuestros navegadores, Rubén publico en su web algunos detalles más sobre la vulnerabilidad, que parece haber sido descubierta casi simultáneamente por él y por Tavis Ormandy, otro conocido investigador.
Según parece, la vulnerabilidad reside en una mala validación de ciertos parámetros que se pasan por linea de comandos al binario java.exe/javaws.exe en el momento que un navegador quiere ejecutar contenido Java.
Voy a tomarme la pequeña libertad de comentar el código publicado por Rubén, en su página web. También añadiré alguna captura mía de algún trozo de código que me parece interesante y que no aparece en la publicación de Rubén.
Aunque parezca raro, creo que en esta ocasión lo mejor para entender la vulnerabilidad es comenzar desde el final, es decir, desde el momento que se llama a javaws.exe. Si nos fijamos en el final del código seleccionado por Rubén, vemos que se apilan un montón de parámetros (push) antes de llamar a la función CreateProcessA. Esta función va a ser la encargada de crear un nuevo proceso con los parámetros que nosotros le hayamos pasado a través de la pila, es decir, todos esos parámetros que justo antes de la llamada estaban siendo apilados. Podemos obtener más información sobre estos parámetros acudiendo a la documentación oficial de Microsoft.
De entre todos estos parámetros, el afectado por la vulnerabilidad es lpCommandLine, mediante el cual le especificamos a la función con que parámetros en linea de comandos deberá llamar al binario (javaws.exe). En este caso, vemos que se está realizando un “push esi”, es decir, en el lugar de la pila de donde CreateProcessA va a sacar el valor de lpCommandLine estamos metiendo el valor contenido en el registro ESI.
Perfecto.
Y…
¿Qué narices hay en ESI? 😛
Evidentemente, el registro ESI podría haber sido cambiado en cualquier sitio y posteriormente haber hecho un salto a la zona de código que vemos, pero si no me equivoco si esto fuera así el IDA Pro nos habría etiquetado la linea con un “loc_direccion”, y no es el caso. Dicho esto, vemos que solo existen dos posibilidades:
  1. La ejecución viene de la dirección 6DAA3EB7 y al llegar a 6DAA3EC6 hace un salto a 6DAA3ED4 (jmp short loc_6DAA3ED4).
  2. La ejecución ha saltado de una zona anterior al código que no vemos a 6DAA3EC8 y desde ahí ha seguido su ejecución normal hasta llegar a 6DAA3ED4 sin ningún tipo de saltos, ya que su código es consecutivo.
Vamos a seguir trazando hacia atrás a ver si vemos donde se ha definido el contenido del registro ESI. En este caso, para ambas opciones vemos que ESI contiene la dirección de memoria de un Buffer donde se va a guardar la cadena de texto resultado de la llamada a la función wsprintfA. Esta función es prácticamente idéntica (solo cambia el soporte para Unicode, que yo sepa) a la típica función de C “sprintf”, en la que definimos un buffer de destino (al que apunta ESI), una cadena de formato del tipo “%s loquesea %d blablabla %s” y las referencias a los datos que irán en los “huecos” que hayamos dejado en la cadena de formato (en mi ejemplo, 3, cadena de texto, entero, cadena de texto). Como antes, podemos obtener más información sobre esta función acudiendo a la documentación oficial de Microsoft.
En el caso que nos ocupa, podemos ver que estamos utilizando 3 cadenas para formar una cadena de la siguiente forma:
Aplicacion [-docbase OpcionesDocBase] Opciones
Siendo esto así, vemos que tanto “OpcionesDocBase” ([ebp+arg_4]) como “Opciones” ([ebp+arg_0]) están saliendo DIRECTAMENTE de los argumentos con los que se ha llamado a la función, por lo que no parece existir ningún tipo de filtrado que impida que introduzcamos espacios en blanco, guiones u otros caracteres que nos permitan modificar los argumentos con los que se creará el nuevo proceso.
Las preguntas evidentes que nos surgen ahora son:
  1. ¿Podemos controlar esos parámetros de forma remota de alguna manera? Porque sino… para poco nos va a servir todo lo que acabamos de ver.
  2. Suponiendo que controlamos los parámetros que se le pasan a estos binarios, ¿para que sirve eso? ¿es peligroso para la seguridad?
Las respuestas son SI, podemos controlar esos parámetros y es peligroso para la seguridad.
Mañana: “Explotando Java Web Start”
Fuente: http://www.pentester.es
May 06

¿Cómo entrar en el Facebook de otra persona?

Hoy al entrar en Facebook me encontré con la sorpresa que el Chat no funcionaba, al pasar el mouse por encima decía que estaba en mantenimiento, después de un par de horas vi que seguía sin funcionar y me di a la tarea de investigar que pasaba.

Aquella pregunta que siempre hacen las personas, sobre si es posible “hackear una cuenta de Facebook” fue respondida esta mañana, la pregunta la realizan algunos por curiosidad o por querer saber cosas como por ejemplo si su pareja le está siendo infiel, por lo cual es muy frecuente que hagan búsquedas en Google del tipo ¿cómo saber la contraseña de Facebook?, pero lo más sorprendente durante mi búsqueda para saber qué era lo que pasaba, fue enterarme que un fallo en Facebook permitía con unos sencillos pasos y tan solo unos clics (nada de programación, ni compilar códigos ni nada) podíamos estar frente a la cuenta de cualquiera de nuestros contactos.

El fallo o bug en Facebook se encontraba en la configuración de privacidad, donde podíamos ver la manera en que otros usuarios ven nuestro perfil, lo que sucedía era que realmente cargaba el perfil de ese usuario y nos permitía ver sus conversaciones, historiales, solicitudes y algunos detalles de la cuenta que dejaban ver información sensible.

Cabe destacar que hoy mismo fue solucionado este fallo y que ya está de nuevo el chat en funcionamiento, sin embargo me quedan dudas acerca de la seguridad de esta famosa red social, ya que era un fallo bastante grave y realmente es un descuido serio en la programación de la misma.

El vídeo acerca del fallo lo publicaron en YouTube y en el podemos ver lo sencillo y lo grave del bug.

Fuente: www.dragonjar.org