26 octubre 2015

Abierto el Call For Papers para Rooted CON 2016


Comienza el proceso de solicitud de ponencias (Call For Papers) para Rooted CON 2016. Al igual que en anteriores ediciones, es posible registrar una o varias ponencias a través del siguiente formulario:


Este año como principal novedad, cambiamos de localización, y el congreso se celebra los días 3, 4 y 5 de Marzo de 2016 en Sala 25 de los cines KINEPOLIS de Ciudad de La Imagen en Madrid.

Las temáticas que se valoran para este año dentro del proceso de solicitud de ponencias son las siguientes:

  • Hacking, cracking, phreaking, virii, WiFi, VoIP, GSM...
  • Seguridad en infraestructuras críticas, entornos SCADA...
  • Financial Tech (FinTech)...
  • Hardware Hacking, Jtag, SWJ, Dap, ...
  • Hacking de consolas y de videojuegos.
  • Terminales móviles: android, iOS, Windows mobile, Firefox OS...
  • Talleres de tecnologí­a
  • Criptomonedas
  • Drones
  • Ingenierí­a inversa, debugging, hooking, fuzzing, exploiting,...
  • Técnicas y herramientas innovadoras tanto en defensa como en ataque.
  • APT, botnets y malware.
  • (In)seguridad "en la nube", seguridad en entornos virtuales,...
  • Criptografí­a, esteganografí­a, canales subliminales,...
  • Forense y antiforense.
  • Comunicaciones, capa2 y capa3,...
  • Charlas (muy) originales que gusten al tipo de público que tenemos...
  • Filosofí­a y Ética, futuro, innovación...
  • CHARLAS MUY ORIGINALES, como monólogos, espectáculos...

Se aceptarán únicamente las charlas que se presenten a través del formulario publicado por la organización, y que hayan sido enviadas antes del 10 de Diciembre.

Cada ponente seleccionado recibirá los siguientes beneficios y privilegios:
  • Una cena con el resto de los ponentes, los profesores de RootedLabs y el equipo de RootedCON.
  • Alojamiento (costes a cargo de la organización
  • Viaje (costes a cargo de la organización)
  • Acceso completo al Congreso en sus tres dí­as
  • Algunas bebidas gratis en la fiesta ;)
  • Gestión de potenciales oportunidades laborales.
  • Un detalle (sorpresa) como agradecimiento por la participación. 
Puedes acceder al resto del texto del Call For Papers a través de este enlace.

¡Te esperamos en Rooted CON 2016!

[+] Noticia: Abierto el Call For Papers para Rooted CON 2016
[+] Formulario Call For Papers
[+] Texto Call For Papers
Leer más...

25 octubre 2015

Enlaces de la SECmana - 299


Leer más...

19 octubre 2015

El estado del SSL en Ayuntamientos Españoles



La semana pasada, presentamos conjuntamente con el bufete de abogados Abanlex y el fabricante de soluciones de seguridad Sophos, un informe en el que se hablaba sobre las necesidades del cifrado. Este informe pretendía ser una extensión del que ya llevaron a cabo Abanlex y Sophos el año anterior. En esta ocasión, contaron con Securízame para analizar el estado de la seguridad SSL en entidades públicas. Tras varias deliberaciones, decidimos enfocarnos en los Ayuntamientos españoles, como entidades que, debido al cumplimiento con la administración electrónica, permiten a los ciudadanos, interactuar de forma cifrada con ellos a la hora de intercambiar datos de tipo personal.

A lo largo de la semana pasada, diferentes medios se hicieron eco de la noticia, como consecuencia de la rueda de prensa en la que participamos, Pablo Teijeira de Sophos, Pablo Fernandez Burgueño de Abanlex y un servidor, por parte de Securízame. Cierto es que debido a que los medios en los que se han publicado no están especializados en seguridad informática, he querido publicar, con permiso expreso de Sophos Iberia, el contenido del estudio realizado, esto con el fin de no generar titulares tan alarmistas como los de otros medios más generalistas.

Antes que nada, quiero destacar que el estudio que realizó Securízame, lo hizo basándose en páginas web que permiten intercambio de datos personales con una muestra de sólo 10 ayuntamientos. Cierto es que, tras exponerlo a Sophos, se propuso extender la muestra del estudio a 77 ayuntamientos, permitiendo tener una mayor visibilidad y dar una estadística más acertada del panorama real, así como deducir si hay una mayor conciencia de seguridad cuanto mayor es el tamaño del ayuntamiento. La toma de datos de los servidores web seleccionados de los 10 ayuntamientos se llevó a cabo a mediados de Julio de 2015, y la elaboración del informe, a lo largo de Agosto.

Como disclaimer, indicar que para este análisis, no se llevó a cabo ninguna técnica intrusiva ni invasiva, y no se “auditaron” las páginas web de los ayuntamientos como se haría en el caso de un hacking ético.

El informe completo, que además habla de la necesidad de cifrado de puestos de trabajo, y que además clarifica muy bien la parte legal sobre los aspectos relativos al cifrado lo podéis descargar de: http://sophosiberia.es/descarga-informe-abanlex/

Bajo estas líneas, he transcrito las partes más relevantes (a mi juicio) del contenido del informe. 
Me he tomado la libertad de corregir alguna errata tipográfica sobre el informe original.

Para aquellos de nuestros lectores que siempre nos agradecen por publicar contenido técnico, he mantenido el apartado en el que se habla de las vulnerabilidades de SSL/TLS a lo largo de los últimos años.




Las necesidades de cifrado


La Ley 11/2007, del 22 de Junio de Acceso Electrónico de los ciudadanos a los servicios públicos, tiene como objetivo reconocer el derecho a que los ciudadanos puedan relacionarse con las Administraciones Públicas mediante medios electrónicos.

Esto implica que el canal a utilizar para realizar diversos trámites que involucran el intercambio, envío o consulta de datos personales, será Internet. Fundamentalmente este tipo de comunicaciones se llevarán a cabo mediante el estándar HTTP (Hypertext Transfer Protocol), utilizado por las transacciones de la World Wide Web.

Por ende, y por cumplir con la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal (LOPD), las diferentes Administraciones Públicas tendrán obligatoriedad de aplicar diversas medidas de seguridad, según la clasificación de los datos personales intercambiados. 

