10 años después descubres que hay que tapar la Webcam #malware #privacidad

Hace 11 años, exactamente en el año 2005 nació el popular RAT (Remote Administration Tool) Poison Ivy. Las herramientas RAT son un tipo de malware creado especialmente para controlar totalmente un equipo desde una consola centralizada. Su evolución natural les llevaría a convertirse en las populares Botnets de equipos Zombie, donde desde un Command & Control Panel se llegan a gestionar millones de equipos infectados. En el año 2005, cuando aparece la primera versión de Poison Ivy, se empiezan a extender las técnicas de Reverse Shell, o lo que es lo mismo, que el llamado "Server" que se instala en la máquina infectada, es quien realiza la conexión al panel de control para recibir las órdenes y no al revés, como se hacía en malware clásico anteriormente.

Figura 1: 10 años después descubres que hay que tapar la webcam

Poison Ivy fue muy popular durante los años en los que  estuvo en plena evolución, hasta llegar al año 2008 donde apareció su última release, la versión 2.3.2. Después vendrían muchos más que copiarían la mayoría de sus funciones. Entre las muchas que traía la herramienta Poison Ivy estaba un módulo de vigilancia que permitía al atacante activar tu Webcam y grabarte en tu intimidad - y este no fue el primero que lo hizo -. Aquí tenéis una captura hecha por la webcam de una persona infectada con Poison Ivy 2.3.2, del año 2008.

Figura 2: Webcam capture en Poison Ivy versión del año 2008

El primer día que yo descubrí que con herramientas como Poison Ivy era tan fácil para un atacante activar tu Webcam la tapé. Desde hace más de una década llevo la Webcam de todos mis equipos tapados, lo que me generó que mucha gente me preguntara desde ese momento por qué lo hacía. Las nuevas herramientas RAT que fueron siguiendo la estela de Poison Ivy fueron añadiendo todas la misma función, y ver ya esa opción entre la lista de posibilidades no sorprende a nadie de este mundo. En la imagen IndSocket y en este otro artículo tienes Incognito RAT que también funciona con equipos Mac OS X infectados e incluso se controlaba desde un iPhone.

Figura 3: Opción de Webcam Capture en IdnSocket RaT

En el año 2011, ya con mi blog abierto, descubrí la existencia de un foro en el que la gente se dedicaba a infectar personas con RATs, capturarles con la Webcam y compartir el material con todos. Las fotos eran brutales, e incluso había vídeos subidos a Youtube - hoy retirados - que mostraban el proceso completo. Si te aburres, abre Youtube y busca vídeos y tutoriales de RAT. Te sorprenderá ver la gran cantidad de esta familia de malware que existe con la capacidad de grabarte en tu casa y hemos visto que hasta vecinos lo usaban para espiar a sus víctimas.

Figura 4: Un caso de espionaje vía Webcam del año 2013 en España

A partir de ahí, sistemáticamente he ido explicando en multitud de ocasiones el riesgo de no taparse la Webcam, además de explicar que el número de fallos que aparecen y que pueden permitir a un atacante infectarte para activar la Webcam es alto. En el año 2011 un bug en Adobe permitía hacer lo mismo.

Figura 5: Security Innovation Day 2014. En esta charla hacemos la demo de infectar a la víctima con un documento Excel y capturar la webcam con Metasploit

En muchas demostraciones, como en el evento de Creo en Internet en el año 2011 o en el Security Innovation Day 2014, he hecho demos con malware que infecta el equipo y activa la Webcam usando Metasploit, que tiene módulos para eso desde hace infinidad de tiempo, e incluso algún ciberespía ruso ha salido retratado en un proceso de doxing con el que le han activado hasta la webcam de su casa - con sus cortinas último nivel de moda -.

Figura 6: Supuesto ciberespía ruso grabado en su casa

Algunos creen que las Webcam con las luces son más que suficientes, porque si se enciende la luz lo ves, pero incluso hay muchos casos que han demostrado cómo es posible llegar a encender la Webcam sin encender la luz. Al final si hay software de por medio hay posibilidad de que haya un bug para saltarse el proceso.

Figura 7: Recomendaciones de la NSA sobre la Webcam y el micrófono en OS X

Otros creen que por tener Linux ya no es necesario tapar la Webcam como si el software fuera diferente en ellos. Lo curioso es que hace años, pudimos ver ya documentos de la NSA que recomendaban a todos los miembros del gobierno que taparan la webcam y el micrófono para evitar este tipo de espionaje.

Figura 8: Equipo de Moxie Marlinspike en Twitter con la Webcam tapada

Entre los hackers esto es muy común desde hace años y en esta foto tomada al equipo de Moxie Marlinspike cuando era responsable de seguridad de Twitter se podía ver que él hacía lo mismo con  la Webcam de su Mac OS X.

Figura 9: Equipo MacBook de Mark Zuckerberg con la Webcam y el micrófono tapado

Ahora la gente ha visto que Mark Zuckerberg también tapa la webcam y el micrófono de su MacBook y ha vuelto la gente a preguntarse si será excesivo o no hacer esto con su equipo, tablet y dispositivo móvil, que el malware para Android también puede hacer estas cosas.

Figura 10: El iPatch de Latch que tapa mi Webcam

