Quantcast
Channel: ElevenPaths Blog
Viewing all 1287 articles
Browse latest View live

FOCA Final Version, la FOCA definitiva

$
0
0
A todos os suena la FOCA. Durante estos años, ha tenido una gran aceptación y se ha convertido en una herramienta muy popular. Pero Eleven Paths ha matado a la FOCA y la ha convertido en un servicio muy especial, FaasT. Sin embargo, la FOCA no ha muerto. FOCA Pro es ahora una versión portable llamada  FOCA Final Version se puede descargar gratuitamente.

FOCA Free vs. FOCA Pro
Solía existir la FOCA Free y la FOCA Pro. La versión Pro incluía algunas funcionalidades extra como reportes, análisis de mensajes de error en las repuestas, fuzzing de URLs buscando errores de conversión de tipos en PHP, errores de sintaxis en consultas SQL/LDAP, errores de desbordamiento de enteros y más paralelismo en su core. Tampoco contenía anuncios.

Pero ahora, FOCA se une en una única versión, basada en la FOCA Pro, pero gratuita. Así que aquí está  FOCA Final Version. Esta versión final incluye todos los plugins disponibles y la posiblidad de crear otros propios. También se han corregido ciertos errores que habían reportado los usuarios.

Si quieres saber cómo funciona, podéis comprar este libro sobre pentesting con FOCA.


FOCA Final Version
FOCA se puede descargar gratuitamente sin necesidad de registro desde la página de Eleven Paths Labs.

Esperamos que la disfrutéis.

Sobre cookies y sistemas de seguimiento (y II)

$
0
0
El tracking o seguimiento a través de web, consiste en intentar identificar al usuario que está navegando y recopilar la mayor información posible sobre él creando un perfil. Con este perfil, se podrá tratar al usuario como receptor de una publicidad más personalizada y por tanto, efectiva. Veamos las propuestas de diferentes fabricantes para "solucionar" este problema, y realizar un tracking más efectivo de los usuarios.

Google

Desde hace algunos años, Google posee doubleclick.com, una de las mayores empresas de publicidad de internet. La compró en 2008 por 3.000 millones de dólares. Está presente en una inmensa mayoría de webs que se visitan. Esta ubicuidad, a efectos prácticos, permite a Google rastrear y evaluar qué anuncios debe mostrar basándose en el perfil de navegación recopilado. 

Fuente: Wall Street Journal
Cada perfil se relaciona con un ID almacenado en la cookie de doubleclick.com. Pero este "viejo método" es fácilmente eludible por el usuario, que puede deshabilitar las cookies de terceros, por ejemplo. Una evolución por parte de Google es su empeño en que realicemos las búsquedas cuando ya estamos presentados (hemos hecho el log in) en su domino, con lo que puede también recabar información sobre el usuario que realiza las consultas.

Pero Google planea cambiar el método de tracking con third party cookies a un ID único que lleve el navegador o el dispositivo. Esto permite una mayor persistencia además de poder unificar la información de varios dispositivos. Así podría seguir recopilando información para el perfil tanto desde el ordenador como desde otros dispositivos móviles.

Esta idea ya se está llevando a cabo en los nuevos dispositivos que usan Android 4.4 (Kitkat). En ellos ya se puede ver el Advertisement id. De momento solo aplicable para las apps y Google Play:

Advertising ID en los nuevos Androids
Como se muestra en la imagen, el usuario puede deshabilitar y restablecer el identificador. La idea es implantar este AdID en los navegadores y dispositivos de Google, con lo que se generaría un "gran perfil" incluso entre varios dispositivos. Con AdID, Google promete traer mayor privacidad y control, permitiendo a través de las opciones del navegador o dispositivo controlar qué entidades acceden a los datos. Además no todas las entidades podrían acceder a la información recopilada, solo las que cumplan con ciertas "normas".

Pero aunque AdID se considere un identificador anónimo para mostrar publicidad acorde a los gustos del usuario, no deja de tratarse de un sistema de seguimiento que podría llegar a vincularse con otros productos de Google como GMail o Google Plus, pudiendo identificar al usuario. De popularizarse, AdID daría a Google más poder y control de información.

Apple

Safari, tanto en su versión de escritorio como móvil, implementa por defecto la política de desactivar las cookies de terceros.  Por otro lado, en los dispositivos iOS existen varias opciones de tracking de ubicación, búsquedas o aplicaciones que pueden ser desactivadas o activadas a elección del usuario, aunque por defecto estén activadas.

Pero aunque Apple no permita cookies de terceros en su navegador, sí que implementa su propio ID For Advertisement (IFA o IDFA) que actúa como identificador para la publicidad de las aplicaciones en los dispositivos móviles. En anteriores versiones se conocía como UDID. Desde iOS 6 en adelante, aparece la opción de privacidad en el menú de ajustes que permitirá al usuario limitar o restablecer este identificador:
Menú de ID for Advertisement en iOS
Facebook

Facebook usa cookies de terceros en los elementos integrados en las webs, como el conocido botón de "Like!" o píxeles transparentespara realizar el seguimiento. Obviamente, Facebook es capaz de relacionarlo directamente con el perfil, puesto que el identificador de sesión de Facebook se envía en la cookie.

Además Facebook es capaz de rastrear al usuario incluso después de cerrar la sesión. Esto ocurre porque existen elementos en la cookie que no varían tras cerrar la sesión, permitiendo identificar al usuario que previamente inició y cerró sesión.

Cookies de Facebook antes y después de cerrar sesión
Microsoft

Por otro lado Microsoft propone una alternativa parecida a Google, creando un ID de dispositivo para sus productos Windows, Windows Phone, Xbox, IE y Bing permitiendo conocer los gustos a través de estas plataformas. Todavía no se ha revelado demasiada información de cómo funcionaría. Aquí, realizaban una pequeña comparativa entre los métodos.

Do not track... ¿la solución?

Hace ya algún tiempo (2001) se introdujo una opción en los navegadores llamada "Do not track" (DNT), que incluye un flag o header en todas las peticiones realizadas por el navegador para evitar que se realice el tracking. Sin embargo, queda en la mano del servidor valorar esta opción o no.

Ejemplo de cliente enviando la cabecera Do Not Track
Actualmente todos los navegadores populares como IE, Firefox, Chrome, Safari y Opera implementan la función DNT y se puede configurar fácilmente en el apartado de preferencias de cada navegador. Internet Explorer es el único que lo implementa por defecto.

Configuración de "Do Not Track" en diferentes navegadores
* Sobre cookies y sistemas de seguimiento (I)
Oscar Sánchez

Latch ya está en Acens (y poco a poco en más servicios)

$
0
0
Ya hemos hablado de la tecnología Latch, pero lo realmente interesante ahora no es que sea posible aprovecharla en diferentes webs, páginas, portales y servicios. Acens la compañía de hosting, ya la tiene disponible para sus clientes.

Acens ha implementado Latch para proteger el acceso a las cuentas de los clientes. Añade así una capa adicional de seguridad en su panel de control, permitiendo al usuario controlar cuándo (incluso si un tercero conociera sus credenciales) se puede acceder a esa información tan sensible. Si hablamos por ejemplo de los servidores DNS, es más que recomendable proteger su acceso. Además no suele ser algo que cambie a menudo.

Acens ha conseguido integrar Latch en sus sistemas en menos de 24 horas, lo que da una idea de lo fácil que resulta para los técnicos involucrados.

Para aprovechar esta oportunidad de proteger las cuentas en Acens, solo es necesario que el usuario descargue la aplicación para iPhone o Android (en Windows Phone estará en breve, y para BlackBerry y Firefox OS dentro de unas semanas).

Después, desde el panel de control de Acens, es necesario parear la cuenta.

Pasos necesarios para parear la cuenta de Acens con Latch desde su panel de control
Y así quedará disponible en el teléfono.

Acens en Latch
Poco a poco, Latch intentará estar disponible en más y más páginas de servicios, para que el usuario pueda realmente aprovechar esta tecnología.

Intercambio de datos entre páginas: SOP, CORS y WebMessage (I)

$
0
0
Los navegadores son las aplicaciones más usadas por los usuarios a causa del desplazamiento del escritorio "a la nube" y por la grandes posibilidades que abarcan. La creciente complejidad del navegador ha permitido potenciar sus funcionalidades y (en consecuencia) aumentar los problemas de seguridad y su criticidad. Pero además, ha exigido nuevos métodos de intercambio de información y protocolos. Veamos algunos.

Comentaremos una de las políticas de intercambio implementadas por los navegadores desde hace tiempo (SOP) y otras soluciones "menos estrictas" ideadas para permitir mayor versatilidad y funcionalidad a las aplicaciones web.

Same-Origin Policy (SOP)

Same Origin Policy (SOP), es una de las políticas que implementan los navegadores desde prácticamente su concepción. Su objetivo fundamental (aunque en realidad esta definición se encuentra muy simplificada) es impedir que dominios que no compartan el mismo host, puerto y protocolo sean capaces de acceder a la información de otro dominio. Esta "información" pueden ser cookies, archivos HTML, imágenes, scripts, bases de datos, etc…
Tabla comparativa sobre SOP. Fuente: Wikipedia
En realidad, es un poco más complejo que todo eso. SOP no solo se trata de "acceder a recursos de otro dominio" sino que necesita distinguir entre qué recursos y de qué manera accede a ellos (con el ánimo de leer, escribir o incluso ejecutar). Eric Lawrence lo explica perfectamente en este enlace aplicando el concepto de permisos Unix (RWX) para explicar SOP.

Profunda explicación sobre SOP por Eric Lawrence
La idea de la política se remonta a NetScape Navigator 2.0, implementándose incluso en lenguajes de terceros como Adobe Flash o Adobe Acrobat o en mecanismos del propio navegador como la navegación por DOM. Incluso en el uso de XMLHttpRequest (peticiones HTML 5).

Esta política es implementada por todos los navegadores, aunque algunos navegadores la interpretan a su manera. Por ejemplo Internet Explorer no incluye el puerto como parte del "origen" delegando parte de su funcionamiento a su particular uso de las Zonas. Por ejemplo, si encuentra dos dominios que el usuario haya establecido como "Sitios de Confianza" la política permitirá la comunicación.