Asimismo, y de forma específica para Administraciones Públicas, entra en juego, en Enero de 2010, el Real Decreto 3/2010, del 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.

Se puede observar que, de forma encadenada, y dado que se obliga a la Administración Pública a poner los datos de los ciudadanos en el escaparate de Internet, son los propios dirigentes quienes aprueban leyes que buscan exigir unos mínimos que garanticen que dichos datos serán accesibles de una forma segura.

A partir de aquí, queda en manos de cada Administración, que de forma independiente, implemente dichas medidas de seguridad, de manera más o menos estricta.

La primera pregunta que viene a la cabeza del lector es ¿Y esto se cumple de forma efectiva? Y en lectores cuyo nivel de sensibilidad con sus datos personales es aún mayor, la segunda pregunta obligada será: ¿Son estas medidas suficientes?


Sobre los protocolos SSL y TLS

Para dotar de una capa de cifrado a las comunicaciones electrónicas que utilizan típicamente el protocolo HTTP, los dos protocolos más utilizados son SSL (Secure Sockets Layer)  y TLS (Transport Layer Security).

Ambos, son protocolos criptográficos que utilizan criptografía de clave pública (o asimétrica) para autenticar a una de las partes (obligatoriamente al servidor) o ambas, siendo opcional la autenticación del cliente.

Para dicha autenticación se utilizan certificados X.509, emitidos y firmados mediante una estructura jerárquica, con diferentes capas basadas en Autoridades Certificadoras y de Registro. 
Cada certificado X.509 lleva información que identifica unívocamente a un individuo o una entidad, como el identificador único del sujeto (CN o Common Name, organización, ciudad y país) información relativa al emisor, desde cuándo y hasta cuándo es válido el certificado, la propia clave pública del individuo o entidad, así como el algoritmo utilizado para generarla.
Además, cada certificado contará también con información de la entidad más inmediata en la jerarquía que ha firmado el mismo, y que avala su autenticidad. La información añadida por la Autoridad de Certificados es el la firma digital del mismo, así como el algoritmo utilizado para realizar la firma, así como el algoritmo de hashing utilizado.
Gracias a la criptografía de clave pública, y mediante la utilización de las herramientas que ésta provee, es posible garantizar la autenticación en las comunicaciones, así como el no repudio en las transacciones, si éstas han sido firmadas digitalmente por una de las partes. Son también misión de los algoritmos de clave pública asegurar la verificación de una determinada firma digital. 
Los algoritmos de clave pública típicamente utilizados en las difernetes fases, son DSA (Digital Signature Algorithm), RSA (Rivest, Shamir y Adelman) y Diffie-Hellman.

Como algoritmos de hashing, a la hora realizar firmas digitales, la criptografía de clave pública provee de MD5 (Message Digest) y aquellos de la familia SHA (Secure Hash Algorithm).
Tanto SSL como TLS, utilizan criptografía de clave pública para las fases de autenticación, intercambio de claves como de firma digital. Sin embargo, para el establecimiento de la comunicación y el intercambio de información entre las partes, se hace uso de criptografía de clave privada, o simétrica. A este grupo pertenecen algoritmos de cifrado como RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Standard).

Entre los diferentes algoritmos empleados para una misma tarea, se distingue, aparte del mecanismo de funcionamiento interno de cada uno, la longitud de clave utilizada. Cuanto mayor sea la longitud de la clave empleada para cifrar el mensaje, y siempre y cuando no se conozcan debilidades de base del algoritmo que aceleren el proceso, mayor será el esfuerzo computacional a realizar para descifrar el mensaje.

Otro concepto importante dentro de la criptografía es que un algoritmo se considera seguro, si el tiempo y el esfuerzo necesarios para romperlo y descifrar el contenido sin el conocimiento de la clave, es mayor que el valor del contenido de los datos en sí.

Con el paso de los años del mundo digital, el brillante trabajo realizado tanto por investigadores, como por gobiernos que ponen su foco en la intercepción y descifrado de las comunicaciones, la supuesta robustez los diferentes algoritmos criptográficos va siendo puesta en entredicho.

Por esto, cada implementación de SSL/TLS, va mejorando de una versión a otra, soportando cada vez algoritmos considerados más seguros, ya sea por mayor longitud de clave, como por la complejidad criptográfica del algoritmo en sí. 

Para que dos extremos (cliente y servidor) establezcan una comunicación, previamente a que ésta exista, han de intercambiarse una lista de algoritmos de cifrado, hashing y firma soportados por cada lado, eligiéndose habitualmente aquellos más robustos. Esto es así, debido a que la implementación SSL de los clientes y servidores no siempre soporta los mismos algoritmos, asegurando la compatibilidad con dispositivos más antiguos, o más limitados en cuanto a recursos de cómputo.





SSL/TLS a día de hoy


Hablar de “el día de hoy”, en un universo tan volátil y en el que cada mañana se hace pública una nueva vulnerabilidad, se hace complicado. Para ilustrar el estado del arte de SSL/TLS, empezaremos referenciando las últimas vulnerabilidades conocidas para estos protocolos.

Un repaso al historial de vulnerabilidades de SSL/TLS

Ya en el año 2011, desde la publicación de BEAST, la industria del software e Internet sufrió un gran revuelo. En 2012, Thai Duong y Juliano Rizzo, publicaron CRIME, otra vulnerabilidad explotable bajo determinadas condiciones, que aprovechaba un fallo en la compresión de los protocolos HTTPS y SPDY.

Pero sin duda, ha sido 2014 el año en el que SSL se haya visto más afectado. Posiblemente, el que mayor repercusión mediática tuvo, fue Heartbleed, ya que permitía leer de forma remota bloques de memoria del servidor. Esto implicaba que un atacante, desde la otra punta del mundo, podía extraer información de uso reciente en el servidor, como credenciales, cookies, e incluso la clave privada SSL utilizada. De esta manera, un atacante sería capaz, bajo ciertas condiciones, de interceptar la comunicación entre cliente y servidor, descifrándola o incluso suplantar a éste. Posteriormente, se descubrió que Heartbleed también podría afectar al lado cliente, siempre y cuando éste sea vulnerable y acceda a un servidor malicioso. Esta modalidad de Heartbleed se terminaría bautizando como Reverse Heartbleed.

