El día que Microsoft cerró muchas puertas... pero abrió un ventanal

lunes, 29 de junio de 2015

El problema presentado en la REcon de mediados de junio, es grave. Y la respuesta de Microsoft, más aún. Lo descubierto por Brian Gorenc, AbdulAziz Hariri, y Simon Zuckerbraun, a efectos prácticos, invalida el ASLR de Windows de 32 bits.

Brian Gorenc, AbdulAziz Hariri y Simon Zuckerbraun no son unos desconocidos en el exploiting. Trabajan para la Zero Day Initiative, de HP. En febrero ya se ganaron 125.000 dólares (que donaron) por sus investigaciones sobre la Isolated Heap y la función de MemoryProtection. En ese momento no dieron detalles, pero desde entonces han pasado ya 120 días y no todo se ha arreglado, así que han publicado un documento con todos los detalles.

¿Qué es MemoryProtection y la Isolated Heap?

Microsoft a veces publica no solo parches, sino que (sin decir nada) en ocasiones introduce mejoras en los boletines. El pasado verano, los boletines MS14-035 y MS14-037 vinieron con dos nuevos sistemas de mitigación de explotación para Internet Explorer. Uno contemplaba la creación de un heap separado para procesar el DOM de las páginas. Esto dificulta mucho la explotación (que se termine ejecutando código) de las vulnerabilidades. El otro introducía MemoryProtection. Se trata de una mejora a la hora de liberar la memoria del heap, que pretendía reducir el riesgo de que las vulnerabilidades provocadas por "use after free" de punteros puedan ser explotadas más fácilmente. Y así fue. Se redujeron el número de fallos explotables por estas causas. Gracias a estas dos estrategias, se cerraron muchas puertas (posibilidades de que muchos tipos de vulnerabilidades pasadas y futuras basadas en el mismo fallo fueran explotables).

Nada es inviolable y, a pesar de estos sistemas de mitigación, en febrero de 2015, en FireEye ya detectaron exploits "in the wild" que conseguían eludir estas mitigaciones. Incluso los propios Gorenc, AbdulAziz Hariri y Simon Zuckerbraun han mostrado cómo conseguirlo con todo lujo de detalles en este mismo estudio. Google llegó a una conclusión parecida a principios de enero... . Pero eso no es lo más importante. Bien por Microsoft y sus estrategias para mejorar la seguridad en Internet Explorer desde la raíz... o no.

Se abrió el ventanal

El problema es que los investigadores no solo han conseguido eludirlas sino que, ayudándose de la implementación de estas mitigaciones, pueden eludir ASLR en Windows de 32 bits. Ciertas funcionalidades de estas mitigaciones les permiten deducir las direcciones base en memoria de ciertas DLL, con lo que, a efectos prácticos, permite a un exploit eludir ASLR puesto que solo necesitará conocer estas direcciones para situarse y lanzar de forma cómoda su shellcode o exploit correspondiente. Aquí un vídeo que lo muestra. En resumen, han abierto un ventanal... y no piensan cerrarlo. Pero ojo, esto solo ocurre de forma fiable en las versiones de 32 bits de Internet Explorer 10 y posteriores.

Y esta ha sido la "excusa" para no arreglarlo. Microsoft ha respondido que las versiones de 64 bits se benefician más y mejor del ASLR (más combinaciones posibles) y que por tanto, los usuarios de sistemas de 32 bits, no tienen tanta protección. Esto es obvio, pero no por ello hay que deducir que, si su protección es menor, ¿qué más da que sea eludible del todo? Error.

Parece que Microsoft antepone el interés de reducir un subconjunto de tipos de vulnerabilidades UAF, al de una protección tan importante (y más genérica) como es el ASLR. En cierto modo tiene sentido: no quieren invertir recursos en arquitecturas obsoletas, necesitan deshacerse de la tecnología de 32 bits en cuanto les sea posible. Y este tipo de problemas, les "ayuda".

¿Es grave o no? ¿Me afecta?

Los atacantes ya saben eludir ASLR en Internet Explorer. Lo suelen hacer a través de plugins instalados u otras técnicas más o menos elaboradas. Por tanto, esto es otra herramienta más en su kit de explotación. Por otro lado, solo afecta a las versiones de 32 bits del sistema operativo Windows 7 y 8, que es donde se lanza el Internet Explorer de 32 bits nativo. De estos quedan pocos, aunque los hay. Hay estudios de 2012 que hablan de que solo el 10% de los Windows son Windows 7 de 32 bits. Ante esto, si no se cambia de arquitectura, solo queda dejar de usar Internet Explorer o configurarlo con EMET.

Pero ojo, no está de más recordar algo interesante sobre Internet Explorer y reforzarlo en este aspecto. Curiosamente, Internet Explorer 10 funciona en Windows de 64 bits como proceso de 64 bits... pero también como procesos de 32 bits (sus pestañas). Esto no hace que sea vulnerable al fallo descubierto por la gente de HP, pero no está de más recordarlo y subir su seguridad (si se puede).

IE 10 sobre Windows 8 de 64 bits por defecto. Proceso padre con nivel de integridad medio y 64 bits.
Pestaña con nivel de integridad bajo y 32 bits.


64 vs 32 bits

En Windows de 64 bits, hay dos Internet Explorer instalados. Uno en "Program files" y otro en "Program Files (x86)". El primero es Internet Explorer nativo en 64 bits, y el segundo en 32 bits. Aunque se lance el de 32, el sistema operativo lo sustituirá rápidamente por el de 64 (aunque mantiene las pestañas de 32). Este es más seguro por varias razones:
  • IE de 32 bits solo puede correr plugins y ActiveX que sean de 32 bits. Los creadores de malware quieren acaparar al mayor número de víctimas, y por tanto programan en 32 bits porque es cómodo, y compatible con lo antiguo y lo moderno.
  • Los exploits para IE de 64 bits son más complejos de crear.
  • Las mitigaciones contra la creación de exploits en un entorno de 32 bits son más sencillas de eludir en 32 bits (y esto es justo lo que ha ocurrido). Pero esto no se le suele decir al usuario. Estéticamente, son idénticos. Hasta Internet Explorer 10, si se abre el navegador de 32 bits, todo es 32 bits, y si se abre el de 64, todo es 64 bits. Pero a partir de Internet Explorer 10, la cosa cambia. En esta versión, el proceso "broker" que corre en el modo de integridad medio, es siempre un proceso de 64 bits, y los hijos (las pestañas), de 32. Así se consigue compatibilidad con los plugins. 
Además, al hecho de que Internet Explorer se ejecute en un nivel de integridad bajo, Microsoft lo llamó "Modo protegido". Esto está relacionado con los niveles de integridad con los que se ejecuta el navegador y sus pestañas (el proceso padre en modo normal, y las pestañas hijas normalmente en modo bajo).

El modo protegido (activo por defecto) es lo que hace que los hijos se ejecuten
en modo de integridad bajo (y no medio), lo que los aísla

Para complicar el asunto, en Windows 8 existen dos versiones del navegador: la de "Escritorio" y la de "Interfaz moderna", esa que nadie usa pensada para los móviles y tabletas. En la interfaz moderna, todo es 64 bits y en el escritorio no. Y esto se complica aún más con Internet Explorer 11 dependiendo si se está en Windows 7, 8 u 8.1...

Protección

Visto este problema que permite eludir el ASLR en 32 bits, ¿es buena idea que todo Internet Explorer (y no solo su proceso padre) se ejecute en 64 bits? Sí. El problema podría venir por la compatibilidad de los plugins, pero es cuestión de elegir bien durante su instalación.

Por tanto, en un Windows 64 bits de escritorio, ¿se puede obligar a que incluso las pestañas sean procesos de 64 bits? Sí. Esto se ha llamado "Modo protegido mejorado". Si el "modo protegido" está relacionado con los niveles de integridad, el "mejorado" tiene que ver además con la arquitectura. Eso sí, insistimos en que antes de habilitarlo, es necesario estar seguro de que las extensiones o plugins que se usan en el navegador son compatibles. Se puede habilitar el "Modo protegido mejorado" desde las opciones avanzadas del navegador.
Activar modo protegido mejorado (solo Windows 8)
En Internet Explorer 10, activando esa opción, conseguiremos este efecto:

Pestañas de 64 bits, preo además.. en un AppContainer

Un AppContainer es un nivel de "sandbox" (nivel obligatorio, como lo llama Process Explorer, o de integridad) pensado para las apps del market de Windows (a partir del 8), bastante restrictivo. Para rematar el lío, en Internet Explorer 11 hay que dar un paso extra. Existe además otra opción avanzada de seguridad que dice "Habilitar procesos de 64 bits para el modo protegido de Internet Explorer" Si eso no está activo en IE11, aunque el modo protegido mejorado esté activo, las pestañas seguirán siendo de de 32 bits (aunque dentro de un AppContainer). ¿Complejo? Sí.

Algunas páginas no funcionarán con el modo protegido mejorado. La buena noticia es que podrás deshabilitarlo selectivamente por dominios tocando una rama del registro (TabProcConfig).

Sergio de los Santos
ssantos@11paths.com

Qué hemos presentado en el Security Day (IV): Latch, plugins ganadores y más hacks

viernes, 26 de junio de 2015

Llegamos al final de la serie del Security Day 2015. Sabéis que desde ElevenPaths desarrollamos Latch, como solución de 2FA (segundo factor de autenticación) y cuando lo creamos, estuvimos pensando plataformas dónde poder integrar esta tecnología y qué hacer con ella. Viendo todas las posibilidades que ofrecía, además de crear en la web de Latch una sección dedicada a los plugins y SDKs que pueden integrarse con Latch, decidimos lanzar un concurso de talento, bajo el nombre Latch Plugin Contest. El reto: desarrollar plugins innovadores y de utilidad para Latch. Gracias una vez más a todos los participantes y enhorabuena de nuevo a los ganadores:



En nuestra web hemos publicado todos los materiales para que podáis descargar las presentaciones de todo lo que vimos en el Security Day 2015 o verlos en vídeo en el canal de YouTube del Security Day 2015 todas las veces que queráis. Si además, quieres o necesitas más información sobre alguno de nuestros productos no dudes en ponerte en contacto con nosotros vía el formulario de la web de ElevenPaths.

Si quieres saber qué más contamos en el Security Day 2015, no te pierdas las demás ponencias. Aquí tienes todos los capítulos de la serie:

» Qué hemos presentado en el Security Day 2015 (IV): Latch, plugins ganadores y más hacks 

Os esperamos de nuevo en nuestro evento anual de innovación y seguridad. No te pierdas la tercera edición del Security Innovation Day, que celebraremos el próximo 8 de octubre en el Auditorio Central de Telefónica. Apúntate esa fecha en el calendario, ¡no te lo puedes perder!

Latch, caso de éxito: Implementado en TELECON, red SCADA

jueves, 25 de junio de 2015

Hoy vamos a contaros el caso de TELECON, empresa tecnológica especializada en el diseño, desarrollo, fabricación y comercialización de redes inteligentes de monitorización y control aplicadas a la seguridad, eficiencia energética y telemedida de agua y energía. Han implementado Latch en sus sistemas desde el propio diseño de los dispositivos.

Uno de los proyectos más relevantes en los que está trabajando TELECON es en un concentrador de telegestión de contadores PLC.


Esquema de concentrador de telegestión

El dispositivo en el que están trabajando permite gestionar los contadores de la zona a través de la red eléctrica, y realizar operaciones como la lectura del consumo, el cambio de potencias...También llevar a cabo órdenes de corte o reconexión del relé (cortar la luz).

Obviamente resulta muy útil para las eléctricas, porque permite la lectura de contadores, generación de informes y facturación de forma automática en remoto, sin tener que ir leyendo individualmente contador a contador. Sobre todo resulta de gran utilidad en entornos rurales, donde gracias a la incorporación de un módem GPRS al dispositivo, se puede dejar el concentrador en el poste de un pueblo y recibir los informes remotamente desde la central, además de acceder a él en cualquier momento para hacer una consulta.

Evidentemente, la seguridad resulta algo crucial en este tipo de sistemas, y desde TELECON han aplicado la seguridad a su diseño en todos los niveles. Estos dispositivos montan como interfaz de usuario una web que corre en el servidor web que levanta el concentrador. Partimos de que son equipos que van a quedar en las eléctricas o en un poste, y por ejemplo, en el caso de la web, vulnerables a todo tipo de ataques por fuerza bruta en el caso de que alguien se pueda hacer con él físicamente.

TELECON nos comentaba: "Pensamos en Latch como una medida añadida de seguridad al producto muy útil para usuarios de pequeñas y medianas distribuidoras eléctricas, y queríamos dar la posibilidad al cliente de que lo usara si lo deseaba. Dar la opción de bloquear el concentrador hasta el momento de recuperar los informes a final de mes y dejarlo bloqueado hasta el mes siguiente fue algo que rápidamente gustó".

¿Cómo TELECON ha implementado Latch con el concentrador?

En el caso del concentrador, TELECON decidió implementar la aplicación desde fábrica, y que así todos los concentradores la incorporaran de serie: todos saldrán con la misma aplicación de Latch configurada, lo que implica que un usuario puede registrar Latch en varios concentradores, manejándolos todos con el mismo Latch (por ahora sólo permitimos una cuenta de Latch asociada por dispositivo). En el momento que Latch está configurado en el equipo pasa a ser indispensable que el equipo tenga acceso a Internet para ser usado mediante la aplicación web.


"El hecho también de que Latch notifique los accesos no deseados en el móvil es un añadido para una herramienta que confiamos nuestros clientes empezarán a configurar pronto (la liberaremos en la próxima versión) y esperamos que sea un ejemplo para que más fabricantes se animen a integrar Latch de serie en sus productos", nos comentaba Uxío Fuentefría, ingeniero de TELECON.

Irene Gómez

Uxío Fuentefría

Telefónica Trend Report: The PoS Malware threat in 2015

miércoles, 24 de junio de 2015

A few weeks ago in the United Kingdom, cashless payments overtook the use of notes and coins for the first time. This is the latest demonstration that, while worldwide cash still remains king, the balance is slowly changing. We present here, a complete study about PoS malware state of art, evolution, figures, countermeasures... These are the main ideas from the report.

Although the smartphone has been the catalyst for the shift towards more secure mobile payments, credit and debit card transactions at point-of-sale (PoS) still remain the main entry point of consumer data into merchants’ information environment. Perhaps an obvious point, and one certainly not missed by cyber-criminals if the "mega breaches" affecting major U.S retailers in the past few years are anything to go by.

Illustration of PoS malware breach headlines, 2002- 2015

Targeting the weak link in PCI-DSS, cyber criminals have refined PoS malware, employing "RAM Scraping" techniques to parse memory processes on PoS terminals before card data is encrypted. It is now a mature cybercrime model, responsible for the majority of confirmed data breaches and feeding a booming underground marketplace. Focusing too much on the headline-grabbing breaches belies that from a frequency perspective, small and medium sized enterprises are most affected; criminals are after the money, not the headlines. However, awareness has undoubtedly risen, and the average time between breach and detection appears to be narrowing, but the number of detections in Q1 2015 outstripping the previous two years is also a narrative of soaring propagation rates.

Frequency of incident classification patterns with confirmed data breaches

Industries with high card transaction volumes (particularly hotels and entertainment) in addition to the more obvious retail sector, are most at risk from PoS malware. The size of the U.S economy combined with the late adoption of EMV "Chip and Pin" technology ensures it will almost certainly remain the most targeted during 2015, and an attack surge within the target rich environment is possible before the October implementation deadline. Although even when EMV is implemented, data remains that enables fraudulent e-commerce transactions. In large enterprise, the drive for innovation at PoS can see security overlooked in favour of the consumer experience and integration with other business applications. Secure technology that would hinder PoS malware such as end to end encryption is often unrealistic for small and medium sized businesses to implement. Conversely, criminals are able to call upon a readily available and proven PoS malware codebase, unthreatened by obsolescence of a PoS data environment set to remain largely Windows XP based for several years to come.

