El bug de IIS Short Name sigue vivo explotado con el método OPTIONS y lista los ficheros de tu servidor web

Esta semana hemos andado acelerando la modificación de un plugin de nuestro sistema de Pentesting Persistente Faast, debido al descubrimiento de que el bug de Short Name en servidores web IIS de Microsoft que permite listar los ficheros en formato 8:3 no se mitiga de igual forma para el método GET que para el método OPTIONS de HTTP, haciendo que de nuevo se pueda visualizar toda la estructura de archivos y carpetas de un directorio publicado en un servidor web IIS - siempre en formato 8:3 -.

Figura 1: El bug de IIS Short Name sigue vivo con el método OPTIONS

Después de actualizar nuestra knowledge base en Faast y de notificar a nuestros clientes de cómo mitigar este bug, ayer sacamos en el blog de Eleven Paths un pequeño post explicando en qué consiste el fallo.

El bug de IIS ShortName para listar archivos

Como se ha explicado muchas veces, este bug afecta a todas las versiones de IIS siempre que haya compatibilidad en el sistema de ficheros NTFS con el formato de nombres cortos. En este escenario, una petición utilizando los caracteres especiales permiten hacer un ataque de booleanización a ciegas para extraer los 6 primeros caracteres del nombre - los otros tres caracteres son para ~1 (o ~2) - y los tres primeros de la extensión.

Figura 2: Pruebas a realizar para detectar la vulnerabilidad

Dependiendo de la versión de IIS hay que probar diferentes condiciones para saber si es una respuesta positiva - existe un fichero con ese patrón en el nombre - o negativa - no existe ningún fichero que cumpla ese patrón -.

Figura 3: Listado de carpetas de windows.microsoft.com
con el bug de IIS Short Name explotado por GET

Una vez comprobado que existe ese fallo, es fácil hacer una automatización para extraer la lista completa de los ficheros, e incluso en Microsoft.com, con el plugin de la FOCA era posible listar el contenido del directorio. Si tienes el libro de Pentesting con FOCA, a este bug en concreto se le dedican partes en profundidad.

El parte del método GET y la nueva explotación por OPTIONS

Los servidores IIS fueron actualizados con una mitigación que ofrecía el mismo comportamiento para las respuestas TRUE y las respuestas FALSE, por lo cuál se acababa con la posibilidad de realizar un ataque de booleanización, pero esto no se mitigó en todos los métodos HTTP y con OPTIONS - un método que sirve para consultar cuáles son los métodos HTTP permitidos en una determinada ubicación del servidor web - se puede continuar detectando el bug y extrayendo el listado de archivos.

Figura 4: El fichero existe y se obtiene un 404 accediendo por OPTIONS

Cambiada la detección y explotación del bug IIS ShortName del método GET al método OPTIONS, muchos servidores que parecían estar parcheados frente a este bug vuelven a estar afectados, por lo que hay que tomar medidas.

Figura 5: El fichero NO existe y se obtiene un 302 con el método OPTIONS

Las alternativas no son muchas, deshabilitar el método OPTIONS en todos los servidores web con Internet Information Services, filtrar el método en los WAF (Web Application Firewalls) o bien deshabilitar la compatibilidad de nombres 8:3 en el servidor Windows Server. Para ello hay que configurar la siguiente clave de registro con un valor 1.

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

Si tienes un servidor web con Internet Information Services de Microsoft comprueba si es vulnerable y si lo es, toma medidas, porque si no te van a poder listar los ficheros de todo tu servidor web con más o menos facilidad.

Saludos Malignos!

Ghost: Por qué debes preocuparte por parchear tus Linux

Hace un par de días que la noticia de la existencia de una vulnerabilidad en las distribuciones Linux está dando la vuelta al mundo. Esto es debido a que explotando este bug se podría tomar el control del sistema operativo afectado remotamente y no de una manera demasiado complicada. Esta vulnerabilidad se ha bautizado como Ghost y debes preocuparte por erradicarla de todos tus sistemas operativos, y que como vas te va llevar cierto trabajo.

Figura 1: Ghost: Por qué debes preocuparte por parchear tus Linux

Un CVE con CVSS de nivel 10

El bug está en la librería glibc, utilizada masivamente por las distribuciones *NIX*, en todas las versiones que van desde la 2.2 de Noviembre del año 2000 hasta la 2.18 de Agosto del 2013 donde fue parchada. El bug en concreto se encuentra en la función __nss_hostname_digits_dots() alcanzable desde las funciones gethostbyname(), gethostbyname2(), gethostbyname_r() y gethostbyname2_r() que la llaman y que son utilizadas para obtener contra un DNS la resolución de un nombre de dominio y donde se encuentra el Buffer Overflow de Ghost que puede ser explotado forzando la resolución de un nombre concreto. 

Figura 2: CVE-2015-0235 relativo a Ghost. Tiene un CVSS 10

El uso de estas funciones es muy común y en una gran cantidad de entornos se puede acceder al Buffer Overflow remotamente, así que al bug que ha recibido el CVE-2015-0235 se le ha puesto un nivel de importancia de CVSS de 10, es decir, el máximo nivel de criticidad.

Figura 3: Explotación del Buffer Overflow en EXIM MTA