Opciones de sitios de confianza de Internet Explorer
Un claro ejemplo de la implementación de SOP y su utilidad, se observa durante la navegación a través del árbol DOM  cuando una web usa la etiqueta IFRAME (que permite incrustar una web dentro de un marco). Ninguno de los documentos podrá acceder al contenido del otro siempre y cuando no estén dentro del mismo dominio, usen el mismo protocolo y el mismo puerto.

Examinando el DOM de una web en la que se bloquea por política
Esta implementación evitaría que cuando el usuario acceda a una web maliciosa con un IFRAME, el atacante sea capaz de recopilar cualquier dato de la web o la cookie de sesión del usuario. Por tanto, la política SOP juega un papel fundamental a la hora de proteger los datos y que estos se compartan con otras entidades.

Sin embargo, en algunas ocasiones esta política puede llegar a ser muy restrictiva, por lo que en HTML 5 se incorporan varias funcionalidades y soluciones que la relajan, llegando a permitir compartir más datos. Un ejemplo es CORS, del que hablaremos en la próxima entrega.

Oscar Sánchez
oscar.sanchez@11paths.com

Accediendo (y "hackeando") el registro de Windows Phone

$
0
0
Aunque Microsoft se esfuerza en proteger Windows Phone 8 de los hacks de la comunidad, acceder al registro de los dispositivos todavía es posible con algunas limitaciones. Escribir en el registro está denegado por defecto,  pero los permisos de lectura son bastantes laxos.

Primera aproximación

Si se quiere intentar leer el registro, la primera aproximación puede ser invocar a una librería a bajo nivel de las API WIN32, como puede ser winreg.h e importar las funciones necesarias. Sin embargo, PInvoke/DllImport no está disponible en Windows Phone, así que se tendría que implementar desde cero. No hace falta decir que esto viola los requerimientos de Microsoft para subir una aplicación a la Store.

Pero investigando un poco, podemos encontrar que una buena parte del trabajo ya está hecho y disponible para descarga desde el foro "XDA Developers". Es posible aprovechar un proyecto llamado "Native Access" de GoodDayToDie que hace exactamente eso. Sin embargo compilarlo y usarlo no es trivial, así que vamos a documentar un poco cómo hacerlo.

Dependencias

El código fuente del proyecto puede ser descargado desde esta dirección: http://forum.xda-developers.com/showthread.php?t=2393243. Para compilar el proyecto, es necesario hacerse con las librerías de referencias y convertir algunas DLL del teléfono en formato .lib usando, por ejemplo, dll2Lib (disponible en este enlace: https://github.com/peterdn/dll2lib). En realidad, las librerías necesarias están en el directorio system32, pero utilizar las del emulador no va a funcionar en un teléfono real. Así que se necesitarán imágenes de dispositivos reales y extraer de ellas las DLL. Hay imágenes ISO de teléfonos reales disponibles "ahí fuera", así que en realidad no es difícil extraerlas y conseguirlas.

Una vez hecho, es necesario, además, poner las librerías .LIB extraías en el directorio Libraries del SDK de WP8 (normalmente en Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Libraries).

Problemas compilando

Sin embargo, si tienes problemas compilando el código, se puede tomar un atajo si se referencia el fichero .winmd de un proyecto ya existente que use Native Access (por ejemplo WebAcess). Se debe extraer el contenido del fichero XAP (que no es más que un zip) y buscar "Registry.dll" que ya es una versión compilada del proyecto.

Ahora ya estamos listos para usar la librería y escribir el código para buscar claves en el registro. La clase proporciona todos los métodos necesarios para acceder al registro: ReadDWORD, ReadString, ReadMultiString, ReadBinary, ReadQWORD, GetHKey, GetSubKeyNames, GetValues

Un ejemplo real

Aquí están los códigos para acceder a las diferentes ramas:
  • 80000000 -> HKEY_CLASSES_ROOT
  • 80000001 -> HKEY_CURRENT_USER
  • 80000002 -> HKEY_LOCAL_MACHINE
  • 80000003 -> HKEY_USERS
  • 80000004 -> HKEY_PERFORMANCE_DATA
  • 80000005 -> HKEY_CURRENT_CONFIG
Ejemplo de código para acceder al registro de Windows Phone 8
Para acceder a algunos puntos del registro que son muy sensibles, o para crear claves, se necesitarán ciertas capacidades especiales. Por ejemplo conseguir interop-unlock que por ahora solo se ha hecho en dispositivos Samsung que aprovechan la "Diagnosis tool" de la marca.

Tero de la Rosa
tero@11paths.com

Accessing (and hacking) Windows Phone registry

$
0
0
Although Microsoft’s efforts on securing Windows Phone 8 devices from community hacks, accessing the device’s registry is still possible with some limitations. Writing to the registry is denied by default but read-permissions are quite lax.

First approach

When trying to read the registry, initial approach is (maybe) to invoke a low-level library from WIN32 API, such as winreg.h to import the necessary functions. However, PInvoke/DllImport isn’t available in Windows Phone, so we would have to implement it from scratch. Needless to say that this breaks Microsoft’s requirements for submitting such an application to the Store.

Doing some research shows that much work has already been done and is available for public download in the "XDA Developers" forum. There is a project called "Native Access" by GoodDayToDie that does exactly this. However compiling and using it is not straightforward so we’ll give it a go and show how to do it.

Dependencies

The project’s source code can be download from the following link: http://forum.xda-developers.com/showthread.php?t=2393243.To get the referenced libraries needed for building the project, it is needed to convert the phone’s DLLs into .lib format (using, for example dll2Lib available from https://github.com/peterdn/dll2lib). Actually, the needed libraries are in system32 directory, but using the emulator’s libraries will not work on an actual phone. So you will need an image from real devices. There are ISO files available "out there", so you can get and extract them easily.

Once done, you need to place the extracted .LIBs in the Libraries folder of the WP8 SDK (typically in Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Libraries).

Problems compiling

However, if you have trouble compiling the code, there’s a shortcut by referencing the .winmd file from an existing project that uses Native Access (WebAccess for example). Just extract the XAP’s contents (which is just a zip file) and search for “Registry.dll” which is a precompiled version of the project.

Now we are ready to use the library and writing code to search for some interesting keys in the registry. The class provides all of the necessary methods to access the registry: ReadDWORD, ReadString, ReadMultiString, ReadBinary, ReadQWORD, GetHKey, GetSubKeyNames, GetValues

A real example

Here are the codes needed to access the different registry hives:
  • 80000000 -> HKEY_CLASSES_ROOT
  • 80000001 -> HKEY_CURRENT_USER
  • 80000002 -> HKEY_LOCAL_MACHINE
  • 80000003 -> HKEY_USERS
  • 80000004 -> HKEY_PERFORMANCE_DATA
  • 80000005 -> HKEY_CURRENT_CONFIG
Example code to access registry in Windows Phone 8
For some registry locations that are highly sensitive, or for writing or creating keys, you need to add special Capabilities to your app. This will require an interop-unlock that has currently been achieved only in Samsung devices by taking advantage of Samsung’s "Diagnosis tool".


Tero de la Rosa
tero@11paths.com

Ocho siglas relacionadas con las vulnerabilidades (I): CVE

$
0
0
Uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades.Para ello existen organizaciones encargadas de tratar temas relacionados a este aspecto, como es el caso de MITRE, FIRST e ICASI. Veremos que estándares utilizan y cómo aprovecharlos para entender mejor los problemas de seguridad.

MITRE es una organización sin ánimo de lucro que gestiona los CVE. Opera en centros de investigación y desarrollo encargados del estudio de distintos campos entre los que se encuentra la seguridad de la información. En la práctica, se encarga de registrar y oficializar todos los datos relativos a vulnerabilidades, debilidades y ataques conocidos en el mundo de la seguridad. Toda esta información es de carácter público y puede ser consultada libremente.

Qué es el CVE


CVE (Common Vulnerabilities and Exposures) es una lista de vulnerabilidades de seguridad de la información públicamente conocidas. Es quizás el estándar más usado. Permite identificar cada vulnerabilidad, asignando a cada una un código de identificación único. Se conoce como identificador CVE (CVE-ID) y está formado por las siglas de este diccionario seguidas por el año en que es registrada la vulnerabilidad o exposición y un número arbitrario de cuatro dígitos. Estos tres elementos van separados por un guion resultando un identificador con el siguiente formato:

Este formato se ha mantenido durante muchos años, pero hoy las cosas han cambiado. Aunque aún no ha dado esta circunstancia, catalogar 9.999 vulnerabilidades en un año, parece que se han quedado corto. Así que desde el primero de enero de 2014 este identificador puede contener más de cuatro dígitos para su asignación a la vulnerabilidad. Lo que esto quiere decir es que si a partir de 2014, el rango de 0001 – 9999 no fuese suficiente, se podrán añadir oficialmente más dígitos según sea necesario sin romper el estándar.

Se agregarán los dígitos a la derecha del número de vulnerabilidad. Los CVE-ID con cinco o más dígitos solo serán utilizados para representar vulnerabilidades que superen la barrera del 9999.

Ventajas del CVE

La utilidad de este catálogo es múltiple:
  • Permite tener una base para la evaluación de las vulnerabilidades.
  • Es un estándar muy adoptado para referirse a ellas. En la mayoría de las ocasiones, la asignación de un CVE permite diferenciar vulnerabilidades que, de otra forma, resultarían muy complejas de describir y diferenciar desde un punto de vista técnico.
  • Realiza un proceso de actualización continua de las vulnerabilidades registradas en la lista.
  • La posibilidad de monitorizar cambios o actualizaciones sobre la lista y los contenidos de las vulnerabilidades.
  • Una revisión exhaustiva de las nuevas vulnerabilidades que podrán ser registradas en el diccionario.
Cómo registrar una nueva vulnerabilidad en CVE

