Latch Exfiltration: Módulo multiplataforma de exfiltración de datos usando Latch

El año pasado, planificando el Trabajo de Fin de Máster del Máster de Seguridad de la UEM que consistía en la fortificación de una cartera Bitcoin con Latch, Pablo González (@pablogonzalezpe) nos propuso una idea muy interesante: aprovechando la integración con Latch, por qué no habilitar la transferencia de la clave privada entre carteras a través de esa plataforma.

Figura 1: Latch Exfiltration: Módulo multiplataforma de exfiltración de datos usando Latch

Poco después, Pablo González y Álvaro Nuñez-Romero (@toolsprods) implementaron sobre esta idea una PoC llamada Latch'sApp en el Equinox de ElevenPaths para exfiltrar datos en general. Hicieron un hack en Python muy completo e interesante, llegando incluso a integrarlo como plugin para Data Exfiltration Toolkit.


Figura 2: Funcionamiento de Latch'sApp
Sin embargo, en nuestro equipo del TFM, decidimos crear una aproximación de la herramienta por nuestra cuenta, para ver hasta donde podíamos llegar partiendo de la idea inicial. Para llevar a cabo el proyecto elegimos el SDK de Latch en Python, ya que teníamos implementada nuestra cartera Coinbase en un servidor Django y Python 2.7. Así, planteamos las siguientes reglas para nuestro desarrollo:

1. Existe un módulo de lectura y otro de escritura, que comparten entre ellos una cadena de caracteres; así podríamos enviar información en formato JSON para luego poderla procesar como nos convenga. 

2. Creamos 8 cerrojos para la representación binaria, junto a otros tres de control. 

3. Los cerrojos de control se encargan de tres cosas. Indicar si la operación es de escritura o lectura, informar de que ha terminado la ejecución cuando se ha transmitido toda la cadena e indicar al módulo de escritura que hay un módulo de lectura escuchando para empezar la escritura. 

4. Si los cerrojos no están creados existe una comprobación para inicializarlos. 

Figura 3: Explicación en vídeo de los pasos de Latch Exfiltration

5. Se lee el primer byte de la cadena y se obtiene una representación binaria en unos y ceros. 

6. El módulo de escritura coloca los cerrojos acorde a los bits y deja el cerrojo de control en “off” para indicar que ha realizado la operación. 

7. El módulo de lectura comprueba el estado de los cerrojos y obtiene la cadena binaria, añadiendo un 1 si el cerrojo está en “off” y un 0 si está en “on” y vuelve a colocar el cerrojo de control en “on”. 

8. Una vez se tenga la cadena entera se obtiene el byte filtrado.

Portar el módulo de exfiltración a iOS con Swift.

A pocas semanas de entregar el TFM se me ocurrió una nueva idea. Ya que Coinbase es una cartera virtual que cuenta con una API y varios SDKs muy completos, sería relativamente fácil portarla a otras plataformas como pueden ser iOS o Android, así que me puse manos a la obra y empecé a portar la aplicación a iOS con Swift.

Figura 4: Implementación de Latch exfiltration en Python

El primer problema vino cuando buscando un SDK para esa plataforma vi que no había ninguno implementado. Primero intenté usar el SDK de Latch en C, ya que iOS soporta la ejecución de código en Lenguaje C tanto en proyectos con Objective-C como en Swift. Por desgracia, una de las librerías necesarias, libcurl, no llegaba a funcionar correctamente con el proyecto, así que pasé al Plan B.

Si no existe, créalo.

Una de las ventajas de Latch es que su SDK se reduce a implementar peticiones HTTPS a un servidor, que producen una respuesta que se procesa para actuar acorde con el estado de la petición, un estándar en desarrollo web. Además, los chicos de ElevenPaths tienen una documentación muy clara y concisa en la página para desarrolladores, además de los vídeos en los que explican cómo usar la tecnología Latch.


Figura 5: Cómo utilizar Latch en aplicaciones PHP
Así, en un par tardes y con ayuda de las las URLs ya formadas que saqué de la herramienta escrita en Python, implementé una primera versión del SDK. A grandes rasgos y sin entrar en detalle - ya que viene muy bien explicado en la documentación - los puntos más importantes a los que me tuve que enfrentar fueron:

1. Implementación de las HTTP Request. Para ello usé una dependencia muy famosa de iOS llamada Alamofire, que envía procesa peticiones HTTP pudiendo elegir el método, cabeceras, parámetros... 

2. Formación las cabeceras y posterior firma usando el algoritmo HMAC-SHA1. Swift tampoco soporta nativamente firmas por hash, por lo que tuve que usar la librería CCommonCrypto y un wrapper para Swift. 

3. Por el carácter asíncrono de las peticiones, la necesidad implementar las funciones con “completion handlers”, trozos de código que escapan el flujo de una función y se ejecutan por un trigger. Así, tuve que recurrir mucho a recursión en sustitución a los bucles que podía usar en Python.

Pese a todo, no resultó muy difícil, y en poco tiempo conseguí implementar todas las funciones necesarias para desarrollar el módulo de exfiltración.

Figura 6: Proyecto con la implementación de Latch'sApp en XCode con Swift

Después de esto, solo fue necesario portar lo que había hecho en Python a Swift, implementando las respuestas asíncronas y buscando librerías que permitiesen la traducción de caracteres a bytes. Para ilustrar todo esto, lo junté en un PoC, una app para iOS que pudiera enlazarse con Latch a través de un código de enlace, poder controlar el cerrojo general de la aplicación y poder exfiltrar datos desde un ordenador a un móvil con iOS.

