sábado, septiembre 23, 2017

Talentum Tour llega a Madrid, Bilbao, Ciudad Real y Valladolid

Como os he contado muchas veces, mi primera "misión" en Telefónica fue trabajar en el programa Talentum - al que yo mismo bauticé con ese nombre tan chulo -. Era el 1 de Febrero de 2012 cuando yo entraba a trabajar en Telefónica. En aquellos entonces aún estaban distantes en el tiempo futuro proyectos como ElevenPaths, LUCA D3, la 4ª Plataforma o AURA, pero la diversión comenzaba.

Figura 1: Talentum Tour llega a Madrid, Bilbao, Ciudad Real y Valladolid

Años después, el programa Talentum sigue impregnando de jóvenes promesas de la tecnología las startups de Wayra, los equipos técnicos de Telefónica, y aparecen en nuevas empresas creadas por ellos mismos. El trabajo que comenzamos un pequeño equipo compuesto por Javier Santiso, Rosalía O'Donnell, Cristina Briales y yo mismo, aún sigue creciendo dentro de la casa, y fuera de ella. Rosalía y Cristina continúan haciendo que sea más grande este proyecto día a día.

Figura 2: Algunos Talentums

Ahora continúan en Tour por las universidades, ofreciendo becas para poder comenzar tu andadura profesional en el mundo tecnológico desde ya, para que puedas compaginar tu etapa formativa y profesional sin necesidad de esperar a terminar los estudios. Las próximas paradas son en Madrid, Bilbao, Ciudad Real y Valladolid.
Si tienes interés en comenzar tu vida profesional de una forma educativa y diferente, te recomiendo que explores las oportunidades del programa Talentum de Telefónica, y si quieres conocer más, que te vengas a uno de estos eventos que van a realizarse. Este programa se creó pensando en potenciarte para tu futuro.

Saludos Malignos!

viernes, septiembre 22, 2017

#TGIF Tres vídeos para ver en la siesta del fin de semana

Hoy es viernes, y no voy a daros mucho texto para leer. Al contrario, os voy a dejar tres vídeos para que los veáis, si os apetece, en algún momento de este fin de semana. A las horas de la siesta, que ya se ha acabado el Tour y La Vuelta, así que, os dejo charlas que ver.

Figura 1: Tres vídeos para ver en la siesta del fin de semana

El primero de los vídeos es la charla que di en Chile, en Un País Digital. Es cortita, de solo 20 minutos, y solo habla un poco de lo que estamos haciendo en Telefónica y el lanzamiento próximo de AURA en Chile. No es profunda, es más divulgativa.


Figura 2: Un País Digital en Chile


El segundo de los vídeos es para los amantes del conocimiento, ya que mis compañeros CSA de ElevenPaths hicieron esta semana una interesante sesión sobre Fog Computing, Edge Computing y Cloudlet Computing que merece la pena que veas para estar informado sobre estas tecnologías. Si no sabes las diferencias, deberías conocerlas.


Figura 3: Fog / Edge /Cloudlet Computing

La última es una charla entre amigos. Una charla entre amigos en Argentina donde Claudio Caracciolo y yo respondemos preguntas de todo tipo, por si queréis ver curiosidades personales y profesionales.


Figura 4: Charla con Claudio Caracciolo en Argentina

Y esto es todo, que tengáis un fin de semana espectacular todos, que hagáis deporte, disfrutéis de comidas, familia y diversión con los amigos. Pero no os olvidéis de alimentar el cerebro, aprender algo y leer algún libro interesante. Yo pienso hacer todo eso y más si puedo.

Saludos Malignos!

jueves, septiembre 21, 2017

Hacking Wi-Fi: Cómo funciona el "Salto de Canal" (Parte 2 de 2)

Una vez que hemos repasado todos estos entresijos de la parte teórica del proceso de "Salto de Canal" en las redes WiFi que vimos en la primera parte de este artículo, ya estamos preparados para crear una pequeña herramienta que realice ese trabajo, así que vamos a ver en esta parte cómo hacerlo. Comencemos con las problemáticas que hemos visto anteriormente una a una.

Figura 16: Hacking Wi-Fi: Cómo funciona el "Salto de Canal" (Parte 2 de 2)

A la hora de hacer un sniffing, tenemos que poder “escuchar” en todos los canales para poder capturar todos los paquetes que viajan por el aire, pero como esto no es posible, puesto que las interfaces inalámbricas tan solo pueden estar escuchando en un canal concreto en un momento determinado, lo que tenemos que hacer es ir cambiando de canal a intervalos reducidos de tiempo. De esta forma, aunque no estemos en todos los canales, virtualmente parecerá que sí.

También es importante recordar que la técnica de salto de canal no persigue capturar en sí todos los paquetes que viajan por el aire, más bien persigue el objetivo de localizar o detectar los dispositivos vivos que están trasmitiendo por el medio. Y, una vez localizados, centrarse en un objetivo concreto, es decir, realizar el sniffing a un solo canal. Por lo comentado hasta ahora, el tiempo que pasemos en un canal es muy importante, de ahora en adelante lo llamaremos “timming”.

Es importante ser conscientes de que muchas estaciones o clientes no están continuamente transmitiendo. Por lo que debemos de utilizar un “timming” lo suficientemente pequeño para barrer toda la banda de frecuencia, pero al mismo tiempo lo suficientemente grande para llegar a capturar los paquetes transmitidos. En las PoCs que he creado he utilizado un “timming” de 0.4 y 0.6. Pero es posible utilizar tiempos menores.

El solapamiento

A la hora de ir saltando de canal, lo más coherente como primera impresión, por sencillez, sería pensar en recorrer mediante un bucle todos los canales de formas secuencial. Es decir, recorrer los canales desde el 1 pasando por el 2, 3, 4... hasta recorrer los 14 canales. Sin embargo, esto no sería lo más eficiente. Como comentamos en los puntos anteriores, la banda de 2.4 Ghz tiene el inconveniente de los solapamientos entre canales - peor todavía si se utiliza el estándar IEEE 802.11n que utiliza un ancho de banda de 40 Mhz -. El solapamiento provoca que sea posible capturar tráfico que pertenece a los otros canales contiguos. Esto no interesa.

Para evitar este problema se suele ir saltando, como mínimo, de tres en tres canales. Si se analiza el funcionamiento de airodump-ng se puede corroborar que sigue un mecanismo basado en saltos no secuenciales.

Figura 17: Arrays de canales en airodump-ng

En el “header” de airodump-ng (aquí el C) se pueden ver los ARRAYs de las listas predefinidos con saltos de canales no secuenciales según el estándar utilizado. Está sería una de las formas correctas. Es posible, utilizando una imagen que muestre los solapamientos entre canales de los estándares IEEE 802.11 bgna buscar otra serie de saltos sin solapamiento.