Para conseguir llegar al bug, el nombre que hay que introducir es un nombre de dominio de más de 1KB para alcanzar el Buffer Overflow, hacer que el nombre comience con un número y que esté construido enteramente de números y puntos. Una vez conseguido llegar al bug, hay que conseguir un exploit para Linux que sea capaz de ejecutar un payload en el sistema. Los investigadores de Qualys - empresa descubridora del bug - han hecho una prueba de concepto para explotar un servidor Linux con EXIM Mail remotamente.  Con este sencillo exploit de la imagen superior se puede tumbar el proceso de EXIM MTA (Mail Transport Agent) alcanzando el Buffer Overflow que está en el código vulnerable

Plataformas afectadas

Como se ha dicho antes, el bug se arregló en glibc 2.18 en Agosto de 2013, pero como el parche no fue marcado como de seguridad o crítico, muchas de las distribuciones Linux no la aplicaron hasta que se ha hecho pública Ghost, momento en que han salido parches críticos de casi todas las distribuciones. En el blog de Matasano se han recogido las principales distribuciones Linux afectadas - que no todas - para que estés alerta si tienes una de ellas.

Figura 4: Lista de distribuciones Linux afectadas (y no) por Ghost

El problema es que no solo estas distribuciones pueden ser afectadas, y muchas otras de routers, switches o Access Point WiFi pueden ser vulnerables también, por lo que debes ir sistema operativo de dispositivo por sistema operativo de dispositivo averiguando exactamente qué versión de glibc tienes instalada en él. Recuerda, este es un CVE con un CVSS de 10, lo que significa criticidad máxima en el mundo de la seguridad informática, y por tanto debes asegurarte de que todos tus sistemas operativos de todas tus plataformas quedan correctamente actualizados cuanto antes.

Saludos Malignos!

"¡Me han cifrado los archivos y me piden dinero para descifrarlos!". 5 Consejos para evitar un "Cryptolocker"

Ni sé cuántos correos llevo ya este año recibidos con un mensaje similar al del título. Gente desesperada porque han sido víctimas de un Ransomware que se ha ejecutado en su sistema operativo y le ha cifrado las fotos de su familia, los documentos de la contabilidad de la empresa familiar, los archivos con las contraseñas para acceder a servicios de Internet que ya no saben cómo recuperar o los trabajos de investigación de una vida. La cantidad de información que tenemos útil y valiosa para nosotros mismos en nuestros equipos es muy alta y mucho más valiosa de lo que te puedas imaginar en un momento dado. Es como cuando pierdes a alguien, no vas a saber cuánto querías a esa persona hasta que la echas de menos porque notas que ya no está, que se fue para siempre.

Figura 1: "Lo que el viento {cibercrimen} se llevó de mi vida"

Eso es lo que intenta hacer un Ransomware, es decir, quitarte algo que tú necesites y pedirte dinero a cambio de devolvértelo. Es un secuestro exprés en el que el mafioso se va a aprovechar de que tienes descuidado algo valioso para ti y te va a hacer pagar por ello. Estos Ransomware, en el pasado han podido ser analizados por los ingenieros de seguridad para encontrar de localizar el algoritmo y las claves de cifrado utilizados en cada instalación y generar un descifrador universal. Así ha sido a lo largo de muchos años, pero... solo era cuestión de que alguien lo hiciera bien para que pudiera liarse parda.

Figura 2: Mensaje dejado por uno de los ransomware distribuidos

En este caso, el despliegue de la última familia de CryptoLocker está haciendo estragos a nivel mundial. Muchos son los usuarios que están siendo infectados y, tras ver, el hilo de los acontecimientos a día de hoy no ha sido posible localizar una solución para descifrarlos más que pagar - algo que alienta a este tipo de negocios de fraude online en el futuro -. La transición económica del pago es a través de BitCoins y por la DeepWeb, para que ser menos traceable.

Figura 3: Para conseguir la clave de cifrado se introduce el ID del cifrado y se reciben las instrucciones

Llegado hasta este punto, haz un ejercicio de reflexión interna e intenta pensar qué harías ahora mismo si te robaran el equipo informático que tienes delante, del portátil o el disco duro & pendrives que llevas tirados en la mochila. Si después de pensar durante 5 minutos en qué tienes ahí, e intentar sentir cómo sería tu día siguiente sin ellos llegas a la conclusión de que es importante, toma medidas.

Medidas para protegerse contra un ataque de ransomware

Si has llegado hasta este punto, y quieres evitar en la medida de lo posible que esto te pueda pasar a ti - o que te vuelva a pasar -, te dejo una serie de recomendaciones para evitar que seas extorsionado con este tipo de prácticas mafiosas:

1.- Mantén todo el software de tu sistema actualizado: Normalmente estos fallos se aprovechan de exploits que suelen estar parcheados - no siempre, ya que a veces cuentan con algún 0day de Flash, Java o similares que explotan durante unos días todo lo que pueden -, a través de kits de explotación que ponen en servidores web hackeados o que distribuyen a través de campañas de malvertising.  

Figura 4: Una imagen de un antiguo panel de control de BlackHole con los explotis y las víctimas 

Cuantos menos bugs sin parchear tengas mejor. Actualiza tu Windows, pero también Java, Adobe Flash, VLC, todos tus navegadores de Internet, etcétera. Mantén todo tu software al día o entrégalo al enemigo. 

2.- Pon un Antimalware profesional con protección en tiempo real: Es una pena que mucha gente ponga en riesgo su vida digital por no tener un antimalware profesional de primer nivel como Intel Security, Kaspersky, ESET, Bitdefender, Symantec o similares con protección en tiempo real. En Tiempo Real, examinando conexiones de Internet, pendrives o cualquier conexión al sistema. No son ni mucho perfectos, pero te garantizo que si lo tienes los malos tendrán que mutar mucho el bicho para que te pille.

