White Paper: Practical hacking in IPv6 networks with Evil FOCA

viernes, 30 de agosto de 2013

We have released a white paper about practical hacking in IPv6 networks with Evil FOCA. This document describes IPv6 basic concepts, most common IPv6 current attacks and how to implement them with Evil FOCA. It's based on previous works released in Spanish by elladodelmal.com

Contents are: 
  • IPv6 concepts
  • Neighbor Spoofing
  • SLAAC attack with Evil Foca
  • Bridging HTTP (IPv6) - HTTPs (IPv4)
It's uploaded in slideshare, and you can download it. Hope you enjoy it.


Certificate pinning. El qué, el cómo y el porqué (II)

miércoles, 28 de agosto de 2013

Después de aclarar conceptos en la entrada anterior sobre las debilidades de las PKI, el TLS/SSL en general y las soluciones propuestas, veamos cómo han implementado el concepto los diferentes fabricantes.

El cómo... de Microsoft.

Quizás una de las soluciones más interesantes, por simples y sencillas para el usuario. No precisan de cambios en ninguna aplicación o protocolo, y está integrada en una herramienta tan "necesaria", que para los paranoicos no implica instalar nuevo software. Lo que ha hecho Microsoft es integrar la funcionalidad de "certificate pinning" en EMET, una de las herramientas de seguridad más interesantes (en el plano defensivo) que existen. En su versión 4.0, añadieron la posibilidad de "unir" dominios con certificados raíz del repositorio de certificados de confianza del usuario. Fundamentalmente esa es la idea.

El funcionamiento es como el de EMET "de siempre". Internamente inyecta una DLL (EMET_CE.DLL) en el proceso de Internet Explorer (que debe estar protegido por EMET a su vez) y comprueba que el dominio del certificado coincide con la regla establecida. Si no es así, muestra un mensaje. El resto de opciones disponibles permiten no ser tan restrictivo. Por ejemplo, se puede bloquear por algoritmo de hash (si es menor que MD5), o a un país concreto (sería extraño que China fuese el país final en el que confía un certificado emitido para Google, por ejemplo) y así no tener que unirlo a un certificado concreto. En cualquier caso, lo más restrictivo es unirlo a un certificado concreto.

Para añadir reglas, se debe comprobar la cadena de certificación de dominio, buscar el adecuado y efectuar la asociación. Las asociaciones quedarán configuradas en un XML junto al programa. Ya viene preconfigurado con algunos dominios populares. Curiosamente, no aparece Google como regla preestablecida, pero sí Facebook y Twitter. Quedan empate en esta tontería, porque Google (aunque puede solicitarlo cualquiera) tampoco preconfigura nada de Microsoft en el sistema de pinning de Chrome.

Los "problemas"

El hecho de unir certificados raíz con dominios, deja un hueco en los certificados intermedios. Si son modificados, EMET no protegerá la conexión. Esta es su principal desventaja. También que todo ocurre en local y de forma manual. No hay espacio para la actualización dinámica de los dominios u otros certificados. Aunque es cierto que los certificados raíz de la mayoría de los dominios no cambian a menudo.

La alerta que propone EMET no bloquea el sitio, sino que muestra una pequeña ventana emergente. Algo poco apropiado para el usuario final. Los certificados raíz que se pueden enganchar en un dominio para crear reglas, solo se toman del repositorio del usuario, no de la máquina. Esto no es grave pero en entornos corporativos puede complicar la administración.

Es importante señalar que una misma clave pública puede estar firmada por diferentes certificados. Es una práctica habitual de las CA que podría provocar falsos positivos. Pero lo solucionan determinando los certificados por dos vías: una tupla de [emisor, número de serie] (que según el RFC debería ser única) o por el campo "SubjectKey" que es el SHA1 de la clave pública "desnuda" del certificado. Es una decisión diferente a la tomada por Chrome, por ejemplo, que los identifica de otra manera argumentando que usar SubjectKey no es del todo acertado.

También es necesario tener en cuenta que dependiendo del país o de la conexión, la cadena de certificación que "ve" el usuario final puede variar. Por tanto unirlo exclusivamente a un certificado raíz puede dar pie a falsos positivos.

La configuración

Es sencilla. Esta imagen resume la secuencia necesaria para añadir Google. Hay que consultar el certificado, comprobar cuál es el raíz en el que confía finalmente la conexión, mirar su huella digital y añadirla como regla encontrando el certificado en el repositorio.

Resumen de la configuración de una regla para Google.es
En caso de error, la ventana que aparece es la siguiente:
Pequeña ventana emergente que aparece cuando no casan los certificados y dominios definidos. También se registra un evento en el sistema.
La apuesta de Microsoft es simple y fácil de implementar pero queda fuera de su navegador, en un programa externo muy útil pero francamente poco popular hoy en día (aunque personalmente creo que evolucionará hasta formar parte integral del sistema operativo). Teniendo en cuenta que otros han elegido integrarla directamente en el navegador, no se sabe si esto quiere decir que se trata de una "tímida" apuesta por el "pinning" en Microsoft, o que han sacado esta solución mientras preparan algo más elaborado integrado en Internet Explorer
Sergio de los Santos

Certificate pinning. El qué, el cómo y el porqué (I)

lunes, 26 de agosto de 2013

Últimamente se usa mucho este concepto. Las muestras de debilidad de las PKI y el TLS/SSL en general, han llevado a pensar soluciones contra este problema que pone en riesgo las entrañas del cifrado en la red. Certificate pinning no es un método, sino solo eso, un concepto que cada uno interpreta a su manera. Aclaremos conceptos.