Canales comunes y no comunes

Otro de los problemas que podemos encontrarnos es que, según la región o el país, vamos a poder utilizar unos canales u otros, dependiendo de la interfaz que se utilice y de la configuración de la región. Por lo que al definir una lista con los canales debemos de tener en cuenta cuales son los canales comunes a todos los países y cuáles no.

Ordenarlos de forma que si un canal no común no se utiliza no rompa la eficiencia ante el solapamiento de la lista. Es decir, si tenemos la siguiente lista: 1, 14, 2. Y no utilizamos el canal 14. Al final se va a realizar el salto del canal 1 al 2 y esto no sería correcto al ser canales contiguos y solapables. Recordad que los canales comunes en todos los países van desde el 1 hasta el 11. El 12 y 13 se utilizan en la mayoría de países y el 14 solo en Japón.

¿Qué canales?

Por el mismo problema que el caso anterior, es posible que no todos los canales funcionen al realizar el cambio de canal (aparezcan errores). Por lo que se estaría realizando saltos a canales no válidos. La solución más óptima, en mi opinión, sería comprobar antes de realizar el sniffing que canales son válidos y cuáles no.

¿Qué bandas?

Lo mismo que el caso anterior, pero en esta ocasión referente a las bandas de frecuencia y a los canales. También se podrá solucionar haciendo una comprobación previa.

Mi módulo, SaltoCanal

El objetivo que se persigue es crear un módulo independiente que pueda ser utilizado por otras herramientas de forma totalmente modular y abstracta. Que esté pensando para utilizar en una Raspberry Pi con la interfaz inalámbrica que trae de serie bajo la distribución modificada de Kali Linux. Como lenguaje de programación he decido utilizar Python. Por diversos motivos. Entre ellos:

  • Es el recomendado por los fundadores de la Raspberry Pi.
  • Por ser un lenguaje de programación de alto nivel. Un lenguaje de sintaxis sencilla y clara.
  • Es un lenguaje con gran documentación y herramientas.
  • Es fácil de aprender. Cualquiera que no conozca el lenguaje pero que sepa programar puede comprender fácilmente el código. Por lo que facilita el aprendizaje a terceros.
  • Es un lenguaje interpretado o de script, fuertemente tipado y dinámico, es multiplataforma y es orientado a objetos.
  • Además, es un lenguaje bastante potente y con muchas librerías que nos ayudan a realizar casi cualquier cosa.

Otro de los motivos más importantes es que se integra muy bien con Scapy. Librería que estoy utilizando para el desarrollo del proyecto que tengo entre manos. Aquí os dejo el enlace a GitHub del código del script:


Figura 18: Módulo salto_canal.py

Este código está sujeto a cambios, no puedo decir que esté testeado a fondo. Por lo que seguro que habrá que corregir algunas cosas.

SaltoCanal

Utiliza los siguientes módulos:

  • Thread de threading.
  • Os.
  • Sys.
  • Popen, PIPE de subprocess.
  • SIGINT, signal de signal.
  • Sleep de time.

Y un módulo propio, manejo_interfaz, para realizar ciertas operaciones que son comunes sobre las interfaces inalámbricas. Las constantes que utiliza son dos listas de canales ordenadas mediante un sistema ideal para evitar el solapamiento:

  • LISTA_CANALES_24GHZ = [1, 6, 11, 14, 2, 7, 3, 8, 4, 12, 9, 5, 10, 13]
  • LISTA_CANALES_5GHZ = [36, 38, 40, 42, 44, 46, 52, 56, 58, 60, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, 149, 153, 157, 161, 165] DN = open(os.devnull, 'w')

Esta constante se utilizará para descartar la salida cuando se invoque a popen.

La clase SaltoCanal

El modulo es una clase que hereda de threading.Thread. Sus métodos son:

Métodos públicos:

 __init__: Para instanciar el objeto.
 comprobar_canales: Para comprobar que canales podemos utilizar.
 fijar_canal: Para fijar la interfaz en un canal concreto.
 tiempo_canal: El “timming”, el tiempo que se utiliza un canal al realizar el salto de canal.
 lista_VIC: Very Important Channel. Crea una lista con los canales más importantes para el usuario.
 fijar_canales: Para fijar los canales en una lista dada por el usuario.
 pausar: Para pausar el hilo.
 continuar: Para continuar con el hilo si está pausado.
 terminar: Para finalizar el hilo.
 run: Para ejecutar el hilo.

Métodos privados:

 __get_pausar: Devuelve la variable pausa.
 __lista_canales_valida: Para comprobar que los datos de entrada del __init__ son correctos.
 __comprobar_interfaz: Comprueba que existe la interfaz proporciona por el usuario y que está se encuentra en modo MONITOR o RFMON.
 __cambiar_canal: Método que cambia el canal de la interfaz mediante un proceso.
 __comprobar_canales: Comprueba los canales válidos que se pueden utilizar y devuelve una lista de ellos.

Pasemos ahora a detallar cada método.

__init__()
Como ya sabréis es un método reservado para instanciar los objetos de la clase (el constructor en Java). Por ejemplo, sc = SaltoCanal(“wlan1”). A este método solo es obligatorio pasarle la interfaz. Todas las demás variables son optativas.
  • La variable espera se utiliza para indicar el tiempo de escucha en un canal concreto.
  • La variable check se utiliza para realizar la comprobación de canales. Es decir, para verificar aquellos que funcionan y descartar los que no.
  • Las variables _24Ghz y _5Ghz indican que listas de bandas de frecuencia se van a utilizar.
  • Por último, verbose, para que la clase imprima por pantalla información al respecto.
