Listar ficheros de Apache con Mod_Negotiation: Un ejemplo

Durante la semana pasada me tocó impartir la sesión dedicada a Pentesting con técnicas OSINT - Open Source Intelligence - en el curso de Ciberdefensa, donde hago un resumen del contenido que recopilé en el libro de Pentesting con FOCA. Tanto en este libro, como en la sesión del curso, procuro contar qué busca FOCA, de dónde, por qué y para qué se buscan esas cosas. Entre los temas que cuento está por supuesto la explotación del módulo mod_negotiation en los servidores Apache, que permiten escanear el contenido de sitios web en busca de backups utilizando el mensaje de error de Multiple Choices.

Este método - que puse en la lista de las 20 técnicas para listar ficheros de un sitio web, está en la lista de 10 cosas que puedes revisar en la seguridad de tu Apache y por supuesto está tratado en el libro de Hardening GNU/Linux - permite conocer qué otros ficheros en el mismo directorio tiene el mismo nombre, pero diferente extensión, cuando se solicita un archivo que no se encuentra en ese directorio. Es decir, cuando se produce un error de 404 en lugar de dar una página con la excepción se muestra una lista de archivos similares al solicitado.

La idea es que una vez que se descubre que un servidor tiene habilitado el módulo de mod_negotiation, lo que hay que hacer es solicitar todos los archivos que se conocen sin extensión. Es decir, si hay un archivo indexado en Google con el nombre index.hml, se pide index. y así sucesivamente. Esto se debe hacer también con los directorios, donde como están los enlaces . y .. se debe pedir cualquier fichero que empiece por dos puntos. Es decir, ..FOCA o ..Whaetever, y se conseguirá la lista de archivos que comiencen por un punto.

La lista de sitios con este módulo activado es grande, pero para probarlo basta con poner ..FOCA - por ejemplo - en el dominio principal y ver el mensaje. Un sitio famoso con este módulo es www.w3.org, donde puedes obtener la lista de ficheros en el sitio principal.

Figura 1: mod_negotiation activado en w3c.org

Buscando directorios en Google es posible encontrar muchos directorios en www.w3.org, como el subdirectorio TR. Probar el mismo mensaje en TR dará la lista de ficheros que comienzan por . en este nuevo directorio.

Figura 2: Lista de ficheros que comienzan por . en /TR/

Haciendo esta prueba se puede ver que aparecía el archivo .cvsingnore, así que era fácil imaginar que existía el directorio CVS, aunque como se puede ver no está indexado en Google para nada.

Figura 3: El directorio /TR/CVS no aparece indexado en Google

Probándolo a capón se puede ver que el mensaje de error que se obtiene es de que no hay privilegio para obtener el contenido de este directorio, pero al menos sabemos que existe.

Figura 4: Privilegios insuficientes para hacer el listado del directorio

Sin embargo, como los archivos por defecto que se crean son siempre Entries, Root y Repository y además el módulo mod_negotiation de este Apache está activado, en primer lugar se puede ver que existen dichos pidiéndolos directamente. Aunque su contenido es poco sí que es posible acceder a una ruta local del servidor y a un servidor nuevo donde se ubica el CVS.

Figura 5: Contenidos de los ficheros Entries, Repository y Root

Y en segundo lugar, como pudiera ser que existiera alguna copia de estos archivos, se puede hacer el mismo truco de pedir uno de estos archivos pero con otra extensión, o sin ella. En este caso se puede ver que solicitando Entries. aparece otro archivo con otra extensión. Curioso, aunque el archivo está vacío.

Figura 6: Error de Multiple Choices para Entries.

Volviendo al directorio TR para evaluar el resto de los archivos, aparecen otros bastante curiosos, como !dtbbos, que al abrirlo da la sorpresa de ser un volcado de directorio completo con todos los archivos y directorios de esta carpeta. Es decir, se puede ver el contenido completo de esta carpeta.

Figura 7: El archivo .!dtbbos tiene un ls -al de la carpeta TR

He intentado ver de dónde puede provenir este archivo, pero no lo tengo muy claro. Si alguien tiene pistas, se agradece. Lo cierto es que entre la lista de los archivos hay muchos .old, muchos que acaban en ~ y muchos con la doble extensión .1. Vamos, copias de seguridad de archivos.

Como también hay un directorio llamado /old/ podemos hacer una petición a /TR/old/..foca para ver qué hay en ese directorio, y ahí tenemos otra lista de ficheros curioso, como uno con extensión .wmd.

Figura 8: Archivos que comienzan con . en el directorio /TR/old/

En él hay información que puede ser útil para un atacante, como son rutas locales del servidor web. De nuevo una fuga de información que podría utilizarse en un ataque.

Figura 9: Contenido del archivo .dir3_0.wmd

Como se puede ver, el módulo de mod_negotiation puede servir para acabar encontrando una buena cantidad de juicy files de los servidores web, solo por la falsa sensación de seguridad que puede dar a un administrador el que un archivo no esté enlazado en la página principal o indexado en un buscador.

Saludos Malignos!

Reto ISACA Madrid para jóvenes en Seguridad Informática