Figura 7 - PoC de Latch'sApp Data Exiltration en Swift

En definitiva, la experiencia ha sido satisfactoria, me quedo con la versatilidad y potencial que tiene Latch, como se ha podido ver en otras ocasiones, y con la experiencia de haber podido ampliar el alcance del Trabajo de Fin de Máster que realizamos mis compañeros Nacho (@DadeKan) y Danilo. Tanto el módulo en Python como el PoC en Swift los podéis encontrar en Github, cualquier mejora o ayuda es bien recibida.

Un saludo.

Autor: Lucas Fernández

uac-a-mola de @ElevenPaths ya lo infirió a finales de 2017: 2018 comienza con un nuevo Fileless bypass de UAC en Win8.1/10

El pasado mes de diciembre presentamos en Black Hat Europa 2017 a uac-a-mola nuestro framework para investigar, detectar, explotar y mitigar bypasses de UAC. Tanto allí como en el paper de la herramienta comentábamos que, según los módulos de investigación que tenemos actualmente, se habían detectado algunos bypasses de UAC potenciales de tipo Fileless. Además, también se observa en el paper un gran número de bypasses mediante DLL Hijacking que afectan diversos binarios de Windows.

Figura 1: 2018 comienza con un nuevo Fileless bypass de UAC en Win8.1/10 

Revisando los últimos bypasses que se van descubriendo, y que parecen no tener fin, vimos que el binario slui.exe es débil a la manipulación de registro, es decir, un posible Fileless. Esto llamó mi atención. Según podemos ver en el proyecto uacme, este bypass es usable desde la versión 8.1 de Windows. Revisé el paper y, en efecto, lo teníamos registrado como uno de los bypasses descubiertos por uac-a-mola a finales de 2017. De hecho, fue parte de la investigación que hicimos para la publicación del libro "Hacking Windows".

Figura 2: Slui File Handler Hijack LPE

El investigador que ha publicado el bypass es bytecode77 y en su blog se pueden ver los detalles para llevar a cabo el aprovechamiento del bypass. Como se puede ver en la siguiente tabla proporcionada en el paper de uac-a-mola, el binario slui.exe se encontraba entre los binarios que podían ser utilizados para llevar a cabo un bypass de UAC. Esto fue descubierto a través del módulo de investigación de uac-a-mola llamado fileless_discovery.

Figura 3: Binarios para usar bypass UAC fileless en el paper de uac-a-mola

El bypass también es utilizable en la versión de Windows 10 y, a día de hoy, no está parcheado, según se indica en el proyecto uacme. Realizar el ataque manualmente es sencillo y lo vamos a mostrar de manera rápida.

En primer lugar, con ProcMon podemos monitorizar las acciones que realiza slui.exe sobre el registro de Windows. Se puede observar como hay un 'NAME NOT FOUND' en la consulta a la clave HKCU\Software\Classes\exefile\shell\open\command. Es bastante similar a la clave que se utilizaba en el primer fileless, el del eventvwr. Cuando el binario no encuentra la clave, se dirige al hive HKCR. Aquí busca HKCR\exefile\shell\open\command.

Figura 4: NAME NOT FOUND en la clave buscada

Entonces, si en la clave no encontrada, la cual pertenece a HKCU, rama del registro dónde escribir sin privilegio, ponemos la ruta a un binario podremos ejecutar algo distinto a lo que se ejecuta cuando se invoca slui.exe. Hay que tener en cuenta el contexto de integridad en el que se ejecuta slui.exe, el cual puede ejecutarse en un contexto de integridad alto, sin solicitar el UAC. Para ello, hay que ejecutarlo con el verb runas.

Visto esto, hay que crear la rama en el registro. Esto se puede hacer a través de la línea de comandos de Powershell utilizando el provider del registro, de manera muy intuitiva.

Figura 5: Creación de rama en el registry a través de PowerShell

Como se puede ver, se crea la clave y se le aporta un valor por defecto que es que se invoque un cmd.exe. Este cmd.exe será ejecutado en un contexto de integridad alto si slui.exe es ejecutado de la forma adecuada. Para invocar al binario slui.exe se debe hacer utilizando el verb runas, por lo que en Powerhsell se puede realizar de la siguiente manera start-process c:\Windows\System32\slui.exe -verb runas. Tras realizar la prueba obtenemos algo tal que así:

Figura 6: Bypass de UAC conseguido

No es el único Fileless que está sin parchear ya que el de fodhelper.exe sigue siendo muy útil en los proyectos de Ethical Hacking. Además, uac-a-mola tiene disponible el módulo para detectar y aprovecharse del binario fodhelper.exe en Windows. Además, tienes disponible este artículo sobre cómo construir un módulo para uac-a-mola.

Por último, os dejamos un video de un ejemplo sobre este nuevo bypass publicado por bytecode77 y que uac-a-mola infirió a finales de 2017, tal y como se puede ver en el paper de la herramienta.

Figura 7: PoC de UAC Bypass con slui.exe tipo fileless 

Sin lugar a la duda, el año 2018 pinta ambicioso a lo que la investigación en UAC se refiere, ¿Tendremos un año similar al 2017? Todo hace indicar que puede que sí. Tanto yo como uac-a-mola estaremos atentos. Si te gusta este tema, tienes estos libros para ampliar conocimientos: Máxima Seguridad en Windows, Hacking Windows, Ethical Hacking y Pentesting con Powershell.


Figura 8: Presentación de uac-a-mola en CCN-CERT 2018
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths  con la colaboración de Santiago Hernández Ramos, nuevo cybersecurity "padawan" researcher en ElevenPaths