Por qué

Porque SSL tiene (entre otros) un claro punto débil: la cadena de certificación. Cuando se visita una web bajo SSL, se producen una serie de muestras de confianzas en cadena, normalmente con tres pasos:
  • El dueño del dominio configura su servidor para que él y sólo él disponga del certificado asociado a ese dominio. El usuario que lo visita confía en que ha acudido al dominio correcto y que el certificado que se le presenta, está aprobado por una CA válida. Sería como pedir el DNI a una página web, y comprobar que el Estado lo ha validado.
  • Pero no lo ha validado el Estado directamente. Ese certificado es aprobado por una autoridad certificadora intermedia, en la que la CA raíz delega (por segregación y seguridad) la firma de certificados de terceros. Esta autoridad firma la relación entre el dominio y el certificado.
  • En las autoridades se confía porque lo dice tu navegador. Poco más. Vienen preconfigurados con una serie de certificados raíz en los que se confía.
Cadena de confianza habitual de Google
Cadena de confianza alterada. No se confía en la CA que se supone ha emitido ese certificado.

Los puntos débiles son obvios y se han dado casos de todo tipo.
  • Gobiernos o empresas que han introducido entidades intermedias. Se desvía el tráfico y se introducen servidores intermedios en los que las autoridades certificadoras confían. Los servidores intermedios pueden descifrar y cifrar el tráfico de forma transparente para el usuario, y la cadena de confianza queda "intacta", aunque con más pasos. En enero de 2013 se supo que Nokia descifraba en sus servidores el tráfico SSL de sus teléfonos. Se sospecha que ciertos gobiernos también puede estar interceptando comunicaciones cifradas entre su población.
  • Si se comprometen las certificadoras raíz o intermedias, un atacante podría crear certificados para cualquier dominio, y firmarlos. Si al usuario se le desvía el tráfico (por envenenamiento DNS, pharming, etc) y acaba en ese dominio, la cadena de certificados seguirá aparentemente igual. La CA delega en la CA intermedia y esta en el certificado. Esto ha ocurrido a niveles preocupantes. El caso Diginotar (agosto 2011), Comodo (marzo 2011) y TURKTRUST (enero de 2013) son los más sonados.
La lista de certificados en los que no se confía ha crecido bastante en los últimos años
Entendemos entonces que el problema es que los certificados finales o intermedios pueden cambiar y el navegador del usuario no mostrará ninguna advertencia, puesto que la cadena de confianza se ha modificado, pero no se han "roto". El atacante ha podido firmar certificados para dominios que no le pertenecen, introducir sistemas intermedios, o incluso alterar los certificados raíz en los que confía máquina... pero todo viene a ser lo mismo: la cadena de confianza alterada. Y eso debe levantar siempre sospechas, porque los certificados de dominios no suelen modificarse a menudo. ¿Por qué no recordar esas cadenas de confianza y alertar al usuario cuando se modifiquen?

El qué

Esta es la idea detrás del certificate pinning. Ahora es necesario implementar el concepto. ¿Cómo hacerlo? Por ahora no hay ningún estándar globalmente aceptado. Los navegadores más populares están tomando caminos diferentes, construyendo encima de lo que ya existe, sin querer modificar demasiado ningún protocolo. Pero también hay propuestas más profundas, que involucran algún cambio más o menos importante alrededor:
  • Por otro lado andan Moxie Marlinspike y T. Perrie que han propuesto hace tiempo una extensión al propio protocolo TLS para permitir el "pinneo" de certificados. Se llama TACKS (Trust Assertions for Certificate Key).
  •  DNS-Based Authentication of Named Entities es un RFC que habla de asociar TLS a los dominios en cierta manera. Requiere modificar el DNS.
  • HSTS junto con la incrustación en el código, es el camino tomado por Google y Chrome. HSTS Requiere, en cierto modo, un cambio en HTTP, pero ya está en marcha en sus navegadores y no se centra tanto en el "pin" sino en la obligación de usar SSL.
Y luego está la propuesta de EMET y por tanto de alguna manera, el camino tomado por Microsoft. EMET (que viene siendo imprescindible) es el único que no requiere ningún cambio en el navegador o protocolo, lo que no significa que sea el mejor... aunque cómodo, sufre sus limitaciones.

Así el asunto, veremos en próximas entregas cómo están funcionando ya Chrome e Internet Explorer, estudiando sus propuestas.



* Certificate pinning. El qué, el cómo y el porqué (II)
* Certificate pinning. El qué, el cómo y el porqué (III)
* Certificate pinning. El qué, el cómo y el porqué (IV)



Sergio de los Santos

Extended Validation Certificate (EV SSL): Cómo funciona técnica y socialmente

miércoles, 21 de agosto de 2013

Se supone que EV SSL es una "mejora" del uso de certificados en conexiones TLS/SSL. Visto de otra forma, se trata de un intento de enmendar algo que la propia industria de las CA (en combinación con los navegadores) había roto, y  es la confianza en las comunicaciones cifradas. De paso, consiguieron hacer algo más de caja.

