Figura 1: VBook Windows Server 2016. Los Video-Books de 0xWord
Se trata de la adaptación de los contenidos de nuestros libros a capítulos en vídeo hechos por los propios autores de los libros de 0xWord, pero con vídeos que permiten acceder a las explicaciones técnicas y las prácticas expuestas en el libro directamente en vídeo.
El primero de los que hemos lazando ha sido el VBook de Windows Server 2016, en el que Ángel A. Núñez recorre los contenidos del libro de Windows Server 206 para entregarlos en formato vídeo. Esta es la agenda del mismo.
Los VBooks se consumen online, y están disponibles durante seis meses para que se pueda consultar tantas veces como se considere necesario, con el objeto de hacer mucho más cómodo consumir el contenido del libro. Por supuesto, siempre puedes optar por el formato clásico del libro y acceder a los contenidos modo "old-school".
El próximo 13 de Julio llega a Barcelona el evento Changing the Game with Big Data, organizado por LUCA D3, la unidad de Telefónica que ayuda a las compañías a recorrer el camino hacia empresas Data-Driven.
El registro está ya abierto, y tendrá lugar en el Auditorio en Torre Telefónica en Diagonal 00, sito en Plaça d'Ernest Lluch i Martin, 5, 08019 Barcelona. Este fue el lugar en el que presentamos por primera vez nuestra querida Aura, y es el lugar elegido para realizar el primer evento en Barcelona de LUCA D3, donde se podrán ver los productos y servicios que realiza Telefónica para clientes.
En este evento, además de poder ver casos concretos de usos de BigData para negocios como el transporte, el retail, el turismo, el mundo de la publicidad o las smartcities, se podrán ver casos concretos con clientes que los utilizan, contando en primera persona sus experiencias.
Ayer un nuevo ataque de ransomware ha comenzado a copar las portadas de todos los medios de comunicación, y también las redes sociales. No es nada nuevo, y son "solo" dos viejos amigos que se han juntado para volver a intentar hacer un WannaCry. Al igual que en la infección de WannaCry, el atacante ha unido un ransomware bastante conocido, como es Petya, y lo ha unido a la vulnerabilidad de Microsoft WindowsEternalBlue, que fue utilizada en el caso de WannaCry. Es decir, un ransonmware más un exploit para crear un gusano y viralizar las infecciones.
Figura 1: Petya con Eternalblue, el miedo a un nuevo WannaCry
y el incentivo a no parchear inmediatamente de Microsoft
En este caso, el ransomware actúa de forma distinta a WannaCry, ya que Petya cifra el MBR (Master Boot Record) del disco duro al estilo de los Bootkits, lo que hace que aunque tengas los documentos protegidos en carpetas seguras, o bajo contenedores cifrados, tus documentos siguen desapareciendo. Lo que no le hace ninguna gracia a los dueños de los equipos. El resultado es el que puede verse en esta foto, de un supermercado de Ucrania que ha circulado por las redes sociales.
Figura 2: Equipos infectados por Petya en un supermercado de Ucrania
Este ataque utiliza otra vez una versión evolucionada de EternalBlue, el mismo fallo de seguridad de Microsoft Windows que utilizó WannaCry para la distribución, así que los equipos que se parchearon durante el ataque del mismo, deberían estar a salvo de posibles infecciones de este ataque. Y la pregunta que surge a muchos... ¿todavía quedan empresas u organizaciones que no se hayan parcheado?
La pregunta tiene toda la lógica del mundo, especialmente después de WannaCry, pero.. vamos a pensar en un mundo nuevo, en el que después de WannaCry todo el mundo comienza a parchear al día siguiente de que salgan las vulnerabilidades. Es decir, que desaparecen los tiempos de QA en los parches. De hecho, Microsoft se "atrevía" a denominar a los equipos no parcheados aún como "Out-Of-Dated", algo que no era del todo cierto. Podían ser equipos en proceso de validación del parche.
Esto querría decir que no se prueba el software en los sistemas antes de poner en producción el parche y eso no es una buena idea. Microsoft, cuando saca un parche, lo prueba con su software soportado, pero no con el software que no es suyo. Miento, es cierto que Microsoft, debido a la notoriedad e importancia de algunos software, tiene el compromiso de probar el software con algunos otros fabricantes, para garantizar que sistemas críticos no fallan, para lo que firmaron acuerdos de colaboración en los procesos de QA. Pero estas son excepciones, y no lo hacen con el software hecho a medida en las empresas.
¿Puede fallar de verdad tu programa si se aplica un parche de Microsoft?
Con estos fallos en las actualizaciones de seguridad, es la propia Microsoft la que "incentiva" de manera involuntaria, a que se extiendan los tiempos en los procesos de QA, porque puede llegar a ser más costoso para una organización con cientos de miles de equipos el costo de repararlos todos - si se aplica masivamente un parche defectuoso - que detectar y responder contra un ataque que aproveche un fallo de seguridad durante la ventana de tiempo de los procesos de QA.
Es decir, al final es una gestión del riesgo que debe balancear adecuadamente los procesos para garantizar integridad, privacidad y disponibilidad del negocio. Y por supuesto, cuanto más calidad tengan los parches, mejor que mejor, pues los tests de QA de las empresas no necesitarán ser tan exhaustivos y largos en todos los casos. No hay magia, solo trabajo.
Hace tiempo nuestro compañero Chema Alonso habló en un artículo de las Hidden Networks que se crean en las organizaciones gracias al - o por culpa del - uso de los dispositivos de almacenamiento USB. En el equipo de ideas locas de CDO de Telefónica estamos trabajando en diferentes experimentos y uno de ellos tiene que ver precisamente en cómo descubrirlas de forma rápida para tener un mapa actualizado de estas redes.
Figura 1: Script PowerShell WinRM para descubrir Hidden Networks
Antes de nada, vamos a repasar someramente lo que son las Hidden Networks y por qué son importantes ya que, seguramente, muchos administradores desconocerán estos riesgos. Cómo se menciona en el artículo de 2014 sobre las Hidden Networks, muchas organizaciones hablan de segmentos de redes aislados controlado e tráfico de uno a otro por un dispositivo de seguridad de red, pero, ¿realmente están aisladas? ¿o están unidas gracias a los dispositivos de almacenamiento USB?
Figura 2: Lista de dispositivos USB conectados a un equipo Mac OSX
Las redes de equipos aislados como, por ejemplo, una red de sistemas de control de fábricas puede estar aislados por seguridad. Esto sería algo lógico, pero si repasamos la historia de la informática nos encontramos con incidentes como Stuxnet, el cual se coló totalmente en una red aislada. Y recientemente hemos sabido del software de Brutal Kangaroo de la CIA que utilizaba los dispositivos de almacenamiento USB para infectar equipos totalmente desconectados.
Figura 3: Brutal Kangaroo para infectar discos -USB
En otras palabras, la historia nos ha demostrado que para tener una red aislada no es suficiente con tener una red de equipos no conectados con cable Ethernet o ß, y que para contener lo que pasa en una red de una empresa, no es suficiente con segmentar las conexiones de red con Routers, Firewalls o Switches L3. Es decir, cualquier conexión que tengamos con el exterior, por ejemplo, a través de un puerto USB, puede conllevar una amenaza y la materialización de ésta provocando un incidente de seguridad.
PoC: Descubriendo a los USB que crean tus Hidden Networks
Hoy queremos mostrar un pequeño ejemplo en forma de prueba de concepto. Mi compañero Francisco José Ramírez ha creado un script en Powershell aprovechándose de la característica de gestión remota de Powershell WinRM. Esta característica permite a los administradores de IT poder lanzar instrucciones remotamente través de un dominio de Microsoft Windows. Existe una rama del registro que almacena los dispositivos que se conectan al equipo, como ya explicaba Chema Alonso en su artículo.
Figura 4: Claves del registro con IDs de discos USB conectados
Estos datos se pueden obtener en la siguiente ruta del registro SYSTEM\CurrentControlSet\Enum\USBSTOR, así que con un poco de programación podríamos ver todos los de los equipos de nuestra red. El código a modo de prueba de concepto en Powershell tiene el siguiente aspecto:
En breve lo subiremos al Github de ElevenPaths para que podáis utilizarlo a través de la característica WinRM. En la siguiente imagen os mostramos cómo ejecutando el scriptHiddenNetworks sobre un dominio que tiene varios equipos se puede hacer un listado de dispositivos USB que fueron insertados en dichos equipos, y estos podrían ser discos de almacenamiento, webcams o cualquier otro dispositivo que pueda realizar una función "polinizadora" de tu red.
Figura 5: Dispositivos USB detectados por cada equipo
Este hecho, puede ayudarnos a relacionar qué equipos han insertado el dispositivo USB, es decir, por cuáles equipos ha ido pasando el mismo dispositivo USB. Incluso, se puede trabajar en un timeline de un dispositivo USB y los equipos por los que ha ido pasando para conocer, en un momento de crisis, cuál ha sido el camino seguido de la infección, por lo que tener estos logs diarios en tu organización es de gran valor.
Figura 6: Grafo de conexiones USB en la red hecho con Gephi
Nosotros hemos utilizado una herramienta llamada Gephi para realizar un grafo que relaciona diferentes equipos, que harán de nodos, con dispositivos USB insertados en esos equipos, que serán sus aristas. Cuando dos equipos tienen una unión, significa que dicho USB ha estado conectado en ambos creando una Hidden Network temporal dentro de la organización. Incluso, una red segmentada o equipos que se encuentran en diferentes VLANes pueden quedar expuestos ante este tipo de redes ocultas.
Figura 7: PoC detectando Hidden Networks con PowerShell WinRM
Os dejamos un video dónde se puede ver a Hidden Networks actuando sobre un dominio de Microsoft Windows. ¿Has comprobado en tu red corporativa dónde se encuentran tus redes ocultas? ¿Has mapeado sobre un plano de red tus posibles redes ocultas? ¿Tienes estos logs bien guardados? Lógicamente, en este proceso nos quedarían aún los equipos macOS de Apple, pero esto lo vamos a atacar desde otra perspectiva que ya os contaremos más adelante.
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:
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.
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.
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.
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.
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.
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 s 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. París. 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. Y más. Mucho más.
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 el 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.
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.
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.
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.
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.
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.
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.
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