A mediados de año, OpenSSL publicaba una nueva versión que corregía varios problemas serios. La vulnerabilidad más grave permitía que un atacante en un entorno Man-in-The-Middle, inyectase mensajes ChangeCipherSpec (CCS) a ambos lados. Como resultado de este ataque, se generan claves débiles que permiten descifrar la comunicación. 

A finales de 2014 apareció POODLE (Padding Oracle On Downgraded Legacy Encryption) afectando a software que utilizase la versión 3.0 de SSL y posteriormente, una variante que afectaba a TLS. Este tipo de ataque, sería aplicable en escenarios en los que es posible previamente interceptar las comunicaciones entre cliente y servidor, mediante un ataque de  Man-in-The-Middle. Esto es necesario debido a que requiere el análisis de un gran volumen de información entre ambos extremos para poder descifrar parte de la misma. Si bien es cierto que sólo afectaba a SSL 3.0, y que ciertos servidores incorporaban TLS, POODLE se basaba en ejercer previamente un ataque de downgrade de protocolos en la negociación inicial entre las partes, de manera que la comunicación se estableciese por SSL v3.

Las vulnerabilidades mencionadas afectaban fundamentalmente a las implementaciones SSL de OpenSSL, y por tanto todos aquellos dispositivos que se basasen en ella. En algunos casos, también afectaba a la implementación SSL de otros sistemas operativos como Android, Windows o Mac OS X.

Pero en 2014 no sólo las implementaciones de OpenSSL se vieron afectadas, sino también se descubrieron vulnerabilidades en la implementación de fabricantes como Apple (con el famoso GotoFAIL) o en el mundo del software libre, a GnuTLS.

En Marzo de 2015, estrena el año FREAK (Factoring Attack on RSA-Export Keys). Esta vulnerabilidad, que afecta a ambos protocolos SSL y TLS, también requiere de un escenario Man-in-The-Middle para ser efectiva. 

Precisamente, se aprovecha de un fallo en la negociación inicial, que permite forzar que se utilicen especificaciones de algoritmos RSA con longitudes de clave muy cortas, consideradas crackeables en un tiempo moderado, con los recursos computacionales necesarios. Algoritmos del tipo de TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, estaban aún soportados por el estándar SSL/TLS, por compatibilidad con las restricciones de cifrado establecidas por el gobierno Clinton en Estados Unidos, en los 90, para aquellas comunicaciones que se llevasen a cabo fuera del país. 

Y ya en Mayo de 2015, el último hit a SSL ha sido Logjam. En este caso, el ataque se establece dentro del algoritmo Diffie-Hellman, cuando se usan de 512 a 1024 bits. Una vez más, en un entorno de Man-in-The-Middle, es posible para un atacante establecer un downgrade de la negociación para utilizar un algoritmo de Diffie-Hellman de longitud baja, soportadas también desde épocas en las que existían limitaciones de cifrado a la hora de ser exportado fuera de Estados Unidos. Esta vulnerabilidad permitía comprometer el cifrado no sólo a HTTPS, sino a otros protocolos como SMTPS, SSH, IPSec y aquellos que confíen en TLS.

De hecho, se especulaba con que Logjam era la vulnerabilidad utilizada por la NSA para poder descifrar tráfico en el programa americano de ciberguerra llamado TURBULENCE.
Han existido otros ataques a SSL/TLS que han tenido menos repercusión mediática, como Lucky13 o Bar Mitzvah, pero que permitían igualmente descifrar contenido parcial o totalmente de las comunicaciones.

Los algoritmos de hashing más populares, MD5 y SHA-1, también han sido reconocidos como no-confiables debido a que en ambos es posible establecer colisiones, de manera que hace que se incumplan por definición, al poder llegarse a dos hashes MD5 o SHA-1 idénticos, partiendo de fuentes distintas.

Tras ver la cantidad de vulnerabilidades existentes en diversas implementaciones de SSL/TLS, se considera que SSL está “muerto” y que la única implementación viable es TLS, actualmente en su versión 1.2. No se puede decir que esta especificación sea la definitiva y la segura, pero al menos, a día de hoy, no se conocen vulnerabilidades que hagan pensar lo contrario.
De hecho, navegadores como Firefox, a partir de su versión 34, deshabilitan SSLv3, confiando en TLS únicamente.



Implementación de SSL/TLS en los Ayuntamientos Españoles


Para el estudio realizado, se ha escogido una muestra representativa de ayuntamientos españoles, de 10 capitales de provincia, repartidos por la geografía española. Las entidades elegidas fueron, los ayuntamientos de las ciudades de Barcelona, Bilbao, Cáceres, Logroño, Madrid, Málaga, Pontevedra, Santiago de Compostela, Sevilla y Valencia.
Como herramienta de métricas estándar, se ha elegido la solución online https://www.ssllabs.com/ssltest, provista de forma gratuita por Qualys Labs. El servicio provisto es online y gratuito.


La prueba consiste en introducir el dominio de cada ayuntamiento en la que el protocolo a servir es HTTPS. Se ha identificado para cada prueba, alguna dirección web a través de la que se envíen datos personales a cada Ayuntamiento.

Por cada prueba, la herramienta ofrece un resultado como el que se puede apreciar en la imagen. En ella se puede observar el dominio y la dirección IP correspondiente, el rating o nota que da el servicio ante multitud de pruebas realizadas, así como un resumen de aquellas mejoras que se pueden hacer para que el servicio tenga una mayor seguridad. El rating va desde la F que es el peor resultado, hasta el A+ que es el mejor. 

Asimismo, el contenido del informe detalla cada una de las pruebas realizadas.
Este servicio evalúa tanto la información del certificado SSL ofrecido por el servidor para el dominio analizado, como la configuración propiamente del mismo, en base a analizar las respuestas de éste.


Por confidencialidad, en este informe se establece un resumen de resultados, sin asociarlos a un Ayuntamiento concreto. 


Análisis de los resultados