Evolution of PoS malware variants
Technical analysis reveals heavy development occurring across a few key codebase variants, with some strains adopting nation-state level complexity and others stripping back and removing unnecessary overhead. The overall malware campaign, in particular the exfiltration of stolen data can be complex, and is often based on detailed network knowledge.
Figures in millions (pounds) of UK credit card fraud and countermeasure implementation date

While it is possible that large companies may be able to limit the impact of protracted "mega breaches", the risk of smaller more distributed breaches remains, and the upwards trajectory of PoS malware in 2015 shows no signs of slowing. However rather than be overawed in the face of the threat, it should be remembered that common PoS network intrusion methods such as phishing and attackers using default passwords are often targeted but nothing new.



PoSeidon Logo and a phishing email campaing used to target PoS vendors

Ben Walton
ben.walton@11paths.com

Otras curiosidades sobre Duqu2 de las que no se ha hablado tanto

lunes, 22 de junio de 2015

Se pueden dar dos situaciones especialmente irónicas en el mundo de las soluciones de seguridad, y en concreto en el de los "programas anteriormente conocidos como antivirus": Una es que se detecten a sí mismos o un componente vital del sistema operativo. Otra es que sus redes internas y corporativas se vean comprometidas por malware. Ambas situaciones se han dado en el pasado (aunque la segunda se haya mantenido probablemente más en secreto si ha sido posible)... Pero nada que ver con el caso de Duqu2 y Kaspersky. Una genialidad que, lejos de quedarse en la anécdota y la ironía, nos enseña un buen puñado de lecciones.

A estas alturas ya lo sabrá todo el mundo. Kaspersky fue infectado por Duqu2, una variante de Duqu. En octubre de 2011 se conoció una amenaza muy avanzada (quizás basada en Stuxnet) que se llamó Duqu (porque muchos de sus archivos comenzaban por ~DQ). En aquel momento era menos avanzado que Stuxnet, pero se consolidó como una herramienta de espionaje muy potente con grandes características para pasar desapercibido. El mismo equipo (sea quien sea) ha desarrollado Duqu2. Kaspersky lo encontró en sus redes, lo ha estudiado y publicado todos sus detalles. Aunque ya se ha hablado mucho del asunto, veamos lo que nos ha llamado la atención.

Cómo infectó en primer lugar

Se ha encontrado en otros sitios (relacionados con las organizaciones que establecen las negociaciones sobre el tratamiento nuclear) , pero obviamente ha llamado la atención que se ocultara en la red principal de Kaspersky. ¿Por qué ellos? Podríamos pensar que querían investigar sobre cómo funcionan sus soluciones de seguridad para pasar aún más desapercibido. O sea, que Kaspersky pudo ser simplemente un efecto colateral para un objetivo aun mayor. ¿Muy osado? No es la primera vez que lo hemos visto. A principios de 2013, alguien entró en Bit9 y se hizo con claves privadas de certificados simplemente para firmar su malware poder evadir la solución de seguridad con la que se protegía su verdadero objetivo.

Duqu2 era capaz de aprovechar al menos tres vulnerabilidades no conocidas hasta el momento. En concreto CVE-2015-2360, parcheada el 9 de junio (probablemente porque Kasperksy avisó a Microsoft) y descubierta gracias al propio Duqu2, permite la elevación de privilegios.

Todo pudo comenzar en una oficina secundaria de Kaspersky en Asia, atacando a un empleado que probablemente lanzó algo que no debía. El historial de navegación e incluso su buzón de correo había sido limpiado, con lo que se sospecha que probablemente se envió algo por correo y se ejecutó aprovechando alguna vulnerabilidad. Esto no extraña a nadie. Más o menos así comenzó todo en el ataque a Google, durante la operación Aurora. Un empleado con un dedo rápido, que lanzó un documento que permitía elevar privilegios, y poca conciencia en seguridad. Esta es la primera lección que se debe reforzar (porque todo el mundo la sabe, pero sigue ocurriendo), el tópico del eslabón más débil. Una vez en esa máquina, varios saltos laterales gracias a ese 0-day que les daba "vía libre" por la red, desplegando e instalando paquetes MSI y finalmente hasta las entrañas de Kaspersky, su controladores de dominio y servidores importantes.

Imitando al propio antivirus

El malware buscaba el propio avp.exe (proceso de antivirus de Kaspersky) en el sistema, en disco y memoria. De una manera totalmente genial, el malware mapeaba avp.exe en una nueva sección de memoria. Parcheaba una pequeña parte de este nuevo avp.exe aún en memoria y le dotaba de mecanismos de callback para llamar a funciones pasadas como argumentos. En resumen, el sistema cree que es el propio avp.exe el que está llamando a otras funciones de sistema. También invalidaban (parcheando el driver del antivirus de Kaspersky "klif.sys" en memoria) una comprobación de firma digital. Básicamente, así se hacía invisible a las propias soluciones de Kaspersky, que creían que las llamadas más comprometidas venían de él mismo.

Conocían muy bien las soluciones de Kaspersky y cómo invalidarlas una vez con los privilegios suficientes en el sistema. Así que no hay nada que reprochar al sistema antivirus propio de la compañía por no detectarlos. De hecho si consiguieron detectarlo, fue con soluciones propias pero diferentes a las de usuario "tradicional". Lo detectaron con un producto orientado a empresas y tecnología muy distinta a su propio antivirus "de siempre".

Los certificados

Detalle de las extensiones X.509 del certificado
El certificado usado fue robado a "HON HAI PRECISION INDUSTRY CO. LTD." (también conocido como "Foxconn Technology Group"). El robo de certificados para firmar binarios ya es un clásico. Se necesita para poder instalar drivers en los Windows de 64 bits. Foxconn es un fabricante de componentes electrónicos que trabaja para, básicamente, todo el mundo. Desde iPhone hasta Microsoft, pasando por Kindle y la Wii. En "el antiguo Duqu" usaron certificados de Realtek and Jmicron, otros grandes fabricantes de hardware asiáticos. Esto no pone en peligro esas marcas, solo da una idea del volumen de la compañía.

De nuevo, Foxconn es solo un actor secundario en esta obra. Su papel es solo el de ser robado para conseguir claves privadas de certificados válidos. Es más, para crear Duqu2 no han repetido certificados, lo que indica que no es tan difícil para ellos conseguir nuevos.

Como curiosidad, el certificado tenía la rara extensión SpcFinancialCriteria, vista también en el certificado de Careto. No significa en absoluto que los grupos de creadores tengan relación, más bien parece que lo tienen el origen de los certificados, empresas de hardware asiáticas, quizás.

Detalle de la contrafirma del certificado

El certificado caducaba en agosto de 2015, pero no significa que pasada esa fecha no siguiera funcionando, puesto que al contrario que Careto, estaba contrafirmado. Esto nos lleva de nuevo a insistir en que, ‎el jueves, ‎19‎ de ‎febrero‎ de ‎2015 19:31:50, Symantec (responsable de la contrafirma) recibió una petición desde alguna IP en la que se estaba firmando un controlador de Duqu2. Quizás esa información no sea relevante (obviamente habrán tomado las precauciones necesarias), pero quién sabe.


Permanencia

Duqu sobrevivía en la memoria de máquinas con altos "uptime". Evitaba el disco, porque sabía que eso significa tener posibilidades de ser detectado. En memoria, todo puede ocurrir y pasará más o menos desapercibido. Esta es una tendencia que cada vez cobrará más importancia. Si el sistema se apagaba por lo que fuese, se volvía a infectar desde otra máquina, gracias a las vulnerabilidades. ¿Punto débil? Un apagón común.

Pero se guardaban un as en la manga. Algunas máquinas infectadas contenían un driver (rootkit) con capacidad de conectarse a internet. Gracias a las credenciales que ya tenían, en caso de pérdida de control, podrían haberse conectado de nuevo por cualquier método y reinfectar en memoria los sistemas más sensibles.