En 2005, Melih Abdulhayoglu de Comodo fundó CA/Browser Forum, con el objetivo de mejorar los estándares del SSL a través de sus dos actores principales: las autoridades certificadoras y los navegadores. Dos años después ya estaba propuesta la primera versión del estándar Extended Validation Certificate (EVSSL). Por aquel entonces (e incluso ahora continúa esa inercia), se habían dado varias circunstancias para que el SSL no estuviese ofreciendo todas las soluciones que se esperaban de él.
  • Los navegadores (en aquel momento, Internet Explorer fundamentalmente) no mostraban coherentemente que una conexión a una página estaba cifrada o autenticada. El fallo venía en parte del hecho de que, en un intento de diversificar el negocio, las CA comercializaron certificados automáticamente a un usuario solo por poseer un dominio, sin mayores comprobaciones.
  • Por otro lado, el navegador trataba (y mostraba) igual la seguridad de esta web que la de otros certificados en los que se habían tomado mayores precauciones. Los usuarios se hacían un lío. ¿Es seguro el candado o no? El famoso "candado" podía aparecer en cualquier web por muchas razones, y terminó por no garantizar la seguridad del sitio, por no significar nada. Las advertencias por conexiones no cifradas también eran ridículamente "débiles" y poco informativas.

  • Comenzaba un verdadero boom de la banca online, y se precisaba de una seguridad especial para estos casos tan potencialmente peligrosos.
Así que pensaron que sería mejor "dar un salto" y ofrecer certificados más caros, con mayores controles de comprobación de identidad, y que se mostraran de otra forma en el navegador para diferenciarlos del resto. En resumen, hacer por fin lo que debía haber conseguido desde el principio el certificado TLS/SSL. Técnicamente, para ello se siguen varios pasos.

Comprobar la identidad

Las CA cobran más por este tipo de certificado, pero también realizan unas comprobaciones más exhaustivas sobre la empresa para saber si realmente es lícita y quien dice ser. Llamadas por teléfono, documentación, etc.

Una extensión al certificado

Estos certificados cuentan con un valor especial en las extensiones que permite la versión 3 del estándar X509. Las CA, a la hora de generarlos, pueden definir cualquier extensión que se añadirá al certificado y por supuesto, darles diferentes valores (en forma de OIDs). Si montásemos nuestra propia CA que emitiese certificados EV, en el caso de usar OpenSSL se añadiría lo siguiente en openssl.cfg.

Parte de la configuración de OpenSSL para generar certificados EV, por ejemplo
Que resultará en un certificado con el campo Certificate Policies, o "directivas de certificado" con el valor establecido como sigue:

Certificado EV donde se muestra el valor que hace que un certificado sea "EV" para el navegador
El ejemplo propuesto son los valores reales que utiliza VeriSign.

El navegador lo interpreta

El navegador, en su código, comprueba el valor OID de ese campo. Si coincide con los que tiene en su código, cambiará la forma de mostrar la barra de direcciones, añadiendo ese color verde intenso que parece "garantizar" mejor la comunicación.

Las CA no utilizan un mismo OID y cada marca utiliza uno diferente. La lista "no oficial" de OIDs y fabricantes está en la Wikipedia. Por ejemplo, en el código fuente de Chromium se puede observar claramente el valor del OID de VeriSign, XRamp Global CA....

Código de Chromium que valida certificados EV. Fuente: http://src.chromium.org/chrome/branches/250/src/net/base/ev_root_ca_metadata.cc
En resumen, EV SSL es un intento de volver "al origen" de lo que siempre debió ser SSL, pero que se "corrompió". El estándar ha tenido un éxito aceptable, es reconocido y aceptado por la industria y los navegadores... pero ¿lo entiende el usuario?


Sergio de los Santos
@ssantosv

Un ataque, 5 errores

lunes, 19 de agosto de 2013

Hace pocos días se ha dado a conocer que el popular periódico Washington Post sufrió un ataque coordinado y su web fue comprometida. Lograron redirigir a los visitantes a una página panfletaria. Se sabe que un simple phishing a ciertos reporteros ha supuesto una parte del origen del problema. Nada fuera de lo común, pero después del incidente cabe reflexionar, ¿cuántos errores en cadena se han cometido y cómo se podría haber evitado?

El autodenominado grupo de atacantes Syrian Electronic Army, consiguió tomar cierto control de la web del  prestigioso periódico. La propia cabecera admitió que una parte del ataque comenzó el robo a un reportero de deportes la cuenta de correo a través de una simple falsificación del portal interno de Outlook. ¿Qué errores se esconden tras este incidente?

1) Como todo ataque, comenzó con algo de investigación. Los atacantes recopilaron nombres y cuentas de correo de reporteros (al parecer los que disponían de cuenta en Twitter). A estos les enviaron correos personalizados "que parecían venir de colegas de trabajo" invitando a introducir su contraseña de email puesto que al parecer la sesión había "expirado". Aunque en algunos casos sea inevitable, conviene controlar en lo posible la fuga de información sensible que pueden suponer datos como el correo,  nombres o direcciones URL internas que se pueden filtrar a través de diversos medios, como metadatos, cuentas personales de trabajadores en redes sociales... Esta es una asignatura pendiente para muchas empresas, que facilitan la labor de investigación previa de muchos atacantes.

2) Como se puede apreciar en la imagen del ataque real, el correo llevaba a un phishing normal y corriente (no es "sofisticado" como lo califican desde el Washington Post), donde se falsifica a través de un dominio de tercer nivel (site88.com) la dirección del periódico.

Fuente: http://krebsonsecurity.com/2013/08/washington-post-site-hacked-after-successful-phishing-campaign/

El dominio real que se pretende suplantar se puede apreciar en esta otra imagen:



Aunque no se ha dado a conocer el contenido del correo enviado en primera instancia que invitaba a visitar el enlace, es más que probable que también falsificara el dominio de procedencia, haciendo creer que venían de otros compañeros. Se sabe que se enviaron en una segunda ronda, correos desde una cuenta ya robada. Aquí los errores son claros y variados. Washington Post (como la mayoría)  no utiliza DKIM y ni siquiera es muy restrictivo a la hora de usar SPF (no bloquea por defecto, sino que deja la elección al cliente).


... puede que técnicamente se pudiese haber evitado que el primer correo llegara a los buzones de los usuarios. Al menos esa primera ronda que proviene de un tercero (una vez que una cuenta es robada, no hay forma de evitar que el atacante la use para enviar nuevos correos aún más creíbles). En todo caso, una vez el correo está en el buzón de entrada, quizás lo más importante es que los administradores tampoco han "entrenado" a sus usuarios para no caer en este tipo de estafas simples (correos que redirigen a enlaces que piden credenciales) aunque parezcan provenir de compañeros.

3) Ya con la web falsa mostrada en el navegador, la víctima no comprueba que el acceso no se hace cifrado, ni por supuesto, el certificado. El SSL, socialmente roto, es otra de las grandes asignaturas pendientes para los usuarios. Entrenarlos y ayudarles en este sentido es algo muy necesario.

4) Con la contraseña del correo de la víctima en las manos, el atacante probablemente, ya podría haber publicado en la web oficial como si de un editor se tratara. Sin embargo, la versión oficial salta (sin relación aparente con el phishing perpetrado previamente) a un problema de un tercero para justificar el ataque a su web. Parece que el phishing se utilizó solo para acceder al Twitter de algunos editores y el ataque a la web es en realidad un acto "complementario" al ataque. Washington Post utiliza Outbrain, una red de publicidad que se encarga de sugerir al lector otros temas y artículos en los que puede estar interesado. Outbrain reconoce un problema de seguridad, que fue comprometida, y que eso explica por qué consiguieron atacar a la CNN, y la revista Time "de un solo golpe" (también usan Outbrain).

Por tanto (aunque en un principio no quedaba claro) parece que no hubo relación entre el problema de seguridad en Outbrain que condujo a la redirección en la web y el robo de credenciales de ciertos redactores o editores. En otros escenarios, lo habitual hubiese sido (simplificando):
  • Se podría haber utilizado algún sistema de "recordar contraseña" a través del correo ya robado para obtener el acceso tanto al Twitter de sus editores como quizás a algún componente de la web manejada por los editores. Nunca se debe devolver el dato en texto claro en un correo, sino que se debe obligar a la generación de una contraseña nueva, y que este hecho sea notificado inmediatamente al administrador.
  • El usuario podría utilizar la misma contraseña para el correo que para editar en la página. Esto debe estar prohibido por políticas. 
  • El atacante, haciéndose pasar por el legítimo dueño de la cuenta de correo, podría haber solicitado acceso especial para publicar en la web (ingeniería social). 
5) Finalmente, es probable que atacante escalara privilegios o eludiese restricciones para poder controlar artículos en la web gracias al fallo de seguridad en Outbrain. En cualquier caso, una auditoría previa interna de su web, tipo "caja blanca" podría haber facilitado el descubrir lo antes posible la vulnerabilidad y solucionar previamente el fallo.

Conclusiones

Puede resultar muy aventurado deducir cómo ocurrió un ataque sin manejar los datos reales, sin embargo, esta estructura básica de errores en cadena expuesta con el caso del Washington Post de fondo, resulta el escenario más habitual en la mayoría de los ataques.

El phishing poco sofisticado sigue siendo una herramienta eficaz y muy usada para cumplir los objetivos de los atacantes. El usuario, su desconocimiento, las tecnologías que no se entienden y la falta de políticas estrictas por miedo a incomodar al propio usuario, son el cóctel perfecto para que cualquiera que sepa clonar una página, pueda conseguir unas credenciales valiosas para realizar otros ataques más dañinos.

Sergio de los Santos

Information leakage in Data Loss Prevention leader companies

viernes, 16 de agosto de 2013

Gartner has released a study that classifies the most important companies that offer Data Loss Prevention (DLP) solutions depending on their position, strategy, effectiveness, and market leadership. We have made a little experiment to test if these same companies control metadata leaks in their own services, as a potential sensible data leak point.

According to the "Magic Quadrant for Content-Aware Data LossPrevention" research made by Gartner in 2014 over 50% of companies will use some kind of DLP-solution to keep their private data safe but only 30% will use a content based solution. 

This same research lists which are the leading companies in terms of data loss prevention establishing a scale based on factors such as Content-Aware proportioned DLP, DLP-Lite products and if a DLP channel is available for the user to clarify doubts about regulatory compliances, for example.

This study made by Gartner determines which are the leader companies when preventing leaking information, establishing as measurement factors to generate leadership indicators as: provided content-aware DLP solutions, DLP-Lite products offered or if they provide a DLP channel to the user so he can clarify doubts about compliments, for instance.
Data Loss Prevention leading companies, by Gartner
Do these companies avoid information loss through metadata in their systems? We conducted an analysis of the main web pages of these aforementioned companies that were included in Gartner’s study using MetaShieldForensics. Metashield automatically downloaded and analyzed every document exposed on the corporative webs of the companies.
The following table displays the results. Every single company leaks metadata associated to their public documents that are being exposed on the Internet. Seemingly these documents are not being cleaned and are therefore a potential private information leaking point that is to be taken into account.