Yo llevo mucho tiempo con la mía tapada, e incluso regalamos para los eventos el popular iPatch con Latch para los asistentes, pero tú eres libre de hacer lo que quieras. Eso sí, "Si no tapas tu Webcam, ponte sexy para salir en Internet".

Saludos Malignos!

Cómo configurar el módulo de informes en FOCA

El proyecto de la "Foquetta" fue un módulo aparte que se integró en lo que antaño llamamos la FOCA PRO. Con la liberación de la FOCA Final Version este módulo está incluido también directamente en la herramienta, pero para que funcione tiene unos requisitos especiales de instalación ya que tira de Crystal Reports. Todo esto está explicado en detalle en el libro de Pentesting con FOCA, pero en este post de hoy os dejo un paso a paso hecho por Leo Gutierrez para que podáis activarla en vuestra instalación. Gracias Leo por preocuparte de esto.

Figura 1: Cómo configurar el módulo de informes en FOCA

Por si no lo sabíais la maravillosa FOCA trae una opción que hay que activar, los famosos Reports, aquí os enseño los pasos que he seguido para poder disponer de ella.

Figura 2: Módulo de informes en FOCA

Para poder instalar el generador de reportes de la FOCA hay que seguir los siguientes pasos:

1) Bajarnos el RunTime de Crystal Reports de la siguiente web: 

- http://downloads.businessobjects.com/...../CRforVS_13_0_7.exe

2) Deberemos instalar el Visual Studio for Desktop para Windows (Recomendable el 2012)

- http://www.microsoft.com/es-es/download/details.aspx?id=34673

3) Descargamos el ultimo update (Visual Studio 2012 Update 4)

- http://www.microsoft.com/es-es/download/details.aspx?id=39305

Una vez tengamos todo esto descargado lo instalaremos en el siguiente orden:

1- wdexpress_full (visual estudio 2012 for desktop)
2- VS2012.4 (update 4)
3- Reiniciamos el equipo
4- CRforVS_13_0_7 (Runtime de Crystal Reports)
5- Reiniciamos el equipo

Ahora ya dispondremos de tres opciones de informes: Documents Report, Metadata Report y Domains Report.

Figura 3: Asistente de Domains Report en FOCA

La opción de visualizarlos es sencilla, seleccionar el deseado y seguir los pasos del asistente seleccionando lo que deseamos que aparezca en el informe. 

Figura 4: Gráficos que se añadirán al informe generado

Al final se hace clic en build y FOCA generará el reporte y nos dará la opción de imprimirlo o de exportarlo en diferentes formatos. Os resumo los pasos con unas capturas de pantalla. Espero que os funcione todo bien.

Figura 5: Opciones de impresión, salvado y exportación de informes en diferentes formatos

No hemos probado a ver si funciona en instalaciones de FOCA o OS X o Linux, así que si alguien comprueba las dependencias y hace algún test con Wine sería genial saber si el módulo de informes también está disponible en OS X y Linux.

Saludos!

Autor: Leo Gutiérrez

Ejecutar FOCA en OS X & GNU/Linux

Como bien sabéis, nuestra queridísima maldita FOCA fue creada en .NET para ejecutarse sobre sistemas operativos Microsoft Windows, pero tiempo atrás nuestros amigos de HackPlayers hicieron una demostración de cómo era posible instalara la FOCA en Linux, utilizando solo Wine con tres plugins de WineTricks, como son dotnet20, gdiplus y fontfix, además de meter todas las DLLs que utiliza la herramienta. Ahora Omar Espino (Omespino) ha hecho una Prueba de Concepto de lo mismo, pero para sistemas OSX.

Figura 1: Ejecución de FOCA en OS X & Linux

Configuración de FOCA en OS X

El funcionamiento es bastante sencillo, basta con primeramente descargar FOCA desde la web de Eleven Paths, que tienes enlazado aquí: Descargar FOCA Final Versión. Después hay que conseguir las DLLs de las dependencias. Omar las ha recapitulado y publicado en un paquete que tienes disponible en Mediafire.

Figura 2: DLLs de dependencia de FOCA para OS X

Cuando tengas el paquete de FOCA descomprimido en tu OS X, debes descomprimir las DLLs y ponerlas en la carpeta BIN de la ruta de instalación de FOCA. Después instala WineBottler para OS X y trata de ejecutar FOCA.EXE.

Figura 3: WineBottler para OS X

Cuando intentes ejecutar FOCA.EXE, al tener instalado WINE en tu OS X, entonces saltará el asistente de WINE para preguntarte si quieres ejecutar una vez o hacer un paquete para OS X.

Figura 4: Asistente de Wine para ejecución de FOCA.EXE en OS X

En ese momento selecciona hacer un paquete y en el asistente de generación de paquetes introduce los tres WineTricks que son necesarios: dotnet20, gdiplus y fontfix.

Figura 5: Asistente de creación de paquete de FOCA. Selecciona los Winetricks necesarios.

Después de este punto, ya podrás ejecutar tu FOCA en OS X con total normalidad, tal y como se puede ver al final del vídeo tutorial que tenéis a continuación, que ha hecho Omar Espino.

Figura 6: Vídeo Tutorial de instalación de FOCA en OS X