3.- Fortifica tu sistema: Muchas de las veces los engaños son tan tontos como incitarte a que instales un programa, como si fueran codecs de vídeo o similares, así que cuantos menos permisos tengas en tu sistema mejor. Configura el UAC al máximo nivel en Windows,  no utilices la cuenta de administrador para navegar por Internet y restringe el acceso a archivos importantes con listas ACL a cuentas privilegiadas que usas solo para acceder a ellos y no para navegar. Aplicar Máxima Seguridad en Windows es la idea.  

Por supuesto, fortifica tu navegador de Internet, así que revisa la configuración de los plugins para evitar que se ejecuten automáticamente. Revisa la configuración de los plugins en tu sistema y si son seguros o no. Puedes utilizar Browser Check para saber cómo está el navegador que estás usando ahora mismo.

Figura 5: Browser Check

4.- Haz un backup en discos desconectados y cifrados: Hazte una buena política de backups y cúmplela a raja-tabla. Usar un disco externo para los archivos importantes es una buena opción. Por supuesto, no los dejes conectados y con acceso para que cualquier ransomware que entre te los cifra también, así que desconecta el disco cuando acabes la copia.  Si no has hecho backup, revisa las Shadow Copies de Windows, para ver si hay alguna copia del sistema.

5.- Copia de seguridad en Cloud: Asegúrate que las copias de seguridad se hagan desde cuentas privilegiadas y que no puedan borrar los archivos de copias anteriores. Es decir, que hagan copias de seguridad pero que no puedan borrar las existentes. La política de borrado de copias de seguridad hazla en el servidor de Cloud con otro acceso. Así, si en algún momento se hace una copia de los archivos cifrados, podrás tener la copia anterior.

Nota sobre el Sentido Común como arma defensiva

Por último, me gustaría hacer una reflexión para todos esos que recomiendan "Sentido Común" como única medida de protección. El sentido común no te va a defender de un 0day, una campaña de malvertising o un ataque de waterholing a una web que visitas habitualmente. En esos casos el sentido común es que tengas tu equipo fortificado para ello y que no pienses que no necesitas haber robustecido tu sistema informático.

Como en todo lo que concierne a la seguridad informática, no hay garantía absoluta de que estas medidas sean del todo efectivas para el 100% de los casos, pero seguro que en muchos de los que estáis jodidos con estos extorsionadores podríais haber continuado tu vida sin tener que pagar el secuestro y además te ayudarán a vivir después de un posible robo/perdida del equipo o de que se te rompa porque... las cosas pasan.

Descifrar algunos ransomware

Un hacker ha compilado todas las soluciones conocidas para recuperar los ficheros de estos Cryptolockers en una herramienta llamada Ransomware Response Kit, así que prueba eso.

- Solución 1: Probar con las Shadow Copies de Windows
- Solución 2: Probar a descifrar una variación de Cryptolocker conocida como TeslaCrypt
- Solución 3: Probar a ver si funciona con solución que Kaspersky ha publicado con una herramienta para descifrar BitCryptor y CoinVault

Saludos Malignos!

En el market Mobogenie puedes infectar tu Android con malware del presente y del pasado

Si quieres ver cómo era una app creada para Android que ya no está disponible en Google Play, tal vez pueda ser una buena idea utilizar un emulador, descargar Mobogenie y conseguir esa herramienta, pero solo si lo haces con fines de usarlo como archivo histórico, y no como una forma de utilizar de manera inteligente tu propio terminal Android.

Figura 1: Puedes infectarte con todo el malware para Android si usas Mobogenie

Y es que el archivado de las apps, le lleva también a tener disponible una gran cantidad del malware que ha sido retirado de Google Play. Puede ser que alguien, inocente en sí mismo, busque una app mágica para hackear Facebook o para espiar WhatsApp, y simplemente con una mala búsqueda tras otra le lleve a terminar en este market alternativo.

Allí, la publicidad que usa Mobogenie está pensada para tranquilizar a los visitantes, con un mensaje como el que puede verse en la imagen siguiente, donde anuncian que todos los recursos que tiene son "Free and Safe". Además remarca el eslogan con un "Mobogenie te proporciona los mejores recursos para garantizar la seguridad de tu teléfono móvil". Ahí es nada.

Figura 2: Mobogenie es "Free and Safe"

Para probar si esto es así, utilizando Path 5 fui a buscar algún malware malo que haya rondado por Google Play, y que esté ya marcado como tal por las casas antimalware. Usando unas búsquedas en nuestra plataforma, fui a ver qué apps han sido marcadas como Trojan SMS, es decir, al estilo de "La linterna molona" que suscribía a sus víctimas a servicios de SMS Premium sin su consentimiento. En este caso, la app llamada Exprime tu WhatsApp.

Figura 3: Varios antimalware marcan esta app como Android/SopSMS 

Esta es una familia de software malicioso que, usando WhatsApp, Telegram o ChatON para obtener el número de teléfono donde se instalan, suscriben a sus víctimas a servicios de pago con solo leer los SMS y hacer el registro vía web. Por supuesto, todas ellas han sido marcadas como malware y están en el grupo StopSMS. Por supuesto "Exprime tu WhatsApp" ya no está en Google Play, tal y como marca el crespón negro que aparece en nuestro Path 5, pero basta con solo hacer un consulta en Google para localizar la app colgada en Mobogenie, disponible para cualquier valiente.

Figura 4: Exprime tu WhatsApp en Mobogenie