El día 15 de Abril es la fecha en la que finaliza el plazo para participar en el Reto que ISACA Madrid ha preparado a través de su comité para Jóvenes Profesionales para menores de 35 años. ISACA Madrid ofrece esta oportunidad a cualquier interesado en la Seguridad Informática, Auditoría y Gobierno de las TIC menor de 35 años, tanto socios como no socios de ISACA.

Cómo Participar en el Reto ISACA Madrid

Prepara un texto breve - entre 200 y 450 palabras - contando tu propuesta para participar y súbelo a la plataforma “EasyChair”. Puedes participar con propuestas relacionadas con la Seguridad Informática, Auditoría y Gobierno de las TIC, como por ejemplo:

• Eres capaz de contar de forma clara e innovadora qué es una botnet, una darknet, cómo funciona un determinado exploit, qué es el ROP, qué es una auditoría TI, qué es una ISO 2XXXX, cómo ha evolucionado el malware a lo largo del tiempo, etcétera.

• Presentar una herramienta de auditoría/seguridad que has desarrollado. 

• Quieres presentar los resultados de una investigación particular sobre seguridad en protocolos, herramientas, etcétera.

Como ves, la temática es muy amplia y abierta a cualquiera que tenga algo interesante e innovador que contar sobre los temas anteriormente mencionados.Tanto si tu propuesta es aceptada como si no, se te comunicará vía e-mail, así como los siguientes pasos a tomar.

¿Por qué participar?

ISACA Madrid premiará a la mejor propuesta con 1.000 € en metálico, además de un curso completo de preparación a una de las certificaciones de ISACA: CISA, CISM, CGEIT, CRISC o COBIT5. Además, los participantes con las mejores y más innovadoras propuestas serán invitados para presentar su propuesta en un evento especial que ISACA está preparando para la última quincena de Junio. Habrá finalistas y menciones especiales.

Si tienes menos de 35 años y te interesa la Seguridad Informática, la auditoría o el Gobierno de las TIC, no puedes dejar de participar en el Reto de ISACA para Jóvenes Profesionales.

Instrucciones para el uso de EasyChair

Paso 1: Accede a la URL del Reto ISACA Madrid 2014 en EasyChair.

Figura 1: Acceso al portal de EasyChair para crear una nueva cuenta

Paso 2: Créate una nueva cuenta en EasyChair si no la tienes. Te vendrá bien para muchos congresos que utilizan este sistema online de valoración de propuestas en Call For Papers.

Figura 2: Información para crear la cuenta de EasyChair

Paso 3: Introduce nombre y tu dirección de e-mail.

Figura 3: Datos necesarios para presentar la propuesta

Paso 4: Abre tu buzón de correo y accede a la URL de activación de tu nueva cuenta de EasyChair. Rellena tus datos personales y ya tendrás tu cuenta creada.

Figura 4: Cuenta creada correctamente

Paso 5: Ahora puedes acceder a la plataforma EasyChair con tu cuenta recién creada y pulsar sobre “New submission”.

Figura 5: Reto ISACA para Jóvenes Profesionales 2014 en EasyChair

Paso 6: Lee y acepta los términos y condiciones - si estás de acuerdo - y vuelve a pulsar sobre "New Submission" ¡Por fin llega el momento importante!

Paso 7: Rellena los datos personales de todos los participantes en la propuesta. Introduce título y una descripción entre 200 y 450 palabras de la misma. Si quieres adjuntar algún documento a tu propuesta, perfecto. Pulsa “Submit”, y ya tendremos tu propuesta sobre nuestra mesa.

Figura 6: Formulario de presentación de propuesta para el reto

Ahora solo te queda esperar a recibir nuevas instrucciones por parte de ISACA☺.No dejes pastar esta oportunidad…

Autor: Rafael Sánchez

No Lusers 168: Conversaciones sociales hoy en día

Figura 1: No Lusers 168 "No me llegó el correo electrónico"

Ya hace años escribí un artículo que se llamaba "¿Te ha llegado mi e-mail?" en el que comentaba que ahora las confirmaciones de correo electrónico se mandan por las redes sociales, pero con la proliferación de nuevos sistemas de mensajería esto es una avalancha. Yo intento contestar todo en el menor de los tiempos, pero supongo que como os sucederá a vosotros, para mucha gente ese tiempo de respuesta no entra dentro de sus estándares de Time-Out, por lo que el remitente pasa al DM de Twitter, o al mensaje de WhatsApp.

En mi caso, tengo configuradas las opciones de privacidad en WhatsApp para que no vean cuando estoy o no online y además he desactivado las alertas de mensajes para que no me molesten durante el día, así que nada, un Telegram, o un iMessage o un correo por Facebook para ver si me ha llegado el mensaje de correo. 

Y si no lo has leído entre la marabunta de mensajes y pones un twitt, peor aún porque esa persona ve que te has conectado y vuelve a la carga, ya públicamente con un mention para decirte... "¿has visto que te envié un correo electrónico?"

Cuando por fin contestas al mensaje, ya no sabes por dónde hacerlo, así que acabas respondiendo al que te pilla más a mano, por ejemplo... un iMessage. Y tu contertulio - que siempre parece tener más tiempo libre que tú, ¿verdad? -  te contesta de nuevo por ahí y espera tu respuesta... que no llega en su Time-Out y vuelve a la carga con otro DM de Twitter en el que te repite lo mismo, y luego por FaceBook y luego por... 