Como el objetivo es utilizar esta clase desde otros scripts puede resultar más eficiente que sea mudo. Por lo que nos bastará por comprobar los códigos de salida para conocer el motivo. Dentro del método se verifican que los datos de entrada sean coherentes, es decir, que al menos se pase una de las bandas de frecuencia, esto se hace con el método privado: “__lista_canales_valida()”. 
También comprobamos que la interfaz facilitada por el usuario es correcta o existe y está en modo monitor o RFMON. Para ello se llama al método privado “__comprobar_interfaz()” que a su vez utilizará otros métodos (existe_interfaz() y esta_modo_monitor()) utilizando un módulo externo que fue creado por mí y que tiene como nombre manejo_interfaz. Con ellos verificaremos que existe la interfaz y que está en modo monitor. Miraros este módulo para ver cómo se comprueban estas cosas. 
Cabe resaltar que es aquí donde se inicializa el hilo (“Thread”) y que se crea como daemon. Que básicamente es para que el hilo principal pueda terminar sin esperar a nadie más. Se inicializan el resto de variables que utilizaremos para el correcto funcionamiento del hilo.
comprobar_canales()
Este método se utiliza para comprobar que canales se pueden utilizar y cuáles no. Por lo que devolverá una lista con los canales válidos. Este proceso solo se realiza si el check está a True. Para ello, utiliza el método privado “__comprobar_canales()”.
__comprobar_canales():
Este método recorre la lista de canales que se le pasan para verificar si son válidos. Utilizando el método “__cambiar_canal()” que devuelve True o False si existen algún error. En caso de no existir, se guarda en una lista el canal, en caso contrario, se descarta.
También comprueba si todos los canales han fallado, por lo que si esto ocurre el programa finaliza con un error, puesto que no existen canales válidos.
__cambiar_canal():
Este método recibe un canal y lanza un Popen. Un Popen es un módulo que nos permite lanzar programas externos y tener cierto control sobre ellos. Mediante la variable del módulo “stderr” comprobamos si existen errores. 
Como se puede observar, estamos utilizando iw para realizar el cambio de canal, como comentamos anteriormente. La sintaxis sería: “iw dev self.interfazset channel canal”, siendo la variable interfaz la facilitada por el usuario, y canal el canal que queremos utilizar. No hay más magia en todo esto.
fijar_canal()
Este método permite fijar un canal en vez de andar saltando de canales. Solo funcionará si el hilo está parado.
tiempo_canal()
Este método permite cambiar el “timming”, el tiempo que pasaremos utilizando un canal.
fijar_canales()
Este método fija el salto de canales a una lista proporcionada por el usuario. Puede resultar útil cuando el usuario tan solo quiere realizar un sniffing a tan solo a una pequeña lista de canales concretos o fijar una lista de canales propia.
lista_VIC()
Very Important Channel. Este método me parece también muy interesante. Como comentamos en la teoría, existen canales más importantes que otros, como son el canal 1, 6 y 11 que no se solapan entre ellos, por lo que puede interesar pasar más tiempo en ellos porque podrían estar más poblados. 
Bueno, en realidad, este es uno de sus usos, pero puede tener muchos dependiendo de la imaginación de cada uno. Al habilitar este método y proporcionarle una lista y un tiempo determinado, el hilo detectara los canales que pertenezcan a esta lista y esperara el tiempo facilitado por el usuario.
run()
Este es un método de la clase “Thread”. Una vez que se lance el hilo se ejecutará lo que está dentro de este método. En nuestro caso un bucle que recorre infinitamente una y otra vez toda la lista de canales, provocando el salto de canal.
sc = SaltoCanal(“wlan1”, check=True, _24Ghz = True, _5Ghz=True, verbose=True) sc.start()
PoC – Proof of Concept.

Una vez que tenemos creado nuestro “bicho” es hora de comprobar que todo funciona correctamente. Para ello, ponemos la interfaz en modo monitor. En los ejemplos estoy utilizando una distribución de Kali Linux un tanto peculiar. Esta distribución modificada, entre otras cosas, permite poner la interfaz Wi-Fi que viene por defecto con la Raspberry Pi 3 en modo monitor.

Hablaros sobre todo esto escapa del objetivo principal de este artículo. Para los interesados aquí os dejo ciertas referencias al proyecto NexMon  y la URL donde podéis descargaros las imágenes de Kali Linux modificada. Para poner la tarjeta de la Raspberry Pi en modo monitor tan solo tenemos que utilizar este comando: monstart Para parar el modo monitor, bastaría con: monstop

Como veis, todo muy sencillo, pero ¡ojo!, si se utilizan varias tarjetas inalámbricas, hay que cerciorarse bien cuál es la interfaz que está en modo monitor. Se puede hacer con iwconfig o iw dev

Una vez que se tiene la interfaz en modo monitor se puede comprobar que todo funciona correctamente utilizando un sniffer. Existen varias posibilidades, yo me he decantado por Wireshark por venir ya preinstalado, por ser un viejo conocido (aka Ethereal) y por la interfaz gráfica, para que todo sea más visual en las capturas de pantalla. Para realizar el sniffing con Wireshark antes se debe de indicar la interfaz por la cual se quiere capturar tráfico. Es decir, la interfaz que esté en modo monitor. Si todo es correcto, irán apareciendo los paquetes capturados en Wireshark.

Probando salto_canal.py.

Existen varias formas de lanzar este módulo. La primera forma es simplemente ejecutándolo directamente con python saltocanal.py. Recordad que si utilizáis este método deberéis de crear en el “main” algo como esto:
sc = SaltoCanal(“wlan1”) 
sc.start() 
raw_input('Presiona enter para finalizar...')
El raw_input es fundamental, de lo conterario el programa y el hilo finalizaran y no se podrá testear. Pero si quieres también puedes probarlo ejecutándolo a través de la consola de Python. Para ello se lanza la consola de Python mediante un comando python y desde allí de importa el módulo. (Para ello se aconseja lanzar la consola de python en el mismo directorio que salto_canal.py). Y se prueban los métodos. Como se aprecia en las siguientes capturas, todo parece funcionar correctamente.

Figura 19: Preobando el módulo de Salto de Canal en Python en una Raspberry Pi 3

Conclusiones:

Como hemos visto, crear un script que realice el salto de canal no es complejo. Lo fundamental es conocer los problemas que pueden aparecer y buscarle soluciones óptimas. Esto solo es posible analizando y estudiando el funcionamiento de las cosas. Gracias al Open Software existen multitud de herramientas de código abierto que pueden ayudarnos en este proceso.

A la hora de auditar una red WLAN puede que las herramientas más conocidas no nos sirvan. Bien por ser algo muy concreto y especifico o porque necesitamos automatizar el proceso. Crear nuestras propias herramientas nos facilitará muchísimo las cosas, además de permitirnos tener un mayor control de lo que estamos haciendo.

Crear herramientas modulares y abstractas nos facilitarán la reutilización de las mismas en casi cualquier escenario. Incluso pueden darnos nuevas ideas. Una vez solucionado el problema del salto de canal, ya se puede empezar a jugar con: python + scapy + dot11 y dejar volar nuestra imaginación. ¡¡happy hacking!!. Si tenéis cualquier inquietud no dudéis en poneros en contacto conmigo.

Autor: Enrique Andrade - NETTinG

miércoles, septiembre 20, 2017

OWASP ZSC (ZeroDay Cyber Research ShellCoder): Weaponizing ShellCodes

