31 oct 2016

Dirty COW: Una condición de carrera que provoca una escalada de privilegios

La semana pasada se publicó un exploit que se aprovecha de una vulnerabilidad para lograr ejecutar código en un contexto privilegiado. DirtyCOW es una vulnerabilidad de condición de carrera que puede provocar la ejecución de código y lograr una escalada de privilegios en un kernel de Linux. Afecta a todas las versiones del sistema operativo y podemos encontrar un mayor nivel de detalle en su CVE-2016-5195. Además, DirtyCOW va camino de vulnerabilidad mediática, por lo que tiene su propio sitio web y su propia imagen.

¿En qué consiste la vulnerabilidad? Realmente es una condición de carrera que se encontró en la forma en la que el subsistema de memoria del kernel de Linux gestiona COW, Copy-On-Write. En otras palabras, un usuario local sin privilegios podría utilizar esta vulnerabilidad para escribir y tener acceso a partes del sistema que son de otros usuarios, incluido el root. En el instante que se puede acceder a la escritura a partes pertenecientes a root, se puede escribir código que, al ser ejecutado, por ejemplo, con setuid, permiten ejecutar código con dicha identidad consiguiendo la escalada de privilegio.

Como curiosidad hay que decir que la vulnerabilidad ha estado presente durante muchos años, desde la versión 2.6.22 del kernel de Linux, la cual fue liberada allá por el año 2007. Incluso, LInus Torvalds comentó en su día que la vulnerabilidad existía, pero todo era de forma teórico. Hoy día, ya tenemos un exploit público que se aprovecha de la vulnerabilidad para lograr ejecutar código con privilegio, y lograr la escalada.

Para verificar que mi sistema es vulnerable o no a esta vulnerabilidad podemos ejecutar la siguiente instrucción en un terminal: uname -a. Si la versión del kernel está entre la 2.6.22 y la 3.9, tendremos un problema. El exploit público está preparado para arquitecturas x86 y x64, solo hay que descomentar la parte que no nos interesa.


En exploit-db encontramos una de las pruebas de concepto de las varias que hay en Internet sobre el exploit. Para nuestra prueba de concepto utilizaremos la que hemos visto en exploit-db, pero os recomendamos que echéis un ojo a las distintas pruebas de concepto que se han ido publicando en Internet. En Github, se ha montado un repositorio sobre todas las pruebas de concepto. 

PoC: Escalando privilegios con DirtyCOW

Una vez descargado el exploit, vamos a editar el exploit para, en función de nuestra arquitectura, amoldarlo a las necesidades. Si estamos en un sistema x86, debemos comentar el payload generado con msfvenom de Metasploit para x64, y si nos encontramos en un sistema x64, sería justamente al revés. 


Una vez tengamos claro esto, debemos compilar el exploit escrito en C, para ello ejecutamos la siguiente instrucción gcc [exploit.c] -o [exploit binario] -pthread. Esto llevará a cabo la compilación del exploit y lo tendremos disponible. Si pensamos en el hardening de servidores Linux tenemos que pensar que tener disponible el compilador en un servidor o máquina dónde no se lleven a cabo este tipo de tareas no es una buena práctica de seguridad. Imaginemos que en un servidor disponemos de gcc u otros compiladores, estamos dando un arma a los atacantes, que hayan llegado hasta aquí. 

Una vez compilado, lanzamos el binario y podremos ver que el exploit tiene éxito. En el momento que tiene éxito, disponemos de una sesión como root en la máquina local. Lógicamente, este tipo de escaladas de privilegios, pueden ir ligadas con un ataque previo remoto, en el que un atacante o un auditor consigue acceso al sistema, para posteriormente lograr la escalada de privilegio. Ya lo tenemos migrado al famoso framework de explotación Metasploit.


Por último, os dejamos el video sobre la explotación local de la vulnerabilidad en un sistema Ubuntu 14.04. Existen ramas en el kernel de Linux que ya están parcheadas, que no son vulnerables a DirtyCOW, por lo que recomendamos a todos los equipos de IT que verifiquen que sus versiones de kernel de los sistemas Linux no sean vulnerables.

30 oct 2016

Informe Flu - 272