Si queréis hacer la instalación de FOCA en Linux, el proceso es análogo, así que no hay más que seguir los pasos del tutorial de Hackplayers. Los ficheros de dependencia de FOCA para Linux que son los mismos, los tenéis en este enlace de Mediafire y aquí tenéis un pequeño vídeo tutorial de instalación de FOCA en Linux. Y si queréis sacarle partido a esta herramienta, ya sabéis que tenéis el libro de Pentesting con FOCA.

Saludos Malignos!

XCodeGhost: Más caminos para infectar iPhone & iPad

Negar la existencia del malware para tecnologías Apple siempre ha sido una estrategia de la compañía de la manzana mordida. De hecho tuvieron hasta una página web que presumía de eso en el pasado, a pesar de que ya habíamos visto ya mucho software malicioso para OS X y algunas muestras para los dispositivos "mágicos" iPhone & iPad. Las guerras con las casas de seguridad que desarrollan sistemas antimalware fueron grande y llenaron muchas páginas de debate en las revistas especializas sobre si el modelo de Apple funcionaría o no funcionaría.

Figura 1: XCodeGhost. Más caminos para infectar iPhone & iPad

Lo cierto es que poco a poco hemos ido viendo como los creadores de malware para iOS han ido expandiendo todos aquellos métodos que recogía yo para meter un troyano en iPhone, y los añadiendo cada vez ataques más sofisticados.

Figura 2: Tu iPhone es tan (in)seguro como tu Windows

De todas las técnicas de ataque a un iPhone versó la charla que di hace tiempo en Barcelona dedicada a la seguridad a seguridad iOS, que titulé "Tu iPhone es tan (in)seguro como tu Windows".

Los terminales con jailbreak

Por supuesto, si el terminal tiene jailbreak los atacantes lo tienen mucho más fácil, ya que todas las protecciones de CodeSigning y es bastante sencillo. En el libro de Hacking iOS: iPhone & iPad explicamos ya hace tiempo cómo se pueden crear estos programas maliciosos y cómo se pueden utilizar. Son estos los que utilizan los troyanos para espiar whatsapp y demás datos.


Figura 3: El Troyano de espionaje Stealth Genie para iOS que fue cerrado por el FBI usaba jailbreak
Siguiendo esta premisa recientemente hemos visto cómo se robaban con Tweaks maliciosos los datos de cientos de miles de usuarios, como en el caso de KeyRaider o LockSaverFree.

Sin jailbreak, pero infectando el equipo

Otra de las vías de entrada que se tenían identificadas es la de infectar el sistema operativo al que se conecta pareado el terminal iPhone o iPad. En ese momento se podrían seguir varias estrategias ya conocidas. La primera de ellas, aprovechando que el terminal está pareado se podrían robar o manipular ficheros, como binarycookies o bases de datos. Tan sencillo como los ejemplos de JuiceJacking que tantas veces he mostrado yo.

Figura 4: Robando una cuenta de Facebook de iPhone con JuiceJacking

La segunda de las estrategias, un poco más compleja y elaboradas, consiste en meter una app firmada por un Provisioning Profile. Este es otro método de los que se explican en el libro de Hacking iOS, y consiste en leer el UDID del terminal conectado y hacer un paquete de software malicioso especialmente creado para ese terminal. El usuario solo deberá aceptar el mensaje y listo. 

Figura 5: El ataque Masque infectado terminales con Provisioning Profiles creados adhoc

El ataque WireLurker y Masque que hemos visto recientemente utilizaban estas técnicas para meter un malware en los terminales iPhone, y vimos que se extendió por muchos sitios.


Figura 6: Instalando una app maliciosa en un iPhone vía AirDrop y Provisioning Profile
Una extensión de esta técnica ha sido la publicada por Mark Dowd que demostraba cómo esto es posible hacerlo vía AirDrop metiendo un malware en el terminal haciendo el Provisioning Profile del terminal de la víctima.

Figura 7: Hacking Team primero hacía el jailbreak y luego metía el troyano

La última de las estrategias, teniendo el sistema operativo infectado, consiste en que el malware haga directamente el proceso de jailbreak al dispositivo y luego le enchufe lo que quiera. Esto lo ha aprovechado en el pasado Hacking Team - además de usar Masque -, como ya vimos.

Infección del compilador: El ataque XCodeGhost

El último de los métodos de los que os quiero hablar aquí consiste en uno que hemos visto ayer mismo pero que se conocía desde tiempo atrás su posibilidad. La idea es tan "sencilla" como conseguir infectar el compilador. En Apple el compilador XCode con el que se desarrollar las apps en iOS. Con una versión manipulada e infectada se ha estado consiguiendo que los propios desarrolladores legítimos de apps estén generando software con malware sin darse cuenta, y algunas de ellas son tan populares como WeChat Messenger.

Figura 8: Código malicioso inyectado en XCodeGhost

Las apps, una vez compiladas y firmadas por el desarrollador, son subidas al market de AppStore con el software malicioso sin que el desarrollador sea consciente de que su app lleva un Alien metido en el código. Fácil de entender.

Lo curioso de todo esto, y es lo que ha motivado esta reflexión, es que este método - que se ha descubierto en uso en China - hace tiempo, concretamente en 2012, fue descrito por Eugene Kaspersky en una conferencia. El artículo que en Seguridad Apple escribimos en aquel entonces recogía este método con estas palabras.