Un detalle que no especifican es cuánto tiempo han permanecido comprometidos. Sí que dejan ver que la intrusión se descubrió "a principios de año", con lo que han investigado durante unos seis meses, pero no se aventuran a decir cuándo fueron atacados por primera vez.

Conclusiones

Kaspersky ha salido airoso de este incidente. De paso, ha instrumentalizado sabiamente el incidente para ganar presencia en los medios, pero de forma justa: Su transparencia ha sido ejemplar, ofreciendo toda la información disponible, y por supuesto, con la industria de su lado. Pensar que puedes engañar, distraer o contar milongas al gremio de la seguridad a estos niveles, es perder el tiempo y el prestigio. Solo cabe la honestidad. Y Kaspersky parece que ha sido honesto. Este tipo de ataques van a seguir ocurriendo, no han demostrado ninguna debilidad importante, por el contrario, de nuevo han demostrado estar a la altura de las circunstancias a la hora de investigar los incidentes más complejos en cuestión de ciberguerra.

Obviamente, también caben las típicas conclusiones: las ciberarmas están aquí no solo para quedarse, sino para evolucionar hasta límites insospechados.

Todos los detalles del informe (muy extenso) aquí: https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns.pdf

Sergio de los Santos
ssantos@11paths.com

"Incident Response Management": Attitudes of European Enterprises

viernes, 19 de junio de 2015

We have recently sponsored a new research study conducted by Pierre Audoin Consultants, PAC, focused on "Incident Response Management". The results detailed are compiled from a survey conducted among large enterprises in France, Germany and the United Kingdom.

The report provides key insights into the reality of security breaches and how enterprises are dealing with the current threat landscape. 67% of companies report that they were breached last year and all admit to having been breached at some point in the past. 43% of those companies rate the incident severity high or very high. With an average direct cost of €75k per breach plus indirect costs associated with taking one to six person months to recover from a breach companies have to accept that breaches are inevitable and adapt their strategies accordingly to face this new reality. Not surprisingly over the next two years companies expect a shift in their security budgets between the traditional  protect and prevent services versus detection and response from a ratio of 4:1 to 3:2.

The shift towards a proactive security strategy
We believe this trend will only accelerate and that incident response is an important element of a more proactive security strategy being employed by enterprises.  This new threat landscape is reflected in the standardized security services within our portfolio designed to detect and mitigate security incidents, including Phishing or Malware, Brand Abuse, Pharming and the ongoing concerns associated with Customer Credential Markets. In addition we provide customised solutions and expert teams to support enterprises address advanced incidents including forensic analysis.

We continue to invest in the development of our Cybersecurity services portfolio in order to provide enterprises with actionable intelligence to help them identify the impact of attacks on their business. This includes insight into the effects on their brand and reputation across their digital estate, including the internet, web portals and social networks, the detection of online fraud and the identification of threat actors, their motivations and attack methodologies.

Security technology provides an incredible amount of data. This drives a key challenge within the security industry, the need to rationalise this data and identify a clear picture of what is occurring and what it means. Importantly, much of the relevant information lies outside of the enterprise, driven by the fact that there is no longer a defined perimeter and because most of the threats are executed via the internet. It is crucial that we are able to provide insight into the current security landscape and clearly articulate the current status for enterprises. Not surprisingly, the PAC study details how companies are challenged by the lack of in-house threat intelligence skills with 38% of security teams identifying this as their main source of concern.

Don’t just stand there, prepare!
Detecting an incident rapidly and effectively means that enterprises need to be ready. The need to prepare and react are two sides of what is usually a single problem. When we consider the need to prepare for a cyber-incident response it is clear that while incidents are out of our control, in that we cannot predict who will attack, when it will occur or what will happen, organizations crucially should expect an attack and be prepared to react appropriately. 86% of enterprises recognise this and within the research identified the need to be ready as central to their strategy. This proactively manifests itself in the form of implementing strategies that will help if and when the breach happens. This includes a CyberIncident Response Strategy or Plan that is maintained and tested.  It includes a crisis handling plan, roles and responsibilities post-discovery and communication plans etc. By having these key items in place and creating controls that allow the discovery of incidents, companies are better prepared for an organized post-incident response.

To notify or not notify, that is the question
The new European regulation with the inclusion of the mandatory breach notification is yet to be issued, however, companies are exploring what this will mean to their businesses. 87% of respondents indicated concern with regard to this change. Responding to an incident is not only a technological challenge it has a negative impact on a number of elements within any organization. The technological response mainly addresses the need to safeguard core aspects including communication, both internal and external, minimizing business operational impact and ensuring continuity. Breach notification requires technological support which produces the right type of information in a reasonable timeframe but also a communications challenge to ensure that any public announcement is effectively managed. This is reflected in the responses captured. 71% of respondents raised this as a key concern whilst 52% considered this a more important challenge than the technical issue. As the legislation initiative evolves, the need for enterprises to develop their cyber-incident response plans becomes paramount in order to be able to manage these issues. We believe this is why increasingly cyber-incident response plans are either linked or even included in the business continuity plan. Many of the softer skills required to manage an incident, will be the same regardless of the nature of the incident. As the market matures, and with a greater understanding of the cyber-risks and the associated importance of these risks increases for enterprises, the concept of Cybersecurity will be considered as another source of risk, to be managed in a consistent way.

I’m in trouble. Can you help?
The final part of the report assesses the strategy of outsourcing as a potential approach to addressing cyber-incident response. 69% of participants indicated that they have a combination of both internal and external staff dealing with security incidents. While initially this number appears surprisingly high, in retrospect, given that the severity, complexity and impact of incidents vary widely, it seems reasonable that companies adopt a human resources strategy which is flexibly designed to provide a range of capabilities in order to be ready for a different  types of incidents.  This is especially relevant when considering that companies often utilise external resources to support the management of standard security incidents which allow them to focus on more strategic security issues.

Once an organisation is aware of an incident they are immediately concerned with its containment and resolution. A breach will not solve itself, or simply disappear, hence its  damaging effects continue to grow. This explains why respondents cite quality, speed and knowledge in preference to the more traditional reasons for outsourcing, which normally include cost or budgetary flexibility. We understand this important requirement and provide key performance indicators for the time taken to close an incident as part of our on-line portal for our cyberincident response services.

Telefónica is both an ISP and an IP backbone provider and we have extensive experience in managing security inside our global and national networks as this is a core requirement for our business. We can leverage that experience as well as our cloud and network assets in order to deliver comprehensive managed security services. We believe that within Cybersecurity we can provide a comprehensive and end-to-end view of the security challenges faces enterprises from the generation of threat intelligence through to incident response where our experience and our network enable us to use network-based mitigation measures.

You can now download the study conducted by the consultancy company Pierre Audoin Consultants (PAC) and supported by Telefónica:

» Download the executive summary of the “Incident Response Management: How European Enterprises are Planning to Prepare for a Cyber Security Breach”.

» Download the full study “Incident Response Management: How European Enterprises are Planning to Prepare for a Cyber Security Breach”.

Luis Francisco González
Twitter: @lfghz

Qué hemos presentado en el Security Day 2015 (III): un combinado de Tacyt y Sinfonier

jueves, 18 de junio de 2015

Sinfonier: la navaja suiza de la seguridad 
¿Crees que el procesamiento de tiempo real es algo complejo y difícil de alcanzar? Entonces no conoces Sinfonier-Project.

Las cosas han cambiado: los sistemas evolucionan y con ellos la manera de generar, consumir e intercambiar la información. Sinfonier-Project es un proyecto abierto que pretende democratizar el procesamiento de datos en tiempo real, creando para ello una comunidad de usuarios donde compartir conocimiento y reutilizarlo. Basado en Apache Storm, Sinfonier permite interactuar con un cluster de forma sencilla, creando nuevos módulos y topologías de manera intuitiva. No hay nada mejor que ver el concepto que proponemos con un sencillo vídeo:

 