¿Los datos de Strava delatan a los militares de USA?

Muchas veces he hablado por aquí del problema de utilizar sistemas de tracking deportivo por medio de apps y dispositivos que hacen un seguimiento de tus rutas de deporte, tus horarios, tus latidos del corazón, etcétera. Si utilizas la app de Endomondo y no controlas las opciones de compartición de tus ejercicios, cualquiera desde Internet puede hacer lo que quiera, tal y como os dejé en el artículo "Róbame, estoy haciendo deporte y estoy así de sano". Peor si comportes tus datos del pulsómetro, porque puede revelar datos de tu salud. Esto también pasaba con la red social Runtastic.

Figura 1: ¿Los datos de Strava delatan a los militares de USA?

Para comprobar el impacto de esto, con mi equipo personal en ElevenPaths hicimos un pequeño estudio que no publicamos. Se llamaba Runners Privacy, y analizamos cuántas cuentas se podían extraer de Endomondo, Strava y Runtastic sin protección de sus datos de ejercicio. 

Figura 2: Datos públicos de las rutas en perfiles de redes sociales deportivas

El resultado fue sorprendente, ya que en 2014 el número de usuarios con datos públicos en Internet de sus ejercicios era de 500.0000 en Endomondo, de 150.000 en Strava y de 100.000 en Runtastic. Y creciendo día a día. Muchos datos publicados en la red que podían dar mucha información de rutas cotidianas de la vida de las personas.

Figura 3: Caminata de un perfil en la red

Pero esto puede ser aún peor si son datos de una pulsera que trackea constantemente. Como ya conté en la charla de "You Are Where You Are", la ubicación de una persona a lo largo del día puede decir mucho de ella. Sus gustos, sus aficiones, si visita un hospital crónicamente, si va a reuniones políticas, con quién se junta, si va a comprar a determinadas tiendas, etcétera. Algo que puede ser muy peligroso si no se protege bien la información.

Figura 4: You are where you are

Estos datos pueden ser valiosos de forma individual, pero también de forma agregada, como es el caso del que os vengo a hablar hoy. Strava ha generado mucho lío publicando un mapa de calor con las rutas por las que sus usuarios realizan ejercicio, o lo que es lo mismo, desde las que mandan ubicaciones GPS.

Figura 5: Mapa de calor publicado por Strava

Esto en lugares como Madrid, te permite encontrar cuáles son las rutas más habituales en la Casa de Campo, o por la zona donde tú vives, y si estás de viaje en alguna ciudad que no conoces, puede ser muy interesante - para eso se crearon las redes sociales de deportistas, entre otras cosas -.

El problema es cuando vamos a países en guerra donde la proliferación de estos sistemas es casi nula. Lugares en los que hay soldados desplazados de países en los que sí que son utilizadas estas tecnologías de tacking deportivo. Es el caso de Irak, o Somalia, con los militares norteamericanos.

Figura 6: Rutas en Irak

En el caso de Irak, se puede ver como existen pequeñas rutas que acaban en puntos en el medio de ningún sitio, lo que puede significar la existencia de una base militar. Hay que recordar que hace tiempo se borraron de las imágenes tomadas por los satélites las zonas que tenían bases militares. Lo mismo en Somalia, donde en ninguna parte del país hay información, más que en algunas rutas que terminan en medio de ningún sitio.

Figura 7: Rutas en Somalia. El resto del país está "desierto" de rutas

Al final, los datos de localización son muy valiosos, y una publicación de ellos de forma anónima puede llegar a descubrir, como ha sido el caso, un PoI (Point of Interest) que puede afectar a la seguridad del personal militar de la base.

Saludos Malignos!

4 citas para esta semana: Hacking Ético Online, TIC Forum Guatemala, Segurxest en Valencia y h-CON en Madrid @0xWord @tssentinel @elevenpaths @luca_d3

Para este semana que se nos viene encima tenemos cuatro citas importantes centradas en el mundo de la seguridad informática, el hacking, el BigData y la transformación digital. Os dejo en el post de hoy el calendario de esta semana, que llega a Madrid, Valencia, Guatemala y un curso online.

Figura 1: 4 citas para esta semana: Hacking Ético Online,
TIC Forum Guatemala, Segurxest en Valencia y h-CON en Madrid

Esta semana arraca el primer evento el día 29 de Enero que es cuando da comienzo el Curso Online de Hacking Ético Experto, que tendrá una duración de 9 semanas y en el que se entregará como material de apoyo el libro de Pentesting con PowerShell. Este Curso Online en "The Security Sentinel" es una de las mejores opciones para adentrarse en el mundo del Ethical Hacking. Además, aunque el curso comienza el lunes, puedes matricularte a lo largo de toda la semana.

Figura 2: Curso Online de Hacking Ético Experto

Está pensado para que le saques el máximo de partido con prácticas por tu cuenta, practicas guiadas, y asesoramiento y resolución de dudas, al mismo tiempo que lees los textos adecuados. Este tipo de formación es perfecto para todos aquellos que tenéis algo de tiempo para avanzar a toda velocidad en vuestra preparación.

El día 30 el TIC Fórum llega a Guatemala. Un evento para CIOs, CSOs, CEOs y CISOs en el que se habla de la transformación digital de los negocios mediante el mundo del Big Data, la Ciberseguridad, el mundo del IoT, la Cloud y las comunicaciones móviles empresariales de banda ancha. Un día para acercarse a Telefónica.

Figura 3: TIC Fórum 2018 en Guatemala