Tras la revisión de cada uno de los informes generados por el servicio online se extrae los siguiente:
  • La nota más alta otorgada a un Ayuntamiento es la B, y la más baja es la F. En tres casos de los diez analizados, la nota obtenida es T, que quiere decir que el certificado no es confiable (Trustable). Esto se da porque el certificado está firmado por la FNMT (Fábrica Nacional de Moneda y Timbre), autoridad de certificados reconocida en España y por el navegador Internet Explorer. Sin embargo, otros navegadores como Google Chrome o Mozilla Firefox no la reconocen como válida, y muestran un error de certificado al cargar la página. En un caso, la nota obtenida se identifica como M (Mismatch) puesto que el nombre de dominio no coincide con el del certificado ofrecido. Esta situación mostraría un error de certificado no confiable en todos los navegadores. Si no se tiene en cuenta la nota T o M, quedaría según muestra la siguiente relación:

    1. Nota B: 3 ayuntamientos 
    2. Nota C: 2 ayuntamientos 
    3. Nota F: 5 ayuntamientos 

  • El servidor muestra el nombre del fabricante y su versión y/o de mod_ssl -> 4 ayuntamientos. Sólo el fabricante del servidor 4
  • El servidor de uno de los ayuntamientos analizados soporta SSLv2, considerado inseguro desde hace varios años.
  • El servidor es vulnerable a POODLE. Ya sea por soporte de SSLv3 como por TLS, al no soportar la extensión TLS_FALLBACK_SCSV, que mitigaría este problema. Se considera que SSLv3 es inseguro y se recomienda deshabilitarlo http://disablessl3.com/ -> 7 de los 10 ayuntamientos analizados
  • El servidor es vulnerable a FREAK. 3 ayuntamientos de los 10 analizados
  • El servidor es vulnerable a CRIME: Sólo un ayuntamiento es vulnerable a CRIME por tener activo el soporte de compresión en TLS.
  • El servidor es vulnerable y explotable a ChangeCipherSpec CCS, 2 de 10 ayuntamientos.
  • El servidor soporta parámetros inseguros de intercambio de claves Diffie-Hellman, 8 de los 10 ayuntamientos.
  • El servidor utiliza primos comunes/conocidos para algoritmo Diffie-Hellman: 6 de 10 ayuntamientos.
  • Soporte del algoritmo de cifrado RC4. Aunque la herramienta indica que soportar RC4 se considera un algoritmo débil, hay que dejar claro que nuestro desacuerdo en ello. La supuesta vulnerabilidad de RC4, supone al atacante estar en un entorno Man-in-The-Middle capturando el tráfico de la víctima hacia el servidor. Esto es perfectamente viable, pero es que además el atacante deberá recopilar una cantidad ingente de los mismos datos cifrados con diferentes claves, lo que inicialmente disminuye la probabilidad de ocurrencia del ataque. No obstante, se destaca que 8 de los 10 ayuntamientos anaizados, soportan RC4.
  • Sólo soportan TLS v1.2 en 6 de 10 ayuntamientos analizados, aunque en todos ellos, se soporta al menos TLS v1.0, siendo bastante común el tandem SSLv3 y TLSv1.0, sin dar soporte para TLS v1.1 ni v1.2
  • Respecto al algoritmo de firma del certificado SSL presentado por el servidor:
  1. Dos ayuntamientos utiliza clave privada con RSA de 1024 bits, considerada una longitud de clave insuficiente.
  2. El algoritmo de hashing utilizado en el certificado es SHA-1  en 8 de 10 ayuntamientos.
  3. De estos ocho, en cuatro de ellos, la fecha de expiración del certificado es mayor de finales de 2016. A partir de esta fecha, Microsoft ha anunciado que dejará de soportar SHA-1 como algoritmo válido en sus navegadores, por lo que se mostrará el certificado como erróneo.
Conclusiones y reflexiones

Tras haber desglosado los diferentes ataques de los que pueden ser víctimas, tanto los servidores, como sobre todo los clientes, que intercambian datos mediante una conexión SSL/TLS, se puede ver que mantener los servicios lo de la forma más segura posible es una labor que requiere dedicación y mantenimiento.

No sólo se trata de actualizar los parches de seguridad, y tener todo el software a la última versión, sino que además, los servicios que hacen uso de SSL, deben estar configurados de forma segura, manteniendo unos niveles de compatibilidad con los algoritmos de cifrado soportados por los dispositivos y sistemas operativos más comunes del mercado.

En muchas ocasiones merece la pena sacrificar la conectividad de aquellos dispositivos más antiguos, en pos de evitar la posibilidad del compromiso completo de los datos de otros usuarios. 
La administración pública suele tenernos acostumbrados a los ciudadanos a que, para poder interactuar con la e-Administración, tengamos que disponer de una determinada versión de la máquina virtual de Java, o al menos no podamos disponer la última. Igualmente, en muchas ocasiones, se ve limitado el navegador con el que podemos acceder a determinados servicios, siendo Internet Explorer para que el que parece que la Administración hace sus pruebas de compatibilidad. Incluso dentro de Internet Explorer, se solicita al internauta que relaje las medidas de seguridad, para que funcione. ¿Y después de todos estos requisitos, se pretende que los ciudadanos tengan tranquilidad sobre el tratamiento de sus datos?

Cada vez que vemos un telediario, que analizamos las noticias relacionadas con los avances de la Agencia Nacional de Seguridad americana (NSA), desvelados por Edward Snowden, y los descubrimientos publicados día a día, cada vez se genera una mayor sensación de inseguridad en los ciudadanos.

Las debilidades de los algoritmos de cifrado empleados en las comunicaciones, permitirían el acceso a quien tuviera el conocimiento de la existencia de una vulnerabilidad. Sin embargo, una vez que los detalles de éstas se hacen públicas, es la propia comunidad quien se lanza a construir exploits y herramientas automatizadas que permitan su explotación a cualquiera con unos conocimientos mínimos. De ahí la importancia vital de que cualesquiera sean los sistemas, cuenten con las últimas versiones y parches de seguridad, sean configurados de la forma más exigente y segura posible, así como que formen parte de un programa frecuente de auditorías, con el fin de disminuir los riesgos al mínimo posible.

Los resultados que se desprenden del estudio realizado sobre la muestra de 10 ayuntamientos, muestran cómo en las ciudades de mayor volumen de habitantes, las medidas de seguridad implantadas en los servidores, son algo más cuidadas, siendo los ayuntamientos más pequeños los que muestran claramente que tienen aún bastante por mejorar.