Tacyt: el producto que todos queremos tener 
Gracias a Tacyt, los equipos de seguridad son capaces de detectar amenazas ligadas a mercados móviles en tiempo real, dándonos el control sobre las apps maliciosas o ataques dirigidos que pueden estar haciendo sobre nuestra empresa. Algo en lo que suelen coincidir los ya clientes y las empresas que han realizado algún piloto, es que resulta tremendamente sencillo buscar, encontrar, detectar, comparar y descubrir amenazas. No es necesario ser ningún experto en Android ni seguridad móvil para comenzar a investigar.

Tacyt permite:
  • Responder con información de las amenazas en tiempo real
  • Analizar y comprender amenazas móviles
  • Crear perfiles de atacantes de acuerdo a su modus operandi
  • Alerta temprana de amenazas futuras
  • Detectar nuevas metodologías y herramientas de ataque

El combinado perfecto
Desde ElevenPaths, nos planteamos analizar, supervisar, correlacionar, indexar… toda la información agregada en una aplicación móvil, con la premisa de que una app no es solo una app sino también sus circunstancias. Y construimos un sistema de búsqueda y correlación potente que permitiese, de verdad y no solo en el papel, aprovechar palabras tan vacías como usadas hoy (“big data”, “inteligencia aplicable”…) en el sector. Además, en la actualidad donde necesitamos tener productos que gestionen grandes cantidades de información (big data), hemos encontrado la solución ideal para poder utilizar todas las fuentes de información privadas y públicas: Sinfonier. Con Sinfonier disponemos de una plataforma innovadora que nos permite analizar y relacionar cantidades masivas de datos de forma sencilla, con lo que es la combinación ideal para Tacyt:

En nuestra web hemos publicado todos los materiales para que podáis descargar las presentaciones de todo lo que vimos en el Security Day 2015 o verlos en vídeo en el canal de YouTube del Security Day 2015 todas las veces que queráis. Si además, quieres o necesitas más información sobre alguno de nuestros productos no dudes en ponerte en contacto con nosotros vía el formulario de la web de ElevenPaths.

Si quieres saber qué más contamos en el Security Day 2015, no te pierdas las demás ponencias. Aquí tienes todos los capítulos de la serie:

» Qué hemos presentado en el Security Day 2015 (IV): Latch, plugins ganadores y más hacks

Os esperamos de nuevo en nuestro evento anual de innovación y seguridad. No te pierdas la tercera edición del Security Innovation Day, que celebraremos el próximo 8 de octubre en el Auditorio Central de Telefónica. Apúntate esa fecha en el calendario, ¡no te lo puedes perder!

Qué hemos presentado en el Security Day (II): Metashield Protector 3.0 - Los vengadores

martes, 16 de junio de 2015



Los metadatos son «datos sobre datos» ocultos en los documentos ofimáticos en los que solemos trabajar día a día. Estos datos silenciosos pueden dejar al descubierto información sensible o confidencial sobre nuestro trabajo, relaciones comerciales, imagen corporativa, clientes o empleados. Por eso, para una organización, uno de los bienes más preciados es la información y los datos que maneja.

El problema 
Si datos confidenciales derivados de fugas de información sensible pasaran a manos ajenas y malintencionadas, el impacto económico y reputacional para nuestra organización sería insanable. Sin embargo, los metadatos son importantes, ya que nos ayudan en la búsqueda e indexación de ficheros y nos proporcionan información valiosa sobre las adaptaciones y evoluciones que han procesado los documentos excel, power point, etc que manejamos. Entonces, surge la pregunta ¿metadatos: eliminarlos o mantenerlos? La respuesta es clara: mantenerlos pero procesarlos de cara a su exposición al exterior. Existen soluciones de seguridad en el tratamiento de metadatos capaces de procesar la información oculta, aplicando completas estrategias preventivas, logrando exponer sólo la información necesaria y de manera organizada. Pero en determinados escenarios, existe una dependencia de terceros en la aplicación de estas medidas. En la mayoría de los casos, son los usuarios los puntos débiles en la conexión con el exterior y por ejemplo, a través del correo electrónico o almacenando información en repositorios documentales, olvidan realizar este proceso de limpieza o no lo realizan de manera homogénea como sería lo ideal en política preventiva.

La solución: Metashield 3.0 para empresas 
Metashield Protector 3.0 es nuestra plataforma para la limpieza de metadatos, que ayuda a las empresas a protegerse frente a la fuga de datos que se produce cuando se envían documentos ofimáticos hacia el exterior. En esta nueva versión del producto, la novedad ha sido el diseño y desarrollo de una consola centralizada de Administración para que sea muy fácil acabar con las fugas de información sensible y confidencial a través de los metadatos. Lo hemos comparado con los vengadores: ahora tenemos una consola centralizada y manejada por Nik Furia, un montón de motores que serían los agentes de Siel y los puntos de limpieza de metadatos que serían los vengadores. Tomar el control de la información oculta que filtra nuestra organización ahora es posible con Metashield Protector para empresas ya que ofrece una administración integral de recursos y aplicación de políticas preventivas comunes en el tratamiento de metadatos

Beneficios:
  • Control total en la aplicación de políticas corporativas de prevención homogéneas sobre los metadatos.
  • Administración y gestión centralizada de todas las soluciones de seguridad de Metashield Protector.
  • Gestión de toda la información oculta asociada a los documentos permitiendo el control sobre los perfiles de tratamiento y aplicación sobre las extensiones deseadas.
  • Reducción del impacto económico y reputacional derivado del uso malintencionado de los metadatos.
  • Cumplimiento de normativas de protección de información de carácter personal, LOPD, ENS, PCI DSS, HIPAA, GLBA, SOX.

En nuestra web hemos publicado todos los materiales para que podáis descargar las presentaciones de todo lo que vimos en el Security Day 2015 o verlos en vídeo en el canal de YouTube del Security Day 2015 todas las veces que queráis. Si además, quieres o necesitas más información sobre alguno de nuestros productos no dudes en ponerte en contacto con nosotros vía el formulario de la web de ElevenPaths.

Si quieres saber qué más contamos en el Security Day 2015, no te pierdas las demás ponencias. Aquí tienes todos los capítulos de la serie:


Os esperamos de nuevo en nuestro evento anual de innovación y seguridad. No te pierdas la tercera edición del Security Innovation Day, que celebraremos el próximo 8 de octubre en el Auditorio Central de Telefónica. Apúntate esa fecha en el calendario, ¡no te lo puedes perder!

"Alarmware" in Google Play: will not stop an alarm until you install another malicious app

viernes, 12 de junio de 2015

In ElevenPaths, we have spotted a few samples of downloaders in Google Play that work in a very special way. The app hides its icon and installs a service that will download another application from a server. We have seen this before... but the interesting part is that, to make sure the downloaded app is installed, it will start a kind of alarm that will start every few seconds until this new package from outside Google Play is indeed installed.

One of the offensive apps

We have found several alive samples of a new variant of a downloader known as "Stew.B" that we covered a few months ago. But this time they work in a different way, even more annoyingly. They maybe should be called, "alarmware".

How it works

The apps are supposed to be Minecraft or Clash of Clans guides. Even pizza recipes or weigh loss advice. The analyzed app shows some ads and then it just removes the icon from the desktop, so the user is not able to launch it again. Although, in the background, the app installs a service that will launch itself on every reboot.

Part of the configuration of the service
This service is ready to respond to two events, when the screen locks and unlocks and when an app is installed or uninstalled. The service has a random function to calculate how many hours or minutes to wait since the first application has been installed until it visits again the attacker's server and gets some instructions. Between them, the URL pointing at a package to be downloaded that could be literally, anything.

The program requests which new app to download and what message to show

Then this fresh downloaded APK starts and... it will really try hard to be installed. Even if you do not have your phone configured to install from outside Google Play.


Basic scheme of the malware program
Many of the devices will maybe have the security measure enabled: "do not install APKs from untrusted sources" (outside Google Play). So the just downloaded attacker's program will not be able to be installed and one of these screens will appear again and again.


APKs from outside Google Play are not allowed, 
and the telephone is not configured to use VerifyApps by default