Ese mismo día 30 de Enero da comienzo en Valencia Segurxest, que durará hasta el día 1 de Febrero. Es un evento dedicado a la seguridad informática en el que tendrás la ocasión de ver conferencias de primera calidad. Además, desde 0xWord colaboramos, y podrás conseguir nuestros libros directamente allí.

Figura 4: Segurxest en Valencia

Después llega la H-CON en Madrid, concretamente en la ETSI de la Universidad Politécnica de Madrid, donde me hicieron Embajador Honorífico. Los días 2 y 3 de Febrero han preparado un programa con una cantidad de actividades.

Figura 5: H-CON en Madrid

Entre los ponentes, estará nuestro compañero de ElevenPaths Santiago Hernández hablando de "Hacking Network Protocols con Python". Además, colaboramos desde 0xWord en el evento. Merece la pena que revises la lista completa de Ponentes de H-CON.

Saludos Malignos!

Distribuidores de @0xWord en Latinoamérica: Panamá, Argentina, Colombia, México, Costa Rica, Ecuador, Uruguay y Chile

La editorial 0xWord es un proyecto "low-cost" que consigue mantenerse con un funcionamiento muy personal. Es difícil ir a cualquier librería y encontrar un título de Seguridad Informática o Hacking de la calidad de los libros que se publican en 0xWord y al precio al que se mantienen. De hecho, aunque muchos no lo sabéis, ha estado a punto de tomarse la decisión de cerrar varias veces, ya que los gastos y los ingresos están muy ajustados.

Figura 1: Distribuidores de 0xWord en Latinoamérica

Aún así, a día de hoy la editorial sigue adelante y, además de todos los que compráis los libros, contamos con la ayuda de distribuidores en los principales de Latinoamérica que nos ayudan a expandir el alcance de la editorial. En España solo se pueden conseguir los libros en la web de 0xWord - o recogerlos en la tienda de Móstoles con cita previa -.

Figura 2: Tienda de 0xWord en Móstoles

En Latinoamérica se pueden conseguir en muchos países hablando con el distribuidor local - aunque a veces hay que tener algo de paciencia con el envío. Recientemente hemos añadido Costa Rica y Panamá a la lista de países, así que en el artículo de hoy os dejo la lista completa de los países en los que puedes pedir los libros.

Figura 3: Distribuidor de 0xWord en Argentina

Figura 4: Distribuidor de 0xWord en Chile

Figura 5: Distribuidor de 0xWord en Colombia

Figura 6: Distribuidor de 0xWord en Costa Rica

Figura 7: Distribuidor de 0xWord en Ecuador

Figura 8: Distribuidor de 0xWord en México

Figura 9: Distribuidor de 0xWord en Panamá

Figura 10: Distribuidor de 0xWord en Uruguay

Estos son los distribuidores que tenemos hoy en día. Nos faltan países, como Perú, Bolivia, Honduras o Venezuela, pero si vas a alguna conferencia en estos países en los que sí hay distribuidor tal vez puedas conseguirlos.

Saludos Malignos!

Hoy "Un informático en el lado del mal" cumple 12 años

Desde que era un niño mis amigos siempre fueron mayores que yo. Como una forma de aprender más rápido de su experiencia, o simplemente por que había madurado un poco más deprisa, siempre tenía más afinidad con gente de más edad que yo. Y no me gustaba eso. Yo quería ser mayor.  Siempre quise tener más edad. Aprender más deprisa. Crecer más rápido. Hice cosas siempre fuera de mi edad. Descompensado con mi tiempo. Rápido. Muy rápido. Que hay muchas cosas aún por hacer. Un viejoven repelentillo que estudiaba mucho, leía todo lo que le caía en las manos y siempre pensaba en nuevas cosas que hacer.

Figura 1: Hoy "Un informático en el lado del mal" cumple 12 años

Tenía en las tripas un veneno que me hacía botar por la noche en la cama si no conseguía comenzar con el proyecto que tenía en mente. Circulando en mi cabeza. Arriba y abajo. Dando vueltas a cada detalle que podía imaginar. Quería hacer cosas. Y las quería hacer ya.

No, no penséis que estoy hablando de construir sistemas tecnológicos - que también - o hacer proyectos en mi etapa profesional. Hablo de cualquier iniciativa personal. Caricaturas. Un trabajo para el instituto. Un programa para mí mismo. Desde hacerme librerías para pintar ventanas, hasta programas para reprogramar el código ASCII y hacer dibujos y pequeñas animaciones. Dibujar un logo. Anunciarme para dar cases particulares en todos los medios que pudiera o encontrarme con Rodol para ver si conectábamos los equipos vía RRAS para jugar al Quake II. Veneno en las tripas que me obligaba a hacer cosas.

Y vaya que sí las hice. No recuerdo tener un día sin estar metido en algo. Sin tener algo que rondara mi cabeza al acostarme. Sin levantarme de un salto para pelear el día. El veneno sigue ahí.  No, ya no quiero ser mayor. Ya no soy el más joven de mis grupos sociales. Ya no quiero que el tiempo pase deprisa para hacer más cosas. Ahora quiero que el tiempo pase despacio para que pueda hacer más cosas. Paradojas de la edad.

Entre todas las cosas que pasaron por mi cabeza en una de esas noches envenenadas fue la construcción de este blog. Era el 26 de Enero de 2006 cuando publiqué el primer post. Un sitio sin muchas pretensiones al inicio, pero con vocación de durar. Yo no hago las cosas por hacer. Si me pongo a hacer algo, es que lo voy a hacer. No dejo las cosas a medias. No dejo las colecciones de cromos sin terminar. No dejo las series sin acabar. Y cuando di al botón de publicar en este blog sabía que era un camino que empezaba que sería largo, porque no tenía fecha de finalización.