Esto convierte a Mobogenie en un buen almacén de malware a largo plazo, como se ha dicho al principio, para los investigadores de seguridad, pero también en un gran riesgo para los usuarios. De este mismo desarrollador, de nombre "piratapalo" se puede ver en nuestro Path 5 que Google Play ha hecho limpia, ya que sus apps de "trucos" utilizaban el mismo "truco" para infectar a sus víctimas.

Figura 5: Otras apps de piratapalo tiradas de Google Play

Todas ellas, como era de esperar, están aún disponibles en Mobogenie, por lo que las probabilidades de que un usuario descuidado acabe instalando una app maliciosa es alto. No solo están las de este ejemplo, sino la gran mayoría de las tiradas por Google Play, por lo que es incluso posible caer en las apps de Shuabang Botnet, con el correspondiente riesgo para el usuario.

Figura 6: apps de piratapalo en Mobogenie

Dicho esto, si eres usuario ten cuidado con este market y si eres una administrador y gestionas un MDM (Mobile Device Management) para una empresa, esta sería una de las cosas que seguro que más de uno te agradecerá que bloquees.

Saludos Malignos!

Tempest: En busca de software y hardware más silencioso

Hace ya algún tiempo os dejé un artículo aquí sobre un trabajo de investigación en el que se explicaba cómo utilizando la tecnología Tempest se podía extraer una clave de cifrado de un equipo con solo tocarlo, utilizando un side-channel que permitiera reconocer las instrucciones que se estaban realizando en el microprocesador. Este trabajo se centró en la extracción de las claves utilizadas en GnuPG y tocando el equipo para tener mediciones de las vibraciones.

Figura 1: Tempest - En busca de software y hadware más silencioso

Cuando se publicó el artículo, los investigadores instaron a los programadores a cambiar la forma en la que realizaban algunos de los cálculos criptográficos, para evitar ser tan "verbose" con las emanaciones de señales que se estaban produciendo por ciertas instrucciones. Es decir, cambiando determinadas instrucciones se puede reducir el volumen de señal que se genera en un side-channel y dificultad en gran medida el trabajo del atacante a la hora de reconocer las instrucciones.

Creando software con menos filtraciones en el side-channel

Esto, como se explica en el artículo de investigación "A Practical Methodology for Measuring the Side-Channel. Signal Available to the Attacker for Instruction-Level Events" se debe a que la señal que se filtra por un canal paralelo depende de dos cosas principalmente, que son:

1.- El tipo de instrucción
2.- La arquitectura del sistema que las ejecuta

Así, por ejemplo, las operaciones de Divisiones son mucho más proclives a dejar más información en un side-channel que una operación de Suma, y las arquitecturas que ejecutan más operaciones dentro del microprocesador tienen menos fugas de señal que las que tiran mucho de una caché externa del microprocesador.

Figura 2: Paper que explica la métrica SAVAT

Para medir lo que un código filtra de señal en un side-channel que pudiera ser atacado por medio de estas técnicas Tempest, los investigadores proponen una métrica que llaman SAVAT (Signal AVailable to ATtacker) , donde miden cuánto de reconocible es una señal por medio de una métrica que mide el periodo de la señal que se produce en el canal paralelo tras la ejecución de programas sintéticos de las instrucciones a medir.

Figura 3: Estrategia de medición de métrica SAVAT en la ejecución de instrucciones

Así, dependiendo de una arquitectura de equipo u otra, habrá una medición de qué instrucciones utilizadas en un programa están generando más información en el side-channel para que los compiladores puedan, por ejemplo, generar un código u otro a nivel de microprocesador consiguiendo evitar las instrucciones que ayuden a la filtración de información. Esto reduciría por tanto el impacto que podría tener un ataque Tempest como el descrito en el artículo inicial para extraer una clave GnuPG.

Usando Hardware con menos filtraciones en el side-channel

Por otro, lado hay que tener presente que la filtración de información que se hace en un canal paralelo depende del canal, así que unos investigadores han propuesto en el artículo "Side-channel Vulnerability Factor:A Metric for Measuring Information Leakage" una métrica para medir cuánto de seguro es un equipo contra la fuga de información por canales paralelos.

Figura 4: Paper que explica cómo medir el Side-Channel Vulnerability Factor de un sistema

En este trabajo lo que hacen es cruzar la ejecución de un algoritmo en una determinada arquitectura y grabar un side-channel para poder cruzar los datos y ver qué cantidad de información se puede reconocer a partir de una distancia del equipo. Dependiendo de lo verbose que sea el sistema será más fácil reconocer unas u otras instrucciones. El resultado final dará un SVF (Side-Channel Vulnerability Factor) que ayudará a reconocer equipos que filtran más o menos información por un determinado side-channel que otros.

Figura 5: Medición del SVF de un side-channel

Eligiendo una arquitectura con poco SVF y generando algoritmos de poco SAVAT, junto a medidas de atenuación de señal adecuadas, lo que se pretende conseguir es que los equipos sean más seguros a la hora de recibir ataques de extracción de información por medio de técnicas Tempest.

Saludos Malignos!

Un informático en el lado del mal: Año 10

Fue el 26 de Enero de 2006 cuando comencé a publicar cosas en El lado del mal. Como algunos sabéis, fue un salto de una pequeña lista de correo electrónico que yo tenía y en la que escribía artículos medio en serio, medio en broma con tanta intención como faltas de ortografía. Al poco de arrancar con el blog, me dedicaba a escribir cosas sin mucha pretensión, más con el objeto de guardarme referencias o pequeños trozos de pensamiento para mí, que luego utilizaba en las conferencias como F.A.Q. ya que tenía escritas las respuestas a las preguntas que me solían hacer en las charlas que daba.