Para registrar una vulnerabilidad en esta lista se debe presentar su candidatura y superar tres etapas. La primera es la de tratamiento, en la que el CVE Content Team se encarga de analizar, investigar y procesar las solicitudes de registro de nuevas vulnerabilidades para la lista CVE. La segunda etapa es la de asignación del CVE-ID, que puede llevarse a cabo de tres maneras distintas:
  • Una asignación directa por parte del CVE Content Team después de que éste realice el estudio de la nueva propuesta de vulnerabilidad.
  • Una asignación directa por parte del CVE Editor al ser difundida ampliamente una vulnerabilidad crítica. Ocurre por ejemplo cuando se descubre un fallo 0day sin claro autor definido. Si no lo asume el fabricante, es esta organización la que directamente debe asignar un CVE para identificarlo.
  • Una reserva de un identificador CVE-ID, por parte de una organización o individuo antes de hacer la propuesta. Habitualmente, los grandes fabricantes reservan en el año un "lote" de CVE que van asignando a sus boletines de seguridad.
La tercera y última etapa es la de publicación. Puede prolongarse un periodo de tiempo indefinido, ya que no solo consiste en agregar la entrada a la lista y publicarla en el sitio web del diccionario, sino que incluye también los procesos de modificación. Durante este proceso podría sufrir cambios con respecto al contenido de la descripción o incluso añadir nuevas referencias que la sustenten.

Se pueden dar casos "especiales", en los que un CVE-ID puede necesitar dividirse en distintos identificadores por la complejidad de la vulnerabilidad. Aunque también podría darse el caso inverso, es decir, que varios identificadores se agrupen para formar un único CVE-ID.

Es posible incluso, que algún CVE-ID sea eliminado de las listas junto con su respectivo contenido. Por ejemplo, esto puede deberse a distintos factores:
  • Que una vulnerabilidad ya haya sido registrada bajo otro CVE-ID.
  • Que un posterior análisis de la vulnerabilidad demuestre que en realidad no existe.
  • Que el informe relativo a la vulnerabilidad deba ser reformulado en su totalidad.
Qué información ofrece la web oficial de CVE

A continuación se resaltan en la siguiente imagen los enlaces más importantes que se pueden encontrar en su página web.
  • En el enlace Documents se pueden encontrar todos los documentos públicos relacionados con CVE.
  • En los enlaces a Search CVE y Search NVD se pueden realizar las búsquedas de vulnerabilidades. El primero de los enlaces facilita la búsqueda a través de la lista CVE, y el otro enlace permite la búsqueda de vulnerabilidades a través de la base de datos de vulnerabilidades del NIST.
  • En el enlace Search the Site pueden realizarse búsquedas específicas de las vulnerabilidades a través de palabras clave que puede estar contenidas en el nombre o la descripción de la vulnerabilidad sin necesidad de conocer el CVE-ID.
  • Con el enlace NVD (National Vulnerability Database) se puede ir directamente a la página web de la base de datos de vulnerabilidades del NIST, (de la que hablaremos en una próxima entrada). En ella se puede consultar también las vulnerabilidades registradas en CVE incluyendo su valoración CVSS.
  • Por último, con los enlaces Vulnerability Scoring System (CVSS) y Software Weakness  (CWE) pueden consultarse las otras dos listas de las que también hablaremos.
De cada vulnerabilidad suele recolectarse por lo general solo una escueta descripción y las referencias que comprueben y apoyen la existencia de la vulnerabilidad. Las referencias pueden ser publicaciones o entradas de foros o blogs en donde se han hecho públicas las vulnerabilidades y demostraciones de su explotación. Además suele también mostrarse un enlace directo a la información de la base de datos de vulnerabilidades del NIST (NVD), en la que pueden conseguirse más detalles de la vulnerabilidad y su valoración. 

Umberto Francesco Schiavo

I+D en troyanos bancarios: versiones de 64 bits y uso de TOR

$
0
0
La industria del malware necesita mejorar y seguir robando. Así que investigan e invierten. Hay dos formas diferentes de invertir si estás "en el negocio": una es invertir en nuevas vulnerabilidades para poder infectar más eficientemente. Esto es complicado y no hablaremos de ello en esta entrada. La otra vía de inversión está en cómo robar de forma más eficiente cuando la víctima ya está infectada. ¿Qué han hecho al respecto últimamente?

¿Cuál es el troyano bancario más lucrativo?

Existen millones de troyanos bancarios. Más de los que probablemente podamos imaginar y más de los que las casas antivirus pueden manejar. Pero la mayoría de ellos tienen mucho en común. Básicamente en sus objetivos (robar, cuanto más mejor) y en la manera en la que llegan y se quedan en el sistema.

Simplificando mucho, el troyano más lucrativo es el llamado "ZeuS" o "Zbot", nacido a finales de 2005. Zeus, dependiendo de con quién se hable, es una cosa u otra. Su historia es lo suficientemente larga como para cubrir filtraciones de código, mutaciones, copias... Para esta entrada, ZeuS es básicamente una filosofía y una plantilla. Una "plantilla" porque permite, con un programa, crear un troyano bancario con objetivos a demanda, con su propia sintaxis y reglas. Un kit de "Hágalo usted mismo" con funcionalidades muy avanzadas. Es también una "filosofía" por la forma en la que roba, que podría ser considerada un estándar hoy. ZeuS consolidó un estilo en los troyanos bancarios. Lo que hace, y la base de su éxito es (entre muchas otras cosas):
  • Se inyecta en el navegador, para modificar lo que el usuario ve realmente en su pantalla. Inyecta nuevos mensajes o campos y modifica el comportamiento o envía los datos relevantes al atacante.
  • Si no puede o no sabe inyectar nada, captura y envía al atacante el tráfico https.
De esta forma y con esta estructura básica, ZeuS (como concepto) ha estado vivo y coleando durante 8 años ya. Existen malware con diferentes nombres, pero fundamentalmente, siguen algunas de estas pautas de estilo.
Uso de navegadores. La versión de Chrome de 64 bits está prácticamente en desarrollo en Windows. La de Firefox de 64bits para Windows incluso se canceló temporalmente
¿En qué están invirtiendo?

ZeuS ha evolucionado técnicamente, pero ha mantenido su estructura "básica". ¿Existe una rama "oficial" de ZeuS? Sí, se puede comprar, pero hay "forks" y variantes que se han convertido a su vez en estándares. Aparecen funcionalidades cada cierto tiempo y otros grupos de atacantes las adoptan, copian o compran.

Centrándonos en los últimos cambios más interesantes que han sido noticia últimamente, los más significativos son :Usar TOR para comunicarse con su servidor central (command and control) y versiones de ZeuS compiladas directamente para 64 bits. Aunque no se han visto "in the wild", esto mejora drásticamente las capacidades de ZeuS.

Uno de los puntos débiles (y a su vez, ventajas) de ZeuS (y del malware en general hoy en día) es que depende de servidores externos. Una vez que estos servidores no están disponibles, el troyano es fundamentalmente inútil. Para solucionar esto, los atacantes han usado hasta ahora dominios dinámicos, generadores de dominio, técnicas de "fast flux" en los DNS, hosting a prueba de balas.... y todas estas técnicas son válidas pero resultan "caras". Usar TOR y dominios .onion les proporciona una resistencia más "barata". Cerrar, detectar o investigar estos servidores será mucho más complicado para los "buenos",  y para los atacantes resultará mucho más sencillo conservar esta estructura más "resiliente".

Por otro lado, crear versiones nativas para 64 bits requiere una explicación previa. Hoy, una buena parte de sistemas Windows son de 64 bits. En esta arquitectura, las aplicaciones de 64 bits y la mayoría de las de 32 (excepto los drivers) funcionan sin problemas. Por eso hoy, muchos programas siguen siendo compilados para 32 bits, y así pueden correr en XP (cuya versión de 64 bits no es muy usada) y el resto (que sí son en su mayoría de 64 bits). Los programadores, para facilitar la compatibilidad, compilan para 32 bits. Y así lo hace el malware también. Hoy incluso con sistemas operativos de 64 bits, los navegadores suelen ser de 32 (incluso Internet Explorer, que viene con versión de 32 y 64 en los últimos Windows). La razón es para mantener compatibilidad con los plugins y extensiones del navegador que son aún de 32 bits. Entonces,¿por qué crear malware que solo funcionaría en navegadores de 64 bits? Porque pueden. Quizás están experimentando en estos momentos, preparándose para el futuro próximo. De hecho, la versión de ZeuS de 64 bits se ha encontrado "dentro" de una versión de 32. Esto significa que, una vez infectado, usa una u otra dependiendo del navegador. Quizás no encuentren a muchas víctimas usando exclusivamente navegadores de 64 bits (según Kaspersky, el 0,01% de usuarios usan IE nativo de 64 bits), pero es un mercado que no quieren dejar de lado, y para cuando aumente (los navegadores ya hacen esfuerzos para disponer de versiones nativas de 64 bits que terminarán por imponerse), quieren que su software esté preparado.

Puede que haya otra razón. Usar versiones de 64 bits puede permitirles pasar más inadvertidos en las sandboxes de los investigadores y casas antivirus. La detección para la mayoría de las casas antivirus pasa por este circuito: sandbox y, si es sospechoso, análisis más profundo y, si sigue siendo sospechoso pero no se ha clasificado todavía dentro de ningún grupo, análisis manual. XP es un sistema muy utilizado como sandbox todavía. Las versiones nativas de 64 bits de malware no funcionarán en ese entorno. Pero esto depende mucho de los recursos de las casas antivirus y sus métodos más o menos sofisticados.

¿Qué significan estos cambios?

Que los programadores de troyanos bancarios no temen a los usuarios y solo un poco las casas antivirus. Su única limitación son sus propias capacidades técnicas. Que, si les apatece, son más proactivos que cualquier otra industria. Y que quieren el pastel completo de usuarios para robarles todo lo posible.

Sergio de los Santos


Banking trojan I+D: 64 bits versions and using TOR

$
0
0
Malware industry needs to improve and keep on stealing. So they research and invest. There are two different ways of investing if you are "in the business": one is investing in new vulnerabilities so you can infect more efficiently. This is complex and will not talk about that in this post. The other side to invest in, is how to steal more efficiently once the victim is infected. What have they done about it lately?

Which is the most lucrative banking trojan?

There are millions of banking trojans. More that you can probably imagine, and more than the antivirus companies can handle. But most of them have quite a lot in common. Basically in their targets (stealing, the more the better) and in the way they break into a system and keep the infection. 