Si me hubieran preguntado en aquellos años si iba a aguantar doce años con él, no habría sabido decir. Me hubiera dado un poco de vertigo. Doce años eran más que los años que llevaba trabajando en tecnología cuando abrí el blog. Lo cierto es que los he aguantado.

Por el camino he tenido tiempo de vivir varias vidas. De poner mi vida patas arriba varias veces. De vivir las experiencias de varios tipos de vidas. De construir y reconstruir mi vida profesional y a Chema Alonso varias veces. De ponerme el gorro en más de mil ocasiones sobre un escenario. De iniciar proyectos de todo tipo. De hacer Retos hacking. Publicar libros. Hacer herramientas. Arrancar con Talentum. ElevenPaths. LUCA. Aura. Informática 64. 0xWord. De cuidar de Cálico Electrónico. De viajar. De dibujar. De leer. De montar en monopatín. De ser Telefónica. De bañarme en el mar. De tirarme por la montaña con la tabla de Snowboard. De patinar sobre hielo. De hacer miles de kilómetros en bicicleta. De romperme las piernas en las rocas. De reír con "Los niños perdidos" hasta llorar y que me duela la tripa.

Por el camino he creado al Dragón Matías. He escrito cuentos a Mi hacker y a Mi Survivor. He escuchado música hasta la saciedad. He conocido a mucha gente que sigue en mi vida. A muchos que se fueron. He perdido a gente que se ha ido dejando vacíos. He conocido a gente maravillosa. De llamar a Rodol una vez más para decirle "Tengo una idea" y liarle para algo nuevo.

Y el blog ha estado ahí. Como compañero de mis penas y alegrías. Como ventana al mundo para contar lo que vivía. Como mi bitácora emocional para que pueda recordar mi vida. Puedo leer los posts y saber cómo me sentía cuando lo publiqué. Qué hacía. Con quién estaba desayunando ese día. Con quién estaba comiendo cuando lo escribía para el día siguiente. Con quién lo comenté antes de escribirlo. Es difícil no haberme conocido y no estar conmigo en algún momento que tuviera que ver con el blog. He publicado desde New York, desde Buenos Aires, desde Inglaterra, desde China, desde Brasil, desde Alemania, desde Noruega, desde Egipto, desde Barcelona, desde Zamora u Orense, por citar solo algunos de los rincones del mundo desde los que he dado publicar un nuevo post.

He escrito en Noche Buena, en Noche Vieja, en mi cumpleaños, en días de mudanza, enfermo, alegre, contento y triste. Muy triste. Dolorido. Sufriendo o con fruición. En silencio. Con música - como ahora mismo -. Escuchando a Rosendo decir eso de "Voy a ser el enemigo disparando Pan de Higo", a Linkin Park con su "Sharp edges", a Queen, a Los Rodriguez con su "Todavía una canción de amor", a Loquillo con su "Voy a ser una Rock'n Roll Star" o a Bon Jovi y su "Born to be my baby". Doce años dan para muchos días. Muchas noches. Muchas canciones. Muchas letras. Muchos sentimientos. Muchos momentos. Muchas vivencias buenas y malas.

Y ahí están hoy. Doce años. Más de 4.400 posts. Con textos de todo tipo. Desde artículos técnicos, hasta chorradas personales. Con dedicatorias escondidas para amigos. Con mensajes de amor dentro de las letras. Con pullas. Con entrevistas. Textos que poco a poco han ido enriqueciéndose con los artículos de amigos que han subido el nivel de mis publicaciones. Con mis dibujos. Con tus comentarios. Con mis ideas. Mis anhelos. Con el toque que cada una de las personas que he conocido en mi vida ha influido en mis letras. Están ahí. 

¿Seré capaz de mantener Un informático en el lado del mal otros doce años más?

Si por mí fuera, no dudéis que así será. Me haré muy mayor para entonces, pero firmaría ahora. Aunque no creo que pase. Supongo que un día algo sucederá. Cambiará mi vida. Me esconderé del mundo y me iré, como dice Rodol, a una isla con un cocotero. Yo a dibujar y leer, seguro. Para que me visite Mi Hacker y se venga a pintar conmigo algún monstruo a pachas mientras se recuesta sobre mí. A esperar a ver si este año Mi Survivor encuentra un rato entre aventura y aventura para venir a ver su papaete. Tal vez con una sonrisa a mi lado que me regañe y me cuide cuando esté estresado.  Que me de un masaje relajante para calmar los nervios en mitad de la noche. Como me ha pasado tantas veces cuando el estrés me sacaba botando de la cama por culpa del trabajo o por no tener listo el post para publicar a tiempo en "Un informático en el lado del mal".

Saludos Malignos!

Cómo pude haber aprobado un máster sin estudiar... pero lo reporté

Hace un tiempo comencé a buscar información sobre algún Máster para profundizar en mis estudios de informática. En la actualidad, con lo amplio que es el mundo del conocimiento en informática, se quedan cortos los pocos años de la Ingeniería de Informática de Sistemas que he estudiado en la URJC y quería profundizar algo más. Así que, utilicé Internet para revisar las ofertas de másteres en las universidades que más me llamaban la atención, escrutando la información que ofrecen en sus páginas web.

Figura 1: Cómo pude haber aprobado un máster sin estudiar... pero lo reporté