Figura 1: Foto de mi primera gira por Argentina en 2008

Después el blog comenzaría a cambiar, a dejar de guardar esas referencias que tenían que ver con mis charlas de aquel entonces, y a empezar a contar las cosas de mi trabajo en Informática 64 y de mi segunda etapa en la Universidad, donde estaba jugando con técnicas hacking para mi Trabajo de Fin de Carrera y mi Trabajo de Fin de Máster. Es por eso que de lo que más hablaba en aquel entonces fuera de técnicas de Blind SQL Injection, Blind LDAP Injection o Blind XPath Injection.

Figura 2: Una de las primeras presentaciones de FOCA 0.x en Pamplona en el año 2008

Poco a poco, las publicaciones en el blog fueron tomando más parte de lo que iba trabajando en mi día a día. Con todos los proyectos en los que me metía, o los Retos Hacking que iba publicando. Por aquí los artículos hablaban de la creación de la FOCA, las auditorías de seguridad web, las técnicas de Connection String Parameter Pollution, los trabajos de creación de herramientas como DUST RSS o más tarde ya el nacimiento de la Evil FOCA, que fueron tomando protagonismo en diferentes periodos de tiempo de estos años en el blog. Durante estos años he podido disfrutar de ver nacer y crecer todas estos proyectos al mismo tiempo que lo contaba en el blog. 

Figura 3: Reto Hacking X inspirado en Los Simpsons para jugar con la charla de Inverted Queries

No solo Informática 64 fue tomando presencia en mi vida y en este blog, sino que otro tipo de inquietudes fueron llenando los días y posts en este espacio. Mis dibujos de No Lusers, los episodios de Cálico Electrónico, relatos fantásticos inventados por mí e incluso algunos días en los que disfrutaba poniendo cosas de música y libros o experiencias personales que fui viviendo por todas aquellas conferencias en las que tuve la suerte de participar. Desde China, a San Diego, pasando por Manizales, Lima, Oslo, Estocolmo o Buenos Aires, donde fui conociendo durante esta más de una década a gente fantástica. Gente, a la que muchas veces entrevisté también para el blog.

Figura 4: Con mis amigos Kevin Mitnick y Pedro Laguna en 2011

Con la madurez de este sitio - y hablar ya de casi una década de posts es hablar de la madurez - entraron otros proyectos en mi vida laboral como el programa Talentum de Telefónica, así como fueron entrando artículos de muchos lectores mucho más listos que yo y que aportaron a este sitio más valor, sin duda, del que yo solo hubiera podido ir generando.  El último año y medio mi vida profesional ha estado marcada por Eleven Paths y 0xWord, y los proyectos en los que desde allí hemos ido lanzando, así que eso, junto con las cosas que día a día me van cautivando son parte de este blog.

Figura 5: Los primeros No Lusers del año 2007

A día de hoy son casi 3.500 artículos los publicados, y mentiría si os dijera que no ha sido para tanto. El mantener este espacio vivo con la autoimpuesta exigencia de tener al menos un post al día con algo que contar a alguien es un trabajo que me lleva mucho más de lo que pueda parecer. Es cierto que en los últimos tiempos muchos son los que colaboran conmigo - lo cual agradezco sobremanera - pero aún así, no es fácil.

Figura 6: Foto de uno de los Calendarios Tórridos que empujamos desde el blog

Es aún mucho menos fácil cuando estoy de viaje en otra parte del mundo, cuando la carga de trabajo diario me supera y no llego a nada, cuando estoy enfermo o simplemente días en los que la vida te enseña la cara menos agradable para hundirte el ánimo. Esos días en los que parece que todo ha confluido en una tormenta perfecta que te hace creer que el único camino es dejar las cosas. Esos días también llegan, y mentiría si dijera que no he pensado muchas veces en dejar de escribir en el blog.

Pero por ahora no lo he hecho.

No lo he hecho porque siento que ha dejado de ser un blog solo mío, y es de todos los que me agradecéis el trabajo. De todos los que han escrito algún articulo en él. De todos los que simplemente lo habéis metido en vuestra rutina diaria para leerlo en el café de la mañana, en el viaje al trabajo o en vuestro lector RSS. Sé que estáis ahí y que este blog alguna vez os ha dado algún pequeño valor, así que merece la pena pensar en qué postear mañana.

Figura 7: El año pasado con Gomaespuma en la radio

Los que me conocéis bien, sabéis que aún pienso en cómo hacerlo mejor, que sigo corrigiendo los posts pasados para que los nuevos lectores los lean con aún más información si es posible. Puedo estar en el otro lado del planeta y seguir preocupado durante todo el día por lo que voy a publicar mañana, y si no lo sé el día antes o no he publicado mi artículo diario antes de las 09:00 A.M. me pongo muy nervioso. Le dedico todo el cariño y trabajo que puedo a este sitio, por eso espero que podamos vernos por aquí algún tiempo más.

Saludos Malignos!

Examen Máster Seguridad UEM 2014 - 2015

Ayer sábado por la tarde fue el día del examen de mi módulo de Seguridad en Aplicaciones en el Máster de Seguridad Informática de la UEM, así que, como en años anteriores os dejo las 10 sencillas preguntas que les puse sobre conceptos base. Si ya te has hecho los de otros años te resultará muy familiar, pero aún así puedes probar a hacerlo.