Desde un punto de vista meramente legal, y atendiendo a las normativas referidas respecto al tratamiento de datos personales, como LOPD o, en el caso de Administración Pública, el Esquema Nacional de Seguridad, en lo que se refiere al cifrado de las comunicaciones, se puede decir que todos los Ayuntamientos menos uno, cumplen con que el tráfico intercambiado entre cliente y servidor “no sea inteligible ni manipulada por terceros”. Sin embargo, y pese a estar al día con la normativa vigente, sigue habiendo una diferencia entre cumplir una ley y tener una conciencia real de seguridad de la información.
Leer más...

18 octubre 2015

Enlaces de la SECmana - 298


Leer más...

16 octubre 2015

SbD te lleva a las 8.8 en Chile y Bolivia!



Como decía ayer, a lo largo de las dos próximas semanas se van a celebrar los Congresos de Seguridad 8.8 en Chile (que será su quinta edición ya), y en ciudad de La Paz en Bolivia. 

Por ser ponente en ambos eventos, la organización me ha regalado dos entradas (una para cada evento). Como tengo muchos compromisos de gente a quien me gustaría regalárselas, he decidido que ni para un@s ni para otr@s. Las voy a sortear entre los lectores de Security By Default.

Al hilo de como hemos hecho otras veces, pido a quienes estén interesados en asistir a alguno de los dos eventos, que dejen un comentario en este post, indicando un correo electrónico válido, y en el campo del comentario, la razón de por qué te mereces una entrada a la 8.8. Recuerda decir si aplicas para la de Chile o para la de Bolivia.

Sobre los comentarios que haya, decidiré el comentario que mejor me parezca para cada evento y me comunicaré con los ganadores. 

Es requisito indispensable que los participantes del sorteo sean de Chile, Bolivia o estén en disposición de viajar a los destinos de los eventos. 

Tenéis hasta el Lunes 19 de Octubre a las 23:59 hora peninsular española, para optar a la entrada para la edición de Chile.

Y tenéis hasta el Viernes 23 de Octubre a las 23:59 hora peninsular española, para optar a entrada para la edición de Bolivia.

Espero vuestros comentarios y nos vemos en Chile y Bolivia! 
Leer más...

14 octubre 2015

En 2015, la 8.8 se multiplica por dos!



Nada más y nada menos que cinco son ya las ediciones que lleva el evento de seguridad informática anual más importante de Chile. He tenido la oportunidad de participar en dos de ellas en los últimos años, y si Dios quiere lo haré en su próxima edición, que se celebrará en la ciudad de Santiago los días 22 y 23 de Octubre. Los que me conocéis, sabéis que es un total placer viajar a eventos en Latinoamérica, pero Chile además tiene para mí un significado especial. No sólo porque el ambiente de 8.8 es una auténtica pasada, sino porque al tener raíces chilenas, aprovecho para visitar a familiares y amigos.


En esta ocasión, el cartel de ponentes es impresionante. Desde Chema Alonso que dará la keynote del evento, hablando sobre fallos de programación en aplicaciones Android disponibles en Google Play (tuve la oportunidad de ver esta charla en Navaja Negra ConectaCON en Albacete y es sorprendente la cantidad de fallos que se cometen). 

Otra charla que me consta muy interesante es la Hugo Bayona, que ví en DragonjarCON, sobre PNL. Igualmente será instructiva la que dará Daniel Echeverri (Adastra), que sacará a la luz los internals de TOR. Fraph, otro de los colegas que conocí en Colombia este año, dará una charla sobre vulnerabilidades que ha encontrado en pasarelas de pago. 

Además, vendrá mi buen amigo Claudio Caracciolo que seguro que trae algo interesante para contarnos (y en la que seguro que aprovecha para trollearme :D) 

Por mi parte, continuaré con la saga de "Memorias de un Perito Informático Forense Vol. II", en la que contaré la experiencia en un par de peritajes que me tocó defender y que espero que guste al público chileno.

Como dice el título del post, la 8.8 este año se multiplica por dos. Y es que resulta que este año se celebrará en La Paz, capital de en Bolivia, la primera edición de este evento. Gracias al apoyo de la organización de 8.8 de Chile, pero a través de organización local de Bolivia, se llevará a cabo un evento que pretende ser el más importante del país en materia de seguridad.... Se celebrará el lunes 26 y martes 27 de Octubre.


Así, viajaré desde Santiago a La Paz para participar en la primera edición de este evento. Por lo que se puede ver en el cartel, esta primera edición estará genial. Ponentes como Jaime Andrés Restrepo, Diego Bruno (que dará una charla sobre las diversas vulnerabilidades en la historia de SSL, que pude ver en Colombia por parte de Javier Antunez), Gabriel Bergel, etc,... Además, espero ver una charla que dará el boliviano Elvin Mollinedo, al que conocí como alumno en el taller de Seguridad en Entornos Corporativos que dí en Colombia, y de la que me dio un adelanto allí, sobre creación de BTS falsas mediante Linux. 

Será todo un honor participar en esta primera edición, y además por partida doble, puesto que daré el keynote y el cierre del evento. En ambos casos, las charlas serán de Análisis Forense y Peritaje Informático, en las que expondré diversos casos en los que me he visto implicado.

Serán dos semanas de viajes y aventuras en CONs por Latinoamérica, en las que espero disfrutar como siempre de un continente y un público que me encanta por su hospitalidad y humildad, así como sus ganas de compartir, aprender y generar comunidad.

Os dejo los enlaces a las webs de ambos eventos bajo estas líneas:


Nos vemos en Chile y Bolivia!
Leer más...

06 octubre 2015

¡Hola criaturas de la noche varias!


Después de muchos años en IOActive, recorriendo medio mundo rompiendo cosas, tenemos la alegría de poder anunciar que IOActive va a abrir un laboratorio en Madrid, principalmente centrado en seguridad hardware.
Foto del interior del Hardware Research Lab de IOActive en Madrid
A medida que nos vayamos estableciendo esperamos poder contribuir con la comunidad. De momento este jueves 8 de octubre queremos invitaros a visitar nuestro laboratorio mientras os tomáis algo. Para los que quieran conocer la cara más lúdica de la seguridad ;) ese mismo día por la noche, y hasta que el cuerpo aguante, organizamos una fiesta con comida, bebida, banderas piratas y ¡música en directo!

Durante el jueves tendremos las siguientes actividades:
  • Hardware Lab Open House – Visita y presentación del laboratorio y su equipamiento a cargo de Ruben Santamarta y Gabriel Gonzalez.
  • Hardware Lab Launch Party – Fiesta al más puro estilo IOActive, con comida, bebidas y música en directo.