Figura 9: Explicación de este ataque recogida en 2012

Sí, a día de hoy el malware en Apple iOS no es comparable al que podemos ver en otras plataformas como Android, pero lo que es cierto es que sí que existen formas de entrar en un terminal iOS con malware (y cada día se descubren más), así que además de aplicar todos los esfuerzos en la fase de Prevenir que entre el malware, también hay que dedicar recursos y tiempo a las técnicas de Detectar a los que ya lo hayan conseguido y Responder cuando se descubra que ya tuvo éxito.

Saludos Malignos!

Atacar la seguridad HTTPs con un Delorean en Python

Entre la lista de conferencias que se han dado este año en DefCon 23 hay una que tenía ganas de revisar, ya que la daba uno de los mejores hackers españoles, el gran José Selvi. Sus trabajos son siempre elegantes e ingeniosos, como cuando migró JailBreakMe a JailOwnMe para ownear los terminales iPhone - tanto me gustó que le pedí que lo detallara paso a paso para incluirlo en el libro de Hacking iOS -. En esta ocasión, su charla en Las Vegas versaba sobre cómo romper la seguridad de las conexiones HTTPs por medio de un Delorean, una que ya había impartido en Black Hat Europe 2014 pero que no había podido ver todavía.

Figura 1: Atacar la seguridad de HTTPs con un Delorean en Python

Sí, el uso de un Delorean es una forma de hacer entender a todo el mundo que el ataque tiene que ver con las medidas de seguridad que dependen de la fecha del sistema operativo y que, por fallos de seguridad en el protocolo NTP, pueden ser manipuladas para hacer viajar en el tiempo al sistema. Si cuando hablamos de Leap Seconds vimos lo mal que le podía venir a al sistema un segundo introducido, os podéis imaginar si hacemos viajar en el tiempo a los sistemas informáticos durante más tiempo. 

Figura 2: Saltar la seguridad de HSTS con un Delorean

La presentación de la charla la tenéis colgada dentro de la recopilación que han hecho nuestros amigos de Cyberhades con todo el material de DefCon 23, y merece la pena que la veas - incluidas las preciosas fotos de esa ciudad de Valencia tan bonita que tenemos en España -, y en la web de BlackHat Europe 2014 tienes acceso a un WhitePaper donde se recoge el trabajo.

Implementaciones de NTP en sistemas operativos

En la lista de sistemas operativos que ha analizado José Selvi se encuentran Ubuntu, Fedora, OS X y Windows. Todos ellos hacen uso de una forma u otra del protocolo NTPv3 o NTPv4 con configuraciones susceptibles de sufrir un ataque de man in the middle. Esto quiere decir que, un atacante, podría interceptar la petición de sincronización NTP emitida por el sistema operativo y darle una hora arbitraria para configurar de forma maliciosa la hora del sistema operativo.

Figura 3: Petición NTPv4 de Ubuntu vulnerable a man in the middle

Para hacer esto, hay que utilizar algún esquema de man in the middle en redes IPv4 o IPv6 que permita interceptar la petición NTP del cliente. Aceptando que en una red insegura - sin IPSec o sin posibilidad de bloquear los ataques de man in the middle - el protocolo NTP es vulnerable, las medidas de mitigación que tienen los sistemas operativos se basan por tanto en reconocer si alguna de estas peticiones puede reconocerse como maliciosa.

En las diferentes implementaciones Fedora es que más fácil lo pone, ya que hace una petición cada minuto y por tanto se le pueden hacer cambios en la fecha del sistema constantemente. En el caso de Ubuntu la sincronización es cuando se levanta la conexión de una nueva red o se produce un reinicio. En OS X se hace cada ciertos minutos, pero en las últimas versiones depende de la carga de trabajo que tengo el sistema.  Windows es el que lo pone más complicado, ya que tarda días en hacer las peticiones, además de que no permite cambios muy grandes en los tiempos, desechando las peticiones que vienen con grandes saltos, dejando una ventana muy pequeña de ataque.

Figura 4: Cuatro de los cinco modos de funcionamiento que tiene Delorean para viajar en el tiempo

Visto esta primera parte, el resumen sería que, con mayor o menor grado de exposición, si un equipo se conecta a una red insegura, su fecha del sistema puede ser alterada de forma maliciosa por medio de una herramienta escrita en Python, que José Selvi ha bautizado como Delorean.

Ataques a HSTS con el Delorean

Visto esto, que un equipo tenga una fecha maliciosa puede ser aprovechado por un atacante para hacerle mucho daño a un equipo. Uno de los ejemplos que propone José Selvi es el de atacar el protocolo HSTS. Este protocolo cierra la posibilidad de ataques Man in The Middle que se producen cuando se utilizan conexiones HTTP, ya que con HSTS se fuerza al navegador a que la conexión sea siempre por HTTPs cuando un dominio esté en la lista. Esto se hace mediante la configuración del HTTP Header HSTS que envía el servidor web en la primera conexión. A partir de ese momento se le impide al navegador conectarse a un dominio por HTTP mientras el TTL configurado por el HSTS sea mayor que cero. Es decir, que no haya caducado.