Figura 1: Tarde de Sábado (ayer) para examinarese en la UEM

Examen Seguridad Aplicaciones Curso 2014-2015

1.- ¿Cuáles son las tres reglas principales para la fortificación de sistemas informáticos?

2.- Explica en que se diferencia una vulnerabilidad de RFI de una LFI

3.- Explica para que sirven los flags Secure y HTTP Only en una cookie

4.- ¿Qué son los headers HTTP de CSP?

5.- ¿Cómo extraerías el nombre de los usuarios de una base de datos a través de una vulnerabilidad SQL Injection Out-Band basada en errores ODBC?

6.- Explica cómo extraer de una aplicación web vulnerable a Time-Based Blind SQL Injection la versión de una base de datos si el motor es un MySQL v4.

7.- En un ataque LDAP Injection en el que la función de consulta es como la que sigue. ¿Cómo conseguirías acceso con algún usuario si el motor es un OpenLDAP?

Web:

User: v_userPass:v_pass

Consulta para acceso:

ldapfilter='(&(uid='+v_user+')(Pass='+crypt(v_pass)+'))';

8.- Explica en que consiste un ataque SQL Injection inband.

9.- ¿Cómo se podría realizar un ataque Time-Based Blind SQL Injection a una aplicación web que utilice un motor de base de datos Ms Access 2007?

10.- Explica algún método conocido para poder robar una cookie con el flag HTTP-Only.

Tiempo: 1 hora y 30 minutos.

Por la tarde pondré las respuestas para el que quiera saber cuál sería la respuesta adecuada a cada una de ellas. Además, os dejo los enlaces a exámenes de años anteriores, por si te quieres ver los de otros cursos, que ya son muchos años de vida de este Máster. 

-  Examen Máster de Seguridad de la UEM 2009-2010
-  Examen Máster de Seguridad de la UEM 2010-2011
-  Examen Máster de Seguridad de la UEM 2011-2012
-  Examen Máster de Seguridad de la UEM 2012-2013
-  Examen Máster de Seguridad de la UEM 2013-2014
-  Examen Máster de Seguridad de la UEM 2013-2014 (Herramientas auditoría)

Recuerda, lo más importante de esto siempre es aprender, no aprobar. Ya sabes que es mejor suspender que atenerse a las consecuencias.

Saludos Malignos!

¿Es Google Project Zero (i)rresponsable publicando 0days y exploits de Windows y OS X?

El año pasado, concretamente durante el mes de Julio, se anunció el nacimiento de Google Project Zero, una iniciativa de seguridad de Google para auditar en busca de vulnerabilidades en aplicaciones de otros fabricantes, incluyendo en esta lista software libre y software de código cerrado. El año pasado fue especialmente vertiginoso en términos de seguridad informática, todavía convulso por las revelaciones de todos los hackeos provenientes de la NSA, la aparición de fallos como Heartbleed, ShellShock, Poodle o el resto de bugs en software criptográfico, hicieron que las inversiones en seguridad empezaran a crecer.

Google montó su equipo en busca de fallos en el software que ellos utilizan que, dicho sea de paso, pensando en una compañía del tamaño de Google es algo así como decir casi todo el software importante del planeta. En sus filas hay hackers de gran nivel y reconocimiento internacional, con varios Pwnie Awards entre ellos, e incluso GeoHot ha pasado a formar parte de este equipo que se dedica a buscar vulnerabilidades.

Figura 1: Es Google Project Zero (i)rresponsable publicando 0days y exploits?

La polémica viene con este grupo ha venido por otro lado, no con la búsqueda de los bugs, sino con la "medida de responsabilidad" que han añadido a la publicación de sus descubrimientos, en 0days de Windows y de OS X recientemente.

Un resumen de la publicación de bugs

Recordemos que hace años atrás, los hackers eran acusados con el dedo por la publicación de sus descubrimientos en Full Disclosure, es decir, se encuentra un fallo de seguridad y se publica. Los fabricantes de software se quejaban de que no estaban ayudando a la seguridad de sus clientes con esta forma de publicar, sino que los estaban poniendo en riego porque cualquier atacante podría con ese conocimiento publicado hacer daño a sus usuarios.

La posición de los investigadores era que los que estaban poniendo en riesgo a sus clientes eran ellos no auditando correctamente el software, además de que no tenían ninguna garantía de que antes de que se hiciera público este fallo no estuviera siendo utilizado por ningún malo de verdad. Ahora que se conoce el fallo, todo el mundo deberá trabajar en pro de solucionarlo. El gran investigador argentino Juliano Rizzo, en la presentación que hizo en Ekoparty del bug BEAST en SSL lo explicó con una de las frases que quedará para la historia:

Figura 2: Juliano Rizzo sobre la publicación del bug BEAST en SSL

En aquel entonces el mundo de Internet estaba preocupado por las consecuencias en el e-commerce que pudiera tener la publicación de un bug en la capa de cifrado, y lo que consiguieron los investigadores publicando el bug es que todo el mundo se preocupara por el fallo y lo subsanara.

Los fabricantes de software siempre reclaman el Responsible Disclosure, es decir, que los investigadores les comuniquen a ellos el fallo y les dejen tiempo para arreglarlo antes de hacerlo público. Esto tiene dos preguntas a responder por parte de los fabricantes de software:

1) ¿Por que una investigación que ha llevado tiempo y dinero te la voy a tener que dar a ti y no a otros?