Figura 2: No Lusers 168 "Seguir una conversación hoy en día"

... Y acabas contestando por otra red social. Esto hace que seguir el histórico de las conversaciones requiera de herramientas profesionales de analistas forenses que sean capaces de hacer un time-line de todos los mensajes, como el famoso Oxygen Forensics o el LiOS de Lorenzo Martínez. Vamos, que eso de "Lo siento, no me llegó el e-mail" empieza a ser una excusa del siglo pasado...

Saludos Malignos!

Latch: Django, Demonios, Secretos y Despareado Seguro

Desde que di la charla en RootedCON sobre Hacking & Playing with Digital Latches han aparecido algunos hacks de usuarios que utilizan Latch de formas diversas y que junto con una recomendación de seguridad para implementar Latch os voy a contar hoy.

RootedCON y el plugin de Latch para Django

Uno de los hackers que organizan RootedCON, nuestro amigo Javi "Deese", me contó en la cena de ponentes que había estado trabajando en integrar Latch con Django. Como la idea me encantó, yo le pedí durante la charla que lo liberará y así lo ha hecho. Ahora está disponible su plugin de Latch para Django que puedes descargar desde el repositorio de GitHub que han habilitado: Django-Latch.

Figura 1: Plugin de Latch para Django

Ese mismo plugin es el que ellos utilizaron para integrar el servicio de Latch en las cuentas de acceso al portal creado por Django que utilizan en el propio sitio web de RootedCON, y ahora tú también puedes usarlo.

Figura 2: Latch integrado en RootedCON

Este se suma a la lista de plugins que ya tienes disponibles para usar en diferentes frameworks y que puedes utilizar desde ya con Latch.

Revelación de Secretos, daemons y 2-Keys Activations

Por otro lado, en HackPlayers publicaron un artículo titulado "Demonizando Latch para proteger archivos con dos llaves", en el que explican cómo implementar un esquema de 2-Keys Activation similar al que expliqué en la pasada charla de RootedCON.

Figura 3: Esquema de 2-Keys Activation con Latch

La idea de estos esquemas es que un determinado activo no se habilita hasta que no se han desbloqueado los dos latches que lo protegen, y ellos lo han integrado con un daemon que permite o no acceder a un determinado fichero.

Figura 4: Las dos cuentas que gestionan las dos llaves que dan acceso al activo

Este esquema lo teníamos nosotros en mente por ejemplo para una Web de Revelación de Secretos controlada remotamente que permitirá o no ver un determinado contenido cuando una o varias personas abran los latches que dan acceso al contenido.

Secure UnPair

Por último, quería explicaros cómo evitar un riesgo que tenemos identificado desde el principio. Supongamos que una víctima se conecta a su sitio web con una identidad que tiene protegida por Latch, peo la máquina está infectada por un bot.

El usuario abre el latch de la cuenta, introduce sus contraseñas y el bot roba el usuarios y la password al mismo tiempo que navega en la web y elimina el latch con un proceso de Despareado. A día de hoy lo que hacemos es avisar al usuario de que la lista de servicios ha cambiado y que una cuenta ha sido eliminada, para que sepa que algo ha pasado y pueda tomar medidas correctivas, como cambiar la password si aún está a tiempo o hablar con el sitio web del que le acaban de robar la identidad.

Figura 5: La lista de servicios protegidos por Latch ha cambiado

No obstante, en implementaciones personalizadas es posible crear un sistema de UnPair seguro, utilizando una operación controlada por Latch. La idea es que en el pestillo de la cuenta habrá una operación que controlará si se puede desparear o no la cuenta. Esto se crea en las operaciones de la cuenta y listo.

Figura 6: Añadiendo la operación de Desparear con opciones de OTP

De esta forma, el usuario tendrá una operación dentro del Latch de la cuenta que le permitirá bloquear el despareado automático e impedirá que un bot robe una identidad aunque sea con un man in the browser y la pueda utilizar. El sitio web lo único que necesita hacer es comprobar el estado de esa operación antes de lanzar un proceso de despareado.

Figura 7: El usuario controla si se puede o no desparear la cuenta

Eso sí, siempre podrá esperar a que el usuario maneje su cuenta para hacer las cosas malas cuando el usuario haya iniciado sesión. Eso sí, si hay operaciones que bloquean parte de la cuenta con Latch no podrá hacer nada que no esté abierto, mitigando el impacto del malware lo máximo posible.

Saludos Malignos!

Windows XP: Uso irresponsable de Abandonware

Corrían los primeros momentos del siglo XXI cuando yo me subía por primera vez a un escenario con Microsoft a hablar de las novedades del Windows XP Service Pack 0 Beta. La historia de aquella presentación en el antiguo auditorio Winterthur de la Diagonal de Barcelona la he rememorado en público en innumerables ocasiones y conferencias, con todo lujo de detalles para jolgorio y algarabía del respetable, que prometo dejar escrita por aquí en breve para que os echéis unas risas. Desde entonces han pasado muchos años, más de una década larga. ¡Cuántas cosas han pasado con Windows XP desde entonces!, ¿verdad?