Desde las URLs internas de Google Chrome, puedes consultar el estado de la política HSTS que tiene tu navegador para cada dominio, así como los datos del certificado que se espera encontrar al otro lado para que no le den uno falso. Es decir, no solo la política de HSTS, sino también cuál es el certificado del que se está haciendo Certificate Pinning.

Figura 5: Configuración de HSTS para el dominio www.gmail.com en Google Chrome

Sin embargo, usando el Delorean alguien puede llevar la fecha más allá en el tiempo, hacer que caduque el TTL de la configuración HSTS y conseguir una petición HTTP a un dominio para lograr hacer, ahora sí, un ataque de SSLStrip, como el que hacía yo con Evil FOCA para robar las cuentas de Facebook o Gmail usando el ataque de WPAD.

Figura 6: Si consigues deshabilitar HSTS puedes conseguir que el navegador pida Facebook por HTTP

A día de hoy esto no es posible con todos los dominios, ya que algunos navegadores tienen listas preconfiguradas en el código, es decir, hardcodeadas, de conexiones HSTS que no van a realizarse nunca por HTTP - ni la primera vez -. Esta lista la gestiona Google Chrome y la utilizan otros navegadores. Además, cualquiera puede solicitar estar en esa lista mediante este sitio web.

Figura 7: Configuración de política de expiración en lista precargada de certificados

Por suerte o por desgracia, los certificados de esa lista también dependen del tiempo y expiran - y no tardando mucho ya que algunos son horas, otros como Google Chrome 10 semanas -, así que es posible hacer caducar la lista precargada en los navegadores y forzar la conexión HTTP a un sitio web para lograr interceptarla y hacer un man in the middle a esa conexión.

Usando certificados digitales expirados

Otra de las cosas curiosas que se pueden hacer es la de llevar con el Delorean la fecha del sistema a un tiempo en el pasado, con el objeto de lograr que los certificados que hubieran expirando antaño o que hayan sido marcados como caducados, vuelvan a ser válidos. 

Figura 8: Certificado de Diginotar firmado para Google.com que se bloqueó

Así, por ejemplo, José Selvi explica cómo se puede engañar a un navegador para que vuelva a dar por válidos los certificados robados a Diginotar que se hicieron para firmar dominios como Google.com o Live.com. Pero también para conseguir que certificados de las listas CRL que han sido marcados como caducados vuelvan a poder usarse.

Los planificadores de tareas y las actualizaciones de seguridad

Por último, una de las cosas más curiosas que se producen es que, si un equipo cambia su fecha y su hora, todo su planificador de tareas puede dejar de funcionar. Esto hace que las tareas de mantenimiento puedan no realizarse a tiempo o incluso no hacerlo nunca. En el caso de Windows, una de las cosas que se puede hacer es llevar la fecha del sistema a un tiempo en el futuro, y cuando se planifique la siguiente actualización de software mediante Windows Update, volver a llevar el sistema a su hora actual. Esto, como efecto lateral dejaría a un equipo sin actualización de parches de seguridad.

Figura 9: Configuración de Windows Update para febrero de 2016

Mis más sinceras felicitaciones a José Selvi por este trabajo. De que forma tan sencilla ha enlazado los ataques de man in the middle, las debilidades NTP - que ya eran conocidas - con la seguridad de HTTPs para lograr, con una herramienta sencilla escrita en Python cargarse su seguridad en ciertos entornos. Me encanta.

Saludos Malignos!

Cómo controlar un troyano en un equipo desconectado de la red usando SSIDs WiFi maliciosos #Hacking #WiFi

Dicen que un equipo desconectado de la red es un equipo seguro, pero según las situaciones esto puede ser cierto, o no serlo. En el caso de Stuxnet, el ataque se produjo por una conexión basada en la conexión de un USB, algo que podríamos llamar una conexión intermitente. En todos esos casos, al final, el equipo estaba desconectado de la red... pero no lo suficiente. De hecho, hace tiempo en este blog se habló de lo que se llamaron los Hidden-Links de las redes de una organización, muchas de ellas formadas por conexiones USB, enlaces Bluetooth, modems 3G/4G conectados a equipos, discos duros externos o enlaces a puntos de acceso WiFi.

Figura 1. Cómo controlar un troyano en un equipo desconectado de la red usando SSIDs WiFi maliciosos

Visto esto, la pregunta que quería responderme a mí mismo era, ¿hasta que punto podríamos estar expuestos estando fuera de Internet o de cualquier otro tipo de red? Pues no tan seguro ni tan aislado como se podría pensar. Si tenemos en cuenta los trabajos que se hacen con las técnicas Tempest, la información podría ser sacada con que alguien toque el equipo o, como se ha visto en el último trabajo de la Universidad Ben-Gurion en Israel hasta con un móvil antiguo y obsoleto que esté cerca es posible detectar cambios electromagnéticos de baja potencia producidos en la memoria del equipo para tener una comunicación que envía datos desde el equipo hacia otro destinatario remoto.

Un conexión de red inalámbrica sin conectar a ninguna red WiFi

Para probar un escenario similar, es decir, a tener una conexión de red sin llegar a establecer ninguna conexión de red WiFi decidí hacer mi propio experimento de comunicación entre un equipo troyanizado pero no conectado a ninguna red y un atacante externo. Es decir, supongamos que alguien en el caso similar al de StuxNet hubiera infectado un equipo que está desconectado de toda red, pero ahora quiere enviarle comandos al malware que está en el equipo. ¿Cómo hacerlo? Pues sencillo, la idea es la siguiente:

1. Se infecta a un equipo con un malware especialmente creado. Por ejemplo vía USB.
2. Este troyano utilizará las herramientas de red del equipo para buscar redes WiFi cercanas.
3. Con este módulo se leerán la lista de nombres SSID que hay cercanos.
4. Los comandos irán directamente en el SSID de las redes cercanas.

Esta técnica no solo puede estar utilizada por atacantes externos para hacer una control remoto de un RAT sin que haya ninguna conexión en el equipo, sino que puede ser utilizado también para, por medio de un programa que genere APs virtuales, sacar datos desde el equipo infectado hacia otro equipo controlado por el atacante.

Para esta Prueba de Concepto he dado el siguiente formato a las SSIDs, para que a través de sencillas expresiones regulares y utilizando las herramientas de red de nuestros sistemas - lo pongo en plural, porque el troyano está escrito en Java, y funciona en Linux, Windows y OS X -, el troyano obtenga una entrada de datos/comandos. Ejemplos usados en las demostraciones:

Figura 2 : Lista de comandos utilizados en las SSID

Gracias al troyano que hemos programado para este experimento - al que he llamado “TroWiSSID” -, podemos utilizar una nomenclatura especial en los SSIDs que tenemos ya prediseñadas, para poder ejecutar código de manera remota y pasiva por medio de comandos. A continuación os pongo un vídeo en el que se puede ver como un equipo troyanizado, el cual a la hora del ataque no tiene red, le ejecutan el primer y segundo comando de la tabla de más arriba por medio de SSIDs con comandos.


Figura 3: PoC de troyano controlado por SSIDs maliciosos en Linux, OSX y Windows
La tabla de comandos expuesta, es una pequeña muestra de lo que se puede hacer, pero el límite es la imaginación. Las instrucciones más atractivas para un atacante serían el envío de comandos multi-línea, ya que por ejemplo, hubiéramos tenido troyanizado un OS X - como se ve en el vídeo -, podríamos ejecutar el exploit de conseguir la elevación de privilegios y haber obtenido acceso root para hacer lo que nos plazca, inclusive sin que este hubiera tenido red.  Como resumen, os dejo aquí algunos pros y contras de este experimento:

- Podemos controlar un objetivo sin que este esté conectado a ninguna red.- Se pueden sacar datos de un equipo usando APs virtuales y SSIDs 

- No se requiere una buena cobertura WiFi sobre el objetivo, pero sí una cierta cercanía. 

- Usando antenas de gran potencia, se pueden controlar equipos o transferir datos desde muy lejos. 

- Si alguien visualiza los SSIDs sería necesario implementar técnicas para que no secuestren el troyano.

Conclusión

Tras este experimento, habría que tener claro que tener una tarjeta WiFi escuchando SSIDs es exactamente igual que tener el equipo conectado a la red, por lo tanto no está desconectado 100% y en el mapa de Hidden Links de una red habría que añadir todos los SSIDs cercanos a los equipos con tarjeta de red WiFi. Para ello, lo mejor es controlar muy bien el espacio de red WiFi que se tiene en la zona geográfica en la que están los equipos que se quieren tener "desconectados". Con un simple dispositivo móvil es posible tener el control de los SSIDs con comandos y sacar datos o enviar órdenes a los equipos infectados de una red. En tus proceso de fortificación de Linux o de fortificación de Windows, acuérdate de apagar la WiFi si no la usas.

Un saludo,

Autor: Christian Prieto, escritor del BlogX86.NET

Happy Eyeballs: Te toca hackear iPhone & OS X por IPv6

Hace un par de días volvía a hablar después de muchos meses del protocolo IPv6 con motivo de la dirección l33t de face::b00c::. En el artículo recordaba las técnicas de hacking en comunicaciones IPv6 y la implementación que habíamos hecho de Evil FOCA para probar muchas de ellas. Al mismo tiempo, sin darme cuenta, iba a acabar leyendo un mensaje que capturó mi atención, pues se trata de la confirmación por parte de los ingenieros de Apple de su apuesta por IPv6.

Figura 1: Happy Eyeballs - Te toca hackear iPhone & OS X por IPv6

El mensaje fue publicado en una lista de correo del IETF dedicada a IPv6. En este correo uno de los ingenieros de Apple confirma la implementación del algoritmo Happy Eyeballs en iOS 9 y OS X El Capitán por el que se trata de primar la elección de IPv6 en entornos de convivencia mixta entre IPv4 & IPv6.

Figura 2: Anuncio de la implementación de Happy Eyeballs en iOS & OS X

Con este anuncio, junto con la implementación que ya estaba realizando Microsoft Windows al respecto de IPv6  basada en LLMNR van a dar un fuerte impulso a la popularización de IPv6, y por tanto hay que estar más informado que nunca de cuáles son los riesgos de seguridad al respecto.

Microsoft IPv6: LLMNR y Happy Eyeball

Esto en los entornos Windows se implementa a partir del protocolo LLMNR (Local-Link Manager) donde se trata de elegir qué protocolo se debe utilizar en cada conexión. En Windows, cuando se hace uso de LLMNR se lanzan búsquedas de resolución de destinos usando IPv4 & IPv6 por toda la red, como se puede ver en la siguiente imagen.