A menudo podemos utilizar la herramienta msfvenom de Metasploit para poder llevar a cabo la generación de shellcodes o código ofuscado para que los exploits consigan ejecutarlos sobre los objetivos. La herramienta msfvenom es una de las fundamentales en el mundo de la seguridad, pero hoy queremos hablar de otras herramientas que pueden complementar a la gran msfvenom de Metasploit. Una shellcode es un pequeño código Assembly el cual puede ser utilizado como un payload o parte de él en una explotación de software.

Figura 1: OWASP ZSC "Weaponizing ShellCodes"

Además, en otros ámbitos también son utilizados: el propio malware o la fase de bypass de antivirus, son claros ejemplos. La posibilidad de personalizar las shellcodes es algo interesante, desde el punto de vista ofensivo, ya que nos permite poder evadir y hacer más difícil la posible detección o contramedida en este caso. La herramienta OWASP ZSC utiliza nuevos encodes y métodos que, al principio, tendrán una menor detección por parte de los antivirus. OWASP ZSC permite generar miles de shellcodes de forma dinámica, a través del uso de encodes aleatorios. La herramienta puede ser descargada desde su Github.

Figura 2: GitHub OWASP ZSC

Con esta herramienta, OWASP, ha trabajado en la creación de nuevos métodos de ofuscación. Esto lo llevaron a cabo durante el último Google Summer of Code. Además, se está buscando penetrar en el área de shellcodes para macOS, lo cual hace que esta herramienta gane en interés. Lógicamente, aún no está, desde mi punto de vista, a la altura de herramientas como msfvenom, pero si el proyecto sigue adelante, la cosa promete.

Figura 3: OWASP ZeroDay Cyber Research Shellcoder

La instalación de la herramienta es sencilla: python installer.py, una vez descargado el código desde su Github. Accedemos a la herramienta ejecutando el comando zsc, previa instalación realizada. Como se puede ver en la imagen, las posibilidades que ofrece la herramienta van directamente relacionadas con la selección de las shellcodes, el listado de éstas y la ofuscación que se puede llevar a cabo.

Figura 4: Comandos de OWASP ZSC

Otra de las opciones que permite hacer las herramientas es listar las shellcodes disponibles. Para ello se puede hacer uso del comando shell_storm_list, una vez cargada la opción shellcode. El listado de shellcodes es el que se tiene disponible en el sitio web de Shell Storm, un sitio web que ofrece una gran cantidad de shellcodes para distintas plataformas y arquitecturas.

Figura 5: Shellcodes en OWASP ZSC

Para ejemplificar el uso de la herramienta, seleccionamos una de las shellcodes disponibles. Para este caso, utilizamos la ruta shellcode/generate/windows_x86/[shellcode]. Si quisiéramos utilizar otra ruta para otra plataforma, sería del tipo: Windows_x86_x64, Linux, etcétera. Para mostrar en el ejemplo, seleccionamos la shellcode add_admin, cuyo código permitirá que cuando se ejecute aparezca un nuevo usuario en el sistema con privilegios de Administrador.

Tras seleccionar la shellcode se puede introducir el nombre del usuario y la contraseña seleccionada. Tal y como se puede ver en la imagen, se preguntará por un encoder después de introducir los datos anteriores.

Figura 6: Generación de shellcode con creación  de un usuario administrador

Se nos preguntará si queremos almacenar los resultados en un fichero assembly o de Lenguaje C. Por otro lado, podremos mostrar la shellcode directamente en pantalla. En la imagen se puede ver un ejemplo de esto. Al final obtenemos una serie de OpCodes, los cuales forman nuestra shellcode. Es el momento de introducirlos en el exploit con el objetivo de que el código que se ejecute, una vez comprometida la máquina en el proyecto de Ethical Hacking, sea el que hemos generado.

Figura 7: Selección de encoder para la shellcode

Para finalizar el ejemplo, configuramos la shellcode en un exploit contra la máquina remota. En sitios como exploit-db existen muchos exploits que podéis modificar y, además, tienen la versión del software vulnerable para que descarguéis y configuréis en vuestro laboratorio con el objetivo de poder probar y aprender.

En la imagen, se puede ver como se ha creado un usuario llamado “pepe” con privilegios de Administrador y que tiene como contraseña “1234”. En este instante, el pentester puede lograr acceso a la máquina a través de este código ejecutado aprovechando la vulnerabilidad.

Figura 8: Creación de usuario con la shellcode

Sin duda, OWASP ZSC es una herramienta que debemos llevar en la mochila del pentesting, ya que es un gran complemento a msfvenom. Además, el listado de shellcodes proporcionado desde Shell Storm ayuda a enriquecer el proceso. Si no lo has probado, te recomendamos que la pruebas.

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

martes, septiembre 19, 2017

"Chema Alonso al final no ha podido venir"

... y puede que sea así, que al final no pudiera ir. Pero también hay otras veces en las que no he podido ir desde el primer minuto o ni tan siquiera era consciente de que tenía que ir. Es por eso que mis amigos muchas veces me preguntan directamente cuando les dicen que yo voy a estar una determinada conferencia, en un evento o en un acto. Y en muchas ocasiones se ríen cuando contesto algo como "¿en dónde?".

Figura 1: "Chema Alonso al final no ha podido venir"

Hoy quiero aprovechar el espacio que me brindo cada día para comunicaros algo a través de mi post, para hablaros de este hecho que a veces es intencionado, otras por entusiasmo, otras por exceso de "overselling", y otras por simple confusión, pero que me ha generado más de un problema en mi vida.

Algunas veces hay gente que hace una agenda para un determinado evento y pone en ella una serie de ponentes con los que se ha contactado, con los que se espera contactar, o con los que aún no se ha contactado, y se pone dentro de un documento que se comparte de manera privada. Ese documento puede ser un dossier que se utiliza para enviar información a otros ponentes a los que se quiere invitar, para enviar a posibles organismos de financiación e incluso empresas sponsor.

En mi caso, me he visto involucrado en eventos de los que nunca he oído hablar, he aparecido en agendas públicas de charlas a las que dije desde el minuto uno que no podía ir, y en otras a las que aún no he dicho ni que sí ni que no. No sería un problema, si ningún asistente se sintiese enfadado o triste porque al final "Chema Alonso no ha podio venir". 

Yo intento publicar en mi agenda de eventos en este blog todos los eventos en los que sí voy a participar, aunque es verdad que no están todos a los que voy a ir. Así que si me ves en alguno que no aparezca, puedes ponerme un comentario, o un twitt (@chemaalonso), o lo que sea, que yo te lo confirmo tranquilamente.