Figura 1: Windows XP en el Último Mobile World Congress

Recuerdo que cuando salió Windows XP decían que consumía mucha RAM, que nadie en el mundo de la empresa lo iba a usar porque Windows 2000 era "more-than-enough", que Windows XP metía muchas cosas de multimedia que ninguna empresa necesitaba, y un largo etcétera de predicciones que aventuraban una penetración inferior al 30 % del mercado en el mundo de la empresa.

Desde entonces la historia de Windows XP ha llegado hasta nuestros días. Consiguió estar en más del 95 % de los escritorios del mundo y parece que se ha convertido en inmortal. A nadie parece importarle que ese famoso Kernel 5.2 que como evolución del Kernel 5.0 comenzase a diseñarse justo después del lanzamiento de Windows NT 4.0, es decir, allá por el año 1997, con modelos de amenazas que tienen más que ver con tiempos de leyendas de hackers, que de una realizad encarnizada como la que sufrimos ahora.

Windows XP fue pasando por todos los estadios habituales en el ciclo de vida de un software. Se implantó, se actualizó, se parcheó, se acabó el soporte normal, se acabó el soporte extendido y a partir del 8 de Abril se convierte, oficialmente en Abandonware.

Esto implica que los CTOs de todas las organizaciones, responsables no solo de mantener sino de evolucionar y cuidar de los sistemas informáticos han tenido tiempo más que suficiente para hacer un plan de migración de todo, porque si no sería la cosa más irresponsable que habría visto en mi vida.

Mantener un sistema como Windows XP en una empresa será prácticamente un suicidio a partir del 8 de Abril, ya teniendo el modelo de amenazas de ese Kernel 5.2 que comenzó a diseñarse en el siglo XX, sumado a que aparecerá sí o sí un bug de explotación remota en Windows XP Abandonware Edition, y a que el mundo en el que vivimos es de una beligerancia total, entrar en las empresas será juego de script-kiddies.

En estos tiempos a todos se nos han llenado los oídos de mensajes de CiberSeguridad Nacional, Ley de Protección de Datos, Esquema Nacional de Seguridad, etcétera, lo que a mi entender implica directamente que tener un Windows XP en una administración pública sea una negligencia de tal envergadura que debería ser hasta denunciable por los ciudadanos.

De hecho, he cogido como manía el estirar la nuca cual serpiente con capacidad de tornar el cuello hasta 270 grados, para conseguir un ángulo de visión mejor de la pantalla del equipo de todas y cada una de las persona que me interrogan por alguno de mis datos personales. Temo encontrarme otra vez las barras de las ventanas de Windows XP.

Por supuesto sé que migrar un sistema operativo no es fácil. Hacen falta recursos económicos, hay que migrar las aplicaciones por encima, cambiar los procesos, las herramientas de soporte y administración, las habilidades de los técnicos y los usuarios. Sí, es cierto, por eso son sistemas informáticos y se administran. Por eso hay CTOs, CISOs, CEOs, CIOs, etcétera en las empresas. Para planificar, para prever, para gestionar la evolución tecnológica segura de las empresas. ¿Somos o no somos informáticos? ¿Somos o no somos buenos en nuestro trabajo administrando sistemas informáticos?

Cambiar las tuberías, las fachadas, la electricidad o las canalizaciones de gas de un edificio no es fácil tampoco, pero hay que hacerlo. Ahora toca a los jefes de los sistemas informáticos responder que lo hicieron porque tuvieron un plan. Y si no lo hicieron, entonces está mal hecho.

A partir del día 8 de Abril se acabaron las bromas. Si tienes un Windows XP en una empresa está mal y tienes un problema, pero si lo tienes en administración pública, tenemos todos un problema que debemos resolver, porque se acabaron los parches de seguridad. No sirve de nada que sigas invirtiendo en otras medidas de seguridad, si la básica que es el parcheo de bugs de los sistemas operativos que dan vida a tus equipos informáticos no existen. Usar software sin soporte es un error grave, usar un sistema operativo sin soporte es un error fatal.

Si estás en cualquier sitio y ves un Windows XP Abandonware en un sitio que no debiera estar, ponme un e-mail con una foto. Yo periódicamente voy a ir recopilando las fotos de los Windows XP que vaya encontrando en sitios que creo que no deberían estar para ver si a todos nos entra en la mollera que la seguridad es importante.

Saludos Malignos!

GeoHot: El hacker que liberó el primer iPhone, lo cambió por un 350z y tuvo un problema legal con Sony por la PS3

Si hay un hacker que me impresiona sobre manera es George Hotz, conocido como GeoHot. Su historia, sus logros, y su trabajo técnico es impresionante y tendrás que aprender todo lo que hizo si quieres saber más de Hacking iOS. Con la tierna edad de 17 años se convirtió en el primer hacker que fue capaz de hacer un unlock a un iPhone original. Un unlock en terminología de teléfonos móviles hace referencia a liberar un teléfono del bloqueo del operador, y GeoHot fue el primero que lo hizo en iPhone para liberarlo del bloqueo con que lo distribuía AT&T.

Figura 1: Foto de un joven GeoHot 