Figura 3: Búsqueda hechas por un cliente Windows de las
direcciones IPv4 e IPv6 de un destino con el protocolo LLMNR

Una vez que se conoce la información del destinatario, Microsoft elige a uno u otro de los protocolos usando el estándar RFC 6724 y la tabla de precedencia que se pueda configurar en cada cliente.

Figura 4: Protocolo de selección de direcciones implementado por LLMNR en Windows

Esta fue la implementación que continuó utilizando y en Windows 8.x desestimó hacer uso del protocolo Happy Eyeballs, lo que generó mucha polémica en la industria.

iOS 9 y OS X "El Capitán"

Ahora Apple confirma que ya ha implementado Happy Eyeballs en iOS9 y en OS X "El Capitán", y que en las pruebas que ha realizado ha pasado de tener un tráfico del 50% con IPv6 a tener un 99% del tráfico bajo IPv6, lo que haría incrementar mucho el uso de IPv6 dentro de las redes de la empresa y en Internet.

Figura 5: Descripción de Happy Eyeballs

Esto quiere decir que, el protocolo de comunicaciones de referencia será IPv6, así que si la infraestructura de red lo permite, será lo más utilizado por Apple. Para resumir un poco el algoritmo, la implementación que hace Apple de Happy Eyeballs en sus sistemas operativos sigue el siguiente flujo de funcionamiento.

- Se lanzan consultas DNS tipo A y AAAA: Si no están cacheados los resultados, se manda por la red lanzando el registro AAAA para obtener la dirección IPv6 primero.

- Si primero se obtiene una respuesta AAAA: se lanza automáticamente el tráfico por IPv6. 

- Si primero se obtiene una repuesta A: Se esperan 25 ms con un temporizador para esperar la llegada de la respuesta AAAA. 

-- Si expira el contador: Se lanza el tráfico por IPv4-- Si llega respuesta AAAA: Se lanza el tráfico vía IPv6

- Una vez obtenida una lista de direcciones IPv6, para elegir la dirección IPv6 a utilizar se hará con un algoritmo de selección utilizando la latencia histórica de conexiones previas. Si dos conexiones tienen una diferencia dentro de un margen de error de 25ms, entonces se utiliza el RFC 3484 para elegir la lista ordenada de más adecuada a menos adecuada. 

- Una vez la lista está construida se lanza el tráfico, con temporizadores, por las conexiones en orden. La primera en responder gana, y se corta el uso del resto de las conexiones.

Desde el punto de vista técnico esta apuesta de Apple por Happy Eyeballs, y la ya hecha por Microsoft en el pasado con LLMNR, hace que algo que debería ser ya muy común - el conocer cómo funciona IPv6 y cuáles son las formas en que se pueden atacar estas comunicaciones a fondo -, deba ser algo obligatorio para cualquier técnico, administrador de sistemas, responsable IT, etcétera así que más te vale que te vayas poniendo al día con IPv6. 

Saludos Malignos!

PD: En El Lado del Mal tienes más de 40 artículos dedicados IPv6, desde conceptos básicos, hasta ataques, pasando por configuraciones, pruebas de conceptos y vídeos de conferencias con explicaciones.

Cómo grabar fotos y vídeos con autodestrucción de Telegram y SnapChat sin dejar rastro

La app de mensajería instantánea Telegram tiene muchos fans por el atributo de seguridad que ha querido potenciar desde el principio, pero a pesar de eso, tiene más o menos los mismos fallos de seguridad que aplicaciones como WhtasApp, tal y como os conté en el post dedicado a las debilidades de privacidad de Telegram. No obstante, hay una característica que desde que me la contaron me parecía una de esas cosas que dan falsa sensación de seguridad.

Figura 1: Cómo grabar fotos y vídeos con autodestrucción de Telegram y SnapChat sin dejar rastro

En este caso concreto me refiero a la posibilidad que se ofrece tanto en Telegram con en SnapChat de enviar fotos y vídeos con autodestrucción por medio de chat secretos con aviso de si alguien toma una captura de pantalla.

Figura 2: WhatsApp INT: OSINT en WhatsApp.

Nuevo libro de Luis Márquez en 0xWord.

Los chats secretos

Cuando se abre un chat secreto en Telegram se utiliza un sistema de cifrado extremo a extremo, es decir, se genera un par de claves pública y privada para cifrar la conversación. Las personas Juan y Marta, cuando abren un chat secreto en Telegram, se pasan las claves públicas, de tal forma que cuando Marta le quiere enviar un mensaje secreto a Juan lo cifra con la clave pública de Juan, lo que hace que solo Juan - que tiene la clave privada - pueda descifrarlo. Así funciona de forma resumida el cifrado asimétrico, aunque si quieres más detalles te puedes leer un buen libro de criptografía.

Figura 3: Establecimiento de un chat secreto en Telegram

En el caso de los chats cifrados de Telegram se aplica este esquema, igual que se aplica en WhatsApp desde el acuerdo con Whisper Systems y en muchos otros sistemas de mensajería como iMessage. Este sistema debería ser privado al usar cifrado extremo a extremo, pero como ya demostraron unos investigadores, si la empresa que está detrás decide no entregar las claves públicas de verdad de Juan y Marta, entonces sí que en los servidores de Telegram, WhatsApp o iMessage alguien podría acceder a esos datos, pero... eso es otra historia.