Dicho esto, si estás organizando un evento en el que cuentas con poder traer a alguien, no lo pongas en documentos como si fuera a venir o lo publicites en Internet  si esa persona aún no ha confirmado. Mucho menos, inventarse el título de la charla, la biografía o la descripción de la misma, que no es la mejor forma de tratar a un ponente al que quieres tener en tu evento.

Para terminar, os confirmo que mañana voy a estar en con los antiguos alumnos de la Singularity University en Madrid, y el jueves en el desayuno ESADE. Luego, ya os pasaré mi agenda de Octubre.

Saludos Malignos!

lunes, septiembre 18, 2017

Hacking Wi-Fi: Cómo funciona el "Salto de Canal" (Parte 1 de 2)

A día de hoy son muchísimas las herramientas que existen para “jugar” con las redes LAN a través de Ethernet (IEEE 802.3), sin embargo, cuando hablamos de las redes WLAN (IEEE 802.11) la cosa cambia, sobre todo si dejamos a un lado la todopoderosa Suite Aircrack-ng. Por lo que se hace indispensable conocer bien el protocolo y alguna herramienta que nos ayude a crear y automatizar nuestros propios scripts para poder auditar este tipo de redes. Hoy vengo a hablaros sobre algo con lo que he estado pegándome para la construcción de un proyecto de seguridad en redes Wi-Fi que tiene que ver con las Raspberry Pi, con Python, con Scapy, con el IEEE 802.11, y con algunas cosas más. Cito estas, como más relevantes, porque vienen a colación, son los protagonistas a lo largo de todo este artículo.

Figura 1: Hacking Wi-Fi: Cómo funciona el "Salto de Canal"

Tengo que decir, que desde que me he adentrado en estos menesteres, me he topado con una gran carencia en cuanto a documentación sobre la librería Scapy referente a IEEE 802.11 (Scapy Dot11), aunque realmente hoy no vengo a hablaros sobre la Scapy - Dot11, sino más bien de un paso previo, imprescindible para crear nuestras propias herramientas para la auditoria inalámbrica. Se trata del salto de canal para poder monitorizar la red. Vais a ver la importancia que tiene realizar bien este proceso.

Puede que muchos pensaréis, y estaréis en lo cierto, que lo más lógico sería comenzar por hablar del modo MONITOR o RFMON. Voy a partir de la idea de que ya sabéis poner una interfaz en modo monitor y que conocéis toda la problemática. De todas formas, os dejo un enlace, donde hablo un poco sobre todo esto, a modo de introducción, seguro que os sirve si queréis repasar conceptos. También, a lo largo del presente artículo, os dejaré algunos escenarios y ejemplos donde podáis probar todo esto.

El "Salto de Canal": Conceptos Básicos

La primera vez que tuve que enfrentarme a este proceso, ¡ingenuo de mí!, pensé que era algo más simple, con menos problemas a tener en cuenta. En algo había acertado, programarlo en sí, no es complejo. Lo más impórtate es tener claros todos los conceptos y entender bien su funcionamiento. Una vez superado este nivel, es coser y cantar.

Voy a dividir este documento en dos partes, por un lado, un poco de teoría que vais a leer en esta parte, lo que nos ayudará a comprender el script que realiza el salto de canal y por otro lado la creación del propio script con una pequeña PoC para verificar que todo funciona correctamente. Antes de comenzar a saltar, voy a internar no profundizar demasiado en ciertos conceptos, más que lo justo, preciso y necesario.

El modelo OSI y el estándar IEEE 802.11

El estándar 802.11 define los protocolos que actúan sobre las capas inferiores del modelo OSI para las conexiones inalámbricas que utilizan ondas electromagnéticas. Estas son:

Figura 2: El modelo OSI y el estándar 802.11
  • Capa1, La capa física. Ofrece tres tipos de codificación de información.
  • Capa 2, capa de enlace de datos. Compuesta por dos subcapas: control de enlace lógico (LLC) y control de acceso al medio (MAC).
La capa 1 es la capa física que define la modulación de las ondas de radio y las características de señalización para la transmisión de datos. La capa 2 es la capa de enlace de datos define la interfaz entre el bus del equipo y la capa física, en particular un método de acceso parecido al utilizado en el estándar Ethernet, y las reglas para la comunicación entre las estaciones de la red.  En realidad, el estándar 802.11 tiene tres capas físicas que establecen modos de transmisión alternativos:

Figura 3: Capas físicas DSSS, FHSS e Infrarojo

Estándares 802.11

En realidad, 802.11 es el primer estándar y permite un ancho de banda de 1 a 2 Mbps. El estándar original se ha modificado para optimizar el ancho de banda o para especificar componentes de mejor manera con el fin de garantizar mayor seguridad, compatibilidad o velocidad. Existen varios estándares como son 802.11b, 802.11g, 802.11a, 802.11n, 802.11ac, que son los más conocidos o utilizados).

Es importante conocer estos estándares, sus velocidades y en la banda de frecuencia en la que trabajan para poder capturar la mayor parte del tráfico inalámbrico. Esto es importante, porque no todos los estándares son compatibles entre sí, sobre todo hacía atrás.

Figura 4: Estándares IEEE 802.11

Podéis encontrar información más detallada de cada uno de los principales estándares en el artículo de la Wikipedia dedicado a 802.11. Como veis, existen bastantes, de ahí que se le conozca como el abecedario de 802.11.

Bandas y frecuencias

Son conceptos importantes cuando hablamos de redes inalámbricas. Entendemos por banda de frecuencia, los intervalos de frecuencias del espectro electromagnético asignados a diferentes usos dentro de las radiocomunicaciones. Cada una de estas bandas tiene una asignación de frecuencias que determina cómo se utiliza y se comparte para evitar interferencias entre canales y especificar el protocolo de comunicación que permita la comunicación entre el emisor y el receptor. Abarcando desde una frecuencia inicial hasta una frecuencia final. Estás bandas puede ser de tres tipos:
  • Bandas particulares.
  • Bandas licenciadas.
  • Bandas libres.
Estas bandas están sujetas a las normativas locales de cada país. Las bandas libres son aquellas donde cualquier persona puede transmitir sin necesidad de tener un permiso. Hablaremos particularmente de las bandas 2,4 GHz y 5 GHz por ser usadas prácticamente en todo el mundo por el estándar IEEE 802.11.

Según el estándar utilizado, se utilizará una banda o la otra, así como la velocidad máxima soportada. Cualquier persona puede tener en su casa un equipo de Wi-Fi transmitiendo en estas frecuencias sin tener que pedir permisos para ello o sin causar problemas a los demás. Para que esto sea posible es necesario cumplir con ciertas reglas que están contempladas en la regulación de estas bandas. Las más importantes tienen que ver con la potencia máxima y mecanismos para evitar interferencias.