And, showing these screens again and again, the user experience with the telephone will become quite annoying. Using a trick with a toast component (a special notification text that appears when you are connected to a new Wi-Fi or any other important system message) it will start popping again and again a message and a very annoying sound. Even vibrating. If you cancel or go back, it will start again (sound and message) trying to convince you it is a Google Service update or something like that. This will happen every few seconds. If the user does allow to install APKs from outside Google Play, or it finally configures it because he can not stand the sound anymore, this screen will appear.

Just before installing the downloaded APK 

The installation toast message and alert will keep on appearing and beeping again and again. Even if the device is silenced. The shown text will be in the browser language (it was taken from the attacker's server).  It will be very difficult to use the telephone normally anymore, unless you uninstall the original app (if you can in such a short time with the annoying screen request and sounds). It will continue annoying the user until the downloaded app is installed or the original app from Google Play uninstalled.

If the user finally installs it, the alarm will stop, and there will be "two" Google Service programs... who will dare to uninstall any of them?

One of the Service Google Play is fake

Funny enough, the application installed (the fake Google Service program) is just again the same code as the original one, which is weird. It is supposed the attacker is testing, but this could change in any minute. This attacker is from Russia, and used a similar technique back in March, but Google removed them.

Some apps of the same kind were removed back in March
A few weeks ago, the attacker got to upload some other apps again. Some of them are still online. These are the ones we found thanks to Tacyt, as we have done before with JSDialers, JSSMSers, Clickers, Shuabang, etc.

  • Guide minecraft game, com.appalexk.mcs, 965559baa77650d9c6249626d33ad14c5210c272
  • Guide Minecraft Free, com.appalexk.aam, bde1502855e2d9912937906c1d85bec24b3b6246
  • Guide for Clash of Clans, com.appalexk.cofc, 30c4db4033478007a1bdc86a40e37b5cd4053633
  • Recipes Pizza, com.appalexk.pizza, a84197a150285f04aee1096e96374255ccf5c2aa
  • Гайд для Earn to Die, com.appalexk.dde
The APK downloaded from the server is (right now): a2123233d8d972b68c721c01c6ad1785d8189fb9


Sergio de los Santos
ssantos@11paths.com

Juan Manuel Tirado
juanmanuel.tirado@11paths.com

"Alarmware" en Google Play: no detiene una alarma hasta que se instala otra app maliciosa

En ElevenPaths, hemos encontrado algunas muestras de downloaders en Google Play que funcionan de una manera muy especial. Las aplicaciones esconden su icono e instalan un servicio que descargará otra aplicación de un servidor. Esto ya lo hemos visto antes... pero la parte interesante es que, para intentar que se instale la app descargada, comenzará una especie de alarma que sonará cada pocos segundos hasta que el nuevo paquete descargado de Google Play sea de verdad instalado por el usuario.

Una de las apps encontradas

Hemos encontrado varias muestras vivas de una nueva variante de downloader conocida como "Stew.B" que ya cubrimos hace algunos meses. Pero esta vez, funcionan de una manera muy diferente, todavía más molesta. Quizás deberíamos llamarlo "alarmware".

Cómo funciona

Se supone que las apps son guías de Minecraft (un viejo truco) o Clash of Clans. Incluso recetas de pizza o consejos para perder peso. La app analizada muestra algunos anuncios y entonces simplemente elimina el icono del escritorio para que el usuario no sea capaz de lanzarla de nuevo. Sin embargo, entre bambalinas, la app instala un servicio que se lanzará a sí mismo en cada reinicio.

Parte de la configuración del servicio
El servicio puede responder a dos eventos, cuando la pantalla se bloquea y desbloquea y cuando una aplicación es instalada o desinstalada. El servicio dispone de una función aleatoria para calcular cuántas horas o minutos esperar desde que la primera app sea instalada, hasta la visita al servidor del atacante y recoger algunas instrucciones. Entre ellas, una URL apuntando a un paquete que será descargado y que podría ser, literalmente, cualquier cosa.

El programa realiza una petición para descargar una nueva app y qué mensaje mostrar

Después se lanza este APK descargado y... realmente intentará que se instale. Incluso si el teléfono no está configurado para instalar apps desde fuera de Google Play.


Esquema básico de funcionamiento del programa
Muchos de estos dispositivos es posible que dispongan de la medida de seguridad activada: "no instalar APKs desde fuentes no confiables" (fuera de Google Play). Así que el recién descargado programa del atacante no podrá ser instalado y una de estas pantallas aparecerá una y otra vez.


APKs de fuera de Google Play no se permiten,
y el teléfono puede no estar configurado para utilizar VerifyApps por defecto

Y, mostrando estas pantallas una y otra vez, la experiencia de usuario será a partir de ahora bastante molesta. Usando como truco un componente "Toast" (una notificación de texto especial que aparece cuando el teléfono se conecta a una red Wi-Fi por ejemplo u otros mensajes importantes de sistema) comenzará a mostrar una y otra vez un mensaje instando a la instalación y un sonido molesto. Incluso vibrará. Si se cancela o se vuelve atrás, comenzará de nuevo (el sonido y el mensaje) tratando de convencer al usuario de que es una actualización de Google Service o algo parecido. Esto ocurrirá cada pocos segundos. Si el usuario permite la instalación de APKs fuera de Google Play, o finalmente lo configura de esta manera porque ya no puede soportar la molestia, aparecerá esta pantalla de instalación.

Pantalla de instalación de la app descargada
El mensaje y alerta sonora de Toast de instalación aparecerá una y otra vez. El texto mostrado estará en el idioma del navegador (porque fue tomado del servidor del atacante). La alerta sonará incluso si el dispositivo está en silencio. Será muy complicado utilizar el teléfono de forma "normal", a menos que se desinstale la app original (si es que se puede con la pantalla de petición de instalación que aparece cada pocos segundos). Será así todo el tiempo hasta desinstalar la app original descargada de Google Play o finalmente acceder a la instalación de lo descargado.

Si el usuario finalmente lo instala, la alarma se detendrá y, en este caso, aparecerán "dos" programas Google Service... ¿quién se atreve a desinstalar cualquiera de ellos?


Uno de los servicios de Google es falso

Curiosamente, la aplicación instalada (el programa falso de Google Service) es otra vez el mismo código que la original descargada, lo que resulta extraño. Parece que el atacante estaba probando, pero esto podría cambiar en cualquier minuto. El atacante es de Rusia, y ya usó una técnica similar en marzo, que fue eliminada por Google.

Algunas apps del mismo tipo ya fueron eliminadas en marzo
Hace unas semanas, el atacante consiguió de nuevo subir otras apps al market. Algunas de ellas todavía están online. Estas son las que hemos encontrado gracias a Tacyt, como ya hicimos anteriormente con JSDialers, JSSMSers, Clickers, Shuabang, etc.

  • Guide minecraft game, com.appalexk.mcs, 965559baa77650d9c6249626d33ad14c5210c272
  • Guide Minecraft Free, com.appalexk.aam, bde1502855e2d9912937906c1d85bec24b3b6246
  • Guide for Clash of Clans, com.appalexk.cofc, 30c4db4033478007a1bdc86a40e37b5cd4053633
  • Recipes Pizza, com.appalexk.pizza, a84197a150285f04aee1096e96374255ccf5c2aa
  • Гайд для Earn to Die, com.appalexk.dde
El APK descargado desde el servidor del atacante es (ahora mismo): a2123233d8d972b68c721c01c6ad1785d8189fb9


Sergio de los Santos
ssantos@11paths.com

Juan Manuel Tirado
juanmanuel.tirado@11paths.com

Qué hemos presentado en el Security Day 2015 (I): éxito empresarial con la firma biométrica manuscrita

jueves, 11 de junio de 2015

El pasado 28 de mayo, celebramos la segunda edición de nuestro evento anual de seguridad, ElevenPaths Security Day 2015, donde presentamos nuestras nuevas soluciones de seguridad pensadas para simplificar algunas de esas tareas incómodas presentes en tu día a día. A los que compartisteis aquella mañana con nosotros, gracias de nuevo por sacar un hueco en vuestras ajustadas agendas, y a los que no; esperamos contar con vosotros en la próxima edición.



Impulsando la confianza digital de usuarios y empresas
El primer capítulo de esta serie se centra en el problema de la autenticación de usuarios y empleados en entornos organizativos. ¿Sabías que el mal uso de una contraseña puede llegar a comprometer los datos de una empresa? Nuestra solución de autenticación empresarial multifactor SmartID mejora la seguridad de acceso implementando un segundo factor de autenticación para los usuarios.



Muchos de vosotros soléis preguntarnos por casos de uso que os ayuden a ver la funcionalidad y entender qué cabida empresarial tienen este tipo de productos. Pues bien, la firma manuscrita es una de las soluciones más demandadas y por eso, queremos compartir con vosotros algunos de estos éxitos de implantación en diferentes organizaciones con SealSign, nuestra solución de firma y autenticación biométrica, que ayuda a reducir costes (eliminación del papel) o mejora la eficiencia de los procesos de negocio (centralización de certificados).

Os mostramos algunos de estos usos:
  • Firma de contratos con proveedores desde cualquier dispositivo con garantías jurídicas, que a su vez permite eliminar el papel y agiliza los tiempos de las licitaciones.
  • Firma de consentimientos informados por médico y pacientes en los hospitales, que ayuda a la eliminación del papel, reducción de costes de archivado y mejora de la eficiencia de los procesos con garantías jurídicas en caso de disputas judiciales.
  • Firma de partes de asistencia técnica en domicilio del cliente con dispositivos móviles de los instaladores, lo que permite la mejora de los procesos internos en firma de documentos de bajo y medio riesgo legal.
  • Firma de contratos de adhesión a un servicio en visita domiciliaria a los clientes por parte de los comerciales mediante el uso de una tablet.
  • Firma de documentos en movilidad para los directivos garantizando el ciclo de vida de los contratos.
  • Firma de contratos laborales de ETT y documentación anexa sobre el terreno mediante tabletas evitando el desplazamiento de los trabajadores a las oficinas.
  • Firma de solicitudes en atención ciudadana en mostradores de administración pública.
  • Firma de trámites internos en dispositivos móviles mediante reconocimiento biométrico.

Esto sólo es un aperitivo de todo lo que presentamos en primicia en el Security Day. Estáte atento porque próximamente iremos publicando el resto de la serie. De momento, y por si os habéis quedado con ganas de más, en nuestra web hemos publicado todos los materiales para que podáis descargar las presentaciones de las cinco sesiones o verlos en vídeo en el canal de YouTube del Security Day 2015 todas las veces que queráis. Si además, quieres o necesitas más información sobre alguno de nuestros productos no dudes en ponerte en contacto con nosotros vía el formulario de la web de ElevenPaths.

Si quieres saber qué más contamos en el Security Day 2015, no te pierdas las demás ponencias. Aquí tienes todos los capítulos de la serie:


Os esperamos de nuevo en nuestro evento anual de innovación y seguridad. No te pierdas la tercera edición del Security Innovation Day, que celebraremos el próximo 8 de octubre en el Auditorio Central de Telefónica. Apúntate esa fecha en el calendario, ¡no te lo puedes perder!


Bombardeado por subir un "selfie"

martes, 9 de junio de 2015

Hace algunos días, hemos vivido un nuevo caso en el que los metadatos han tomado especial relevancia. Si bien habitualmente se puede hablar de circunstancias similares, esta noticia sorprende porque las consecuencias muy diferentes. El pasado seis de junio un integrante de los yihadistas del Estado Islámico tuvo la brillante idea de realizarse un "selfie" dentro del propio centro de mando del cuartel general y subirlo posteriormente a las redes sociales jactándose de su posición y poder dentro de la organización sin percatarse que ese acto no tardaría en tener sus consecuencias.

Son muchas las ocasiones en las que hemos comentado la importancia de tratar los metadatos de las imágenes que realizamos con los dispositivos móviles o cámaras fotográficas antes de distribuirlas fuera de nuestro entorno. Famoso fue el caso de John Mcafee que se encontraba desaparecido tras un turbio caso ocurrido en su casa de Belice y que tras la entrevista de un periodista que se hizo y público una foto junto a él, permitió a las autoridades que este fuese localizado en Costa Rica. El caso que nos ocupa es más especial, e incluso invita a la reflexión.

Las imágenes de los dispositivos suelen incrustar el geo posicionamiento entre los metadatos que contienen. Los analistas de inteligencia de la Fuerza Aérea en Florida detectaron la información, la procesaron y extrajeron la ubicación exacta del individuo y su cuartel general a las orillas del Éufrates en la zona Siria.

Recoger esta información (a través de programas como Metashield Forensics o webs como Metashield Analyzer) y colocarla en un geo localizador es trivial. La diferencia en este caso es que, después, esto derivó en una orden de ataque.

Ejemplo de extracción de metadatos de una fotografía

Apenas 22 horas después del hallazgo, aviones de combate de la fuerza aérea se posicionaron en la zona y lanzaron una descarga de proyectiles reduciendo el edificio a escombros. Este es un claro ejemplo de la importancia de los metadatos y su tratamiento previo en las imágenes que se suben a los repositorios web y redes sociales. La información que se proporciona dice mucho de nosotros y nuestro entorno. En el caso del yihadista posiblemente haya sido su última publicación, puesto que parece que el autodenominado Estado Islámico utilizaba frecuentemente este tipo de redes sociales para el envío de imágenes y propaganda yihadistas, buscando la captación de adeptos para su causa.

Aunque lo cierto es que la duda no tarda en surgir: ¿de verdad ha sido un "despiste" (parece demasiado "obvio" entre gente entrenada en este tipo de entornos), o quizás más bien una fórmula para traspasar información a un tercero, a través de un canal abierto? Que cada cual saque sus propias conclusiones.

Antonio Bordón
antonio.bordon@11paths.com

Cómo funciona el fraude de los billetes de avión y reserva de hoteles (y II)

lunes, 8 de junio de 2015

En la entrada anterior se introdujo el asunto y las fórmulas de fraude de los billetes de avión y reserva de hoteles. Se describió cómo funcionaba, de dónde venían las fuentes de fraude, y se ofrecieron algunas cifras. Veamos ahora otros detalles sobre el asunto, que nos permitan conocer en profundidad este tipo de estafas.

Quién puede comprar

Cualquiera con bitcoins y acceso a la Deep Web (y algo de valor, todo sea dicho) puede comprar a estos vendedores. La transacción suele funcionar así:
  • El comprador envía al vendedor una captura de una agencia de viajes donde se vea el vuelo/hotel deseado, con el precio retail publicado. 
  • El vendedor crea un "custom listing" en el mercado negro por el valor acordado (que oscila entre el 20% y el 50% del precio retail). 
  • El comprador compra el anuncio y envía el dinero en bitcoins. El dinero queda depositado en una especie de depósito (escrow) en el black market, junto a los datos de los viajeros. 
  • El vendedor hace su trabajo y proporciona el localizador. 
  • El comprador verifica con la aerolínea que el billete es correcto y libera el pago del depósito. Dependiendo del vendedor, esto suele ser entre las 24 horas después de la entrega del billete hasta 24 horas antes del vuelo. Muy pocos aceptan liberar el escrow después del vuelo.
¿Cuánto cuesta?

Los precios son variables, y están directamente relacionados con el precio retail encontrado en el mundo real. Por ejemplo, si un vuelo cuesta 1.000€ y la tarifa del vendedor es del 25%, se pagan 250€ en bitcoins. Los vendedores con métodos de compra basados en carding o uso de cuentas de puntos robadas, cobran entre el 20% y el 35%, dependiendo de su experiencia, referencias etc.

Los vendedores con métodos más sofisticados y seguros, cobran entre el 40% y el 50%, ofreciendo según ellos métodos absolutamente seguros e indetectables que nunca supondrán un problema para los viajeros.

¿Los viajeros usan su identidad real? 

En general, está bastante extendida en la Deep Web la creencia de que viajar de esta forma es seguro. La inmensa mayoría suele disponer siempre de una coartada, como denegación plausible. Por ejemplo, es fácil alegar que tú como viajero eres inocente y que has sido víctima de una estafa, que creías que estabas comprando un billete legal a alguien que conociste y decía trabajar en una agencia de viajes y poder conseguir billetes más baratos.

Aunque, en caso de ser descubiertos, muchos podrían alegar ser víctimas de otra estafa, difícilmente podrían justificar portar documentación falsa. Si bien existe mucha oferta de documentación falsa (incluso a precios asequibles) la inmensa mayoría de esta documentación difícilmente pasaría un control fronterizo, ya que si no se trata de malas imitaciones, es documentación real perdida o robada a sus propietarios Esta documentación suele estar registrada en bases de datos policiales como la STLD (Stolen and Lost Travel Documents) de la Interpol.

Venta de identidades falsas en la Deep Web

Existe también bastante oferta de documentación falsa "de calidad", cuando no realmente auténtica de determinados países, aunque sus precios son demasiado altos (hasta 20.000 dólares). Esto hace que se utilice para otra clase de actividades ilícitas y no precisamente viajes. Quien puede portar esta clase de documentación falsa tiene otras actividades ilegales bastante más lucrativas que le permite comprar billetes auténticos.

¿Y la policía no hace nada? ¿Y los bancos?

Durante mucho tiempo ha estado bastante extendida la creencia de que las fuerzas de seguridad, en sus actuaciones cibernéticas, no se dedican a la persecución de este pequeño fraude, y que principalmente se centran en la persecución de delitos de pornografía infantil y similares.

Su argumento es que al estar involucrados distintos países y el fraude ser relativamente pequeño (de forma individual) no se persigue. Por lo general el viajero es de un país, la compra del billete se produce en una agencia de viajes de un país diferente. Además, el pago se hace con una tarjeta de crédito robada de un tercer territorio. Para colmo, el país origen/destino del viaje es quizás diferente a los anteriores. Al haber tantas jurisdicciones involucradas, es muy complicado realizar su persecución legal, más allá de cancelar la compra si es detectada a tiempo.

Y el caso es que esto era así hasta hace no mucho tiempo. Sin embargo en el último año y medio se han realizado ya hasta tres grandes redadas a escala mundial de forma coordinada entre Interpol, Europol y otras fuerzas de seguridad de otros países, junto a bancos y aerolíneas, en las que se ha detenido a cientos de viajeros. Y todo parece indicar que estas redadas globales continuarán.

Cómo protegerse de este fraude

El fraude en viajes afecta sobre todo a bancos y agencias de viajes, y en menor medida a las aerolíneas. Desde los servicios de Vigilancia Digital de Telefónica intentamos detectar en qué lugares de la Deep Web se está produciendo esta venta ilegal para conocer en detalle cuáles son los sistemas empleados para el fraude.

La lucha contra este fraude, al igual que contra el fraude en general, pasa por intentar reducir el robo de medios de pago (o dejarlos sin utilidad en caso de ser robados) y, sobre todo, identificar al titular de cada transacción correctamente.

Cómo funciona el fraude de los billetes de avión y reserva de hoteles (I)

Marcos Monge
marcos.monge@cybersecurity.telefonica.com

Cómo funciona el fraude de los billetes de avión y reserva de hoteles (I)

miércoles, 3 de junio de 2015

Perpetrar un fraude relacionado con billetes de avión u hoteles y salir airoso, no parece buena idea. Durante todo el proceso se está identificado, y sería trivial para las autoridades detener a los autores. Pero... nada más lejos de la realidad. Existe un floreciente mercadeo de fraude en viajes en el mundo underground. Cada vez más personas consiguen viajar un 30%-50% por debajo del precio real (incluso alguno, gratis). Y lo que es más sorprendente, aunque se trate de un fraude, la gente viaja con sus identidades reales. ¿Cuál es el secreto?

Para los aficionados a la seguridad informática, las dos posibilidades de fraude más conocidas serían:
  • El "carding" (uso de tarjetas de crédito robadas)
  • El uso de puntos/millas robados de cuentas atacadas (reward points)
Y lo cierto es que, según una estimación basada en una investigación reciente realizada por Eleven Paths y el Servicio de Detección de Amenazas y Vigilancia Digital de Telefónica, alrededor del 70% del fraude en viajes tiene como origen una de esas dos técnicas.

El resto de viajes robados, vienen cada uno de diferentes fuentes, dependiendo de las habilidades de cada "vendedor" o proveedor de los viajes. Dado que el carding es fácil de detectar (con servicios como JetSetMe, o de detección de tarjetas robadas con plataformas como BlueLiv), la industria del fraude en viajes ha buscado otros métodos "más" seguros. En la investigación llevada a cabo se han identificado distintos métodos "más sofisticados", como los ataques directos a las agencias de viaje (tanto online como offline)  y sus sistemas de backend conectados a los sistemas GDS (Global Distribution System) de las aerolíneas y hoteles (como AMADEUS o SABRE), robando las credenciales de acceso de esas agencias.

También se han identificado ataques a cuentas corporativas de grandes empresas que manejan una gran cantidad de viajes, entre los que se introducen puntualmente los fraudulentos de forma que pasen desapercibidos, o fraudes a los seguros... y otros muchos más variopintos, pero no masivos.

¿Vendedores? ¿Es que hay vendedores de viajes robados?

Como todo en Internet, esto se ha convertido en un negocio, y las mafias se han encargado de hacerlo floreciente. Han creado una gran oferta en los mercados negros de la Deep Web. El objetivo final de las mafias es monetizar el método usado para conseguir los viajes (ya sea carding, o el robo de credenciales de sistemas GDS...) y sobre todo, traspasar el riesgo. Quien se arriesga es el que viaja, nunca el vendedor (proveedor) de viajes, que permanece en el anonimato usando toda clase de medidas de protección para no ser localizado.

A su vez, muchos de los compradores que acuden a la Deep Web revenden los billetes a gente de la calle. Traspasan el riesgo y evitan ser pillados.

Billete de viaje a mitad de precio vendido en la Deep Web

También existe un gran número de vendedores con varios años de antigüedad "en el negocio", retirados de las ofertas públicas de los Black Markets. Estos suelen trabajar solo con compradores de forma directa, que adquieren un gran volumen de viajes y que les proporcionan un flujo constante de nuevos viajeros.

¿Y cómo es de grande el fraude?

Se han localizado más de 40 vendedores distintos en activo, donde alguno de ellos dice gestionar picos de hasta 100 viajes al día. Los vendedores, salvo unos pocos que se mantienen estables (entre 15 y 20), van y vienen. Todas las semanas aparecen nuevos vendedores y desaparecen otros. Algunos estafando a sus "clientes"… Obviamente, nada suele ser lo que parece en la deep web.

Si tenemos en cuenta las estimaciones de Interpol y Europol, junto a las aerolíneas, el fraude asciende hasta los 1.000 millones de dólares, y afecta (de forma proporcional a su tamaño) a todas las aerolíneas y bancos emisores de tarjetas de crédito.

Datos del fraude con robo de billetes

Para hacerse una idea de la magnitud del fraude, pueden usarse los resultados de las redadas de Interpol y Europol, de las que se han realizado tres grandes operaciones en el último año y medio. Consisten en cazar viajeros que consuman este tipo de billetes comprados u obtenidos de manera ilícita. Durante los aproximadamente dos días que dura cada redada, se detectan o detienen a unos 150-250 viajeros. Realizando una media de forma extremadamente conservadora, se puede extrapolar que el fraude asciende a unos 100-200 viajeros diarios a nivel mundial. El dato  probablemente sea mucho mayor, puesto que las redadas se centraron en el fraude ya descubierto (principalmente realizado con carding, y por tanto "detectable" cotejando los billetes comprados con tarjetas que se saben robadas). Es lógico pensar que hay mucho fraude no descubierto (a tiempo).

En la siguiente entrada, veremos si cualquiera puede comprar estos billetes, cuánto cuestan, cómo usan su identidad real y cómo protegerse.

* Cómo funciona el fraude de los billetes de avión y reserva de hoteles (y II)
Marcos Monge
marcos.monge@cybersecurity.telefonica.com