If we simplify a lot, the most lucrative banking trojan is the one we call "ZeuS" or "Zbot", born in late 2005. Zeus, depending on who you are talking to, is one thing or another. Its story is long enough to cover code leakages, mutations, copycats... For this article, ZeuS is basically a philosophy and a template. A "template" because it allows, with a program, to create a banking trojan targeting bankings on demand, with its own syntax and some rules. A DIY kit with very advanced features. It is also a "philosophy" because of the way it steals, that may be considered a standard nowadays. ZeuS consolidated a style in banking trojan. What it does, and the basis of its success is (among mucho more things): 
  • It injects itself in the browser, so it can modify what the user actually sees in the screen. It injects new fields or messages and modifies the behavior or sends the relevant data to the attacker. 
  • If not injecting anything, it captures and sends all the outgoing https traffic to the attacker.
In this way and with this basic structure, ZeuS (as a concept) is alive and kicking for 8 years now. There is some more malware with different names, but fundamentally, they follow some of this style patterns.

Browser usage. 64 bits Chrome version is under developing in Windows. 64 bits version for Firefox for Windows was even cancelled for a while.
What are they investing in?

ZeuS has evolved technically, but maintaining same basic structure. Is there an "official" ZeuS branch? Yes, you can buy it, but there are forks and other variants that became standard. Some features appear from time to time and some group of attackers adopt, copycat or buy them.

Focusing on latest changes, the most significant observed are:  Using TOR to communicate to Command and Control Servers and Zeus compiled directly for 64 bits. Although not seen "in the wild", this improves dramatically ZeuS capabilities.

One of the weak points (and advantages, in a way) of ZeuS (and malware in general these days) is that it strongly depends on external servers. Once these servers are down, the trojan becomes mostly useless. To solve this, so far they have used dynamic domains, domain random generator, fast flux playing with DNS, bulletproof hosting... and all these techniques are ok but they result expensive. Using TOR and .onion domains gives them "inexpensive" strength. Shutting down this servers will be very difficult for the good guys, and easier for the attacker to keep than any other "resilient" infrastructure used so far.


On the other hand, creating a 64 bits native version requires some clarification. Today, most of Windows system are 64 bits. In this architecture, 64 and (most of) 32 bits applications (except drivers) can run without problems. That is way today most of programs are compiled for 32 bits, so they can run in XP (with a not very used 64 bit version) and any other Windows (mostly 64 bits). So developers create 32 bits versions for all of them to ease compatibility. So does malware. Today, even with a 64 bits OS, browsers are still 32 bits (even IE, that comes in this two flavors in latest Windows). The reason is being compatible with plugins and extensions that are still 32 bits. So, why creating a 64 bit version of malware? Just because they can. They are maybe experimenting right now, for the near future. In fact, the 64 bit version have been detected "inside" a 32 version. This means that, once infected, it uses one or another depending on the browser. They will find very few people using a 64 bits browser (Kaspersky says only 0,01% of desktops are using native 64 bits IE), but that few is a market they do not want to refuse to, and when it raises (browsers are making efforts to have native 64 bits versions that will end up imposing) they want their software to be ready.

There is maybe another reason. Using 64 bits versions makes them even more unnoticeable for sandboxes in antivirus companies. This is the first step for most of AVs that goes through this detection circuit: sandbox, and, if suspicious, deeper analysis and, if even more suspicious but not classified yet... manual analysis. XP is still very used as a sandbox. 64 bits version of malware will not work there, and will go probably as a corrupted file. But this depends much on their resources and the way they work.

What that this changes mean?

That banking trojan developers do not fear users and just a little bit the AV companies... Their only limitations are their own technical skills. If they want to, they can be even more proactive than any other industry. And that they want the whole cake of users with every single nickel they have.

Sergio de los Santos

Cómo integrar Latch en aplicaciones ASP.NET

$
0
0
Como ya sabéis, se ha lanzado Latch al mundo, y por ahora, hemos recibido muy buenas críticas por parte de los usuarios y, sobre todo, de los profesionales del sector. También muchas sugerencias y dudas que iremos solventando y atendiendo poco a poco.

Nuestra misión ahora es conseguir que crezca la cantidad de proveedores de servicio que ofrecen Latch a sus usuarios, y que así puedan proteger sus cuentas de manera sencilla incluso en el caso de que les hayan robado las contraseñas. Por ahora, Latch está disponible en Acens, 0xWord, RecoverMessages... en breve lo estará en Tuenti. Nos consta además, debido al número de usuarios registrados en el "developers area" de latch.elevenpaths.com, que muchos administradores y programadores están ya integrando Latch en sus webs o, al menos, tienen la intención.

Para el usuario, están ya disponibles las apps en iOS, Android y Windows Phoney sus respectivos markets oficiales. Pronto lo estará para otras plataformas.

Siguiendo el hilo de algunos post que explican paso a paso cómo integrar Latch en Wordpress, o servidores FTP, hemos creado este tutorial para administradores y desarrolladores de páginas ASP.NET. En él, se explica paso a paso cómo integrar Latch en una web creada con ASP.NET, desde cero y de forma muy sencilla, gracias a las librerías que proporcionamos.

El PDF lo hemos alojado en slideshare, desde donde se puede descargar si se desea.




Arquitectura y cifrado de seguridad en redes 3G

$
0
0
Las redes de telefonía móvil, por su naturaleza radioeléctrica, son tanto o más vulnerables que otras redes de comunicaciones. Con su uso generalizado, garantizar la seguridad en este tipo de redes cobra mayor importancia. El estándar UMTS (Universal Mobile Telecommunications System) de telefonía 3G implementa un esquema de seguridad específico que intenta garantizar la confidencialidad y la integridad de la información enviada a través de la interfaz radio, ya sean datos de usuario o de señalización. ¿Cómo lo hace? Y, sobre todo... ¿lo consigue?

Fundamentalmente usamos hoy en día dos tecnologías:
  • 2G: Que es la combinación de GSM para voz (en Europa, porque en Estados Unidos se puede usar CDMA) y GPRS para datos. Estos estándares pueden ir cifrados o no, pero si lo están, ya se conocen formas de romperlo en un tiempo razonable. Además tiene un problema adicional: en el mundo 2G, el teléfono se autentica contra la torre pero no al revés. Por tanto se pueden "falsificar".
  • 3G: UMTS, del que hablaremos. La estación base (torre) sí se autentica contra el teléfono.
Actualmente, 2G es un desastre porque permite a un atacante suplantar la estación base (la torre) y que el teléfono se conecte a ella sin dudarlo. A todo esto ayuda bastante que los teléfonos "degraden" la conexión a 2G cuando lo necesitan y que uno de los modelos más usados (el iPhone) no permita evitar este comportamiento. Además, un atacante podría montar una estación base por relativamente poco dinero (actualmente, unos pocos miles de euros). El teléfono puede, para ahorrar batería o porque la señal es más fuerte, conectarse a esa estación base falsa que emite en 2G y ofrecer todos sus datos.

Arquitectura UMTS

A grandes rasgos, el sistema UMTS está dividido en dos grandes bloques lógicos:
  • El núcleo de red (Core Network, CN) desempeña labores de control de tráfico, señalización, conmutación y encaminamiento. Además, hace posible la conexión de UMTS con otras redes de comunicaciones. Reutiliza varios elementos ya presentes en la arquitectura 2G y soporta tanto conmutación de paquetes como conmutación de circuitos.
  • La red de acceso radio (UTRAN) se encarga de los aspectos de comunicaciones, tales como la gestión de los recursos radio, el control de potencia y el traspaso de llamadas.  Sus elementos principales son los controladores de red (RNC), que se encargan de gestionar una o varias estaciones base que dan cobertura a los terminales de usuario.

Arquitectura UMTS. Fuente: Wikipedia
Dado que la CN hereda elementos de la arquitectura 2G, es frecuente ver estaciones base GSM y UMTS coexistiendo dentro de una misma red móvil.

Arquitectura de Seguridad UMTS

La arquitectura de seguridad de UMTS está compuesta por un conjunto de características y mecanismos de seguridad. Un mecanismo de seguridad es un elemento que proporciona una característica de seguridad. Y una característica de seguridad es una funcionalidad de un servicio que satisface uno o varios requisitos de seguridad.

Brevemente, en UMTS tenemos cinco grupos de características de seguridad, cada uno orientado a hacer frente a ciertas amenazas y alcanzar determinados objetivos.
  • Seguridad en el acceso a la red (I en la figura): Proporciona acceso seguro a los servicios  y protege contra ataques en el enlace radio.
  • Seguridad en el dominio de red (II): Permite a los nodos del operador de red intercambiar datos de señalización de forma segura, y protege contra ataques en la red cableada.
  • Seguridad en el dominio del usuario (III): Permite a los usuarios disponer de acceso seguro a las estaciones móviles.
  • Seguridad en el dominio de aplicación (IV): Permite que las aplicaciones en el dominio de usuario y en el dominio del proveedor intercambien mensajes de forma segura.
  • Visibilidad y configuración de seguridad: Permite al usuario obtener información sobre las características de seguridad que  se están utilizando.
Arquitectura de seguridad UMTS. Fuente:www.etsi.org
En UMTS, por otra parte, tenemos tres grandes mecanismos de seguridad: el sistema de autenticación y acuerdo de claves; los algoritmos de integridad y confidencialidad; y el cifrado en bloque KASUMI. Los vemos a continuación.

UMTS Authentication and Key Agreement

El UMTS AKA es el mecanismo que gestiona todo el proceso de autenticación, basándose en un protocolo de tipo desafío-respuesta. Son los que se suelen utilizar para que una entidad verifique la identidad de otra sin revelar una clave compartida común.