El laboratorio se encuentra en la siguiente dirección:

Calle del Conde de Serrallo, 1
Portal 3, 1° Puerta 7
Madrid


Además de todo esto, en IOActive actualmente tenemos vacantes disponibles por lo que, si lo tuyo es romper todo aquello que se te ponga por delante: web, binarios, redes, embebidos, etc.. ¡pásate y déjanos tu CV!

Las plazas para esta fiesta de apertura son limitadas y gratuitas, por lo que realizad el registro lo antes posible para que no os quedéis sin vuestra entrada, utilizando el siguiente enlace:


Contribución por: 
Ruben Santamarta (@reversemode)
Principal Security Consultant at IOActive
Leer más...

05 octubre 2015

Bases y formulario de inscripción para el Hackathon de CyberCamp 2015

Como anunciamos en un post anterior, durante el CyberCamp 2015 entre el 26 y 29 de Noviembre, se celebrará un Hackathon. Pues bien, ya tenemos más información al respecto.


A continuación publicamos un resumen de lo más destacado de las bases, cuyo documento completo podrés encontrar en este enlace:
  • El Hackathon de CyberCamp 2015 es una competición o evento presencial de desarrollo colaborativo de software en un corto periodo de tiempo, centrado en el desarrollo y/o mejora de herramientas de ciberseguridad de código abierto.
  • Podrán participar todas aquellas personas mayores de 14 años que dispongan de DNI/NIF o pasaporte, en vigor, u otro documento que, conforme a la legislación española, acredite la identidad y edad del participante.
  • El proceso de inscripción se inició el 2 de Octubre, y finalizará el 2 de Noviembre.
  • Para participar en el Hackathon, los interesados (individualmente o por equipos) deberán seleccionar la herramienta de ciberseguridad de código abierto sobre la que desean realizar sus desarrollos, mejoras y contribuciones
  • Es necesario utilizar este formulario de inscripción
  • El Hackathon tendrá una duración estimada de unas 42 horas, distribuidas en los diferentes días asociados al evento CyberCamp 2015, y considerando un periodo diario de descanso recomendado de 8 horas
  • Los premios consisten en: 
    • Primer premio: un ordenador portátil para cada integrante del equipo ganador.
    • Segundo premio: un smartphone para cada integrante del segundo equipo. 
    • Tercer premio: un smartwatch para cada integrante del tercer equipo.
Toda la información referente al Hackathon la podréis encontrar en los siguientes enlaces:










Leer más...

04 octubre 2015

Enlaces de la SECmana - 296

Leer más...

02 octubre 2015

Seguridad Bluetooth: Instalando Ubertooth en Kali Linux 2.0.0


El proyecto Ubertooth es una plataforma de desarrollo de código abierto, con componentes tanto hardware como software, que permite experimentar y profundizar en la seguridad de las tecnologías inalámbricas Bluetooth. Ubertooth proporciona capacidades de captura e inyección de tráfico, y dispone tanto de un sniffer para BLE (Bluetooth Low Energy o Bluetooth Smart) como para las conexiones Bluetooth clásicas que emplean el estándar de trasmisión básico (o Basic Rate, BR).

El proyecto Ubertooth está constituido por tres componentes:
  • Dispositivo hardware Ubertooth One, que se puede construir (al ser un proyecto hardware de código o diseño abierto) o comprar. Su potencia de transmisión y sensibilidad de recepción son similares a las de un dispositivo Bluetooth de Clase 1.
  • Firmware: Software que ejecuta en el procesador ARM del propio Ubertooth One, compuesto por el gestor de arranque (bootloader) y el firmware de recepción y transmisión de Bluetooth (bluetooth_rxtx).
  • Software (o host code): Software que ejecuta en un ordenador de propósito general (por ejemplo, Linux) al que está conectado el Ubertooth One mediante un puerto USB. 

El proyecto Ubertooth estaba disponible originalmente en Sourceforge, pero se ha movido a GitHub. La documentación oficial está disponible en el Wiki, dónde se dispone tanto de la guía de instalación como, adicionalmente, de las instrucciones para actualizar el firmware del dispositivo Ubertooth One.

La última versión de Ubertooth disponible en la actualidad es la 2015-09-R2, vinculada a la librería libbtbb, una librería de decodificación de la banda base de Bluetooth (Bluetooth Baseband, btbb), identificada con el mismo número de versión.

Instalación del proyecto Ubertooth en Kali Linux 2.0.0

El proyecto Ubertooth tiene numerosas dependencias o prerrequisitos necesarios para su instalación. Las siguientes instrucciones hacen uso de Kali Linux 2.0.0 como plataforma para instalación de la última versión de Ubertooth disponible, 2015-09-R2, ya sea directamente en un sistema real o en una máquina virtual.

En primer lugar se debe actualizar Kali Linux 2.0.0 con las últimas versiones de los paquetes y aplicaciones existentes por defecto en Kali Linux mediante los dos comandos siguientes:
$ sudo apt-get update
$ sudo apt-get dist-upgrade

A continuación se deben instalar todas las dependencias de Ubertooth. Este proceso se puede llevar a cabo manualmente, o automatizarse mediante un script (referenciado posteriormente):
$ sudo apt-get install cmake libusb-1.0-0-dev make gcc g++ libbluetooth-dev pkg-config libpcap-dev python-numpy python-pyside python-qt4

Es necesario instalar previamente la librería libbtbb para que las herramientas de Ubertooth puedan decodificar paquetes Bluetooth (por defecto, en "/usr/local/lib/libbtbb.so"), junto al fichero de cabeceras ("/usr/local/include/btbb.h") y a la herramienta "btapbtap" (bajo "/usr/local/bin"), un sniffer para teclados Bluetooth:
$ wget https://github.com/greatscottgadgets/libbtbb/archive/2015-09-R2.tar.gz -O libbtbb-2015-09-R2.tar.gz
$ tar xf libbtbb-2015-09-R2.tar.gz
$ cd libbtbb-2015-09-R2
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install

NOTA: Si se desea instalar libbtbb en una ubicación diferente se podría hacer uso del siguiente comando, en lugar de utilizar simplemente "cmake ..":
$ cmake -DINSTALL_DIR=/path/to/install -DINCLUDE_DIR=/path/to/include ..