Los mensajes con autodestrucción de Telegram y Snapchat

Al estilo de los mensajes de Snapchat, del que hablaré un poco más abajo, si alguien que recibe una foto por un chat secreto de Telegram con un tiempo de vida de unos segundos decidiera hacerle una captura, en ese caso se le notificaría al emisor de la foto que el destinatario ha hecho una captura.

Figura 4: Aviso de que "Chema" ha hecho una captura de una foto con autodestrucción

Esto, entre muchas personas es una forma de que el emisor sienta una "falsa" sensación de seguridad y privacidad al pensar que la otra persona es de su confianza y la foto sólo la ha visto unos segundos. Por supuesto, en las relaciones de sexting entre adolescentes y no tan adolescentes, este tipo de sistemas es de lo más usado pero... la verdad es que no da ninguna garantía.

Figura 5: Capturas hechas en una conversación de SnapChat

Como se puede ver en la imagen de arriba, eso sucede igualmente en SnapChat, donde tanto si tu haces el captura como si la hace la otra persona - en cualquier momento - el historial de los mensajes muestra que se ha hecho esa captura.

Grabar las fotos con autodestrucción de Telegram y SnapChat sin dejar aviso

Entre los menos avezados tecnológicamente la solución más sencilla es hacerle una foto al móvil mientras que se ve la fotografía, pero para hacerlo más cómodo existen otras soluciones. Yo hice la prueba con Reflector para OS X, un software que permite duplicar la pantalla de tu iPhone en el equipo personal de trabajo, con toda la calidad que necesites. 

Figura 6: Streaming de la pantalla de vídeo de un iPhone a OS X con Reflector

Este software cuesta unos pocos dólares y me habréis visto usarlo en muchas presentaciones. Para capturar una foto en OS X con Reflector solo necesitas duplicar la pantalla por AirPlay y listo, podrás capturar la pantalla desde tu sistema operativo utilizando todas las herramientas que necesites. Por supuesto, la resolución a la que verás la imagen será a la que se vea - en este caso - en la pantalla del iPhone, por lo que será tan grande como se vea en el propio Telegram - no más -. 

Figura 7: Foto con autodestrucción en chat secreto de Telegram capturada en OS X

Este mismo truco, lo puedes utilizar en sistemas operativos Windows Phone y Android utilizando herramientas similares y, por supuesto, al emisor de la fotografía nunca le va a llegar ninguna alerta, así que puede seguir teniendo la "falsa" sensación de seguridad de que nadie ha copiado sus fotos.

Figura 8: Foto con autodestrucción de SnapChat capturada en OS X

Como se puede ver arriba, esto también vale para Snapchat, donde aunque haya autodestrucción la foto se puede capturar desde la pantalla del equipo sin que llegue ningún aviso al emisor.

Grabar los vídeos con autodestrucción de Telegram y Snapchat sin dejar aviso

Por supuesto, una vez que tienes que conectado un iPhone a un sistema operativo usando Reflector, tienes un canal de streaming que da más Frames Per Second que una película normal, así que se puede grabar vídeo de la misma forma.

Figura 9: Configuración de Reflector para streaming de vídeo

El truco para hacer esta captura de vídeo es tener una herramienta que permita grabar la pantalla para mostrar lo que allí se ve. Existen herramientas profesionales, pero tal y como se puede ver en la imagen siguiente, con un sencillo QuickTime Player para OS X se puede grabar una parte de la pantalla.

Figura 10: Grabar el vídeo que se reproduce en pantalla.

En el siguiente vídeo tenéis un ejemplo de grabación de un vídeo normal, de un vídeo enviado por Telegram y de un vídeo secreto enviado por SnapChat.

Figura 11: Demostración de cómo se pueden grabar vídeos con QuickTime Player y Reflector de Telegram y SnapChat

En mi demo no me he preocupado por el audio, pero si quieres hacerlo aún más profesional, puedes usar un cable de audio que conecte la salida de tu smartphone a la entrada de tu equipo y grabar al mismo tiempo la pista de audio del vídeo para luego tener el montaje completo del vídeo.

Reflexión Final

La moraleja de todo esto es que una vez que el mensaje está enviado al destinatario, el dueño del endpoint podrá siempre manipular la aplicación o el entorno para poder llevarse las fotos o los vídeos que se envíen. De hecho, esto es por lo que existían las famosas aplicaciones que le permitían a una persona [¡dándole la cuenta de Snapchat a un servidor web!] grabar todas las fotos y que a la postre fueran todas públicas porque fue hackeado en el escándalo de The Snappening.

Figura 12: Información sobre "The Snappening" dada por SnapSaved.com

A día de hoy no tengo constancia de casos de sextorsión, Cyberbullying o grooming por medio de fotos con autodestrucción de Telegram o SnapChat, pero ten en cuenta que aunque la app no te diga que ha hecho una captura de pantalla o un screenshot, el destinatario ha podido grabar y conservar esa foto con total tranquilidad, así que más vale que te fíes muy mucho de la persona a la que le estás enviando esas fotos "Secretas".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)