Los hackers comenzaron una campaña llamada "No more free bugs" en la que exigían que se reconociera su esfuerzo de investigación y el valor que tenía para todos el descubrimiento de los bugs. En Internet había empresas de todo tipo de reputaciones dispuestas a pagar a los investigadores por ese conocimiento, así que los grandes software vendors deberían ponerse las pilas. 

Figura 3: Alex Sotirov y Dino Dai Zovi apoyando al campaña No More Free Bugs

Esto llevó a la aparición de brokers (empresas que compran bugs y luego negocian su venta con los fabricantes de software) y a las famosas Bug Bountys que algunas empresas pagan por los bugs reportados, como hace Google, Facebook y en algunos productos puntuales Microsoft. Por supuesto, para sacar una Bug Bounty, primero las empresas deberían auditar mucho más el software de su compañía con equipos de auditoría mucho más formados lo que llevó a que las grandes empresas se "pelearan" por conseguir tener en sus filas a los mejores hackers del panorama internacional trabajando para ellos.

2) ¿Cuál es exactamente la medida de responsabilidad?

Cuando un investigador encuentra un bug se hace un time-stamp. Ese día el hacker toma constancia de que hay un bug en un producto que pone en riesgo muchas cosas. Tal vez incluso cosas críticas que afectan a nuestra seguridad como ciudadanos si hablamos de un bug en un software que se usa en instalaciones críticas. Ese día, por desgracia, no es el tiempo que tiene ese bug. Ese bug es mucho más viejo y existe desde el día que alguien lo introdujo por error o conscientemente. Ese sería el tiempo de verdad que tiene el bug.

Entre el tiempo que va desde que el bug se introdujo hasta el tiempo en el que el hacker lo descubrió hay por medio a veces mucho tiempo, lo que aumenta las posibilidades de que otro hacker lo haya encontrado antes y lo haya usado para vendérselo a los malos o para explotarlo en su provecho.

Figura 4: Tiempos, riesgo y responsabilidades

En el momento en que el hacker lo comunica al fabricante de software empieza a correr otro cronómetro hasta que se arregla, lo que obligará al fabricante a meter personas y trabajo en pro de solucionar este fallo. A veces esto puede costar mucho, por lo que los fabricantes prefieren acumular"varios parches en cada actualización para ahorrar esfuerzos y dinero.

Sin embargo, mientras sucede este parcheo masivo del fallo, el tiempo sigue creciendo. Crece el tiempo desde que se introdujo, crece el tiempo desde que el hacker lo descubrió y crece el tiempo desde que el fabricante es consciente de él. Pero lo más importante, también puede crecer el tiempo en el que otro lo esté utilizando - por ejemplo una agencia de inteligencia internacional o un grupo de cibermalos que lo quiere usar para cibermalas cosas -. Y esto debe tener un límite.

La medida de responsabilidad para Google Zero Project

¿Cuándo debe parchearse algo? La respuesta es cuanto antes, y es el fabricante del software el que lo debe hacer. ¿Cuál es el límite de tiempo que el investigador debe darle al fabricante antes de decir basta? Pues el equipo de Google Project Zero ha determinado que 90 días.

A partir de ese momento, para forzar a la actualización se hace público, aumentando masivamente el riesgo de los clientes, pero al mismo tiempo dándoles la oportunidad de poner workarounds, es decir, medidas de mitigación del bug en WAF, Firewalls, configuraciones de software, políticas de seguridad e el Active Directory o directamente deshabilitando componentes en piezas del sistema como los navegadores. Es decir, transfiere a los clientes la responsabilidad, y al mismo tiempo la oportunidad, de hacer algo para protegerse contra un fallo que puede que esté siendo explotado actualmente.

Figura 5: Exploit publicado por Google Project Zero para atacar OS X

¿Es necesario que publique también exploits? ¿Es 90 días el tiempo adecuado para publicar? Cada cuál tendrá sus opiniones. ¿Cuál es la tuya?

Saludos Malignos!

¿Se debe ocultar y apagar la red WiFi de tu casa?

Cuando oigo en las noticias las recomendaciones de seguridad para fortificar las redes WiFi de casa siempre acabo pensando en un montón de cosas, sobre si son correctas o no. Yo hice mi propia lista de recomendaciones para asegurar una red WiFi y evitar tener que acabar hackeando al vecino hax0r que te roba la WiFi, pero aún así hay algunos aspectos que siempre me hacen reflexionar si es mejor una cosa u otra.

Figura 1: ¿Se debe ocultar y apagar la red WiFi?

Apagar o no la red WiFi cuando no la estás utilizando ¿Sí o no?

En teoría, si apagas la red WiFi cuando no estás ayudas a que una atacante no cuente con todo el tiempo del mundo para hacer un intento de hackeo. También está bien, ya que reduces la superficie de exposición temporal a atacantes casuales,  en el ámbito de la WiFi si solo quitas la WiFi y en el ámbito de Internet si quitas el router  completo.

Sin embargo, como contrapartida los vecinos o ladrones rápidamente tienen una forma sencilla de saber si estás en casa o no. Sin necesidad de hacer un seguimiento especial, con ver que tu red WiFi está apagada sabrían que no estás en casa y eso puede ser a veces peor. De hecho hay gente que programa el encendido y apagado de luces para conseguir dejar muestras de actividad en el hogar.

Esto contradice la parte de la Guía para Fortificar Casas donde justo dice que se debe apagar la red WiFi, algo que a mí me hace confundirme más aún.

Ocultar el SSID de la red WiFi ¿Sí o No?