A continuación se deben instalar las herramientas de Ubertooth, que incluyen (entre otros) el software para la captura de tráfico Bluetooth (referenciado como host code), para configurar el dispositivo Ubertooth y para actualizar el firmware:
$ wget https://github.com/greatscottgadgets/ubertooth/releases/download/2015-09-R2/ubertooth-2015-09-R2.tar.xz -O ubertooth-2015-09-R2.tar.xz
$ tar xf ubertooth-2015-09-R2.tar.xz
$ cd ubertooth-2015-09-R2/host
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
$ sudo ldconfig

Este paso instalará la librería "/usr/local/lib/libubertooth.so", junto a nuevos ficheros de cabeceras (bajo "/usr/local/include/ubertooth*.h") y múltiples herramientas bajo "/usr/local/bin/ubertooth*". Adicionalmente se instalará el fichero de reglas de detección y acceso al dispositivo Ubertooth One (y Zero), tanto en modo de funcionamiento estándar como DFU (Device Firmware Upgrade) bajo "/etc/udev/rules.d/40-ubertooth.rules".

NOTA: Los comandos de la presente guía (instalación y uso) pueden ser ejecutados como "root", opción desaconsejada desde el punto de vista de seguridad ;-) Sin embargo, las reglas de Ubertooth creadas permiten el acceso al dispositivo por parte de cualquier usuario perteneciente al grupo "plugdev".

Instalación del plugin de Ubertooth para Kismet

La versión de Kismet disponible por defecto en Kali Linux 2.0.0 es la "2013-03-R0":
$ kismet -v 
Kismet 2013-03-R0

Para poder hacer uso de Ubertooth en Kismet es necesario compilar Kismet a partir de su código fuente, incluyendo todas las dependencias necesarias:
$ sudo apt-get install libpcap0.8-dev libcap-dev pkg-config build-essential libnl-dev libncurses-dev libpcre3-dev libpcap-dev libcap-dev
$ wget https://kismetwireless.net/code/kismet-2013-03-R1b.tar.xz
$ tar xf kismet-2013-03-R1b.tar.xz
$ cd kismet-2013-03-R1b
$ ln -s ../ubertooth-2015-09-R2/host/kismet/plugin-ubertooth .
$ ./configure
$ make dep && make && make plugins
$ sudo make suidinstall
$ sudo make plugins-install

Como resultado se dispondrá del plugin de Ubertooth bajo "/usr/local/lib/kismet_client/ubertooth_ui.so".

Adicionalmente, es necesario añadir "pcapbtbb" a la línea "logtypes=..." en "/etc/kismet/kismet.conf" para que Kismet genere ficheros de log con el formato de captura de Bluetooth.

Instalación de los plugins de Ubertooth para Wireshark 

La versión de Wireshark disponible por defecto en Kali Linux 2.0.0 es la "1.12.6":
$ wireshark -v 
wireshark 1.12.6 … 

Por un lado, desde la versión 1.12 de Wireshark (en concreto desde la versión de desarrollo 1.12.0-rc2) se incluye por defecto el plugin de Ubertooth para BLE (Bluetooth Low Energy o Bluetooth Smart).

Por otro lado, los plugins de Ubertooth para BTBB (BlueTooth BaseBand) y BR/EDR (Basic Rate / Enhanced Data Rate), más nuevo, permiten analizar y diseccionar (o decodificar) desde Wireshark el tráfico de banda base Bluetooth que ha sido capturado mediante Kismet y las herramientas de Ubertooth, respectivamente.

En el caso de Kali Linux 2.0.0 (64 bits), el directorio de instalación indicado en "cmake" a través de "MAKE_INSTALL_LIBDIR" que corresponde con la ubicación de los plugins de Wireshark debe ser "/usr/lib/x86_64-linux-gnu/wireshark/plugins/1.12.6".

Para poder hacer uso de Ubertooth en Wireshark y, por ejemplo, analizar el tráfico generado por Kismet, es necesario compilar los dos plugins de Bluetooth a partir de su código fuente, incluyendo todas las dependencias necesarias, aparte del resto de herramientas de Ubertooth y de la librería libbtbb.

NOTA: Antes de llevar a cabo los siguientes pasos es necesario consultar los detalles del siguiente apartado, debido a la existencia de un conflicto en los plugins de Ubertooth para Wireshark.

En primer lugar, debe instalarse el plugin BTBB:
$ sudo apt-get install wireshark wireshark-dev libwireshark-dev cmake
$ cd libbtbb-2015-09-R2/wireshark/plugins/btbb
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/wireshark/plugins/1.12.6 ..
$ make
$ sudo make install

A continuación, debe instalarse el plugin Bluetooth (BT) BR/EDR:
$ sudo apt-get install wireshark wireshark-dev libwireshark-dev cmake
$ cd libbtbb-2015-09-R2/wireshark/plugins/btbredr
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/wireshark/plugins/1.12.6 ..
$ make
$ sudo make install

Este proceso instalará los plugins "btbb.so" y "btbredr.so" en el directorio de plugins de Wireshark indicado previamente.

Conflicto de nombres duplicados en los plugins de Ubertooth para Wireshark

Ambos plugins actualmente (en la última versión oficial de libbtbb, 2015-09-R2) emplean el mismo nombre completo de plugin, "Bluetooth Baseband" y el mismo nombre corto, "BT Baseband" (aunque hacen uso de referencias diferentes para los filtros de visualización de tráfico, "btbb" y "btbredr"), por lo que es necesario modificar los mismos para poder utilizar Wireshark.

Una futura versión de libbtbb y de los plugins de Wireshark asociados evitará este conflicto, al disponerse ya de una solución (commit) en la última versión de libbtbb disponible en GitHub.

Sino se lleva a cabo ninguna modificación, al ejecutar Wireshark se obtiene el siguiente mensaje de error que indica que hay un nombre de protocolo duplicado en Wireshark para el tráfico de banda base Bluetooth:
$ wireshark & 
… 
Err Duplicate protocol name "Bluetooth Baseband"! This might be caused by an inappropriate plugin or a development error. 