Information leakage exposed by companies that provide DLP tools and services
Based on this information we proceded to graph the data showing the amount of information being leaked by the studied DLP companies. Logically the companies that most suffer of information leaks also have more publicly available documents in their web pages.
Information leakage exposed by companies that provide DLP tools and services
Names or account names followed by internal directories where the documents were created are the most commonly leaked pieces of information. Another usual leak is the the software version being used when generating the document. This group of information is valuable for a potential attack.
Let’s see some details about the leaked information:
  • Users and user accounts: The internal usernames and their mail accounts are very noteworthy. This information can help the attacker to forge a more complex and sophisticated attack.
  • Paths to internal web services: Some of these provide valuable information about the internal network. For example, one of the documents contained an URL that points to an OpenNMS portal (http://159.36.2.25:8980/opennms/event/.../). OpenNMS is offered by Symantec as a solution for network administrators for controlling critical services in remote machines.
  • Internal user directories: The most common directories that are found contain user information in default paths such as “Desktop, My documents…”. For example, “C:\Documents and Settings\holly_waggoner\M20Documents\****** Web\press\2004\” was detected in one of the DLP companies.
  • Network printers: This is also a very common leak. Network printers that expose information about their exact model and the server they’re associated with (either name or internal IP address).
  • Software used by the company: It is very common to leak the software being used by the company for generating a document. The most common piece of information refers to PDF documents which are very popular for publications.
  • Other metadata that exposes private information: A rather unusual but curious case is custom metadata generated in some documents which can result in a much more relevant leak than one can think at first sight. For example, properties like the subject of a specific email, an attachment or to whom it was sent can expose clues and evidence of internal business strategies like relations between companies or workers.

Conclusions
Metadata may still be widely unregarded when controlling information flow exposed on corporative webpages or simply sharing documents..
Information leak can happen at very different levels and in different ways. Document loss, non-controlled publication and non-intentioned document exposing is indeed a clear example of a problem to be avoided, however document metadata can’t be despised either, specially by a company that offers data loss prevention solutions.
Metadata and information leak shall not be regarded as a singular incident that only provides an attacker a document, an email or sensitive data. It’s also a process that a determined attacker will invest his time into. Depending on the implemented solutions and how protected the company is the attacker will gather all possible information taking advantage of every single leak (as inconsequential as they may seem) for getting to know his target and forging an attack.
The companies that offer solutions against information loss should take it into account in their own products. For example, erasing of metadata is a compulsory task for the Civil Service according to the "Esquema Nacional de Seguridad" (National Security Scheme) and LOPD. MetaShield Protector is a solution that some of them chosed.

Rubén Alonso Cebrián
ruben.alonso@11paths.com

Fuga de información en empresas líderes en Data Loss Prevention

jueves, 15 de agosto de 2013

Gartner ha publicado un estudio en el que clasifica a las empresas más importantes que ofrecen soluciones de prevención de fuga de información (Data Loss Prevention o DLP) según su posición, estrategia, eficacia y liderazgo en el mercado. Hemos realizado un pequeño experimento para comprobar si estas mismas compañías controlan la publicación de metadatos en sus propios servidores, como potencial punto de fuga de información sensible.
Según el estudio Magic Quadrant for Content-Aware Data Loss Prevention realizado por la consultora Gartner, en el año 2014 más del 50% de las empresas utilizará alguna característica en sus políticas de seguridad a la hora de realizar una prevención de fuga de información (Data Loss Prevention) en sus datos sensibles. Sin embargo sólo el 30% de estas dispondrá de una solución o estrategia DLP global basada en el contenido.
El estudio realizado por Gartner determina cuáles son las empresas líderes a la hora de realizar prevención de fuga de información, estableciendo como factores de medición para generar el liderazgo indicadores como las soluciones empresariales Content-Aware DLP proporcionadas, los productos DLP-Lite ofertados o si proporcionan un canal DLP para aclarar al usuario dudas respecto a determinados cumplimientos regulatorios, por ejemplo.
Gráfico de las empresas líderes en Data Loss Prevention, según Gartner
¿Evitan estas empresas la fuga de información a través de metadatos en sus propios sistemas? Con MetaShield Forensics, se ha realizado un análisis al frontal web principal de estas compañías que aparecen en el estudio. MetaShield se ha encargado de descargar y analizar los documentos públicos expuestos en la web.
Los resultados se muestran de manera genética en la siguiente tabla. Todas las empresas estudiadas cuentan con metadatos asociados a los documentos públicos que exponen en internet. Parece que estos documentos no están siendo sometidos a ningún proceso de limpieza y, por  tanto, son susceptibles de convertirse en un punto de fuga de información confidencial que es necesario tener en cuenta.
La siguiente tabla muestra en datos brutos, la pérdida de información expuesta por cada una de las empresas de seguridad.
Total de fuga de información expuesta por las empresas que proporcionan herramientas y servicios DLP
En función de la tabla anterior, se ha procedido a realizar un nuevo gráfico mostrando la cantidad de fuga de información producida por las empresas DLP estudiadas. Lógicamente, las entidades analizadas que sufren más fuga de información a través de los metadatos son las que también exponen un mayor número de documentos públicos en sus sitios web. 
Fuga de información expuesta por las empresas que proporcionan herramientas y servicios DLP
La información que se filtra en mayor número de ocasiones a través de los metadatos son en general los nombres o cuentas de usuario, seguido de los directorios internos desde donde se generaron los documentos. También es muy habitual encontrar las versiones de software concreto usadas para su generación. En conjunto, información valiosa para un potencial atacante.
Veamos algunos detalles sobre la información expuesta:
  • Usuarios y cuentas de correo de usuario: Los usuarios internos y sus cuentas de correo constituyen una de las fugas de información más llamativas. Exponer información de este tipo puede facilitar al atacante la elaboración de ataques más sofisticados.
  • Direcciones a servicios web internos: Tanto web como locales, algunos de los directorios expuestos proporcionan información valiosa sobre los sistemas de gestión internos utilizados por las entidades. Como ejemplo, se ha encontrado entre los metadatos de uno de los documentos, la URL que apunta a la solución OpenNMS (http://159.36.2.25:8980/opennms/event/…/) de la compañía Symantec. Se trata de una solución utilizada por administradores de red para controlar servicios críticos en máquinas remotas.
  • Directorios internos de usuarios: Los directorios más comunes localizados son aquellos que se generan asociados al perfil de usuario de los equipos de trabajo, donde se puede identificar al propio usuario a través de las típicas rutas establecidas en determinados sistemas (como la que se establece a las carpetas personales tipo Escritorio, Mis documentos, etc.). Como ejemplo C:\Documents and Settings\holly_waggoner\M 20Documents\****** Web\press\2004\ es detectada en una de las empresas DLP.
  • Impresoras de red asociadas a servidores de impresión: Es otra de las fugas de información más comunes detectadas. Impresoras de red que exponen información sobre su modelo y tipo, así como sobre a qué servidores se encuentran asociadas (ya sea mostrando su nombre o dirección IP interna).
  • Software utilizado por la organización: Otro dato que puede considerarse fuga de información consiste en los datos acerca de los elementos de software utilizados por las organizaciones. La fuga de información más común encontrada en la categoría de software es aquella que hace referencia al tipo de software utilizado a la  hora de generar los archivos PDF, al tratarse de uno de los formatos más utilizado para publicar en entornos web.
  •  Otros metadatos que proporcionan información sensible: Un apartado curioso al analizar los metadatos de los archivos son esas propiedades personalizadas que muchos ficheros exponen, y que de tanto en tanto, son detectadas proporcionando una fuga de información más relevante de lo que en un principio pudiera sospecharse. Propiedades como el asunto de un determinado correo donde se ha adjuntado un archivo o a quién fue enviado, pueden ofrecer pistas sobre las estrategias internas de negocio de una organización, como puedan ser relaciones entre empresas o profesionales.

Conclusiones
Quizás los metadatos siguen siendo uno de los grandes olvidados a la hora de controlar el flujo de información expuesto en las páginas corporativas o simplemente en el momento de compartir documentos.
La fuga de información puede producirse a diferentes niveles y a través de muchos frentes. Si bien la pérdida, publicación no controlada o exposición no intencionada de documentos supone un claro ejemplo de problema que debe ser evitado, la fuga de metadatos de los documentos (aunque sean públicos) no deben ser menospreciados, especialmente en compañías que ofrecen soluciones para controlar la fuga de información.
El proceso de fuga de información no debe observarse como un único incidente aislado que permite a un atacante obtener un documento, correo o información sensible. También es un proceso al que un atacante dedicará un tiempo (determinado por su motivación) para concluir un ataque. Durante este estudio del objetivo (y dependiendo de las soluciones que implemente y lo protegida que se encuentre la entidad) el atacante recopilará toda la información posible sobre la compañía aprovechando todo tipo de fugas (por pequeñas que pudieran parecer) para conseguir conocer en profundidad el objetivo y perpetrar un ataque dirigido.
Las empresas que comercializan productos contra la fuga de información, deberían tenerlo en cuenta también en sus propios sistemas. Por ejemplo, es una práctica que ya está contemplada y que es de obligado cumplimiento para administraciones públicas según el Esquema Nacional de Seguridad o la LOPD.

Rubén Alonso Cebrián

Mobile banking and banking trojans

martes, 13 de agosto de 2013

During 2012 there was an increase around 28% in mobile banking or M-Banking operations. Users can access their bank accounts from their mobile devices, mainly making use of a specifically created banking access applications. What benefits and problems bring us this new way of interacting with banks?

Source: http://qz.com/79818/why-you-should-access-online-banking-on-your-smartphone-rather-than-your-computer/
Specific applications for accessing banks accounts (downloaded mainly from official app stores like Apple Store or Google Play for the sake of security and availability) ease our access making it quicker and avoiding  in some way phishing attacks, that are more common in a "browser and link" environment.

But the use of this kind of applications involve other risks. Apps are supposed to be reviewed, tested and analyzed before making them available for users. Among other measures, Google Play uses “Bouncer”, an automatic system to dinamically analyze applications before making them public. Unfortunately it does not avoid this official shop hosting quite a lot of malware for these devices, hidden in legitimate applications as well as in applications which simulate belonging to real bank entities but only steals credentials. Apple Store implements a better protection, because of its policy being much more restrictive when allowing an application to be uploaded to the store.

So far, we have seen applications which simulate to be an official application, necessary to operate with a bank from a mobile device. These are usually offered from fraudulent repositories or from the official store (during a short time, until it is detected). But there are other ways. Although not too many cases of this kind has been detected, malware previously hosted in the device could try to steal information from the legitimate bank application. For infecting the device in first place, the user has to install an application that contains malware or that "is" malware, although it may come from an email attachment, or even an infected PC. Then, it would be enough to get keystrokes or network data sent by the legitimate application.

The guilty ones
Zeus (Zbot) malware with its multiple variants, is the most popular baking trojan. Programmed in C++ (and PHP for its "server" side) it was first seen during 2007 and supposed a real revolution in malware's world, given its specialization and ability to obtain bank credentials while in Windows boxes. It has evolved during time, adapting and getting better to avoid new security systems.

Zeus could be purchased in black market for 2500-3000 €, providing a complete information arsenal for "learning to steal". Aside, scammers may buy additional modules to improve funcionality or even use it as a service, renting infected botnets. In 2011 its source code was leaked, generating some other versions manteined by "the community". SpyEye is a very popular banking trojan too, with quite a lot of plugins and advanced funcionality.
Zeus based malware is constantly improving, trying to make money selling the product. As an example, a new variant of banking malware "as a service" that showed up in 2013 is "KINS" (Kasper internet non security) developed from Zeus and adding SpyEye features.
Source: https://blogs.rsa.com/is-cybercrime-ready-to-crown-a-new-kins-inth3wild/
Malware and phones

While security in online banking improves, integrating the cell phone as a second factor authentication, malware (specially Zeus and its variants) had to adapt and infect as well these devices. So, the term "MitMo" (Man in the mobile) was established for a kind of Zeus variant that tried to avoid online bank security by infecting smartphones as well and, obtaining in this way the SMS used for authentication. The user (with her PC already infected) is asked to download and execute an application for his smartphone. This malware for mobile devices has to work together with the trojan infecting the victim's system. By themselves, they are not expected to specifically steal bank information while in the smartphone.

But new variants for Android have been spotted, specifically designed for stealing users from a particular bank. Kaspersky has alerted about a malware that, aside from stealing all kind of information from the smartphone itself, it is able to communicate via POST commands to a C&C server. But the most interesting feature is that it is specifically programmed to obtain the bank account balance for users registered with Sberbank Russian bank (sending a SMS to a free number available for their clients). It also intercepts every SMS and calls related to this bank. So this may be considered the first approach to a basic feature in PC banking trojans, that have been programmed long ago sepecifically for every bank.

Source: http://www.securitylab.ru/news/442700.php
At the moment, it has been only detected in Russia, cradle (among other Eastern countries) for most of the sophisticated banking trojans.

Antonio Bordón Villar

Banca móvil y troyanos bancarios

Durante 2012 se produjo un incremento del 28% en la banca móvil o M-Banking. Los usuarios acceden a sus cuentas bancarias desde sus dispositivos móviles, principalmente a través de una aplicación creada específicamente para el acceso a la entidad bancaria. ¿Qué beneficios y problemas nos trae este nueva forma de interactuar con las entidades bancarias?

Fuente: http://qz.com/79818/why-you-should-access-online-banking-on-your-smartphone-rather-than-your-computer/
¿En qué nos beneficia M-Mobile?

Las aplicaciones específicas de cada entidad (descargadas generalmente desde las tiendas de aplicaciones oficiales, como la App Store de Apple o Google Play de Android por seguridad y disponibilidad)  facilitan el acceso a nuestras cuentas de una manera más rápida y directa evitando en cierta manera el riesgo de phishing que podría resultar del uso del navegador y enlaces.

Pero el uso de aplicaciones conlleva otros riesgos. Se supone que las apps se someten a una serie de pruebas y análisis antes de estar disponibles para el público. Entre otras medidas, Google Play utiliza "Bouncer", un sistema que analiza dinámicamente las aplicaciones antes de hacerlas públicas, pero que no ha evitado que la tienda oficial aloje una buena cantidad de malware para el dispositivo, camuflado tanto en aplicaciones legítimas como en programas que simulan ser de una entidad bancaria y que solo pretenden robar credenciales. La Apple Store se encuentra mejor protegida en este aspecto, por su política mucho más restrictiva a la hora de permitir subir una aplicación a la tienda.

Hasta ahora, se han dado casos de aplicaciones que simulan ser los programas oficiales necesarios para operar con una entidad bancaria. Estas se ofertan habitualmente desde repositorios fraudulentos o desde la tienda oficial (durante un corto espacio de tiempo en cuanto consiguen detectarla). Pero hay otras fórmulas. Aunque no se han dado muchos casos de este tipo, el malware previamente alojado en el dispositivo también podría llegar a robar la información de la aplicación bancaria legítima. El método para infectar el dispositivo en primer lugar suele ser la instalación de una aplicación que contiene el malware o que "es" el malware, aunque también puede venir desde un adjunto de un correo electrónico, o incluso a través de un PC infectado. Luego, bastaría con acceder a los datos tecleados, o que viajan por la red generados por la aplicación oficial.

Culpables
El malware Zeus (Zbot) con sus múltiples variantes es el troyano bancario más popular. Programado en C++ (y PHP su parte "servidor") fue descubierto inicialmente en 2007 y supuso una verdadera revolución en el mundo del malware, dada su especialización y habilidad para obtener credenciales de la banca online en un Windows. Ha ido evolucionando con el tiempo, adaptándose y mejorando para eludir los nuevos sistemas de seguridad.
Zeus se podía conseguir en el mercado negro con un coste aproximado de 2500 – 3000€ proporcionando un completo arsenal de información y manuales para "aprender a robar". Aparte, los estafadores pueden comprar módulos adicionales para mejorar la funcionalidad o incluso usarlo como servicio, alquilando botnets de sistemas infectados. En 2011 se filtró su código fuente, dando lugar a otras variantes mantenidas por "la comunidad". SpyEye es también un malware bancario muy popular, con una buena cantidad de plugins y funcionalidades muy avanzadas.
El malware basado en Zeus está en continuo movimiento y mejora, en un intento de hacer caja con la venta del producto. Como ejemplo, una nueva variante de malware bancario "as a service" aparecido en 2013 es “KINS” (Kasper internet non security) desarrollado a partir de Zeus y añadiendo mejoras de SpyEye. Se puede adquirir en el mercado negro y se espera que cubra el hueco dejado por sus antecesores y aproveche un trozo del "mercado".
Fuente: https://blogs.rsa.com/is-cybercrime-ready-to-crown-a-new-kins-inth3wild/
Malware y teléfonos

A medida que avanzaba la seguridad en la banca online, integrando el móvil como segundo factor de autenticación, el malware (en especial Zeus y sus variantes) tuvo que adaptarse e infectar también estos dispositivos. Así, se instauró el término "MitMo" (Man in the mobile) para un tipo de variante de Zeus que intentaba eludir la seguridad de la banca online infectando también el teléfono y, con ello, los SMS usados como fórmula de autenticación. El usuario (ya infectado en su PC) es instado a descargar una aplicación en el móvil. Este malware para móvil debe funcionar en conjunto con el troyano que se aloja en el sistema de la víctima. Por sí solos, no están destinados específicamente al robo de información bancaria en el móvil.

Pero ya se han observado variantes de malware para Android específicamente diseñadas para robar a usuarios de un banco en concreto. Kasperksy ha alertado sobre un malware que, además de robar todo tipo de información del teléfono, es capaz de comunicarse a través de comandos POST con un C&C. Pero lo más interesante es que contiene código específicamente diseñado para obtener el balance del usuario si este está registrado con el banco ruso Sberbank (enviando un SMS a un número gratuito a disposición de sus clientes). También intercepta todos los SMS y llamadas relacionadas con ese banco, lo que supone un primer acercamiento a una funcionalidad básica de los troyanos bancarios para PC, que desde hace tiempo están programados específicamente para cada banco.
Fuente: http://www.securitylab.ru/news/442700.php

De momento solo ha sido detectado en Rusia, cuna junto a otros países del Este de gran parte del malware bancario más sofisticado.

Antonio Bordón Villar

(re) Introducing Evil Foca (DEFCON Edition)

miércoles, 7 de agosto de 2013

Evil Foca was introduced in early April, as a tool to make local networks pentesters and auditors life easier. In a simple way and with a very simple interface too, it allows to automate different attacks, showing how insecure local networks may be "indoors". Among them:
  • Man In The Middle (MITM) over IPv4 with ARP spoofing.
  • MITM over IPv4 with DHCP ACK injection.
  • MITM over  IPv6 with Neighbor advertisement spoofing.
  • MITM over IPv6 with SLAAC attack.
  • Rogue DHCPv6 attacks.
  • DoS (Denial of service) over IPv4 with ARP spoofing.
  • DoS over IPv6 with SLAAC DoS.
  • DNS Hijacking.
Even more, during DEF CON 21, celebrated a few days ago in Las Vegas, a new version of Evil FOCA (DEFCON Edition) was introduced. The main feature added for this version is the implementation of a full automated Web Proxy Auto-Discovery attack.


This presentation, quite successful according to some witnesses, showed live what you can get with IPv6 (enabled by default in Windows) MITM attacks, and how easy it is to leverage protocol vulnerabilities with Evil Foca.
IPv6 attacks with Evil Foca. New version does not include ads
Slides are available here:


You can now download Evil Foca from here: http://www.informatica64.com/EvilFoca/download.aspx



(re) Presentando Evil FOCA (DEFCON Edition)

A principios de abril se presentaba Evil Foca, como una herramienta que facilitaría la vida a pentesters y auditores de redes internas. Con una interfaz simple y de forma sencilla, permite realizar diferentes ataques automatizados, mostrando así lo inseguras que pueden ser las redes de puertas para dentro. Entre ellos:
  • Man In The Middle (MITM) sobre redes IPv4 con ARP spoofing.
  • MITM sobre redes IPv4 con DHCP ACK injection.
  • MITM sobre redes IPv6 con Neighbor Advertisement spoofing.
  • MITM sobre redes IPv6 con ataque SLAAC.
  • Ataques de rogue DHCPv6.
  • DoS (Denegación de Servicio) sobre redes IPv4 con ARP spoofing.
  • DoS sobre redes IPv6 con SLAAC DoS.
  • DNS Hijacking.
Pero además, en la DEF CON 21 celebrada hace bien poco en Las Vegas, se ha presentado la nueva versión de Evil FOCA (DEFCON Edition) cuya principal novedad es la inclusión del ataque Web Proxy Auto-Discovery en IPv6 totalmente automatizado.


La charla, que según diferentes testigos ha tenido bastante éxito, mostró en vivo y en directo lo que se puede llegar a conseguir con los diferentes ataques MITM con IPv6 (activo por defecto en los Windows) y lo sencillo que resulta aprovechar las vulnerabilidades del protocolo con Evil Foca.
Ataques IPv6 con Evil Foca. La nueva versión no incluye publicidad
Las dispositivas de la charla están disponibles desde:


Puedes descargarla ya, en la página de ElevenPaths.