Esta es una de las recomendaciones de las que ya he hablado. Yo soy partidario de cambiar el SSID por uno distinto de los que vienen de fábrica y poner uno distintos del que, a ser posible, no haya Rainbow Tables precalculadas para crackear los paquetes de autenticación WPA/WPA2 y cambiarlo periódicamente, lo que dificultará el que se pueda atacar redes WiFi WPA/WPA2.

Figura 2: Probes capturados de un terminal iPhone

Ocultar el SSID hace que los equipos que buscan las redes WIFI ocultas, por ejemplo tu terminal iPhone, Android e incluso los Windows, vayan emitiendo mensajes PROBE de todas las redes WiFi a las que se conecta. Cualquiera puede capturar esos SSID y buscarlos en una base de datos de WarDriving para saber por donde te mueves, lo que puede afectar a tu privacidad.

Figura 3: iSniff-GPS pinta las ubicaciones por las que se mueve un iPhone

Además, en el caso de que un atacante quiera hackear tu red WiFi, solo necesitaría un cliente que buscara la red oculta, y como hoy en día en la casa hay muchos dispositivos que se conectan, incluso cuando tú no estás, es bastante trivial para un atacante malicioso averiguar el nombre de tu red.

Ahí quedan esas dos reflexiones sobre medidas de seguridad que oigo mucho en los medios de comunicación y que creo que habría que evaluar su conveniencia o no junto con el resto de todas las medidas necesarias para fortificar una red WiFi, sobre todo teniendo en cuenta que los ataques de man in the middle con Fake AP se han popularizado tanto.

Saludos Malignos!

La venta de apps al cibercrimen convierte tus apps en Gremlins malos

Si hace unos días hablaba de las apps mágicas para hackear, hoy quiero hablar de las apps Gremlins que se pueden volver malas. Seguro que los que hayáis vivido los años 80 con intensidad recordaréis aquella mítica película en la que un tipo en la trastienda de un local en un subsuelo entregaba al protagonista de la cinta una cajita con Gizmo, ese precioso y adorable Gremlin. Luego la cosa se complicaba, y al caerle gotas de agua se comenzaba a duplicar en otros nuevos Gremlins pero que tenían peor carácter que el original para luego, comer después de las 12:00 de la noche y convertirse en unos bichos verdes que querían romper las cosas, beber, fumar, y esas cosas que hacen los adolescentes con ganas de fiesta.

Figura 1: La venta de apps al cibercrimen convierte tus apps en Gremlins malos

Eso mismo le puede a cualquiera de tus apps, si el programador decide sacarse unos dineros extras a sus conocimientos de desarrollo de apps para Android y vende tu instalación al mejor postor, como pasó con el caso de Pixel Battery Saver, que por unos 699 $ entregó sus entre 50 y 250 mil instalaciones a alguien al que se le ocurrió una mejor forma de monetizarla con un Fake AV para Android, llamado "Protección Completa de Antivirus".

Figura 2: Mensaje recibido de un usuario contando su experiencia

El funcionamiento de este negocio es ya conocido, y podríamos entenderlo como una mutación del típico Pay Per Install, donde los cibercriminales especializados en Fraude Online se dedicaban a pagar por las veces que un adware o malware se haya instalado. En el mundo de las apps fraudulentas, alguien quiere hacer un negocio con ransomware, adware o directamente montarse una botnet para hacer BlackASO como nuestro amigo de ShuaBang Botnet.

Para ello el cibercriminal, compra una app que está ya instalada en muchos terminales. Esto se puede hacer en sitios web como Sell The Apps, donde el que tiene las apps las pone a la venta al mejor postor, recibiendo ofertas por el código de la app o por el código, la app y la cuenta de desarrollador.

Figura 3: Apps a la venta en Sell the Apps

Evidentemente, los cibercriminales quieren la cuenta del desarrollador, porque así pueden hacer una actualización de la app cambiando absolutamente todo su comportamiento, y convirtiendo una app de ahorro de batería en un Fake AV para vender vacunas, publicidad, y hasta los datos del dueño del terminal. En el momento de escribir este artículo, Google Play aún no la ha tirado.

Figura 4: Pixel Battery Saver aún disponible en Google Play

Esta forma les hace conseguir un buen número de víctimas en muy poco tiempo, y aprovechar muy bien la ventana de tiempo que Google les de antes de que se tiren las apps de Google Play, momento en que se van a comprar otra app y listo.

Figura 5: Venta de Pixel Battery Saver en Sell The App

Por su parte, el vendedor de la app tampoco está muy preocupado por la cuenta del desarrollador, pues por supuesto el certificado digital utilizado para firmarla no tiene nada que ver, y probablemente la cuenta de Google Play ha sido también comprada en Internet, así que no tiene ningún rastro o información personal apuntándole a él.

Figura 6: Venta de cuentas de desarrollador de Google Play

Por supuesto, si un desarrollador vende su cuenta y tiene varias apps, todas se vuelven potencialmente maliciosas, pero lo que hay que tener en cuenta es que, las apps que están a la venta se pueden volver maliciosas en un futuro, y si el desarrollador está usando varias cuentas de developer en Google Play, todas se pueden acabar tornando peligrosas, por lo que nosotros desde Path 5 podemos ver cuáles son las que en un futuro cercano se van a convertir en Gremlins verdes malos.

Tú, por si acaso, ten mucho cuidado y no te instales Gremlins que vengan desde trastiendas en subsuelos o desde post patrocinados o recomendaciones de Facebook de amigos que tienen poco cuidado con la seguridad.

Saludos Malignos!