Sin embargo, es posible evitarlo aplicando el parche asociado a ese commit concreto que soluciona el problema de nombres duplicados en los plugins de Ubertooth/libbtbb para Wireshark. El parche puede ser generado mediante Git:
$ mkdir Ubertooth-git 
$ cd Ubertooth-git/ 
$ git clone https://github.com/greatscottgadgets/libbtbb.git 
Cloning into 'libbtbb'... 
remote: Counting objects: 1460, done. 
remote: Compressing objects: 100% (4/4), done. 
remote: Total 1460 (delta 0), reused 0 (delta 0), pack-reused 1456 
Receiving objects: 100% (1460/1460), 415.78 KiB | 508.00 KiB/s, done. 
Resolving deltas: 100% (880/880), done. 
Checking connectivity... done. 
S cd libbtbb/ 
$ git format-patch -1 ae840325b61ad74181b079db288b4309ce96746b 0001-Fix-Ubertooth-issue-112-duplicate-plugin-names.patch 

Posteriormente, sólo es necesario copiar y aplicar ese parche sobre la versión 2015-09-R2 oficial de libbtbb antes de compilar e instalar los plugins:
$ cd libbtbb-2015-09-R2/ 
$ ls 0001-Fix-Ubertooth-issue-112-duplicate-plugin-names.patch 
… 
$ patch -p1 < 0001-Fix-Ubertooth-issue-112-duplicate-plugin-names.patch 
patching file wireshark/plugins/btbb/CMakeLists.txt 
patching file wireshark/plugins/btbb/packet-btbb.c 
patching file wireshark/plugins/btbb/packet-btbrlmp.c 
patching file wireshark/plugins/btbb/packet-btlmp.c 
patching file wireshark/plugins/btbredr/packet-btbredr.c

Automatizando el proceso de instalación del proyecto Ubertooth

Con el objetivo de automatizar el proceso de instalación de Ubertooth en Kali Linux 2.0.0, se ha publicado el siguiente script, "ubertooth_install.sh", en el repositorio GitHub de DinoSec.

Una vez se dispone de conexión a Internet, su ejecución automatiza todo el proceso de instalación de Ubertooth descrito previamente:
$ sudo ./ubertooth_install.sh

El parche previamente descrito está también disponible en el repositorio GitHub de DinoSec y ya es utilizado directamente por el script de instalación.

Instrucciones para actualizar el firmware del dispositivo Ubertooth One 

Tras obtener e instalar la última versión del software de Ubertooth disponible (proceso detallado previamente), se recomienda verificar la versión actual de firmware desde el modo estándar (no DFU), tras conectar el Ubertooth One a un puerto USB:
$ ubertooth-util -v 
Firmware revision: 2014-02-R2 
$ ubertooth-util -V
ubertooth 2014-02-R2 (dominicgs@mercury) Thu Feb 20 13:28:01 GMT 2014 

NOTA: En el caso de no disponer de una conexión USB suficientemente rápida, por ejemplo, al emplear un cable USB de mala calidad o especialmente al hacer uso de una máquina virtual, pueden obtenerse errores de temporización USB:
$ ubertooth-util -v
libUSB Error: Timeout: (-7)
Firmware revision: error: -7

Se recomienda encarecidamente utilizar el Ubertooth One directamente desde Linux empleando un ordenador físico y no hacer uso de una máquina virtual.

En el modo de funcionamiento estándar, por defecto, se encienden los leds verdes de 1V8 y RST, y el led rojo de USB:



Tras cambiar al directorio asociado al firmware, se recomienda hacer uso de la herramienta de actualización del firmware de Ubertooth, "ubertooth-dfu", para cambiar el Ubertooth One al modo DFU (Device Firmware Upgrade) y hacer una copia de seguridad del firmware instalado actualmente en el dispositivo:
$ cd ubertooth-2015-09-R2/
$ cd ubertooth-one-firmware-bin/
$ ls -l
total 228
-rwxrwxr-x 1 1000 inetsim 14732 Sep 5 13:44 assembly_test.bin
-rw-rw-r-- 1 1000 inetsim 41484 Sep 5 13:44 assembly_test.hex
-rwxrwxr-x 1 1000 inetsim 34344 Sep 5 13:44 bluetooth_rxtx.bin
-rw-rw-r-- 1 1000 inetsim 34360 Sep 5 13:44 bluetooth_rxtx.dfu
-rw-rw-r-- 1 1000 inetsim 96633 Sep 5 13:44 bluetooth_rxtx.hex
$ ubertooth-dfu -u bluetooth_rxtx.2014-02-R2.dfu -r
Switching to DFU mode
..................................................................................................................................................................
Detached
$ ls -l
-rw-r--r-- 1 dino dino 245760 Sep 29 11:44 bluetooth_rxtx.2014-02-R2.dfu

Posteriormente, se recomienda actualizar (o flashear) el nuevo firmware en el dispositivo:
$ ubertooth-dfu -d bluetooth_rxtx.dfu -r
Switching to DFU mode...
Checking firmware signature
.......................................................................................................................................
Detached
$ ubertooth-util -v
Firmware revision: 2015-09-R2
$ ubertooth-util -V
ubertooth 2015-09-R2 (dominicgs@hydrogen) Sat Sep 5 12:44:21 BST 2015

En el modo de funcionamiento DFU, por defecto, se encienden los leds verdes de 1V8 y RST, el led rojo de USB parpadea, y los leds de TX, RX y USR parpadean con un patrón de persecución secuencial.

La opción "-r" permite resetear el dispositivo y pasar del modo DFU al modo estándar tras completar la operación, mostrando el mensaje "Detached". Adicionalmente se puede desconectar y volver a reconectar el dispositivo, o llevar a cabo un reset del mismo mediante el comando "ubertooth-util -r".

Si te interesa la seguridad y el hacking ético de tecnologías inalámbricas, como Bluetooth y Wi-Fi, podrás profundizar mucho más, entre muchos otros temas, en el uso del Ubertooth One como un analizador de espectro básico, o emplearlo para la captura de tráfico Bluetooth y BLE desde Kismet o desde Wireshark, descubrir dispositivos Bluetooth ocultos o investigar la seguridad de cualquier dispositivo Bluetooth, como por ejemplo analizar el proceso de emparejamiento entre un Apple Watch y un iPhone, en el Curso online de Hacking Ético de Securízame, donde impartiré el módulo "Módulo V Hacking Ético de tecnologías inalámbricas: Bluetooth y Wi-Fi".

Colaboración por cortesía de Raúl Siles

Leer más...