Buenas a todos, como cada domingo os dejamos con nuestros enlaces de la semana :)
    Lunes 24 de Octubre
      Martes 25 de Octubre
      Jueves 27 de Octubre

        27 oct 2016

        Descubriendo facturas por la red

        Muy buenas a todos, tras varios años realizando pentests a numerosas compañías, he tenido la oportunidad de participar en procesos de hacking ético a bancos, operadoras de telefonía, aseguradoras, empresas del sector utilities, y un largo etcétera de organizaciones muy diferentes entre sí. Sin embargo y por suerte, en contadas ocasiones me he encontrado con ficheros muy críticos subidos a un servidor web (por razones obvias) como puedan ser las facturas de una empresa, que puedan exponer su listado de clientes, los productos/servicios que adquieren o venden, su lista de precios y ofertas, etc. cuyo valor para la competencia puede ser incalculable.

        Dando un paseo por Google, me dio por buscar algunos términos clave como "factura euros iva s.l. dirección cif fecha total" unidos al verbo ext, con el fin de filtrar por archivos de tipo PDF, que pudiesen contener facturas reales emitidas o recibidas por un organismo; y fue curioso observar los centenares de compañías que tienen expuestos datos tan críticos sobre su facturación tan a la ligera:


        Organizaciones del sector textil, de servicios integrales, de viajes, .... la lista es grande y daría para un libro. Este problema sería resuelto de dos sencillas maneras, el primero y por descontado eliminar la presencia de facturas y archivos críticos de cualquier servidor expuesto a Internet, y en segundo lugar, revisando la seguridad de dichos servidores antes de publicarlos a Internet. Al final, la mayor parte de estas indexaciones en google son producidas porque los servidores web se encuentran mal configurados y presentan un listado de directorios, de manera que los bots de Google lo tienen fácil para recorrer todos los archivos del server y almacenar sus ficheros en su base de datos, presentándolos a las pocas horas cómo resultados de sus búsquedas:


        Administradores de sistemas (o a quien corresponda), cuidado con lo que colgáis en los server de vuestras organizaciones, no alimentéis sin querer los instintos de hacer una guerra sucia a vuestra competencia...

        Saludos!


        25 oct 2016

        Encuesta: ¿Qué quieres para tu futuro? ¿Seguridad?

        Nuestro día a día cada vez es más rápido, cada vez la tecnología avanza más rápido y nuestra sociedad debe estar preparada. En nuestro sector, la seguridad de la información, debemos estar preparados para las nuevas amenazas y riesgos que Internet y la nueva sociedad de la información proporcionan. En este artículo, simplemente, pretendemos hablar del crecimiento del mercado de la seguridad de la información, cada día hay más demanda de personal cualificado, personas a las que les apasione la seguridad y que disfruten descubriendo día a día lo que este sector es capaz de proporcionar.

        En muchas ocasiones nos preguntamos que es lo que realmente gusta a los nuevos informáticos que día a día van saliendo de FPs, Universidades o, sencillamente, autodidactas que tienen la misma pasión que nosotros por este trabajo. No hace mucho, me tocó dar una charla en una Universidad de la Comunidad de Madrid y pude ver como eran las empresas de consultoría y audoría las que iban detrás de los futuros informáticos. Esto puede provocar una reflexión, ¿Qué es lo que quiere realmente el joven que en poco tiempo se meterá en el mercado laboral? Entendiendo que la seguridad le interesa, ya que asiste a este tipo de eventos, ¿Qué es lo que realmente les interesa?


        La respuesta es sencilla: es difícil de saber. La seguridad de la información es un campo muy grande, por lo que no es fácil dar una respuesta sobre gustos e intereses. Si nos centramos en la rama de la seguridad informática la cosa cambia, todos van hacia la parte técnica, aunque hay posiciones ofensivas y defensivas. ¿Qué es lo que le interesa a la gente que el blog? ¿Qué es lo que le interesa a la gente que asiste a los eventos de seguridad informática?

        Incluso la rama de seguridad informática tiene muchas posibilidades: pentesting, hardening, hacking web, hacking de redes inalámbricas, seguridad en redes, análisis forense, incident response, etcetera. Nosotros, hoy, queremos hacer una pequeña encuesta para poder los gustos de los lectores. 

        24 oct 2016

        Ataques MITM en IPv6, renovarse o morir. Parte 1

        Buenas a todos, en el post de hoy me gustaría iniciar una nueva cadena de varios artículos para hablaros sobre los ataques MITM en redes de datos IPv6. Esta cadena la iremos alargando en función de las inquietudes que nos vayáis transmitiendo o ideas que queráis ir compartiendo con nosotros.

        ¿Por qué una cadena sobre IPv6 y MITM? Sobretodo cuando se trata de un protocolo que lleva más de 20 años con nosotros... Pues la respuesta es sencilla, y se puede responder con otra pregunta, ¿cuántos administradores de sistemas de cualquier organización dominan IPv6? ¿Un 20%-30%? quizás... ¡y siendo generosos! Esto quiere decir que si los ataques de envenenamiento ARP y los MITM en IPv4 siguen siendo un éxito en muchas de las revisiones de hacking ético que realizamos los pentesters en nuestro trabajo diario, imaginaros en IPv6, que se encuentra configurado en infinidad de organizaciones sin que el personal de sistemas se haya percatado de tal hecho.

        Para la realización de los ataques MITM en IPv6 primero tendremos que familiarizarnos con el propio protocolo. La diferencia principal que encontraremos frente a IPv4 es que ahora tenemos direcciones IP de 128 bits, separadas en 8 grupos de 16 bits escritos en hexadecimal. Un ejemplo de dirección podría ser la siguiente:


        Al igual que en IPv4 se aplicaban reducciones de los ceros, como por ejemplo "192.168.001.001" > "192.168.1.1", en IPv6 se pueden aplicar reducciones de la siguiente forma "fe80:defe:0000:0000:0000:0000:0000:ca10" > "fe80:defe::ca10", eliminando los grupos de 0 consecutivos por "::". 

        Por otro lado, en IPv6 desaparece la máscara de red, apareciendo un nuevo sistema que cumple la misma labor, denominado "prefijo" o "prefijo de subred", con la que podremos hacer subnetting y supernetting.


        En lo referente a la puerta de enlace, se sigue manteniendo al igual que en IPv4, tal y como se puede ver en la imagen anterior.

        Además, ARP deja de existir en IPv6, y en su lugar nos encontramos con el protocolo NDP, siglas de Neighbor Discovery Protocol. Dentro de NDP nos encontramos, entre otros, con los mensajes NS que son los que hacen referencia a las peticiones de resolución de una dirección MAC asociada a IPv6, y los mensajes NA para la contestación con la MAC buscada. Por ello, ya no disponemos de la típica tabla ARP que consultábamos en Windows con el comando "arp -a": 



        Ahora nos encontramos con una tabla de vecinos, que podemos consultar con el comando "netsh interface ipv6 show neighbor":



        ¿Sencillo hasta aquí verdad? 

        Vamos a realizar un ejemplo sencillo para verificar que tengamos IPv6 configurado y podamos lanzar nuestro primer ataque MITM. En primer lugar vamos a levantar dos máquinas con Windows, en mi caso he optado por Windows 7. A continuación haremos un ipconfig con el fin de ver si se encuentra activo IPv6. Si está todo ok, veremos una dirección de enlace local del tipo "fe80::/64" (https://es.wikipedia.org/wiki/Direcci%C3%B3n_de_Enlace-Local). El siguiente paso consistirá en hacer ping de una máquina a la otra con el parámetro "-a", con el fin de ver cual es el nombre asociado a la máquina destino y una vez lo conozcamos, hacer un ping directamente al nombre de netbios. Si IPv6 se encuentra configurado y no nos encontramos algún FQDN (https://es.wikipedia.org/wiki/FQDN) típico de redes corporativas, veremos que ha contestado el equipo de destino desde la dirección de IPv6.

        Bien, tras esta introducción básica y exprés, ya estamos en disposición de iniciarnos en el mundo de los MITM en IPv6, pero eso será en el próximo post. Por lo que podéis aprovechar esta semana para trabajar con IPv6, arrancando Wireshark y comenzando a sniffar algo de tráfico para analizar el contenido de las comunicaciones y estudiar paquetes como ICMPv6, frente al ICMP tradicional de IPv4, para comenzar a entender los entresijos del protocolo.



        Saludos!



        19 oct 2016

        #X1RedMasSegura - Vuelve el concurso de infografías de @X1RedMasSegura. Edición 2017

        Tras el éxito de las Jornadas X1RedMasSegura, en sus 4 ediciones anteriores, todo el equipo nos hemos puesto manos a la obra para la preparación del evento de 2017.

        Este año repetiremos actividades y añadiremos otras, con nuevos talleres y muchas sorpresas que os iremos revelando según se acerquen las fechas.

        Para ir abriendo el apetito, hoy lanzamos una de las actividades en las que más ganas pusimos, por tratarse algo por y para nuestros menores.

        Hoy da comienzo el plazo de participación en el Concurso "Concurso Jóvenes X1RedMasSegura '17", con el objetivo de concienciar y educar a los más jóvenes en el uso seguro y responsable de Internet.

        Este año de nuevo, los jóvenes pueden participar creando y compartiendo sus Infografías con x1RedMasSegura: se participa de forma individual creando como máximo DOS infografías sobre alguna de las temáticas que se proponen para ello:
        • Contraseñas Seguras 
        • Datos Personales e Internet 
        • Privacidad y Redes Sociales 
        • Amenazas en Internet 
        • Uso de dispositivos móviles 
        En el concurso podrán participar, a título individual, todos los alumnos de Tercer Ciclo de Educación Primaria, Educación Secundaria Obligatoria y Bachillerato a nivel individual, así como colegios o institutos que lo deseen que podrán colaborar y difundir el material didáctico sobre uso seguro y responsable de Internet que se acompaña al concurso, que optarán a ser candidatos a "Centro x1RedMasSegura", para lo que los participantes deberán informar de haber conocido el concurso a través de ellos en las inscripciones individuales.

        ACCESO A LA INFORMACIÓN DEL CONCURSO

        13 oct 2016

        Hacking Devices Around World: Playing ‘Gallinita Ciega’

        Hace un par de semanas se celebró la VI Edición de Navaja Negra y mi compañero de Eleven Paths Rafa Sánchez y yo tuvimos el honor de estar allí para dar una charla. El tema que estuvimos mirando es conocido por muchos, pero quisimos ahondar en el tema motivacional de los ataques y reflejar el nivel de exposición de ciertos servicios que pueden acabar siendo críticos. Además, algo llamaba la atención entre la gente que se juntó en Navaja Negra y era eso de la ‘Gallina Ciega’. 

        ¿Qué es jugar a la gallinita ciega en términos de hacking? Según el libro Got Root, la gallinita ciega es realizar una acción de elección de forma aleatoria, tras la cual la motivación de la acción viene determinada por un simple hecho de exposición. En otras palabras, da igual a quién pertenezca esa dirección IP, esa máquina o esa aplicación/servicio, lo importante es que puedo hackearte y te elijo a ti. En la imagen se puede visualizar parte del diálogo de Got Root, psicóloga y paciente.

        Teniendo claro este sencillo concepto estuvimos revisando diversos informes de varias empresas en el que hablan de la motivación de los atacantes a la hora de llevar a cabo sus acciones. De primeras, sabíamos por informes antiguos que la mayoría de acciones delictivas se realizan sin importar el por qué, el quién eres y el qué tienes. En otras palabras, y tal y como refleja el estudio e informe de IBM – Cyber Security Intelligence Index de 2015, el 49% de los atacantes tiene una motivación “opportunistic”, es decir, sufren una motivación expositiva. ¿Expo qué? La motivación expositiva o por exposición es la motivación que sufre un atacante al descubrir máquinas, servicios o aplicaciones potencialmente vulnerables, sin seguridad o con configuraciones erróneas o débiles. 

        En la charla, ejemplificamos esta motivación expositiva con el hecho de entrar a una discoteca plagada de personas, los ojos pueden seguir a ciertas curvas. La exposición es clara y llama la atención de las personas y, volviendo al ámbito informático, está claro que muchos atacantes no dejan pasar la oportunidad por exposición. 

        El 23% de las motivaciones son de tipo industrial, espionaje, política, etcétera. En la charla comentamos el ejemplo de los hackers rusos que están haciendo “temblar” el sistema de voto electrónico de Estados Unidos y ha sembrado la duda sobre la democracia en dicho país. El 15% pertenece a los insiders y como ejemplo tenemos el caso de Ashley Madison y los Panamá Papers. Por último, el 7% de las motivaciones pertenecen a actos de activismo social o desobediencia.

        Una vez dicho esto y viendo que la realización de los ataques viene de la mano de la oportunidad más que de ataques pensados y planificados quisimos ahondar en los tipos de descubrimiento o Discovery y en cómo juegan un papel fundamental según el objetivo final del atacante. Enumeramos una serie de objetivos detrás de la motivación:
        • Diversión
        • Aprendizaje
        • "Por joder"
        • Económica 
        • Aprendizaje más avanzado
        • Etcétera.
        Necesitamos direcciones IP

        En primer lugar, y antes de lanzar escaneos a todo IPv4 se puede aprovechar ciertas cosas y entender otros conceptos. El caso de los RIRs. Los RIR son los encargados de gestionar los rangos de red que hay en el mundo, diferenciados por continentes. 


        Como ejemplo de la información que se puede obtener de estos organismos encargados del registro de direcciones iP analizamos el reciente incidente del TLD de Korea del Norte. Un error en el DNS del dominio .kp provocó una transferencia de zona que propició que supiéramos todos los dominios que cuelgan de .kp, y aunque puede parecer que existan muchos, solo 28 dominios se ofrecen de Korea al exterior. Por supuesto, la teoría conspiranoica cobra fuerza, pensando que dentro del país tiene su pequeño Internet. 


        Este es solo un ejemplo de que conseguir direcciones IP de máquinas se puede lograr de muchas maneras, incluso no usando la “fuerza bruta” y escanear todo IPv4. En la siguiente dirección URL http://www.cidr-report.org/as2.0/autnums.html encontramos el listando de AS que conectan proveedores con otros y podemos saber el número de redes de las que disponen los proveedores. En el caso de Korea nos encontramos solo 3 redes con máscara “/24” para todo el país. Solo una palabra: Raro.


        Encontrar rangos de redes de proveedores y países es algo realmente interesante. Es una forma lógica de hacer las cosas, pero si aun así no encontramos cosas interesantes podemos tirar de Discovery bruto. ZMap es una herramienta interesante que proporciona la posibilidad de recorrer todo el espectro de IPv4 en un tiempo muy razonable. Por otro lado, también comentamos que motores como Shodan o Censys realizan esos escaneos en bruto, para ofrecer la información a los usuarios que así lo quieran. Es un Discovery pasivo y rápido.

        Por último, quisimos hacer hincapié en el mundo IPv6 y su “difícil” descubrimiento. MrLooquer es un servicio, creado por el propio Rafa, junto a Fran Gómez, con el que realizan una fase de descubrimiento más un proceso de banner grabbing e identificación de servicios. Quisimos destacar el concepto de Dual Stack, y es que hoy día las empresas pueden tener sus máquinas y servicios conectados tanto a IPv4 como a IPv6. 

        Hay ejemplos curiosos en los que podemos ver como una máquina conectada a IPv4 e IPv6 no tiene los mismos puertos en las diferentes “stacks”. Esto es interesante, ya que para muchos IPv6 es más seguro que IPv4 por el simple hecho de ser más difícil de “encontrar” una dirección IP. Esta afirmación es totalmente errónea, ya que estaríamos cayendo en el concepto de Seguridad por Oscuridad, lo cual nos llevaría al error. 

        En un ejemplo que mostramos pudimos ver como una máquina conectada a IPv4 disponía de los puertos 80 y 21 abiertos, mientras que en IPv6 tenía el 21, 80 y 3306. Es cierto que hay una prueba realizada por un investigador que configuró una máquina con SSH, usuario “root” y contraseña “password” en IPv4 y en IPv6. En IPv4 tardaron 12 minutos en encontrar la máquina, lanzar fuerza bruta y comprometer la máquina. En el caso de IPv6 no se llegó a localizar la dirección IPv6, por lo que ni mucho menos se llegó a comprometer. Es cierto que puede dar una sensación de seguridad, pero solo es seguridad por oscuridad. 

        Aplicando un “algo” más

        Estas formas de descubrimiento nos permiten conocer máquinas y servicios expuestos en Internet. Muchas de estas máquinas tienen configuraciones erróneas, servicios abiertos y sin autenticación, etcétera. El nivel de exposición es enorme, y cualquier que pase por ahí puede observar y manipular lo que hay dentro. 

        ¿Y si tenemos la información de máquinas y servicios y podemos detectar vulnerabilidades potenciales? Hablamos de la ponencia “Cómo los malos pueden conquistar el mundo” y mostramos los resultados que se obtuvieron en IPv4 y que se actualizaron el pasado agosto.



        Hicimos una prueba en IPv6. Utilizando la API de MrLooquer y escribiendo un script en Ruby que pudiera detectar las versiones vulnerables de algún software elegido pudimos sacar conclusiones. Detectamos más de 300.000 máquinas con el software ProFTPd, pero solo 39 máquinas con la versión que queríamos la 1.3.3c, para la que tenemos exploit público. En comparación con IPv4 los números quedaron lejos. 

        Encontrando pantallas

        El artículo Hacking de taxímetros en España vía Shodan de Diego Soto nos llamó mucho la atención. Además, tuvimos la suerte de conocerle en Navaja Negra. Realizamos algunas pruebas basándonos en rangos de redes, como algoritmo o pasos a seguir hicimos:
        • Rango de red IPv4 / 16 
        • Buscar con ZMap puertos 6000 abiertos
        • Sobre esas direcciones IP con puerto 6000, es decir servicio X11, abierto lanzar nmap con el script de NSE x11-access, el cual nos indica si ese servidor X11 tiene autenticación o no. 
        Se descubrieron, tanto en IPv4 como en IPv6, bastantes máquinas con X11 abierto y sin autenticación. Con la herramienta xwd se pueden hacer screenshots sobre dichas máquinas, pero esto lo dejaremos para la gente que asistió a la charla. Además, uno de los elementos pudo ser relacionado con su hardware en el mundo físico, incluso se pudo saber si tenía matrícula o si seguía algún tipo de ruta. 


        Por otro lado, si se pueden sacar screenshots se pueden ejecutar acciones de forma remota gracias a X11. La herramienta xdotool permite ejecutar pulsaciones de teclado, eventos de ratón, etcétera. 

        Para ejemplificar el peligro, sin poner a nadie en riesgo, se montó un escenario totalmente real. Una máquina Ubuntu con un servidor X11 expuesto al exterior y sin autenticación. Cabe destacar que la configuración por defecto en la instalación de un Linux es la contraria a la expuesta, pero existe gran cantidad de máquinas en Internet, por alguna razón, con esta horrible configuración. 

        Ideas:
        - Con xdotool crearnos un Remote “Rubber Ducky”.
        - Pulsar partes de una GUI y llevar a cabo acciones.
        - Proporcionar una shell inversa abriendo un terminal y ejecutando nc.
        - En definitiva, control total sobre el sistema con X11 expuesto, con la ACL habilitada para cualquier ubicación y sin autenticar.





        Por último, también realizamos un análisis de VNC. No pensábamos que obtendríamos tantos resultados positivos. Shodan incorpora una aplicación para poder ver todos los VNC abiertos y sin autenticación que están expuestos en IPv4. Preferimos no mostrar lo visto o lo expuesto en Navaja Negra, pero si estás interesado visita: images.shodan.io.

        Conclusiones

        Las conclusiones preferimos enumerarlas y que sirviesen de resumen de la charla. A día de hoy seguimos opinando igual:
        - No pasan más cosas porque no queréis.
        - La motivación expositiva existe y tiene un condicionante claro: la facilidad de accesibilidad. Cualquier, con un conocimiento mínimo, puede aprovecharse, en muchas ocasiones de dicha exposición.
        - La información, sistemas, servicios y aplicaciones están ahí fuera, en Internet, sol ohay que saber por dónde y cómo buscar.
        - En la charla se ha visto que no todo es encontrar máquinas que exponen servicios sin exposición. Además, existen máquinas potencialmente vulnerables o que disponen de configuraciones de seguridad muy débiles.
        - El concepto de ‘Gallinita Ciega’ existe y consiste en la exposición y en la elección aleatoria. 

        12 oct 2016

        Hack & Beers VII - Madrid

        ¡Nueva (y séptima) edición de Hack&Beers Madrid! En este caso, tendrá lugar el próximo viernes 14 de octubre en el local +K Copas situado en Calle de las Infantas, 13, 28004 Madrid, mismo lugar que la edición anterior. Comenzaremos a las 16:30h, y podremos tomar unas cervezas mientras aprendemos con las charlas y ponentes, que en esta edición serán:
        • Fernando Gómez (@fgomezal): “Los Viejos Hackeros Nunca Mueren” 
        • Carmen Torrano (@ctorranog): “Criptografía: pasado, presente y futuro"
        • Ponentes A y B: “Guerrilla TOR”. Charla elegida del Rincón de la propuesta.
        Registro

        Como siempre, agradecer a Pablo y Juan Antonio su disponibilidad y ayuda desinteresada en la difusión de esta nueva edición de Hack&Beers. Si todavía no tenéis vuestra entrada, no os lo penséis y conseguidla en el siguiente enlace: Registro Esperamos veros por allí y que, como en ediciones anteriores, podamos pasar una buena tarde de “hacking” y “beers” entre amigos. Un saludo, Valentín Martín (@valenmarman) y Miguel Ángel Cazalla (@miguelkazabar) – Dinamizadores de Hack&Beers Madrid.

        10 oct 2016

        ¿Me das tu web?: Buscando códigos fuentes de Wordpress por Internet

        Buenas a todos, siempre me ha parecido curioso encontrar listados de directorios en webs de cierta entereza, grandes empresas, clubes deportivos, instituciones públicas, ... Simplemente paseando por Google, sin tan si quiera entrar a ninguno de estos sites, puedes echar la tarde viendo de cuántos servidores puedes descargarte sus archivos y carpetas. Al principio con buena voluntad comienzas reportando, pero la lista es interminable y poco se puede hacer.

        Hoy he querido hacer este ejercicio con wordpress, para ver cuantos administradores de estas plataformas exponen algo tan sencillo como lo que acabamos de presentar. Y podemos localizar nada más y nada menos que 34.000 sitios web vulnerables:


        Si afinamos la búsqueda podemos encontrar cosas muy diversas que los administradores olvidan por sus servidores, como archivos con copias de seguridad de las bases de datos (ficheros generalmente nombrados como localhost.sql, generados por phpmyadmin) o incluso algún uploader de archivos con estas copias de bases de datos comprimidas: 


        Cómo veis, de nuevo Google nos expone de una manera básica, y es necesario (además de bastionar nuestras plataformas), hacer el ejercicio de buscarnos regularmente por los buscadores para ver que saben de nosotros...

        Saludos!

        8 oct 2016

        Promociona tu blog: fwhibbit

        Somos un grupo de personas, colegas, amigos y compañeros. Alumnos que nos conocimos en un curso, unidos por la curiosidad, la duda, la incógnita y el ansia de seguir aprendiendo, de seguir avanzando en nuestro conocimiento, de seguir al conejo blanco...


        http://fwhibbit.es/

        ¿El por qué follow the white rabbit? Porque queremos que esta persecución desemboque en más descubrimientos.

        Observa a la persona más cercana que tengas, mírala, y piensa, que cuando te ve sentado delante de tu ordenador, es probable que no entienda que es lo que haces, que tal cosa no vale para nada. Y cuando intentas explicarle lo que estás haciendo, cómo se hace, y sobre todo, para qué se hace. No lo entenderán, no lo valorarán, porque ellos decidieron tomar la pastilla azul.

        En Follow the White Rabbit, decidimos en algún momento de nuestra vida, seguir al the white rabbit, decidimos tomar la pastilla roja, decidimos embarcarnos en este viaje, decidimos dar lo mejor de todos nosotros, para exponerlo aquí, para seguir con esta lucha imcomprendida para muchos, de que un mundo está dentro de tu ordenador, oscuro y peligroso, y que algunos queremos ayudarte, a través de nuestros conocimientos y afición por el hacking, a protegerte de los peligros que encontrarás en la red.

        Nuestro viaje no ha hecho más que comenzar, en él, haremos lo posible para aprender, avanzar y progresar en esta incesante persecución del white rabbit, a través del hacking. También participamos en el canal de youtube Rabbit Hutch ligado al blog, donde hacemos lo mismo pero más "visual".https://www.youtube.com/channel/UCxZfTx6KRz6pOoe-QLo9GRA
        Es nuestro hobby, nuestra manera de ser, nuestro estilo de vida, nuestro camino... y queremos que tú vengas con nosotros, queremos que tú también ¡¡¡Follow the White Rabbit!!!

        fwhibbit Team

        7 oct 2016

        Hacking Web y Python para Pentesters en el Centro de Formación TAES - Valencia (15 y 29 de Octubre)

        Para cerrar el año en Valencia, TAES lanza un par de cursos para el mes de Octubre. Los cursos son: Auditoría y Hacking Web, que se impartirá el 15 de Octubre de 2016 en Valencia (centro de formación de TAES), impartido por Marta Barrio, y Python para Pentesters, que se impartirá el 29 de Octubre de 2016 en Valencia (centro de formación de TAES), impartido por Daniel Echeverry, autor del libro Python para Pentesters. El precio de los cursos son 140 €, cada uno, incluyendo la comida. Para los estudiantes: 80 €, incluyendo comida. 

        A continuación os dejamos el temario del curso de Auditoria y Hacking Web:


        El temario de Python para Pentesters es el siguiente:


        Os esperan el 15 y 29 de Octubre, ¡no pierdas la oportunidad!

        Las formaciones son bonificables por la Fundación Tripartita. No esperes y reserva tu plaza. TÉCNICAS AVANZADAS DE ESTUDIO S.L. - Pasaje Ventura Feliu 10-12. Para inscripciones dirigirse por email a rfuentes@taesformacion.es o al teléfono 963413537.

        5 oct 2016

        CVE-2016-6210: Enumeración de usuarios en OpenSSH basados en tiempo

        El pasado jueves 14 de Julio se hizo pública una vulnerabilidad que afectaba a la última versión de OpenSSH. El CVE-2016-6210 indica que se puede enumerar usuarios en un sistema a través del servicio SSH, gracias al proceso de cómputo que tiene este tipo de servicios. ¿Cómo funciona esto? Un servicio SSH recibe un nombre de usuario y solicita una contraseña para comprobar si debe validar el acceso al usuario remoto o no. Hay que mencionar que la contraseña será solicitada, siempre y cuando este método de autenticación esté habilitado, ya que lo recomendable sería que el método de autenticación fuera de clave pública, sobre todo si el servidor es importante o crítico. 

        ¿Dónde se encuentra la vulnerabilidad? Cuando un usuario remoto envía un usuario y una contraseña al servidor SSH, éste valida en primer lugar el nombre de usuario, si éste no existe o no tiene acceso remoto, corta la conexión. Este corte de conexión provoca que el tiempo de respuesta del servidor sea muy bajo. En el caso de que el usuario exista, el servidor SSH coge la contraseña y la aplica un algoritmo SHA256/SHA512. El proceso de hashing que se lleva a cabo tiene un conste computacional, por lo que, si la contraseña que el usuario remoto envía es lo suficientemente grande, se producirá un retardo importante en el tiempo de respuesta. 

        ¿Dónde está el error? Realmente, el error se encuentra en varias partes. Si analizamos un flujo de ejecución se observa que cuando un usuario no existe solo disponemos del tiempo de comprobación de existencia de usuario, lo cual es algo, prácticamente, instantáneo. Cuando el usuario existe, la contraseña es hasheada para llevar a cabo la comprobación. Esto hace que al tiempo de comprobación de existencia de usuario se le sume el tiempo de hashing, el cual es bastante más grande que el primero. Una posible mitigación es insertar un tiempo de “no operación” con el fin de igualar tiempos en ambos casos. 

        ¿Por qué digo que el error se encuentra en varias partes? Aparte de ver el error en el punto anterior. Otro error de configuración es que el usuario pueda incluir contraseñas enormes, las cuales no tienen sentido. En la prueba de concepto que se ha incluido en el full disclosure se puede ver como la contraseña enviada es de 25.000 A’s. Esto no tiene sentido. Para usar contraseñas tan grandes, lo mejor es cambiar de método de autenticación a una clave pública.

        PoC: Enumerando usuarios

        El código presentado por los descubridores de la vulnerabilidad está escrito en Python y es muy sencillo de entender. Os lo dejo a continuación.

        import paramiko
        import time
        user=raw_input("user: ")
        p='A'*25000
        ssh = paramiko.SSHClient()
        starttime=time.clock()
        ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
        try:
                ssh.connect('127.0.0.1', username=user, password=p)
        except:
                endtime=time.clock()
        total=endtime-starttime
        print(total)

        Ejecutando el código anterior contra un servidor SSH observamos que si el usuario existe en la máquina remota el tiempo se encontrará cercano al segundo. En el caso de que el usuario no exista, la respuesta o corte de conexión se realizará en una magnitud de tiempo muy inferior.


        Como se puede ver, el usuario “pablo” existe y, por lo tanto, obtenemos unos resultados grandes en lo que a tiempo de respuesta se refiere. El resto de usuarios que fueron probados dan resultados mucho más bajos, por lo que quiere decir que los usuarios no existen.

        Esto podría llevarnos a pensar a que podríamos modificar el script de Python ligeramente para leer los nombres de usuario desde un fichero. Cada línea del fichero sería un nombre de usuario e iríamos probando por diccionario que usuarios se encuentran registrados en el sistema.



        A continuación, os dejo la pequeña modificación. Simplemente se añade la lectura de un fichero de texto con diferentes nombres de usuario y la posibilidad de indicarle la dirección IP por parámetro de entrada al script. 


        Descubriendo si root está habilitado o no

        Una de las cosas útiles que pueden ser sacadas de esta enumeración es comprobar si el usuario root está habilitado o no a través del servicio SSH. La buena práctica en fortificación de sistemas GNU/Linux nos dice que no debemos tener habilitado el login como root, para evitar que un usuario se conozca, y que pueda ser utilizados ataques de fuerza bruta contra el sistema. 

        Por defecto, los sistemas y configuraciones modernas de SSH no habilitan por defecto el uso de root. Por esta razón, y para esta prueba de concepto, hemos utilizado un sistema Ubuntu con OpenSSH instalado dónde probaremos el estado de root. Para el primer caso configuramos root con posibilidad de ser accedido en remoto a través de SSH. 


        Como se puede ver en la imagen, el usuario root existe y el tiempo de respuesta de toda la operación es bastante más grande que la del usuario root2, el cual no existe. Ahora vamos a llevar a cabo la misma prueba, pero deshabilitando previamente el usuario root del sistema SSH de la máquina Ubuntu.


        Como se puede ver en la imagen el usuario root tiene unos tiempos cercanos al usuario root2. Esto es debido a que el sistema SSH no ha generado el hash de la contraseña enviada junto al usuario root, ya que por política del servicio el login con root está deshabilitado. Con esto queda demostrado el funcionamiento de la vulnerabilidad y las posibilidades que ofrece en una auditoria o proceso de hacking ético. Se recomienda actualizar la versión de OpenSSH lo antes posible.

        3 oct 2016

        Un phishing de 3 millones de dólares

        Buenas a todos, en el post de hoy me gustaría compartir con vosotros una noticia de hace algunos meses sobre Mattel, la empresa de las Barbies y los Hot Wheels, que de sobra todos conoceréis.

        Comentando esta semana con mi compañero Daniel, estuvimos debatiendo cual había sido el caso de phishing más grande de este año. Tras ver varios casos recientes tanto en España como fuera de nuestras fronteras, dimos con el sonado caso de Mattel, que les costó hace 6 meses la friolera de 3 millones de dólares.

        Se produjo en el mes de Abril, y los 3 millones acabaron en el Banco de Wenzhou, en China, una de las cunas de los scammers. Sin embargo, estos 3 millones no hacen más que unirse a los 1,8 mil millones de dólares que el FBI ha confirmado que han sido sustraídos mediante delitos por Internet recientemente. Y la mayor parte acaban en bancos de China.

        Por casualidad o no, he llevado varios casos similares, aunque de mucho menor importe, y aproximadamente la mitad han acabado en transferencias a bancos de China, pero la otra mitad en la India.

        Un modus operandi habitual se basa en vulnerar servidores de correo electrónico, interceptar los emails de envío de facturas a los clientes. Analizar los dominios de correo profesionales de los proveedores, y registrar dominios visualmente similares, para montar un servidor de correo con una dirección de email lo más parecida posible. Y en una horas, reenviar esas facturas a los clientes pero cambiando la cuenta bancaria. Todo esto lo suelen hacer en menos de 48h. Y cuando las organizaciones se quieren dar cuenta, siempre es tarde... Normalmente se dan cuenta pasados 60 días, tiempo habitual de espera para cobrar una factura de un cliente, cuando contactan con el cliente para reclamar el pago.

        En el siguiente video relacionado con otro caso en el que se sustrajeron 6 millones de dólares, se explica como se produce el lavado del dinero en este tipo de delitos:


        Tenéis todos los detalles sobre el caso en:


        Y en:


        Saludos!

        2 oct 2016

        Informe Flu - 269



        Buenas a todos, como cada semana os traemos nuestros enlaces de la semana :)

          Lunes 26 de Septiembre
          • El lunes abrimos la semana hablando de Los módulos de ingesta de Autopsy. Los módulos de ingesta de Autopsy en sus últimas versiones permiten procesar los datos contenidos en un disco que nos encontremos analizando, extrayendo la información de interés, clasificándola y permitiéndonos exportarla a numerosos formatos de una forma sencilla y cómoda. No es la herramienta más rápida, sobretodo si la comparamos con algunos de sus hermanos mayores como Encase Forensic, pero sí es una utilidad bastante efectiva. Existen 2 grandes tipos de módulos de ingesta de los que os hemos hablado en este artículo.
            Miércoles 28 de Septiembre
            • El miércoles continuamos hablando sobre Los módulos de ingesta de Autopsy, en la Parte 2 de esta cadena de artículos. En él os presentamos los módulos de terceros, desarrollados por la comunidad, y que pueden ser desplegados en las instalaciones de Autopsy, en sus últimas versiones. Disponemos de módulos más orientados a fuerzas y cuerpos de seguridad, como el de "Child Exploitation Hashset", o los de análisis de vídeos e imágenes, otros módulos más orientados a analistas de malware y software dañino, como los módulos de Virus Total, Prefetch o de Windows Registry Content Viewer, y otros módulos más generales. [...]
            Saludos!