Figura 5: Banda de 2.4 Ghz y sus canales

En Europa, para aplicaciones de interior estas bandas tienen una limitación de potencia de 200 mW y para exteriores de 1 W o 4 W dependiendo de la frecuencia exacta. Estas potencias son bastante bajas si las comparamos con las que radian las antenas de móviles que pueden llegar a ser de 25 W o más y por eso hay que tener cuidado al poner antenas muy grandes a los equipos de Wi-Fi para enlazar dos puntos alejados. Cada banda incorpora su propia distribución y numeración de canales de forma independiente.

Canales Wi-Fi

Un canal define simplemente la frecuencia central de transmisión de una comunicación con un ancho de banda concreto según la banda utilizada. A mayor ancho de banda mayor será la “velocidad” de la comunicación. Las comunicaciones mediante Wi-Fi utilizan entre 5 MHz y 60 MHz de ancho de banda. Como veremos posteriormente los canales se representan con un valor numérico que hace referencia a una frecuencia concreta.

Figura 6: Canales de la banda 2.4 Ghz

En la imagen podemos observar los canales disponibles en la banda 2.4 Ghz. Que van desde el 1 hasta el 14. Como se aprecia, al restar las frecuencias de los canales contiguos, el ancho de banda es de 5 Mhz. También podemos observar, según el país, los canales disponibles. En España utilizamos lo canales que van desde el 1 hasta el 13. Una vez que hemos definido a grandes rasgos todos estos conceptos, pasemos a detallar lo más importante y a tener en cuenta con relación a lo que estamos estudiando. El salto de canal y la captura de tramas a través del aire.

El "Salto de Canal": Conceptos Clave

.Una vez digeridos, grosso modo, los pilares de las comunicaciones inalámbricas a través del IEEE 802.11, comentemos todo aquello que tenemos que tener en cuenta para poder realizar un óptimo “sniffing” en redes WLAN.

Como comentamos, el estándar utilizado es importante. Éste define la velocidad y la banda de frecuencia. Por lo que si queremos analizar todo el tráfico WLAN debemos de utilizar una tarjeta inalámbrica que sea compatible con las bandas 2.4 Ghz y 5 Ghz y a su vez soporte la mayor parte de los estándares, por ejemplo: 802.11b,g,n,ac. También debe de soportar el modo monitor y la inyección de paquetes.

Otro de los aspectos importantes a la hora de capturar los paquetes que viajan por el aire es el canal que, como vimos, es una frecuencia especifica según la banda utilizada. Según el país en el que nos encontremos podremos utilizar unos canales u otros. Por lo tanto, deberemos de tenerlo en cuenta a la hora de realizar el sniffing.

Una interfaz inalámbrica solo puede utilizar un canal a la vez. Esto quiere decir que no podemos estar realizando un sniffing en el canal 1 y en el 10 a la vez. Si la interfaz se encuentra en el canal 1 no podrá capturar los paquetes que se trasmiten por el canal 10 y esto, obviamente, es un problema. Sea como sea, estamos perdiendo tráfico, aunque existen diferentes estrategias para solventarlo, pero las dejaremos por ahora para más adelante.

Solapamiento de canales o channel overlapping

Como comentábamos, la banda de 2.4Ghz utiliza unos canales definidos según el país que van desde el canal 1 (2.412Ghz) al canal 14 (2.484 Ghz) con un ancho de banda entre canales contiguos de 5 Mhz. Cuando se transmite se utiliza un ancho de banda determinado, no es algo específico, que se propagará de igual manera a ambos lados de la frecuencia central del canal. Si el ancho de banda que se transmite es mayor al ancho de banda de dos canales contiguos (> 5 Mhz) entonces estaremos hablando de un solapamiento entre canales.

Figura 7: Solapamiento de canales en 2.4 Ghz

Por ejemplo, si una interfaz transmite en el canal 6, y la transmisión utiliza un ancho de banda superior a los a los 5Mhz, estará solapando, como mínimo, a sus canales contiguos 5 y 7, dependiendo del ancho de banda consumido. Un canal necesita un ancho de banda de 22 Mhz. Por lo que solapará a todos los canales contiguos hasta donde llegue el ancho de banda del canal. A continuación, os dejo una tabla con todos los canales y sus solapamientos.

Figura 8: Solapamiento de canales

El solapamiento no solo complica la tarea de compartir la banda de frecuencia por parte de todos los dispositivos, también genera múltiples interferencias en las comunicaciones. Por este motivo, resulta de suma importancia elegir correctamente un canal para realizar las comunicaciones. Los canales que no se solapan entre si son: 1, 6 y 11. Que son conocidos como los canales no solapados. Para un estudio con mayor profundidad sobre todo esto os dejo el siguiente enlace de Recursos TIC.  Para la banda 5Ghz os dejo el siguiente enlace.

Para cambiar el canal de nuestra interfaz tenemos dos opciones.
  • iwconfig [interfaz] channel [canal: 1-14]
  • iw dev [interfaz] set channel [canal: 1-14]
Potencia Máxima

Como comentamos, las frecuencias en las que puede trabajar una tarjeta de red Wi-Fi están reguladas por la normativa del país. También se regula la potencia máxima con la que se transmite. Las tarjetas vienen con restricciones para que no se pueda transmitir a mayor potencia y, por extensión, cometer un delito. Mediante iwconfig podemos comprobar la potencia máxima de nuestras interfaces.

Figura 9: iwconfig en Kali Linux 2

NOTA: Todas las capturas y ejemplos se han realizado en una Raspberry Pi 3, utilizando la interfaz inalámbrica de serie del dispositivo y una distribución de Kali Linux modificada.

Como se puede ver en la imagen, la interfaz wlan1 es la interfaz de red por defecto de la Raspberry Pi:
  • Utiliza los estándares IEEE 802.11 bgn.
  • Está en modo managed (cliente - estación).
  • Tiene una potencia de 31 dBm (Tx-Power).
Aunque no aparece el campo “Frequency”, este se puede cambiar como mencionamos anteriormente. En contra-ejemplo, la interfaz wlan0, una tarjeta inalámbrica USB externa, está conectada a un punto de acceso en la frecuencia 2.457 Ghz que corresponde al canal 10 de la banda 2.4Ghz. En esta salida no se aprecia la potencia máxima. Utilicemos entonces las nuevas extensiones inalámbricas de GNU/LiNUX (nl80211 – Paquete iwutils).

Figura 10: iw dev en Kali Linux