Pero la "deformidad profesional" que tengo en el desarrollo de "canales digitales" - una manera muy moderna de llamar a los puntos de interacción con los clientes, ya sean páginas web, aplicaciones móviles, los famosos chatbots o las redes sociales - me llevó a profundizar un poco más en algunas de las webs de las universidades en cómo estaban diseñadas y acabar haciendo algo de Hacking Web Technologies, lo que me llevó a descubrir un fallo de seguridad bastante relevante en la web de UAB.

Está página me llamo la atención porque descubrí que estaba desarrollada con un gestor de contenidos sobre el que tengo bastante conocimiento, Oracle Webcenter Sites. En concreto, delató el uso de este gestor de contenidos el formato no amigable de las URLs.

Figura 2: URLs del portal de contenidos

Esto se puede configurar de otra forma, pero a partir de este pequeño detalle, un cúmulo de errores mucho mayores en la gestión de la seguridad da a cualquier persona la capacidad de acceder a la base de datos de la web, al gestor de contenidos e incluso poder ejecutar una Shell Remota contra los servidores de la universidad. En definitiva, cualquier persona podría aprobar el máster sin pasar por clase - a falta de ver otros controles que se tengan más allá del sistema informático .-  Para entender bien el problema, hay que tener en cuenta dos cosas principalmente.

• Arquitectura de Webcenter Sites: La arquitectura común de Webcenter Sites, es similar a la de cualquier otro gestor de contenidos. Existe un usuario "lector" capaz de navegar por la web de manera pública, pero sin acceso a la aplicación de gestión de contenidos. Este "bloqueo" de acceso, como en otros gestores está basado en permisos de usuario. 

• Aplicaciones de Gestión de Webcenter Sites: Es habitual en este gestor de contenidos instalar una "extensión" comúnmente conocida como Support-Tools que nos brinda unas herramientas para detallar la configuración del servidor donde se instala Webcenter Sites, y que además nos habilita de un catálogo operaciones de mantenimiento/administración extremadamente útiles. El acceso a esta extensión, como ocurre con el acceso a la interfaz de "contribución" de contenidos está basado en Roles.

Los errores en esta web

En este caso existían dos errores graves que permitían el ataque:

1.- Se ha dejado accesible desde internet el acceso a la herramienta "Support-Tool" 

2.- Se ha otorgado al usuario "lector" el ROL necesario para acceder a la herramienta "Support-Tool"

Y a partir de esto,  cualquier atacante podría tomar control del sistema. Vamos a ver cómo es el proceso. Como ya os he dicho, conocía el gestor de contenidos, así que lo primero que miré al llegar a la web fue ver si estaba accesible la herramienta Support-Tool desde Internet, y como veis el resultado fue positivo.

Figura 3: Support-Tool expuesta a Internet

Esto es un error de fortificación, ya que habría que reducir la superficie de exposición, haciendo que solo estuviera accesible desde dentro de la red, o vía conexiones VPN, pero en muchos casos, acaban siendo publicadas en Internet.

Como se puede ver, el portal además se ofrece vía HTTP, y no bajo HTTPs, lo que es un problema que permite a cualquier ataque de sniffing o man in the middle, capturar las credenciales de los usuarios, algo muy peligroso cuando hablamos de un sistema expuesto a Internet.

Figura 4: Páginas de administración indexadas en Google

Lo siguiente, lógicamente, era comprobar las credenciales, para ver si tenían los usuarios por defecto con sus passwords por defecto, si habrían implementado sistemas de Segundo Factor de Autenticación como Latch o como un TOTP, o no. Probé con los usuarios por defecto, los cuales rechazaban el login. Pero una última prueba me reveló el problema del rol que os comenté antes. Las páginas de administración de la herramienta eran accesibles sin necesidad de password de administración o gestión.

Figura 5: Páginas de administración accesibles sin necesidad de sesión de administración

Una vez dentro se pueden realizar multitud de operaciones, entre ellas tirar consultas contra el motor de la base de datos del gestor de contenidos. Siendo posible poder recuperar, por ejemplo, el listado de usuarios existentes con los hashes de las passwords.

Figura 6: Consulta para sacar los usuarios del SGBD

Realizar cambios sobre el SGBD ya nos da acceso casi completo a la web, pero la sorpresa vino cuando al tratar de descifrar el password del usuario administrador desde una herramienta de coincidencias online, se produjo un "match".

Figura 7: Hash de password de administrador descifrado

Este match quiere decir que tenemos acceso a la herramienta como usuario administrador. Lo que nos permitirá además de modificar la web a nuestro antojo, subir diferentes programas Java - como una Shell Remota, o un RansomWare tan de moda últimamente - que se  ejecutará sobre la máquina el usuario que esté corriendo el servidor. Por supuesto, no había configurado ningún 2FA como Latch, por lo que una vez que se tiene la password, cualquiera puede entrar.

Figura 8: Acceso como Administrador

En resumen, lo que me encontré fue:

- Exposición de portal de administración en Internet. 

-  Páginas de login sin usar conexiones cifradas bajo HTTPs. 

- Gestión de sesiones inseguras, lo que permitía acceder a administración. 

- Usuarios sin 2FA. 

- Webs sin auditorías de seguridad.

- Mala gestión de las opciones de indexación del sitio web.

Después de esta aventura no acabé con cinco másters y una beca pre-concedida para el resto de mi vida. Les avisé de todo esto a los administradores del sitio, y a día de hoy la web ha sido cambiada por completa. Con esto aprendí que antes de que se publique cualquier tecnología por un "canal digital" hay que hacerle unas buenas pruebas de seguridad.

Saludos y a estudiar mucho, no seáis malignos!

Autor: Eduardo Trujillo, Ingeniero de Sistemas.

Google alerta de las apps NO verificadas al pedir permisos OAuth. Microsoft Office 365 aún debe mejorar un poco.