Como su trabajo de liberación no estaría completo mientras existiera un bloqueo de Apple en el terminal, también hizo creó varios exploits para bugs que descubrió en el iPhone que le permitieron crear varias herramientas de jailbreak, entre los que se encuentra el archifamoso bug de BootROM que explota limera1n, y que está presente el firmware de los iPhone Original, iPhone 3G, iPhone 3GS e iPhone 4, permitiendo que se pueda seguir haciendo jailbreak hoy en día, incluso con iOS 7.1 a los dispositivos de Apple vulnerables.

El primer iPhone Original al que hizo unlock lo cambió por un Nissan 350z - bonito coche - cuando aún contaba con esa edad de 17 años, y con todo el desparpajo del mundo le podéis ver en la siguiente entrevista en CNN hablando del cómo y el porqué del unlock y el jailbreak en los terminales iPhone Original. Digno de ver.

Figura 2: GeoHot entrevistado en la CNN para hablar del unlock y jailbreak de iPhone

Keys Open Doors y un Pwnie Award

A día de hoy GeoHot tiene 24 años, y aunque joven, desde que liberó el primer iPhone tuvo tiempo de estudiar la forma de hacer el jailbreak de la PlayStation 3 de Sony y hacer descubrir la clave maestra que daba paso a todo. En su web personal publicó un sencillo texto "Keys Open Doors", por el que puedes encontrar replicada en miles de sitio la clave necesaria para hacer el proceso. 

A Sony no le gustó esto, y denunció a GeoHot. A la comunidad de Internet no le gustó que Sony demandara a GeoHot y comenzó una avalancha de ataques a los servicios de Sony que llevó a que las cosas se les fuera de las manos con tanta brecha de seguridad, incluso meses después de que la demanda fuera retirada.

GeoHot, fiel a su desparpajo natural decidió dedicarle una bonita canción a Sony que grabó en su casa, y con la que ganó un Pwnie Award a la mejor canción en la edición de los premios de BlackHat USA 2011. Este es el vídeo que no debes perderte.

Figura 3: GeoHot dedica un Rap a Sony por su demanda

Tras toda la avalancha de problemas de seguridad, Sony decidió llegar a un acuerdo con GeoHot por la vía rápida. En el acuerdo GeoHot se comprometía a no volver a hacer ingeniería inversa, hackear, o liberar ninguna herramienta o información de ningún producto de Sony, o debería pagar 10.000 USD a Sony. GeoHot accedió, y se comprometió a no hacerlo nunca más (al menos con su nombre).

Remain Vigilant & Don´t buy Sony products

De aquella historia, Sony dejó para el recuerdo la frase más famosa que se recuerda tras el robo de identidad que sufrió. Tras reconocer que le habían quitado los datos de sus clientes - muchos los puedes encontrar en "Have I been Pwned?" y desperdigados en pastes varios, publicó un post en su blog en el que decía esta frase:

Figura 4: Te animamos a permanecer vigilante

Al final, los datos se los habían quitado ya y poco podían hacer más que entonar el mea culpa y avisar a las verdaderas víctimas del robo de identidad de que sus datos habían volado hacia discos duros en quién sabe qué ubicación de la red.

Por su parte GeoHot nunca volvió a publicar nada sobre hackear ningún producto de Sony, pero sí que actualizó su web personal para poner este texto en el que recomienda no comprar productos de Sony o de cualquier compañía que lo demande en el futuro.

Figura 5: Web personal de GeoHot con el mensaje a Sony

A día de hoy GeoHot sigue estudiando y pese a todo el buzz en los media parece que tuvo claro que ir a la Universidad era lo que tenía que hacer, donde ahora además está con un proyecto personal de creación de su propia Start-Up aunque se rumorea que sigue metido en el business del jailbreak.

Figura 6: Foto más actual de GeoHot con un terminal móvil de...

Puedes seguir sus publicaciones públicas en Twitter en su cuenta @GeoHotUS.

Saludos Malignos!

Cuentas robadas y bloqueos en Yahoo!, Gmail y Hotmail

Gestionar la seguridad de cualquier servicio online que sea ofrecido por Internet sin poner un ojo en los rincones de la red donde se encuentran las guaridas de los ladrones de identidad es imposible. Es por eso que para todas las empresas que precien la seguridad de sus sistemas su CPD hace tiempo que se convirtió en un Mundo Sin Fin. Con estas cosas en mente fui a probar a ver cuánto tardan las cuentas identidades robadas de los servicios de Hotmail, Yahoo! y/o Gmail en ser bloqueadas o qué medidas de seguridad tenían después de ser expuestas en algún rincón de Internet, y la verdad es que ha sido un resultado curioso que os cuento por aquí.

Buscamos un dump fresco

Para hacer la prueba me dediqué a buscar en Pastebin algunos ficheros con dumps de passwords que no llevaran mucho tiempo publicados. La idea es tan sencilla como filtrar los resultados por fecha y hacer las búsquedas adecuadas para que aparecieran los dumps. Alguno con varios miles de claves, otros con solo algunos cientos, pero en todos ellos con cuentas de Microsoft, Yahoo! y/o Hotmail, que es lo que quería probar y que seguramente habrían sido robadas por medio de algún malware in the browser.