El proceso UMTS AKA es gestionado por el registro de ubicación de visitante (Visitor Location Register, VLR), y consta de los siguientes pasos:
  1. El VLR envía al Registro de ubicación base (Home Location Register, HLR) del abonado una petición de autenticación.
  2. El HLR computa un conjunto de vectores de autenticación (AV1:AVn) a partir de la clave privada K del usuario (que solo se almacena en la propia USIM y en el HLR/AuC), y lo envía al VLR, que los almacena.
  3. El VLR escoge uno de los vectores de autenticación (AVi), y desafía a la USIM enviándole los campos RAND y AUTN (token de autenticación) del vector seleccionado.
  4. La USIM del usuario procesa el token de autenticación, y mediante su clave privada K puede comprobar que los datos recibidos solo pueden provenir de alguien que tenga acceso a esa clave, por lo que de esta forma la red queda autenticada frente al usuario. La USIM procede entonces a generar una clave de confidencialidad (CK), una clave de integridad (IK), y una respuesta para la red (RES).
  5. La USIM envía la RES al VLR.
  6. Como el VLR conoce el AV, puede computar la respuesta esperada (XRES), y contrastar la RES que recibe con ésta. De esta manera el usuario queda autenticado también. El VLR computa entonces CK e IK a partir del AV.
  7. Las CK e IK establecidas son transmitidas por la USIM y el VLR a las entidades encargadas de las funciones de integridad y cifrado (generalmente el RNC).
Mecanismo de control de integridad

La información de señalización es vital tanto para el usuario como para la red, por lo que es fundamental poder garantizar su integridad (para prevenir, por ejemplo, ataques de falsa estación base). Así, se implementa tanto en la estación móvil como en el RNC el llamado algoritmo f9. El proceso de verificación de integridad es como sigue:
Mecanismo de control de integridad UMTS. Fuente:www.etsi.org
  1. El dispositivo del usuario calcula un código de autenticación de mensaje de 32 bits (MAC-I) a partir de ciertos parámetros de entrada, entre ellos los propios datos y la IK  que se obtuvo en el proceso de autenticación.
  2. El MAC-I calculado se adjunta a los datos de señalización y se envía al controlador de red.
  3. Una vez que el controlador de red recibe la información de señalización con el MAC-I adjunto, calcula, empleando el mismo método que el dispositivo de usuario, el XMAC-I.
  4. La integridad de la información de señalización se comprueba comparando MAC-I y XMAC-I.
Mecanismo de control de confidencialidad

La confidencialidad de la información transmitida es esencial tanto para el usuario como para el operador móvil. De la comprobación de confidencialidad se encarga el denominado algoritmo f8, que funciona de la siguiente manera:
  1. El dispositivo de usuario, a partir de la CK previamente calculada durante la autenticación y otros parámetros, calcula una secuencia de cifrado. 
  2. Se realiza un XOR entre esta secuencia de bits y los datos, obteniendo un bloque de datos cifrados.
  3. Estos datos cifrados se envían a la red a través de la interfaz radio.
  4. El RNC, a partir de los mismos parámetros que el dispositivo de usuario (incluyendo la CK compartida), genera la misma secuencia binaria de cifrado.
  5. Realizando una operación XOR entre esta secuencia y el bloque cifrado recibido, se recuperan los datos originales.
Mecanismo de control de confidencialidad UMTS. Fuente:www.etsi.org
Algoritmo de cifrado por bloque KASUMI

Los algoritmos f8 y f9 de integridad y confidencialidad están basados en el algoritmo KASUMI. Este algoritmo de cifrado por bloque está desarrollado a partir de MISTY-1, y presenta una estructura de Feistel que opera con una clave de 128 bits sobre entradas y salidas de 64 bits.


Estructura Kasumi. Fuente: http://eprint.iacr.org/2010/013.pdf

El algoritmo KASUMI realiza ocho iteraciones o rondas y, para cada una, genera un conjunto de claves de rondaa partir de la clave K de 128 bits. Con esas claves de ronda se computa una función f, diferente para cada ronda. Cada una de estas funciones fiestá compuesta por dos subfunciones, FLi y FOi, que dependen de los datos de entrada a esa ronda y de las claves.

Mientras que la función FL es relativamente sencilla (operaciones lógicas y desplazamientos binarios), la función FO presenta internamente una estructura de Feistel propia consistente en tres rondas, para cada una de las cuales se computa una subfunción FI que consta a su vez de otras tres rondas.

Debido a su complejidad, el algoritmo KASUMI ofrece un grado de seguridad elevado. Fue escogido por la 3GPP para la implementación de los algoritmos de confidencialidad e integridad en redes UMTS, además de integrarse posteriormente en las redes 2G. Sin embargo, varios equipos de investigación han intentado romperlo. Ya en 2003 se realizó una primera aproximación, que si bien no rompía el cifrado, lo eludía, haciendo posibles ataques MITM en GSM. Posteriormente, en 2005, investigadores israelíes propusieron un ataque boomerang contra KASUMI, que en realidad no resultaba práctico por su excesiva complejidad, pero comenzaba a medrar la confianza en el algoritmo. Finalmente, en 2010, investigadores del Weizmann Institute of Science de Israel consiguieron romperlo, obteniendo la clave completa en menos de dos horas utilizando un PC de sobremesa (y gracias a una tabla que fue previamente precomputada durante meses). Este ataque, curiosamente, no es efectivo contra el cifrado MISTY-1, que ha probado ser más robusto (pero también más consumidor de recursos) que KASUMI en contra de lo que sostenía inicialmente la 3GPP.

En general, los mecanismos anteriores hacen de UMTS un estándar relativamente seguro para la comunicación. Especialmente la doble autenticación (usuario-red y red-usuario) hace que UMTS sea difícil de vulnerar frente a ataques de hombre en el medio de falsa estación base, mientras perpetrar estos ataques en GSM resulta sencillo. Aunque el cifrado pueda considerarse fácil de romper, obtener el tráfico cifrado a través de ataques MiTM resultaría muy complejo para el atacante.

Las recientes tecnologías 4G, por otra parte, buscan mitigar los problemas de la actual generación. Entre las prestaciones de seguridad de LTE podemos encontrar la reutilización de la autenticación y acuerdo de claves UMTS, nuevos algoritmos para integridad y confidencialidad (SNOW 3G, AES) y una jerarquía de claves más profunda, con claves de hasta 256 bits.

Cristóbal Bordiú
cristobal.bordiu@11paths.com


Vulnerabilidades escurridizas, invisibles en el código durante años

$
0
0
Hace poco se ha corregido una vulnerabilidad de desbordamiento de pila que afecta al servidor X11. Llevaba "escondida" en el código desde 1991, presente en muchas de las distribuciones Linux y permitiendo, para quien la conociese, elevar privilegios en el sistema afectado. ¿Existen otros casos de vulnerabilidades que han pasado desapercibidas durante años?

El caso X11

X11 es un servidor gráfico desarrollador por el MIT a mediados de los 80 que proporciona interfaz gráfica a los sistemas basados en UNIX. A principios de 2014, y usando una herramienta llamada cppcheck, se ha encontrado un desbordamiento de pila a la hora de procesar fuentes BDF con la librería libXfont. Básicamente, esto permite a un atacante local elevar privilegios a root haciendo que el sistema procese un tipo de letra especialmente manipulado. La sencillez del parche (que simplemente limita el tamaño) explica el problema. Se trata de un desbordamiento de pila "de libro").