Hace ya dos años que comenzamos a trabajar sobre la posibilidad de que aparecieran apps maliciosas en el mundo del cibercrimen para robar datos de los sistemas IdP de plataformas como Gmail u Offife365. Sobre el funcionamiento de estos ataques construimos Sappo, una prueba de concepto de cómo una app maliciosa inyectada en el IdP de Google u Office365 mediante una ataque de phishing que robara tokens OAuth privilegiados para leer el correo, gestionar la agenda, y, como expusimos en un paper, construir ataques RamsonCloud.

Figura 1: Google alerta de las apps NO verificadas al pedir permisos OAuth.
Microsoft Office 365 aún debe mejorar un poco.

Como se puede ver en la demo de Sappo que hicimos para la RootedCON 2016, un atacante podría, usando una app maliciosa, robar un token OAuth que fácilmente cifrara el contenido de un buzón completo de Office 365.

Figura 2: Demo de Sappo en Rooted 2016

Meses después de aquella charla, vimos como se creó un gusano en Gmail que utilizaba justo ese mismo truco, tal y como expliqué en el artículo de "Cómo se ha hecho a Gmail el ataque de Spam masivo por Auth". Es decir, el cibercriminal creo una app integrada en el IdP de Google que utilizó para conseguir el token OAuth2 de las cuentas afectadas. Una vez dentro, accedía a la agenda de contactos y volvía a distribuirse.

Figura 3: Enlace que se re-enviaba por Gmail para robar tokens OAuth

Desde aquel entonces Google ha tomado cartas en el asunto, y ha puesto una alerta bastante gorda cuando se quiere dar permisos OAuth a apps que no han sido verificadas por las manos de sus ingenieros de seguridad. Es decir, un Warning rojo que debería hacer pensar a más de uno antes de darle un token OAuth privilegiado a esa app.

Figura 4: Alerta que da Google cuando la app no ha sido verificada y pide tokens OAuth privilegiados

Sin embargo, en el caso de Office365 - una plataforma ampliamente utilizada en la empresa, y que es fácil de comprobar si una empresa utiliza solo mirando los registros DNS - aún mantiene un sistema mucho más relajado con las apps.

Figura 5: Kevin Mitnick explicando Ransomcloud Office365

Tal y como se puede ver en el vídeo que hizo mi amigo Kevin Mitnick (@kevinmitnick) sobre Ransomcloud, la pantalla de Microsoft Office 365 para dar permisos a tokens OAuth sigue siendo muy user-friendly incluso cuando la app no ha sido verificada por nadie - y es maliciosa como en este caso -.

Figura 6: Pantalla que recibe un usuario con una app NO verificada (y maliciosa)

A ver si mis amigos en Microsoft me ayudan a pedir que empiecen a tomar cartas en el asunto a los equipos de seguridad antes de que tengamos una hecatombe con el sistema de Office 365 en muchas empresas.

Saludos Malignos!

Named Pipe Impersonation: Escalando privilegios en Windows

Cuando te enfrentas a una escalada de privilegio en un pentesting dentro de un Ethical Hacking existen diferentes formas de afrontar este problema. La búsqueda de fallos en la configuración de los servicios, la búsqueda de la falta de paquetes de actualización en Windows mediante herramientas como Windows Exploit Suggester o el aprovechamiento de una vulnerabilidad en un instante de tiempo, ya sea porque tiene poco tiempo o porque no ha sido parcheada, como puede ser Hot Potato y su implementación en Powershell con Tater.

Figura 1: Named Pipe Impersonation: Escalando privilegios en Windows

Sin duda, la post-explotación puede ser una tarea ardua, aunque en algunas ocasiones nos parezca algo "sencillo". Hoy quería hablar del funcionamiento de la técnica Named Pipe Impersonation y cómo puede ser detectada gracias al registro de eventos de Windows. Este tipo de técnicas y otras se podrán conocer en el lab de Metasploit de Rooted CON 20018 - si te apuntas  y te has leído el libro de Metasploit para Pentesters 4ª Edición antes, podrás sacar lo máximo del training.

¿Qué es Named Pipe Impersonation?

Lo primero que hay que decir es que es una técnica utilizada dentro del framework de Metasploit, aunque también podría ser utilizada fuera de dicho contexto. Es una técnica que permite escalar privilegios. Un named pipe es una técnica que tiene el sistema operativo Windows para facilitar la comunicación entre procesos. Es sencillo, si un proceso quiere "contactar" con otro, el primero de los procesos puede enviar un mensaje sobre la red o utilizar un fichero. En el segundo caso, el proceso escribe el mensaje en un fichero y el otro proceso lo lee.

Esta es la base de la técnica Named Pipe, por lo que, si se mira desde el punto de vista de un pentester, ésta puede ser utilizada para lograr un objetivo como el de ejecutar un código en un contexto privilegiado. Hay que tener en cuenta que el malware NotPetya utilizaba un nuevo proceso para comunicarse con el malware y hacer un dumpeo de credenciales. Este proceso utilizaba esta técnica para utilizar una comunicación encubierta, entre el proceso y el malware.

¿Qué significa realmente "impersonar" un Named Pipe?

Imagina un servidor y un cliente. El cliente solicita al servidor que realice alguna acción, por ejemplo, una consulta a la base de datos. El servidor puede tener control total sobre la base de datos, pero, por el contrario, el cliente puede tener un acceso limitado. Si el cliente no tiene los suficientes privilegios, el servidor nunca le dará o ejecutará la consulta que éste pueda solicitar. Hasta aquí, todo claro.