Figura 1: Dump con 3708 cuentas con 24 horas de antigüedad

Pruebas con los sistemas de protección "autenticación adaptativa"

En el caso de Gmail lo cierto es que si las cuentas tenían más de 24 horas no parecían funcionar ninguna de ellas, pero en algún caso llegué al segundo factor de verificación. Este segundo filtro de seguridad salta debido a que la huella digital de la conexión de esa cuenta no le encajaba a Gmail, y por tanto - con buen criterio - se asumía que había posibilidad de que no fuera una conexión legítima.

Figura 2: Segundo factor para una cuenta robada de Gmail.

La huella digital de la conexión se genera para conocer el patrón de conexión habitual de un cliente, como su región geográfica, su navegador, y la configuración del entorno de completo, algunas veces con técnicas de fingerprinting del navegador exhaustivo. Con estos datos, si se nota un cambio radical lo que debe hacerse es bloquear la conexión con un segundo desafío.

En el caso de Microsoft Hotmail las cuentas tampoco parecían bloqueadas, pero si protegidas por alguna capa extra debido al "número" de conexiones simultáneas desde diferentes zonas geográficas, y de nuevo aparecía un desafió de segundo factor.

Figura 3: Cuenta con protección, pero la password parece funcionar

En el caso de Yahoo! de nuevo apareció un comportamiento similar. Primero un captcha doloroso que obliga a afinar tu humanidad para reconocer los números y las letras, y luego una verificación extra cuando la contraseña era correcta para poder continuar.

Figura 4: Segundo factor en Yahoo! para una cuenta robada. Contraseña funciona.

En todos los casos el haber realizado las pruebas desde la red TOR sumado a la huella digital de las conexiones parece que genera alertas extras de seguridad, lo que tiene más que todo el sentido del mundo. Es por eso que yo me "quejé" de que el comportamiento de algunos bancos en su banca online no detectarán un cambio de conexión en la huella digital tan brutal como conectarse a la cuenta por medio de la red TOR cuando antes nunca se había realizado.

Para terminar, también probé alguna cuenta de Facebook, pero al salir por un nodo en la red TOR situado en alguna dirección IP de algún país remoto, acabé topándome con una barrera idiomática. 

Figura 5: Cuenta de Facebook ...¿?

Lo cierto es que con las cuentas de Facebook, a veces puedes saber mucho sobre la víctima, ya que con las búsquedas en el propio Facebook es fácil saber a quién le han robado la cuenta en cada momento.

Rompiendo la barrera geográfica

Por supuesto, también hay dumps con la dirección IP de la víctima, lo que ayuda a que sea más fácil saltarse la validación de "ubicación extraña" si controlas algún equipo cerca de esa ubicación geográfica.

Figura 6: Dump con usuarios, passwords y direcciones IP

Dicho esto, os recomiendo a todos que pongáis un second factor authentication tipo Google Authenticator a tu cuenta Gmail, una verificación en 2 pasos para Apple o asociar un número de teléfono para poner un OTP en Hotmail, o poner un Latch en los servicios que ya puedas... just in case.

Saludos Malignos!

No Lusers 167: Extreme Bring Your Own Device

Figura 1: No Lusers 167: Extrem eBring Your Own Device 

Aplicar una política Bring Your Own Device es algo que ya muchas empresas han realizado, pero no siempre de la forma más correcta. En esta viñeta de No Lusers hecha a boli en un rato libre de este fin de semana he querido llevar al extremo una de las situaciones que he vivido en algún proyecto en mi vida cuando se han limitado los dispositivos que se pueden traer a una empresa.

Supongamos una política BYOD donde los usuarios traen terminales Android que no tienen soporte por el fabricante para actualización de nuevas versiones del sistema operativo, o entornos donde el usuario realiza jailbreak al terminal para instalarse cualquier cosa. Eso dispositivos se pueden convertir en un posible foco de infección dentro de la red, que acaben con troyanos de espionaje que puedan grabar hasta las conversaciones en las reuniones o malware usado en esquemas APT contra organizaciones.

El uso de políticas BYOD está bien por muchos motivos - entre otros porque es casi imparable la entrada de dispositivos nuevos en nuestros entornos de trabajo - pero desde el punto de vista de seguridad es fundamental marcar una lista de dispositivos aprobados dentro de la BYOD, y a ser posible que tengan que estar sometidos a controles o monitorización de seguridad, sino acabarás teniendo que formar a tus técnicos de sistemas - seguro que acabarán siendo BOFHs o iBOFHs - y seguridad en mil y un posibles problemas. No abraces el Extreme Bring Your Own Device.

Saludos Malignos!

Uso de API Hooking en Windows para analizar binarios

Una de tantas técnicas que usan algunas muestras de malware es la conocida como API Hooking aunque en este artículo lo que me interesa es darle una función buena a esta técnica para poder facilitarnos un análisis a alguna muestra de software malicioso. Vamos a repasar un poco antes para entender el proceso.

Introducción

Los procesadores X86 de Intel y compatibles tienen 4 niveles de privilegios que son conocidos como "anillos" o Ring 0 a Ring 3. En los sistemas operativos Win32, tal y como se explica en el libro de Máxima Seguridad en Windows, solamente se hace uso de los niveles de Ring 0 y de Ring 3 y donde nosotros trabajaremos con las aplicaciones será en nivel de usuario que es el conocido como Ring 3.