-        if (sscanf((char *) line, "STARTCHAR %s", charName) != 1) {
+        if (sscanf((char *) line, "STARTCHAR %99s", charName) != 1) {
             bdfError("bad character name in BDF file\n");
             goto BAILOUT; /* bottom of function, free and return error */}

Página de descarga de cppcheck.sourceforge.net
X11, aun siendo un software extremadamente usado y popular, contuvo durante 23 años una vulnerabilidad, en principio, que parecía bastante sencilla de detectar por el ojo humano, pero que en realidad tuvo que se cazada con la ayuda de un programa automático.

Un caso Solaris

El  12 de febrero de 2007 se da a conocer una vulnerabilidad en (por aquel entonces) Sun Solaris 10 tan simple como sorprendente. El fallo permitía el acceso trivial como cualquier usuario (incluido root) a través de telnet. El error fue ya descubierto y corregido en sistemas UNIX en 1994, pero Solaris lo "reintrodujo"en sus sistemas en noviembre de 2002, con lo que pasó inadvertida durante unos 5 años. A través de un simple parámetro del cliente telnet ("-f", utilizado para traspasar las credenciales locales), se podía acceder a un servidor telnet en Sun Solaris 10 sin necesidad de autenticación. Sólo conociendo el nombre de usuario. El comando para "explotar" el fallo era:

telnet -l "-froot" [direccion_del_host]

El código del demonio telnet en Solaris 10 es abierto.

Un caso Oracle

El fallo CVE-2012-1675 en Oracle, reconocido por la compañía en abril de 2012, fue reportado en 2008 por Joxean Koret (@matalaz). Afectaba a todas las versiones de Oracle Database (desde 8i hasta la versión 11g R2). La vulnerabilidad permitiría controlar el tráfico cliente-servidor y modificarlo, a través de un ataque MITM. Aunque se reportó en 2012, la vulnerabilidad estaba en el código probablemente desde 1999. Además de la antiguedad del problema, Oracle protagonizó un episodio vergonzante en la gestión de parches. Koret, creyendo que había sido por fin solucionado, publicó todos los detalles. Haciendo gala de una respuesta totalmente absurda, Oracle respondió que en realidad "the vulnerability was fixed in future releases of the product", lo que no tenía sentido (fue corregida en futuras versiones).

Un caso Windows

A principios de 2007, todo el mundo hablaba de la vulnerabilidad de los Windows MetaFile (WMF) que supuso una pesadilla para Microsoft por muchas razones (se llegó a sacar un parche extraoficial por la comunidad, antes que la propia Microsoft). Era tan sencilla de explotar que Steve Gibson llegó a insinuar que podría ser intencionada, una puerta trasera incluida a propósito en el sistema operativo más famoso.

El fallo estaba basado en los registros de tipo META_ESCAPE, concretamente en el subcódigo SetAbortProc. En ella se deben especificar dos argumentos, uno que representarían el "Device Context" y el segundo sería una función a ejecutar ante un evento de cancelación de impresión. Controlarlos y ejecutar código era tan sencillo como enviarles los comandos adecuados. Stephen Toulouse escribió además en el blog oficial de Microsoft que el fallo estaba presente desde los tiempos de Windows 3.0, creado hacia 1990. SetAbortProc fue programada cuando la seguridad no representaban la mayor de las prioridades y fue introducida en los tiempos en los que procesar imágenes era lento y quizás fuese necesario abortar el proceso de impresión antes de que terminara, mucho antes incluso de que existiera el formato WMF. Aunque la funcionalidad fue perdiendo importancia, se fue portando junto con muchas otras, versión tras versión, en lenguaje ensamblador a los siguientes sistemas operativos que surgieron después. Se mantuvo por tanto unos 17 años en el código sin que nadie lo detectara. Ni siquiera los profesionales que se dedican a tiempo completo a encontrar fallos en Windows (que los hay).

¿Cómo puede ocurrir esto?

Los ejemplos expuestos son los más llamativos y escandalosos. Hay más ejemplos de todo tipo, en código abierto y cerrado. De hecho, todos los días se corrigen vulnerabilidades en sistemas operativos o programas que llevan años funcionando, y quizás las vulnerabilidades corregidas hoy llevan ahí ocultas desde que se usa ese sistema. Por ejemplo, muchas vulnerabilidades que se siguen encontrando en XP puede que estén ahí desde octubre de 2001, cuando fue sacado al mercado.

Las vulnerabilidades son inevitables, tanto en el diseño de programas como de protocolos. En este sentido, el fallo de Kaminsky en los DNS descubierto en 2008 es un buen ejemplo de un fallo de diseño que pasó desapercibido durante decenas de años, aun siendo un estándar completamente abierto aprobado en su teoría e implementado en la práctica por decenas de compañías.

istruecryptauditedyet.com
Poco parece que tenga que ver la eterna discusión sobre el código abierto o cerrado y las ventajas frente a la detección "temprana" de vulnerabilidades. Sin entrar en el aspecto filosófico del uso de software de código abierto, ¿en realidad resulta más sencillo encontrar vulnerabilidades en programas muy complejos de código abierto que en programas muy complejos de código cerrado? Un buen ejemplo es el caso TrueCrypt. Aunque sea de código abierto, sus usuarios necesitamos poder fiarnos totalmente de él, dada su importancia para proteger la confidencialidad. Pero para conseguirlo, se ha precisado de una campaña de recogida de fondos para (entre otras cosas) poder permitirse auditar su código, y premiar a los auditores que encuentren fallos en él. Llevean ya varios meses con el proyecto, y su sueño (porque no es fácil) sería realmente conseguir una auditoría completa de un código tan complejo como es cualquiera que trabaje con criptografía. Otro ejemplo de lo difícil que es auditar (o encontrar errores) en código en general y criptográfico en particular, es el desastre ocurrido en el demonio openSSL de Debian, que eliminó la entropía de creación de claves públicas y privadas en 2006. Nadie lo notó durante dos años.

Todo esto viene a recordar que de esos "miles de ojos" que pueden mirar el código, no son todos igual de efectivos... que algunos programas son más eficaces que el ojo humano, y que el hecho de que se permita mirar el código no significa que todo el mundo lo mire ni lo entienda realmente. El código abierto tiene muchas ventajas (prácticas y teóricas): en programas muy complejos una que sí se aprovecha en la práctica es que permite entender y mitigar (pero quizás no tanto detectar) las vulnerabilidades más rápidamente. Por supuesto, se puede argumentar que, si no fuese código abierto, no se hubiesen encontrado nunca estos fallos. Es posible. Defender uno u otro modelo es un asunto delicado para muchos. Lo que no hay que olvidar en cualquier caso es que auditar código desnudo es una tarea muy compleja que no puede ser delegada exclusivamente a programas. Necesita además del ojo humano, pero no cualquiera... no los "miles de ojos potenciales", sino de "pocos pero reales" que cuentan con gran experiencia, que son buenos programadores, profesionales, que saben interpretar correctamente los resultados de los programas automáticos de auditoría, que disponen de paciencia, tiempo... Y no se dedican todos estos recursos a todos los programas de código abierto (ni cerrado) "mágicamente". De hecho, lamentablemente, encontrar vulnerabilidades es una tarea a la que los atacantes profesionales parecen dedicar mucho más esfuerzo y empeño que cualquier comunidad o auditores y se centran en cualquier programa que les reportes beneficios, independientemente de la filosofía de código.

Sergio de los Santos
ssantos@11paths.com

How to bypass antiXSS filter in Chrome and Safari (discovered by ElevenPaths)

$
0
0
Modern browsers usually have an antiXSS filter, that protects users from some of the consequences of this kind of attacks. Normally, they block cross site scripting execution, so the "injected" code (normally, JavaScript or HTML) is not executed inside victim's browser. Chrome calls this filter XSSAuditor. Our coworker Ioseba Palop discovered a way to bypass it months ago. Since it is already resolved in the "main" version of Chrome, we are publishing technical details now.

In ElevenPaths, we just found a way to evade XSS filter in Chrome. This means, if the victim visits a website with an XSS problem that an attacker is trying to take advantage of, it would not be fully protected. The  bug  is  based  on  a  misuse  of  srcdoc  attribute  of  IFRAME tag,  included  in  HTML5 definition.  To  perform an  XSS  attack  on Google  Chrome  Browser  using this  bug,  the website must  include an IFRAME and must be able to read any attribute of this element from HTTP parameters (GET/POST) without applying any charset filter. Then, in the IFRAME parameter,  the  srcdoc  attribute  may be included with JavaScript  code. Chrome cannot filter it and will be executed.

To reproduce the PoC, there should be a webpage with some IFRAME tag like this:

And an HTML injection on src parameter would be:


and XSS filter will fail and let the script run.


Google derived this to Chromium, who does not treat this bypasses as a security problem, since XSSauditor is considered a second defense line.

The problem was reported in October, the 23rd. They fixed it two days later, making XSSAuditor catch reflected srcdoc properties even without an "IFRAME" tag injection. Chrome has just fixed it in recent 32.0.1700.76 version.

Some other bug

A few weeks ago, in this post, someone took our PoC as an inspiration and developed another way of bypassing the filter. This one is still not fixed. The trick is to inject an opening "script" tag inside a parameter that is written directly in the HTTP request output stream. This is, without filtering any character just as our case. In this writing there should be content inside scripts tags that belongs to the web itself.



The browser will include our injection (remember, without closing the tag), omit the "script" opening tag from the web itself, and now, use the closing one from the web to create a well formed script and execute it... this is the bypass.




Safari, still vulnerable

Safari for Mac and iPhone is vulnerable as well. They confirmed our email, and told us they were working on it. And seems that they still are, since the program is still vulnerable. Everytime we have tried to contact back with them again, they reply back telling there is no news, but they are working on it. Internet Explorer filters it with its own filter, and Firefox does not implement an XSS filter by itself.

Cómo eludir el filtro antiXSS en Chrome y Safari (descubierto por Eleven Paths)

$
0
0
Los navegadores modernos cuentan con un filtro antiXSS que protege a los usuarios de algunas de las consecuencias de este tipo de ataques. Normalmente, bloquean la ejecución de cross site scriptings de forma que el código inyectado (normalmente JavaScript o HTML) no se ejecuta en el navegador de la víctima. Chrome llama a este filtro XSSAuditor. Nuestro compañero Ioseba Palop descubrió una manera de eludirlo hace meses. Puesto que ya se ha resuelto en la versión principal de Chrome, publicamos los detalles técnicos.

En ElevenPaths, hemos encontrado una forma de eludir el filtro antiXSS de Chrome. Esto significa que si la víctima visita una web con un problema de XSS del que se está intentando aprovechar un atacante, no estaría totalmente protegido. El fallo se basa en un uso incorrecto del atributo srcdoc de la etiqueta IFRAME, incluido en la definición de HTML5. Para realizar un ataque XSS en el navegador Google Chrome usando este fallo, la web debe incluir un IFRAME y debe ser capaz de leer cualquier atributo de este elemento desde parámetros HTTP (GET o POST) sin aplicar filtrado de caracteres. Después, en el parámetro IFRAME, el atributo srcdoc se puede incluir con código JavaScript. Chrome no lo filtra y se ejecutará.

Para reproducir la PoC, debería haber una página con un IFRAME como este.

Y la inyección HTML en el parámetro src sería:


y el filtro antiXSS fallaría y dejaría correr el script.


Google derivó el problema a Chromium, que no trata estas elusiones como problemas de seguridad, puesto que  XSSAuditor se considera una línea de defensa secundaria.

El problema se reportó el 23 de octubre. Lo arreglaron dos días después, haciendo que XSSAuditor cazara las propiedades reflejadas de srcdoc incluso sin una inyección en la etiqueta "IFRAME",. Chrome lo ha corregido en su versión 32.0.1700.76.

Otro fallo

Hace unas semanas, en este post, alguien se fijó en nuestra PoC como inspiración y desarrolló otra forma de eludir el filtro. Este fallo todavía no está corregido. El truco es inyectar una etiquesta "script" de apertura en un parámetro que se escriba directamente en el stream de salida de la respuesta HTTP (es decir, sin filtrar ningún carácter al igual que en el caso anterior). Bajo esta escritura debe existir contenido dentro de etiquetas scripts que pertenezcan a la propia página.


El comportamiento del navegador será incluir nuestra inyección (recordemos que sin cierre de etiqueta), obviar la apertura de "script" de la propia web, y ahora sí, utilizar el cierre de la propia web para generar un script bien formado y ejecutarlo sin ningún tipo de problema, consiguiendo así un bypass de XSSAuditor.




Safari, todavía vulnerable

Safari para Mac e iPhone también son vulnerables. Confirmaron la recepción del correo, y nos dijero que estaban trabajando en ello. Parece que todavía lo están, puesto que el programa aún es vulnerable. Cada vez que se ha intentado contactar con ellos, la respuesta que no había novedades y que estaban trabajando en ello. El filtro de Internet Explorer impide la ejecución, y Firefox no implementa ningún filtro anti XSS.

Metashield videotutorials... now on YouTube

$
0
0
Nowadays, most common information leaks occur through unseen channels such as metadata and unseen document information. Through these externally shared documents it is possible to obtain critical data from an organization that can allow an attacker to fingerprint its assets and computer network. The consequences of this leak may have economic impact and the organization reputation can be seriously harmed. Metashield is our bet to solve this.

Metashield Protector lets you configure a security policy of metadata in the documents you are serving outside your organization. It provides a holistic solution to control the information leaks through its product portfolio.

We have uploaded some Video tutorials to Youtube, with English subtitles, to make it clear how easy to install and use they are. We have different videos for different solutions.

Metashield for IIS 

Server based solution for sanitizing documents on the fly as they are served to users by Microsoft IIS web server. It deletes or replaces documents metadata on the fly, offering a normalized public image of the organization.



Metashield for File Server

Sanitizes documents hosted on file servers (FTP servers, etc.), automatically deleting their metadata and hidden information and optionally replacing it with the desired one.


Metashield Forensics

Do you suspect you have a compromised system due to unauthorized access to internal files and need a forensic analysis? MetaShield Forensics extracts digital and time-stamped evidences available in metadata for a later forensic analysis.



Metashield for SharePoint

Cleans data served by Microsoft SharePoint Servers. If your company provides ECM (Enterprise Content Management) services based on SharePoint this server based solution helps you prevent inadvertent information leak.




Metashield for Client

Professional solution for workstations. It allows to remove metadata from files, just right clicking on them. Ideal to clean files before sharing them with someone else.



Videotutoriales de Metashield... ahora en YouTube

$
0
0
Hoy, las pérdidas de información más habituales ocurren a través de canales no visibles, como los metadatos o la información oculta en documentos. A través de estos ficheros compartidos con el exterior, podría ser posible obtener información crítica de la compañía que permite a un atacante identificar los activos y las redes. Las consecuencias de este filtrado de información pueden ser de gran impacto económico para la organización, además de que su reputación puede verse seriamente dañada. Metashield es nuestra apuesta para resolver esto.

Metashield Protector permite configurar una política de uso de metadatos en los servidores dentro o fuera de la organización. Prorporciona una solución ideal para controlar la información que se escapa de una organización.

Hemos subido algunos tutoriales a YouTube, con subtítulos en inglés, para dejar claro lo sencillo que son de usar e instalar. Disponemos de diferentes vídeos para explicar diferentes soluciones.

Metashield for IIS 

Una solución para el servidor Microsoft IIS que permite eliminar al vuelo los metadatos de los ficheros compartidos por web. Borra o reemplaza los metadatos de los documentos, contribuyendo a ofrecer una imagen más homogénea con respecto a los metadatos, o directamente libre de ellos.


Metashield for File Server

Limpia los documentos alojados en servidores compartidos internos, (o servidores FTP...) automáticamente, borrando los metadatos e información oculta y opcionalmente, reemplazándolos por los que se desee.



Metashield Forensics

Si se sospecha que se ha comprometido un sistema y se ha accedido de forma no autorizada a ficheros internos, MetaShield Forensics extrae evidencias digitales disponibles en los metadatos para facilitar un análisis forense.



Metashield for SharePoint

Limpia los datos servidos a través de servidores Microsoft SharePoint. Si la compañía proporciona servicios ECM (Enterprise Content Management) basados en SharePoint, este servicio ayuda a evitar que se filtre la información oculta en los ficheros.


Metashield for Client

Solución profesional para escritorios. Permite borrar la información de ficheros simplemente analizándolos con una opción añadida en el menú contextual. Ideal para limpiar ficheros antes de compartirlos con un tercero.


De cómo el malware modifica ejecutables sin alterar su firma

$
0
0
Microsoft acaba de arreglar (a medias) un método que permitía alterar un fichero firmado con Authenticode. Aunque el método fue descubierto en 2009, no ha sido  hasta ahora, cuando se ha observado que ciertos programas han comenzado a usar la fórmula, que ha introducido una corrección (que todavía no se activa por defecto). Se trataba de aprovechar un fallo de diseño de Authenticode. Veamos cómo funcionaba.

Varios métodos para cambiar la integridad sin alterar la firma

Existían varios métodos para alterar una imagen de un binario firmado sin que el sistema se quejase de que la firma era incorrecta (de que se había alterado su integridad). El parche MS12-024, de abril de 2012, corrige algunos. Tiene el CVE-2012-015 y lo descubrieron Robert Zacek e Igor Glucksmann, de Avast. No se había observado en malware aún.  Pero sí que existía un problema pendiente de arreglar. El truco era muy sencillo.

Ya hemos hablado en varias ocasiones de Authenticode en este blog. Fundamentalmente, cuando se firma un binario, se calcula el hash de todo el flujo de datos del menos algunos pequeños huecos que "se salta": La cabecera del fichero llamada "Security directory RVA" (también llamada Certificate Table RVA) y el checksum del fichero completo.

En 2009 se comprobó que era posible además añadir código al final de un ejecutable, sin alterar la firma. Aunque publicaron herramientas para conseguirlo, se demuestra manualmente de manera muy sencilla, con cualquier editor hexadecimal. El truco consiste en que se puede añadir código más allá del final del fichero y modificar las cabeceras correspondientes de tamaño. La última parte del fichero (entre 1 y 4 kbs), cuando se firma, corresponde a la estructura PKCS que contiene la firma en sí. En esta estructura se encuentra el certificado y toda la información criptográfica de la firma. Para engañar a Authenticode, se le puede simplemente indicar al fichero en su cabecera que la estructura PKCS es un poco más larga (cambiar el valor del tamaño) y que abarque la parte añadida. Así de simple.

Cómo conseguirlo

Es necesario modificar el valor "Security Directory Size". En el ejemplo usado, el tamaño del directorio (de la estructura PKCS) es 0x1918 bytes. Si se van a añadir, por ejemplo, 16 bytes (0x10), se modifica el valor de 0x1918 a 0x1928 en el valor de la cabecera correspondiente. 
Un fichero cualquiera firmado, y las cabeceras correspondientes. Se ha modificado el tamaño de 1918 a 1928
 Este valor se repite más abajo en el fichero, en la estructura PKCS1_MODULE_SIGN.dwLength, que está dentro del PKCS. Encontrarlo es de nuevo muy sencillo. Se halla justo donde indique el offset de la cabecera Security Directory RVA. Se modifica ahí de nuevo el valor del tamaño. Pasa de de 0x1918 a 0x1928.

En ese mismo archivo (offset 0046c858 indicado por Security Directory RVA) se modifica el valor del tamaño PKCS
Luego, al final del fichero, se añaden los bytes necesarios con el texto o datos que se desee. En este caso, hemos añadido 16 bytes, comenzando por la palabra "ElevenPaths".

Datos añadidos justo al final del fichero, con un editor hexadecimal
Para comprobar que el tamaño del PKCS calculado es correcto, podemos simplemente restar el tamaño final del fichero (hasta dónde llegan nuestros datos añadidos) y el del offset donde comienza el PKCS (el valor de la cabecera). En el ejemplo, 0x46e180 - 0x46c858 = 0x1928. Este resultado debe corresponder con el dato que hemos modificado.

Al comprobar la firma, dirá que todo está correcto, y que no se ha perdido la integridad del binario, aunque lo hemos modificado hasta en tres puntos. Por completar, se podría modificar y actualizar la cabecera del checksum, pero no es imprescindible (Authenticode no lo tiene en cuenta).

Firma correcta del fichero de prueba, aun habiendo modificado hasta tres puntos diferentes.
¿De qué sirve añadir código ahí y por qué lo han corregido?
Esquema de cómo el malware se aprovechaba
de instaladores que acudían al Payload para descargar

Microsoft ha reaccionado a este problema cuando se ha encontrado malware (o al menos, pruebas de concepto) aprovechando el problema. De hecho, parece que fue Didier Stevens quien dio la voz de alarma este año. Encontró instaladores firmados válidos, cuyo código acudía a esa parte extra del fichero no firmado. Ahí habían añadido una URL de la que descargaba otro ejecutable. Este ejecutable descargado ya no estaba firmado.

Así, firmaban una sola vez un ejecutable, pero conseguían que sirviera para muchas instalaciones diferentes. Solo había que cambiar la parte añadida del binario, una URL en el payload, sin volver a firmar (la integridad se mantenía) y apuntar a otra URL donde se descargaba otro código. Firma una vez, instala cualquier cosa. Cómodo... pero peligroso.

El malware, sin embargo, ha visto en este método del instalador una oportunidad de pasar como instalador válido de un tercero, firmado, y descargar malware a su gusto. Ingenioso.

¿Cómo lo han corregido?

El parche MS13-098 comprueba que, tras el bloque PKCS propiamente, no se encuentran datos que no sean diferentes de cero. Si es así, la firma no será válida. Deja abierta la puerta a otros ataques, como reconoce la propia Microsoft, pero dependen ya de una muy mala práctica de los desarrolladores (introduciendo datos no firmados en la propia estructura PKCS...)

Pero este parche no estará activo hasta junio de 2014. Si se quiera activar ya, es necesario realizar un cambio en el registro (añadiendo un REG_SZ en la ruta adecuada con el valor indicado).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1"

En los sitemas de 64 bits, modificar además para binarios compilados nativamente en este arquitectura.

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1"

Y reiniciar. Teniendo en cuenta los problemas criptográficos que tuvo Microsoft con TheFlame a causa de una cadena de errores simples,... debería haber reaccionado antes a este problema y no tardar casi 5 años en solucionarlo.

Sergio de los Santos
ssantos@11paths.com

Eleven Paths con Latch, en la Campus Party de Brasil

$
0
0
Este año es la séptima edición de la Campus Party de Brasil, que tendrá lugar en la Ciudad de San Pablo. Para Eleven Paths será una semana muy particular en la Campus: se organizará un concurso estilo Hackathon en el que se pondrán a prueba las posibilidades de nuestra nueva tecnología Latch. También Claudio Caracciolo, CSA Argentino de Eleven Paths, dará una ponencia junto a Leandro Bennaton sobre CiberSeguridad el día 28.

El hackathon surge ante la intención de Telefónica de generar un espacio de encuentro, diversión y aprendizaje basado en el desarrollo de aplicaciones a partir de la API de Latch para poder ser integrada en distintas plataformas o bien, para darle diferentes usos originales y capaces de aprovechar todo su potencial. El objetivo concreto es la generación de nuevas aplicaciones o implementaciones utilizando la API de Latch (perfectamente documentada en nuestro sitio web) exprimiendo todo el potencial de la herramienta y la imaginación de los desarrolladores que asistan a la Campus Party de este año.

Esperamos que en esta Hackathon se desarrollen aplicaciones diferentes e imaginativas, por eso se han propuesto los siguientes temas, que no son excluyentes:
  • Controlar los accesos de las cuentas de servicios de control remoto a diferentes sistemas operativos, correo electrónico, CRM’s, etc.
  • Activar o desactivar accesos o las cuentas de administración de un router Wi-Fi.
  • Activar o desactivar el broadcast de un SSID en una red Wi-Fi, o directamente encender o apagar la red.
  • Activar o desactivar la llave de arranque de un automóvil, o bien hacer que el coche no pueda arrancarse en un determinado rango horario.
  • Activar o desactivar un cliente de TOR, de VPN, Torrent, o programarlo para que funcione ante determinadas condiciones o en determinados horarios.
  • Habilitar o no, tarjetas de ingreso tipo RFID.
  • Activar o desactivar funcionalidades de otros teléfonos o tabletas. 
Los participantes podrán competir en equipos o en forma individual, los resultados evaluados y habrá interesantes premios para los ganadores:
  • 1er. puesto: Un Portátil de AlienWare
  • 2do. puesto: Una Tablet (Ipad o Galaxy)
  • 3er. puesto: Un Smartphone (Iphone 5 o S/note3)
Los pasos para poder participar en el Hackathon que se desarrollará desde hoy día 27 al 29 de enero serán:
  • Inscribirse en la Campus Party para poder ingresar al evento.
  • Inscribirse para el Hackathon de Latch en https://www.elevenpaths.com/cpbr7
  • Ingresar a https://latch.elevenpaths.com y crearse una cuenta como desarrollador de manera gratuita, si aún no lo había realizado.
  • Leer la documentación de la API
  • Desarrollar en base a las condiciones y a las reglas del Hackathon, que se encuentran disponibles en: http://www.vivo.com.br/campusparty 
Le deseamos suerte a los concursantes y esperamos grandes aportes.

Eleven Paths with Latch, in Campus Party Brazil

$
0
0
This year is the seventh edition of Campus Party Brasil, that will take place in Sao Pablo, Brazil. For Eleven Paths, it will be a very special week in the Campus: a Hackathon will be organized,  where the contestants will put to the test the possibilities of our new Latch technology. Our Argentinian CSA, Claudio Caracciolo, from Eleven Paths, will give a presentation together with Leandro Bennaton about CiberSecurity on January 28th.

Hackathon is born as an intend of Telefonica to generate a meeting, fun and learning place, based on the development of applications from Latch's API, in order to integrate it to other platforms, or to give it different uses taking full advantage of its potential. The target is to generate new applications or implementations using Latct's API, (which is perfectly documented on our website), on purpose to get the most out of the tool and of the imagination of the assistants to Campus Party Brazil 2014

We hope really different applications will be developed at this edition of Hackathon, that is why we have proposed the following topics, not mutually exclusive:
  • Access Control for remote control account services to different operating systems, e-mail, CRM´s, etc.
  • Activate or deactivate accesses to administration account of a wi-fi routers.
  • Activate or deactivate SSID broadcast within a wi-fi net, or just turn on/off the net.
  • Activate or deactivate ignition key of a car, or make sure the car will not be turned on at certain range of hours.
  • Activate or deactivate a TOR, VPN, or Torrent client; or program a schedule in order to make it run under specific conditions or certain hours. 
  • Enable or disable RFID type access cards.
  • Activate or deactivate features of other phones or tablets. 
Participants may compete in teams or individually. The results will be evaluated and there will be great prizes for the winners:
  • 1st. place: AlienWare laptop.
  • 2nd. place: A tablet (Ipad or Galaxy)
  • 3rd. place: A Smartphone (Iphone 5 or S/note3)
The steps to participate in the hackathon that will be held since today, January 27th to January 29th, are:
  • Register for Campus Party to be able to access to the event.
  • Register for Latch Hackathon on https://www.elevenpaths.com/cpbr7
  • Access https://latch.elevenpaths.com and create an account and register for free, if you had not done it before.
  • Read the API documentation.
  • Develope based on the conditions and rules of Hackathon, , available on : http://www.vivo.com.br/campusparty 
Good luck to all contestant. We expect great ideas and contributions.

Intercambio de datos entre páginas: SOP, CORS y WebMessage (y II)

$
0
0
Los navegadores son las aplicaciones más usadas por los usuarios a causa del desplazamiento del escritorio "a la nube" y por la grandes posibilidades que abarcan. La creciente complejidad del navegador ha permitido potenciar sus funcionalidades y (en consecuencia) aumentar los problemas de seguridad y su criticidad. Pero además, ha exigido nuevos métodos de intercambio de información y protocolos. Veamos algunos.


En el desarrollo web actual se pueden llegar a realizar múltiples peticiones AJAX a distintos componentes de la aplicación, como pueden ser gráficas que reciben JSON o un componente de login externoPuesto que SOP puede llegar a ser una política demasiado restrictiva para satisfacer esta demanda en algunos casos, la tecnología CORS nace como solución para compartir recursos con otros dominios sin llegar a poner en peligro la integridad de la información que manejan... siempre y cuando se implementen correctamente.


Usando CORS, se pueden realizar peticiones a otros dominios, como b.com. Fuente: http://linuxism.tistory.com/732
Cross Origin Sharing Resource (CORS) permite al navegador realizar una petición web a otro dominio que no cumpla con la política SOP siempre y cuando el dominio destino agregue la cabecera Access-Control-Allow-Origin, especificando a qué orígenes permite la petición. Por ejemplo:


Access-Control-Allow-Origin: http://www.dominio-tercero.com

Con apenas unas líneas, el navegador será capaz de realizar una petición XMLHttpRequest. Se observa cómo el flag Access-Control entra en juego:

Código JavaScript para realizar una petición XMLHttpRequest
En caso de que el servidor no responda con la cabecera Access-Control-Allow-Origin esperada, el navegador impedirá realizar la petición lanzando una excepción:

Chrome rechaza la petición XMLHttpRequest por no incluir el dominio destino la cabecera Access-Control-Allow-Origin
Por el contrario, si contiene la cabecera Access-Control-Allow-Origin, el código JavaScript obtendrá la respuesta en HTML o XML dependiendo del formato y continuará su ejecución. Como medida de seguridad, también es destacable que la cookie de sesión no se incluirá en la petición si el servidor no añade explícitamente la cabecera Access-Control-Allow-Credentials. De este modo, a menos que el servidor indique expresamente que quiere compartir sus recursos, el navegador no lo permitirá. Por otro lado los dominios que implementen esta funcionalidad añadiendo la cabecera Access-Control-Allow-Origin,permitirán al atacante leer el contenido de la página (lo que implica que además podrá evadir los Anti-Forgery Token que pueda contener la web).

Un posible ataque

Un escenario de ataque en el que el atacante obtuviese el contenido de una web interna y lo reportase, sería el siguiente:

Diagrama funcional de un posible ataque. Fuente: http://application-aegis.blogspot.com.es/2012/06/html5-feature-cross-origin-resource.html

El escenario consta de un servidor web interno que tiene habilitada la cabecera Access-Control-Allow-Origina cualquier dominio representado con el asterisco (*), y una web atacante a la que el usuario accederá.

Una vez el usuario accede al sitio web del atacante, este incluirá una porción de código JavaScript que se ejecutará y provocará una petición XMLHttpRequest al servidor interno:


Código malicioso del atacante
Tras obtener el contenido de la petición, el JavaScript realizará una petición POST al sitio del atacante incluyendo el contenido de la web interna para almacenarlo en el servidor.

Por otro lado, Access-Control-Allow-Origin también permitiría evadir los Anti-Forgery Token. Este impedirá que un atacante pudiese forzar una acción en la web, sin que el usuario se diese cuenta.

Gracias a que CORS comparte el contenido de la página, se podría montar la otra web en un contenedor o un IFRAME y obtener el token haciendo una consulta al árbol DOM o filtrando por expresiones regulares:

Código para obtener el token de verificación
En este caso imprimimos el token, aunque podría usarse para formar una petición con parámetros y con ello ejecutar una acción:
Muestra del token de verificación
CORS es una forma de intercambiar información entre dominios, y esta funcionalidad abre otro vector para permitir que CORS pueda ser utilizado como puerta trasera para enviar información fuera de un dominio. Por ejemplo, en el caso de la existencia de un XSS, podría enviar la cookie de sesión para realizar un hijacking. Sería un comportamiento similar a lo que se ha dado en llamar shell of the future.

En cualquier caso CORS no es la única manera de intercambiar información entre dominios, pues con HTML 5 aparecen más formas que facilitan esta tarea y así nuevos vectores de ataque.

WebMessage

Otra forma de comunicarse entre dominios es WebMessage  que permite mandar y recibir mensajes mediante JavaScript sin necesidad de incluir una cabecera. Para usar esta funcionalidad basta con indicarlo en el JavaScript del "servidor" que recibirá el mensaje con un manejador de eventos y en la parte cliente que enviará el mensaje:

Código JavaScript del servidor para recibir para e imprimir el mensaje
Código JavaScript para enviar el mensaje


Es importante tener en cuenta de que en caso de que el "servidor" no maneje los mensajes, estos nunca llegarán.

Al necesitar un manejador explícito para usar WebMessageno se implementa SOP directamente, por lo que es importante comprobar el origen del cliente, porque si el servidor no comprueba el origen en su lógica, podría ser usado (y abusado) por otros dominios.

Además también es importante comprobar el contenido enviado por el usuario porque podría ser un vector de ataque para realizar un XSS a través de WebMessage:

Ejemplo de XSS preparado con WebMessage


Intercambio de datos entre páginas: SOP, CORS y WebMessage (I)
Oscar Sánchez
oscar.sanchez@11paths.com
Viewing all 1287 articles
Browse latest View live