¿Qué ocurre si el cliente tiene más privilegios que el servidor? Tú puedes pasar este hecho, es decir, estos privilegios al servidor para que utilice dichas credenciales. El servidor puede "impersonar" la cuenta del cliente para realizar las acciones que requiera. Esta idea es la utilizada en el contexto del named pipe, es decir, si un proceso crea un pipe, este proceso será propietario del pipe server. Cuando otro proceso conecta a este pipe, éste llamará al pipe client. Una vez ambos conecten, el pipe server puede utilizar el privilegio del pipe client, el contexto de seguridad en el que se ejecuta el cliente o los privilegios que éste tiene.

Figura 2: Namedpipe.c en Meterpreter

Este hecho puede ser aprovechado para crear un pipe server con bajos privilegios e intentar conectar con un cliente con más privilegio que el pipe comentado. Cuando esto sucede, el pipe server podrá realizar acciones con los privilegios del cliente. Metasploit simplifica este hecho y lo automatiza a través del comando Getsystem del Payload Meterpreter. El código se puede encontrar en el Github del proyecto.

Profundizando un poco más

La idea está clara, pero ¿cómo interactúa realmente? Getsystem, cuando utiliza la técnica Named Pipe Impersonation, crea un pipe server con privilegios limitados. Posteriormente, configura un servicio en Windows, el cual será el cliente, para conectarlo a ese pipe. De esta forma se "impersona" el contexto de seguridad, ya que un servicio se ejecutará en un contexto de SYSTEM.

Como se puede ver en la documentación del código que implementa la técnica en el Github de Metasploit, se ejecutará una cmd.exe bajo un contexto de SYSTEM para que conecte al named pipe y se "impersonará" a este cliente. Esto puede ser llevado a cabo cuando se es Administrador sin la necesidad de tener el permiso SeDebugPrivilege. Esta técnica trabaja con Windows 2000/XP/2003 y 2008. En Windows Vista y Windows 7 solo trabaja si el proceso ha sido elevado a través de UAC o con un bypass de UAC. En versiones más modernas del sistema operativo también sigue funcionando.

Figura 3: Elevación de privilegios a SYSTEM para hacer la impersonación

En el caso de que la técnica no tenga éxito, se intenta un método similar llamado named pipe impersonation 2. En este caso, Meterpreter subirá una DLL al equipo y la ejecuta por medio de rundll32.exe, haciéndolo como servicio. La DLL se ejecutará en el contexto de SYSTEM y conectará con el pipe server para "impersonar" el token.

En la imagen, se puede ver como se obtiene una sesión en la que hay un token con la identidad y el privilegio del proceso.

Figura 4: Obtención de sesión con privilegios

El comando getsystem tiene diferentes técnicas implementadas para llevar a cabo la escalada de privilegio. Se utiliza la opción 1 para utilizar la técnica Named Pipe Impersonation, aunque la técnica 2 utiliza el mismo procedimiento, solo que hay que hacer la parte de la DLL en disco y la ejecución a través de la invocación del servicio y rundll32.exe.

Como se puede ver en la imagen, se utiliza la opción "-t 1" para seleccionar la técnica de Named Pipe Impersonation, explicada anteriormente.

Figura 5: Con -t 1 se configura Named Pipe Impersonation

En resumen, y para simplificar el entendimiento de la técnica, se ejecuta un proceso el cual se está ejecutando con el token, el cual tiene limitados los privilegios. El proceso creado genera un pipe con un nombre aleatorio. En este ejemplo se llama gbsbtr el pipe. El pipe es creado con el privilegio del usuario.

Figura 6: Uso de Named Pipe Impersonation en Meterpreter

Desde los servicios de Windows se puede ejecutar un nuevo servicio, el cual se ejecuta con usuario SYSTEM y puede enviar cualquier mensaje a través del pipe llamado gbsbtr. Aquí tenemos la escalada. El servicio es creado y está listo para conectar con el pipe. Cuando el servicio arranca, se lanza un cmd.exe como SYSTEM y conecta al pipe creado por el proceso generado por Metasploit, el cual ahora obtiene un entorno de SYSTEM.

Detectándolo en la máquina

Ahora, vamos a ver cómo detectar esta situación en una máquina comprometida. Para ello hacemos uso de Powershell y del cmdlet Get-EventLog. Buscamos dentro del mensaje de los eventos el contenido "A service ". Nos devolverán todos los eventos que encajen con lo buscado.

Figura 7: Buscando servicios con PowerShell

En esta ocasión, se puede ver como se recopila la información del registro de eventos de Windows y se buscan los servicios que tienen un pipe creado para interactuar. Hay que fijarse en la expresión regular de "*\\.\pipe*".

Figura 8: Buscando servicios con pipe

Una vez tenemos esto, se puede ver que lo almacenamos en una variable. Esta variable el contenido de los diferentes objetos podemos verlo con la instrucción $services | ForEach-Object {$_.message}. Obtenemos el comando ejecutado por cmd.exe y el servicio creado, además, de la cuenta de servicio utilizada, en este caso se puede ver como realmente es SYSTEM.

Figura 9: Servicio instalado

Una técnica interesante para el pentesting y que muchas veces utilizamos en el día a día. Es interesante ver cómo funciona por debajo y saber que está ocurriendo a nivel de proceso para que esto tenga éxito y en qué condiciones puede fallarnos.

Figura 10: PoC de Named Pipe Impersonation

En el vídeo anterior tenéis una demostración de 1 minuto paso a paso de cómo funciona el proceso de Named Pipe Impersonation desde una equipo con Kali Linux.

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