En esta imagen se aprecia mejor que la interfaz wlan1 tiene un txpower de 31 dBm mientras que la interfaz wlan0 tiene un txpower de 12 dBm. La potencia máxima legal autorizada de la mayoría de los países, donde se incluye España, es de 20 dBm. Con los números sobre la mesa, se puede llegar a la conclusión de que si mi tarjeta inalámbrica (wlan1) tiene una potencia máxima de 31 dBm y la máxima permitida en España es de 20 dBm, lo que podría llegar a hacer pensar que mi tarjeta funcionara en márgenes ilegales.

No. No es así. Estos comandos muestran la señal a la que podría emitir la interfaz, pero aún así sigue estando limitada a 20 dBm. Existen varias formas para cambiar el txpower de una interfaz.
  • iwconfig [interfaz] txpower [dBm]
  • iw dev [interfaz] set txpower <auto|fixed|limit> []
  • iw phy [phyname] set txpower <auto|fixed|limit> []
Saltando restricciones


Hasta aquí hemos comentado que, por defecto, la interfaz inalámbrica restringe el uso de los canales a la normativa vigente del país, de igual forma ocurre con la potencia máxima. Por lo que si realizamos un cambio de canal a la interfaz wlan1 para que utilice el canal 14.  Nos encontraremos con el siguiente error.

Figura 11: Error obtenido al poner el canal 14

Lo mismo ocurrirá si cambiamos la potencia máxima. Y esto, ¿a qué se debe? Pues como comentamos, a la restricción del país. Mediante  iw reg get podemos comprobar la región.


Figura 12: Región configurada
Podemos observar que por defecto la distribución de Kali Linux para Raspberry Pi viene configurada con un “country” “DE: DFS-ETSI”. Si buscamos ese “codeen la siguiente tabla obtenemos que pertenece a Alemania (“Germany”) ISO 3166-2:DE. Vamos a cambiarla a la normativa a la española. Con lo que obtenemos lo siguiente.


Figura 13: iw reg set ES

En la primera columna encontramos las bandas de frecuencia en las que podemos emitir. Para el caso de la banda 2.4 Ghz, sería desde 2.4 hasta 2.483 Ghz. Es importante recordar que, aunque el primer canal se encuentra en la frecuencia 2,412 Ghz, el ancho de banda, como dijimos anteriormente, se reparte hacia ambos lados del canal. Recordar también que el ancho de banda máximo es de 22 Mhz, por lo que serían 11 Mhz para cada lado, dejando una holgura de 1 Mhz. Es decir, 2,412 menos 0,012 nos da la frecuencia de 2,4 Ghz. Lo mismo ocurre con el canal 13, que tiene una frecuencia de 2.472 Ghz, si le sumamos los 11 Mhz del ancho de banda obtenemos 2,483 Ghz, que es la frecuencia máxima permitida en esa banda.

El valor después del símbolo “@” es 40 Mhz, que es el máximo ancho de banda. ¿Pero el máximo ancho de banda no era 22 Mhz? Sí, efectivamente, pero en el estándar IEEE 802.11g. Sin embargo, en el estándar IEEE 802.11n que utiliza también la banda de frecuencia de 2.4 Ghz el ancho de banda es de 40 Mhz. Ese es el motivo.

El siguiente valor, es un 20, que nos indica la potencia máxima a la que podemos emitir. Por eso, aunque la tarjeta inalámbrica tenga, como es el caso, una potencia máxima de 31 dBm se restringe a 20 dBm.

Figura 14: Valores de Bolivia antes y ahora

Y ahora la pregunta del millón... ¿Se pueden cambiar estas restricciones? La respuesta es, sí. Hay varias formas de hacer esto. En el siguiente enlace os deja una base de datos con todas las restricciones según el país a fecha de 07/03/2017. Si el controlador de la tarjeta inalámbrica no está “hardcoded”, bastaría con asignar un país con unas restricciones menos prohibitivas. Hasta hace poco, Bolivia permitía utilizar todos los canales con una potencia máxima de 30 dBm. Pero esto ha cambiado. Aunque siempre nos quedará la Guyana Británica.

Figura 15: Valores de Guyana Británica

Existen otras formas más oscuras de cambiar estos valores, pero para mi trabaja no me interesa profundizar en esto. Para lo que estéis interesados, aquí os dejo un enlace donde se explica correctamente el proceso. Recordad que “transmitir a mayor potencia de la permitida en su país, así como en canales no permitidos es completamente ilegal y no debe de hacerse.” También os dejo aquí un enlace sobre qué ventajas reales puede tener aumentar la potencia máxima, sobre todo a la hora del hacking.

Autor: Enrique Andrade - NETTinG

domingo, septiembre 17, 2017

Nuevo Video-Book "Ataques en redes de datos IPv4 & IPv6" de @0xWord

Ya os anuncié meses atrás que habíamos lanzado en 0xWord una nueva línea de trabajo con los Vídeo-Books. En una primera instancia lanzamos el VBook dedicado a Windows Server 2016, y hoy os quiero anunciar que ya está el segundo VBook, dedicado a "Ataques en redes de datos IPv4 & IPv6" disponible.

Figura 1: Nuevo Video-Book "Ataques en redes de datos IPv4 & IPv6" de @0xWord

Los VBooks llevan las explicaciones que se dan en los diferentes capítulos del libro, así como las demostraciones técnicas paso a paso, a sesiones en formato vídeo donde el ponente se detiene en todos los detalles del libro, y en todas las acciones que hay que realizar para probar las PoCs que se describen.

Figura 2: VBook "Ataques en redes de datos IPv4 & IPv6"

En el caso del libro de Ataques en redes de datos IPv4 & IPv6, uno de los más vendidos a lo largo de la historia de 0xWord, hicimos una nueva edición recientemente, y aprovechamos para construir el VBook correspondiente gracias al esfuerzo de Juan Luis Romero, experto en técnicas de Ethical Hacking. Ésta es la agenda del mismo, donde se ven ataques de Man in the middle en redes IPv4, técnicas de Session hijacking, ataques en IPv6 con Evil FOCA, etcetera.


Con este formato, para los que disfrutan más con las explicaciones multimedia, que con la lectura de un libro, se puede seguir la misma formación pero de distinta manera.

Saludos Malignos!

sábado, septiembre 16, 2017

WebHooks: Cómo integrar Latch como un boss en tus apps sin hacer pooling