Ring 0: Mayor privilegio (nivel kernel del Sistema Operativo)
Ring 1
Ring 2
Ring 3: menor privilegio (nivel usuario)

Cuando trabajamos con Ring 3 estaremos invocando a las APIs del sistema Microsoft Windows de nivel de usuario que proveen la funcionalidad del sistema que permite a un programador hacer que un programa funcione sobre este sistema operativo. Estas funciones de la API de Ring 3 cuando necesitan un acceso privilegiado lo que hace es entrar a nivel kernel Ring 0 a ejecutarse, y después retornar a nivel usuario para de esta forma aislar el programa del nivel de Ring 0.

Ahora bien, crear un gancho o Hook para alguna función de la API es simple y existen diversos métodos. Uno de esos métodos que es muy sencillo pero a la vez muy útil es el conocido como Método del Columpio, que se basa en inyectar una librería DLL al proceso. Se le llama así porque la primera instrucción que se coloca al iniciar la función de la API que es una redirección a nuestro código inyectado.

La idea con API Hooking es que si podemos enganchar no una, sino todas las APIs del sistema, por ejemplo las de manipulación de archivos o las de conexiones de red, entonces se podría crear un registro en un fichero LOG con todo lo que va modificando el binario cuando se ejecuta, tal y como hacen herramientas de análisis profesional de malware. Esto tiene algunos pros y contras ya que me he encontrado algunos bichos que detectan y eliminan algunos ganchos ya que es una de las técnicas para poder evadir algunas sandbox de análisis de malware, por ejemplo la famosa Cucko Sandbox.

Un ejemplo de API Hooking

En este ejemplo vamos a hacer una pequeña prueba para monitorizar un supuesto fichero malicioso para guardar en un fichero todo lo que haga en nuestro sistema relativo a ficheros y claves de registro. Comenzaremos con el código de este proyecto que se encarga de incluir nuestra DLL dentro del proceso del malware. cargando el proceso suspendido con la función de la API CreateProcess.

En este caso el proceso será nuestro supuesto malware al que he llamado virulo.exe. Posteriormente hacemos espacio en el proceso e incluimos nuestra DLL con VirtualAllocEx y WriteProcessMemory. Para terminar se crea un hilo en la DLL que inyectamos y con ResumeThread conseguimos que siga ejecutándose el proceso suspendido ya con la DLL que se encargará del resto:

Figura 1: Inyectando la DLL

Ahora pasemos al código de la DLL encargada de hacer el gancho donde lo que está remarcado en rojo es quizá lo mas importante para entender cómo funciona. Lo primero que hacemos es obtener la ruta donde está ubicada la librería que contiene la API que nos interesa y así obtener con GetProcAddress el offset de la API. Posteriormente hacemos una llamada a “inyector” que es una rutina que he añadido a la DLL para poder enganchar varias y no solo una API, aunque en este artículo no entraré en tantos detalles. Los parámetro que pide y su contenido son:

Figura 2: DLL que hace el hook de la API

Direcciones: El offset de la API.
Bytesoriginales: Dirección del buffer donde guardaremos los bytes reales.
Bandera: Contiene la dirección a donde queremos redirigir nuestro gancho.

Como verán, el código esta comentado y básicamente lo que hace es guardar en uno de los parámetros que coloqué los bytes originales para mantenerlos y si queremos después volver a colocarlos en su lugar.

Figura 3: Parámetros para volver a reparar el estado

Ya guardado todo, pasa a cambiar los permisos a escritura a la zona donde se inicia la API que queremos enganchar, pues para poder escribir los primeros bytes debemos cambiar el permiso si no saltaría una excepción y no pasaría nada. Después escribe algunos bytes, como son 0x68 que es el offset de mi redirección y 0xc3 que corresponden a un “Push + dirección” y un “RET”. Esto podríamos verlo dentro del debugger, por ejemplo en la API MessageBox.

Figura 4:  Cambiando los permisos y hookeando la API

Esto es básicamente el gancho y ya tenemos hookeada nuestra API lo cual es un columpio hacia nuestro código. En este momento podríamos hacer algunas cosas como registrar todos los movimientos que hace. Apoyándonos con el stack o pila en una API que de acceso al registro como "RegQueryValueExA" podríamos ver en la pila:

Figura 5: Valores en la Pila del proceso

Recuerden que ya estamos en el mismo proceso por lo tanto manipular los parámetros que tiene el stack es simple pues el registro ESP contiene siempre el inicio de la pila. Sumando un ESP+4,  ESP+8, etcétera podríamos obtener los datos de qué es lo que lee, crea, etcétera la API o las APIs hookeadas y hacer un registro de acciones realizadas por el proceso, que era la idea principal de la herramienta, pero también podríamos jugar creando filtros para saber exactamente en qué parte del registro hace los cambios, por ejemplo:

Figura 6: Filtrando los cambios en el registro de Windows

Si queremos restaurar lo que hemos hecho para que todo actúe otra vez normal sin ganchos o redirecciones, podemos hacerlo entrando a otra rutina que nombré como “repairbytes” cuyos parámetros son:

DireccionesAPI: Dirección de la API a restaurar.
Bytesoriginalesencurso: buffer que contiene los bytes originales que guardamos.

Esta rutina es similar a la anterior que escribía al inicio de la API, solo que en lugar de guardar los bytes originales, los saca del buffer y los ubica donde estaban originalmente:

Figura 7: Para dejar el sistema como estaba

Las últimas pruebas que hice fueron monitorizar las actividades del registro y manipulación de archivos, guardando en un fichero de LOG con extensión .ini toda esa información:

Figura 8: El fichero de LOG con los datos de actividad

Conclusiones

Con este ejemplo se puede ver cómo funciona el API Hooking en Ring 3 con el Método del Columpio, utilizado para analizar malware o para hacer proyectos de ingeniería inversa en cualquier otro índole, como por ejemplo las técnicas de cracking, exploiting o fuzzing para hacer  auditoría de seguridad de binarios. Mi idea es seguir desarrollando estas técnicas y hacer una herramienta de monitorización que funcione con solo hacer drag and drop de un binario a una sandbox y genere un informe de actividad, así que si alguien se anima a colaborar que contacte conmigo.

Autor: Alejandro Torres (TorresCrack)
Twitter: @TorresCrack248

Microsoft gestiona regular su SEO en Microsoft BING

Cuando tengo que dar una charla con mis máquinas Microsoft Windows siempre utilizo una herramienta para hacer zoom en las partes más interesantes de la pantalla. Esa herramienta se llama Microsoft ZoomIT - fue creada por Mark Russinovich - y desde la adquisición de la compañía SysInternals por Microsoft, forma parte de las utilidades que se pueden descargar desde la web de Microsoft TechNet.

Lo curioso es que si buscas en BING la herramienta ZoomIT, el primer enlace que te oferta la web es el de Softonic, ya sabéis, la web esa que se dedica a re-empaquetar las herramientas públicas de Internet con nuevos instaladores que poner barras de navegadores, y crapware vario.

Figura 1: Resultados de Softonic en Bing

Cuando lo he buscado en Google, sorprendentemente el primer enlace que sale es el de Microsoft Technet, así que o Microsoft se curra mejor el SEO en Google de sus sitios o bien en BING no se han tuneado bien los resultados que deberían ofrecerse.

Figura 2: Resultados de Zoomit en Google

He mirado a buscar otras herramientas de Microsoft en BING, y la batalla es dura. En algunas consigues primero el enlace de Microsoft, en otras el enlace de la indeseable Softonic. Una de las que más me ha llamado la atención ha sido la búsqueda de Microsoft OneNote, que como ha sido anunciado su disponibilidad gratuita seguro que se está de moda.

Figura 3: Resultados en BING de buscar descargar onenote

Al final no sé si Microsoft debe trabajar mejor el SEO en BING de sus productos o mejorar en BING algo para que no pasen estas cosas, que al final genera insatisfacción en los usuarios que empiezan a ver como sus sistemas operativos se llenan de basura.

Saludos Malignos!

Más de 161 millones de identidades pwneadas en Internet

En muchas conferencias de las que he dado últimamente he hablado del sitio Have I been Pwned? que se dedica a recoger bases de datos de identidades expuestas en Internet tras el hackeo de sitios de renombre. En este sitio se encuentra, por ejemplo, la base de datos de Adobe con 152 millones de identidades, que es la más llamativa, pero también hay otras como una de Vodafone con algo más de 52 mil cuentas expuestas, la de Snapchat con más de 4 millones de identidades, la base de datos de Forrester y Gawker con algo más de 1 millón de cuentas cada una, etcétera.

Figura 1: Bases de Datos consolidadas en Have I been Pwned?

Al final, la lista alcanza los más de 161 millones de identidades en Internet, por lo que si alguien ha tenido la brillante idea de utilizar una cuenta de otro sitio para registrarse en los servicios hackeados y usar una contraseña repetida, entonces sus cuentas están en serio riesgo.

Figura 2: Cómo conquistar el mundo gracias al password reuse por XKCD

El servicio en cuestión de Have I been Pwned? permite realizar búsquedas de cuentas de correo electrónico en esa base de datos, para ver si alguna cuenta de correo electrónico ha aparecido en alguna de ellas. Yo he buscado por ejemplo admin@forbes.com y puedes ver que aparece expuesta en el incidente de hackeo de Forbes, lo que es hasta normal.

Figura 3: La identidad de admin@forbes.com aparece en la base de datos de Forbes

Lo que no es tan normal es que ma haya salido como resultado que la cuenta admin@sony.com no aparezca en la base de datos del hackeo Sony y sí por el contrario en la base de datos del hackeo de Adobe, como es el caso.

Figura 4: La cuenta de correo de admin@sony.com apareció en la base de datos de Adobe

Que el administrador de Sony ha utilizado su cuenta de correo para registrarse en Adobe es una mala idea, pero esperemos que al menos no haga reutilización de passwords ni tenga algún método de construcción de contraseñas similares al de Dan Kaminsky en su famoso pwnage... o que al menos use Latch }:)

Saludos Malignos!