El proyecto de Latch es cada día un poco más grande y más completo. Desde la idea original con la que le dimos vida en el año 2013, Latch ha ido añadiendo funcionalidad tras funcionalidad para hacerse más flexible y versátil. Primero añadimos las Operaciones - que ahora son dinámicas y permiten hacer cosas como Latch Antiransomware -, luego el Auto-Lock, una gran cantidad de plugins integrándolo en diferentes plataformas así como SDKs para múltiples lenguajes, los Limited Secrets, el Dashboard, la integración con Mobile Connect, los Cloud TOTP o los WebHooks, han ido ampliando paulatinamente las opciones de lo que cualquiera puede construir con Latch.

Figura 1: WebHooks en Latch

Con el objeto de permitir que los desarrolladores aprendan cómo sacarle mucho más partido a las diferentes opciones, dentro de la nueva serie de CodeTalks 4 Developers habrá sesiones dedicadas a cada una de ellas. En la primera de esas sesiones, uno de nuestros mejores desarrolladores en ElevenPaths, el gran Javier Espinosa, ha sacado algo de tiempo para explicar en solo media hora, y con demos, cómo funcionan los WebHooks.


Figura 2: Cómo eliminar el pooling en tus apps con Latch WebHooks

Esta característica permite que las aplicaciones web creen un punto de notificación al que el propio servidor de Latch enviará los cambios de estado de los pestillos creados con un determinado ApplicationID, lo que permite evitar una de las características que peor usabilidad y experiencia dan: El pooling. De forma elegante lo puedes sustituir por los Latch WebHooks, y aquí te explicamos cómo se hace directamente con el código.

Saludos Malignos! 

viernes, septiembre 15, 2017

Protege tus BitCoins, LiteCoins y Ethereums en Coinbase con Latch Cloud TOTP

Al precio que se están poniendo algunas criptomonedas, tener una cuenta que gestione nuestro Wallet sin un Segundo Factor de Autenticación es un poco peligroso. El equipo que estamos detrás de Latch estamos analizando cuáles de estas Wallets permiten protegerlas con esquemas TOTP, así que en la comunidad de ElevenPaths vamos publicando cómo hacerlo. Hoy comenzamos con Coinbase.

Figura 1: Protege tus BitCoins, LiteCoins y Ethereums en Coinbase con Latch Cloud TOTP

Coinbase permite comprar, utilizar y aceptar Bitcoins, Ethereums y Litecoins. Se fundo en San Francisco a partir de una incubadora de startups en el año 2012. Posteriormente en 2016 fue identificada como una de las organizaciones de Blockchain más influyentes, según la compañía inglesa Richtopia. En mayo del año actual tenían más de siete millones de usuarios. Y por supuesto, permite proteger las cuentas de los usuarios con TOTP, así que vamos a ver cómo hacerlo con Latch Cloud TOTP.

Figura 2: Configuración de Segundo Factor de Autenticación en Perfil de usuario

Después de iniciar el registro en Coinbase, en su propia we, donde se nos solicita una serie de datos personales, podremos configurar el segundo factor de autenticación que protegerá nuestro inicio de sesión. Dentro de la opción de seguridad disponemos de la opción de dos factores y en este caso con aplicaciones de terceros, como puede ser Latch. Esta configuración de la opción de utilizar Latch como aplicación de un tercero en la verificación de dos pasos, se muestra en las próximas figuras. Configuración -> Seguridad.

Figura 3: Código QR a escanear para poner Latch Cloud TOTP

Para esta configuración tendremos que escanear el código QR que nos muestra Coinbase en la ventana de autenticación de dos factores por Aplicaciones de terceros. Realizamos el escaneo del código QR que nos muestra en la Figura 3, e incluimos el TOKEN TOTP en la parte inferior como comprobación posteriormente.

Figura 4: Añadir un servicio Cloud TOTP en Latch

Después de escanear el código QR, podemos cambiar la denominación del TOTP, que por defecto nos indica la dirección de correo utilizada en el alta del servicio de Coinbase.

Figura 5: Cuenta de Coinbase protegida con Latch Cloud TOTP

Para finalizar la instalación incluiré un código del TOTP en la parte inferior de la ventana mostrada en la ventana del código QR (“Introduzca el código......”). Y ya tenemos nuestro servicio de Coinbase fácilmente protegido por Latch.

Figura 6: Cómo proteger cuenta de Coinbase con Latch Cloud TOTP

Y en este vídeo tienes un ejemplo completo del proceso. Protege tus criptomonedas para que no tengas un disgusto.

Autor: Juan Carlos Vigo, Product "Warrior" de Latch en ElevenPaths

jueves, septiembre 14, 2017

Security.TXT un draft del IETF para mi Hackers.TXT

Hace ya muchos años, harto de no saber cómo actuar cuando una vulnerabilidad era descubierta en una página web, yo propuse la creación de un fichero llamado Hackers.TXT para que los investigadores supieran cómo debían actuar sin tener un problema legal. 

Figura 1: Security.TXT un draft del IETF para mi Hackers.TXT

Una idea que a mí me parecía una necesidad en el mundo de hoy en día, y que incluso muchos compañeros me pidieron que empujar con más fuerza. De hecho, algunos researchers reservaron hackers.org y otros canales para potenciar esta idea, y en varios rincones del mundo se solicitaba formalmente una definición. A mi me bastaba con un texto informativo.

Figura 2: Petición de definición de hackers.txt

En ausencia de esta información, las alternativas de los investigadores era reportar a empresa que tuvieran Bug Bounties abiertas o que fueran Hacking Friendly, y no reportar ninguna en el resto de las empresas. 

Figura 3: Draft para Security.TXT

Ahora, me alegra ver que hay desde ese mes de Agosto un draft propuesto para esta idea, con el nombre de Security.TXT y que está abierto para debate en el IETF, bajo el nombre de "A Method for Web Security Policies".

Figura 4: Motivación, Terminología y Especificación para SECURITY.TXT

La idea es tan sencilla como yo proponía en Hackers.txt, es decir, que un investigador supiera cómo actuar cuando una vulnerabilidad había sido descubierta, lo que ayuda a explicar si hay una Bug Bounty o no abierta, y dar los puntos de contactos habilitados.

Figura 5: La definición del formato

Con un formato muy sencillo que se puede ver en esta definición, el fichero SECURITY.TXT, publicado en el path raíz de una aplicación web, daría toda la información que necesitan los investigadores para saber cómo actuar y eliminaría uno de los problemas que aún siguen teniendo:
- ¿Cómo lo reporto?
- ¿Me voy a meter en algún lío?
- ¿Hay algún premio por ello?
Saludos Malignos!

Entrada destacada

Nuevo libro "Máxima Seguridad en Windows: Secretos Técnicos 4ª Edición" de @0xWord

Desde 0xWord se ha acelerado para tener a tiempo antes del verano la 4ª Edición del libro "Máxima Seguridad en Windows: Secretos Técn...

Entradas populares