Ángel, un hacker en el ascensor del Edificio Telefónica de Madrid en 1947

Mi padre trabajó en Telefónica durante toda su vida, y antes de ayer descubrí una historia que no conocía de cuándo estaba comenzando su carrera profesional en la compañía. Es una aventura que tuvo lugar en el mítico, histórico y emblemático edificio de Telefónica que el año pasado celebró sus 90 años de vida. Pues bien, ésta es una de las infinitas historias que cuentan sus muros, y la protagonizaron mi padre y su hermano, mi tío, en uno de los ascensores que lleva desde la planta baja hasta las plantas cercanas al reloj que ilumina la Gran Vía de Madrid.

Figura 1: Ángel, un hacker en el ascensor del Edificio Telefónica de Madrid en 1947

La escribo y os la dedico con cariño a mis queridos amigos telefónicos, ya que fue por casualidad cómo me enteré de que mi padre pudo ser uno de los primeros, si no el primer, hacker de la historia en el edificio de Telefónica. Entendedme, “hacker”, en su esencia, significa pensar y hacer las cosas en una forma diferente a lo esperado y ya me diréis si en esta narración no es precisamente eso lo que hicieron mi padre y mi tío.

Para que os pongáis en situación, corría el año 1947, donde aún era época de posguerra en la ciudad de Madrid. Pero también ese fue un año muy importante para Telefónica, ya que fue el año de la nacionalización de la compañía, por aquel entonces conocida como CTNE (Compañía Telefónica Nacional de España). Ese año, la Compañía Telefónica Nacional de España pasaba de ser una empresa privada a ser una empresa pública.

Mi padre, que se llamaba Ángel, era un chaval de familia humilde de aquella España de postguerra con cinco hermanos. Había nacido en el madrileño barrio de Chamberí y era huérfano de madre e hijo de taxista. Y como muchas otras historias de aquellos años, comienza su carrera profesional en su querida Telefónica con solo 13 años, tras haber conseguido un puesto de trabajo como botones de ascensor en el Edificio de Telefónica.

Figura 2: Mi padre Ángel

Los botones de ascensor en aquel entonces no deben confundirse con los botones de los hoteles que hacen labores de recepción y ayuda a los huéspedes. En aquellos años, copiando el modelo económico de Estados Unidos, los botones ascensoristas eran los responsables del buen funcionamiento y mantenimiento de un ascensor, ya que las reparaciones de un ascensor tenían un coste extremadamente alto por culpa de los repuestos. Un mal uso de un ascensor que provocara una avería podría ser mucho más caro que tener un equipo de ascensoristas 24x7.

Es por eso que, en todos los edificios con ascensor como los de la ciudad de los rascacielos “New York”, se ponían en marcha con un  equipo de botones ascensoristas que sabían cómo manejar correctamente y cuidar la maquinaria. De hecho, el Edificio de Telefónica en la Gran Vía de Madrid se convirtió en el primer rascacielos de España y uno de los primeros de Europa, y fue construido por arquitectos e ingenieros americanos que había hecho otros rascacielos en New York. Es por eso que los ascensores se trataron con el mismo mimo. 

Mi padre entró a trabajar en ese edificio como ascensorista en ese precioso e histórico edificio de la compañía en la Gran Vía de Madrid, para tener cuidado de la maquinaria en el uso de los ascensores, pero también para operarlo y mantenerlo. Muchos chavales, como el caso de mi padre, comenzaron como ascensoristas y acabaron creciendo dentro de las compañías como expertos en tecnología hasta llegar a ser el CTO o el CIO de la empresa.

Uno de sus hermanos pequeños, mi tío Emilio, me contó en el transcurso de un homenaje póstumo a mi padre, desgraciadamente fallecido el pasado 6 de Abril por causas naturales, esta historia que os voy a contar a continuación, y que cuenta mucho de cómo era mi padre y cómo era la vida en aquellos años en España. Después de oír esta historia, creo que si yo estoy aquí de milagro, porque debía ser peligroso hacer ese tipo de cosas. 

Resulta que mi tío Emilio fue a buscar a mi padre Ángel un día al trabajo, cuando éste se encontraba de guardia como ascensorista. Solo que se hicieran guardias en los trabajos de ascensoristas os puede hacer ver que en aquella época, un ascensor era tan valioso como un servidor crucial de la compañía en la que se gestionan servicios críticos de la empresa. En aquel entonces, eso de meterse en uno de los ascensores del edificio más alto de Madrid debía ser lo más, así que mi padre, aprovechando algún descanso, o quizá el fin de su jornada (dado que su hermano iba a buscarle para irse a casa) le coló para dar un paseo en “su” ascensor, algo que para ellos era como ir al parque de atracciones y subir a la montaña rusa.

Figura 3: Ascensores en el Edificio Gran Vía de Telefónica

Pero claro, mi padre “señor del ascensor” en ese momento, no se iba a conformar solo con dar un paseo a su hermano pequeño, así que ni corto ni perezoso le enseñó a subirse con él encima del ascensor y cómo era capaz de manejarlo desde la maquinaria interna del ascensor. Es decir, sobre su techo. Hackear el ascensor para deslizarse por alguno de sus accesos superiores, colarse ambos por ahí, volver a medio cerrarlo y viajar de arriba a abajo de ese gran edifico sobre esa cubierta superior, entre cables, cuerdas, maromas de acero, etcétera, utilizando los controles de mantenimiento del ascensor que se encuentran fuera de la caja de pasajeros. 

Pero ahí no termina la historia. En el transcurso de alguno de estos “peculiares” viajes, se abrieron las puertas y entró en el ascensor un camarero portando lo que sería el catering de la época, incluyendo una bandeja de pequeñas ensaimadas con destino a la planta séptima, donde parece ser había algún evento social a donde se iban dirigiendo invitados, servicios, etcétera.

Imaginaos al camarero firme con la bandeja en alto. Y a mi padre y su hermano pequeño sobre el techo del ascensor observando sin ser descubiertos desde el hueco semiabierto. En aquel momento, cuando observaron el manjar, no se lo pensaron y, silenciosamente, alargaron la mano con cautela y ... zas... despistaron hábilmente cuatro estupendas mini ensaimadas de esas que a día de hoy aún se siguen poniendo en los caterings de Telefónica.

Y nadie se enteró, así que ellos se las zamparon tan alegremente sobre el techo del ascensor mientras este subía y bajaba por ese edificio de Gran Vía, haciendo que la comida de las ensaimadas tuviera el dulce sabor de haber sido “extras” y disfrutadas en la montaña rusa de la robusta mecánica de uno de los ascensores.  Escuchando esta historia, estoy seguro de Oliver Twist habría palidecido de envidia ;-) y nuestro querido Lazarillo de Tormes ya ni os digo.

Esa mentalidad “hacker” es la que le hizo probablemente aprovechar todas y cada una de las oportunidades que le fue ofreciendo su querida Telefónica, hasta conseguir ser el decano de los programadores de Telefónica en Proceso de Datos, analista de sistemas, etcétera, y de ahí hasta su jubilación, pero ya es otra historia. Un paralelismo con la historia de mi amigo Chema Alonso, que comenzó también como freelance en ese edificio, y lanzó su carrera en Telefónica con la misma mentalidad hacker que mi padre.

Telefónicos, Chema Alonso, visitantes, recordad esta historia cuando subáis en el ascensor de Gran Vía, y mirad a ver si aún quedan esas trampillas en el techo de las que te pueden robar la merienda. Si las paredes o techos de esos ascensores hablaran ..... os contarían la historia del primer hacker.

Con cariño a la memoria de mi padre,

Autor: Héctor Sánchez Montenegro

Figura 4: Contactar con Héctor Sánchez Montenegro

ATTPwn: Ejecución en Docker y nueva GUI

ATTPwn es una de nuestras herramientas en el equipo de Ideas Locas en el área CDCO de Telefónica. Estamos contentos con lo que tenemos entre manos, ya que creemos que aporta un valor a la emulación de adversarios. También sabemos que debemos seguir incorporando la implementación de técnicas de ATT&CK, ya que la gracia de todo esto está, precisamente, en ello.

Figura 1: ATTPwn: Ejecución en Docker y nueva GUI

La semana pasada presentábamos en el blog la herramienta y nos queda un mundo por contaros. Poco a poco iremos desgranando los secretos de la herramienta y, también, como vamos metiendo funcionalidades y añadiendo técnicas que mejoren las posibilidades que ofrece ATTPWn. Además, hablaremos más adelante del modo colaborativo, un modo en el que la compartición de conocimiento de técnicas ofensivas es una realidad.

Figura 2: ATTPwn en GitHub

Hoy quería mostrar algo que me gusta mucho y es la posibilidad de dockerizar el proyecto para unas pruebas rápidas. En el mundo de la seguridad probamos y utilizamos muchas herramientas y, en muchas ocasiones, es un quebradero de cabeza el tener que instalar dependencias, librerías, otros binarios, etcétera. En el caso de ATTPwn no debería ser muy complejo ya que con un: “pip install -r requirements.txt” debería valernos.

Figura 3: Libro de Docker: SecDevOps
de Fran Ramirez y Rafael Troncoso

Sea como sea, hemos decidido ‘dockerizar’ el proyecto, tal como puede verse en el Github. Las instrucciones para desplegar el proyecto, generando una imagen y, posteriormente, un contenedor son dos. En primer lugar, generamos la imagen y metemos todo lo necesario con docker build. La instrucción es la siguiente y es opcional usar :versionX si queremos llevar un control de la versión que utilizamos.

docker build . -t attpwn[:versionX]

La segunda instrucción ya nos permitirá levantar el contenedor. Si estás en modo probar el proyecto y no quieres que nada de lo que hagas persista, puedes ejecutar la instrucción:

docker run –rm -d -p X:5000 IMAGE_ID | TAG

En esa instrucción “--rm” indica que cuando se pare el contenedor éste se destruirá, “-d” indica que entramos en modo “dettach”, la variable X indica el puerto de la máquina anfitriona con la que quieres mapear el 5000 del contenedor y, por último, IMAGE_ID o TAG, si quieres referenciar a la imagen a través de su ID (visible ejecutando docker images) o por el tag que le has puesto al utilizar la instrucción docker build, con el formato “repository:tag”.

Figura 4: Instrucciones para dockerizar ATTPwn

Como comenté anteriormente, con la instrucción “docker images” puedes ver las imágenes construidas y que están disponibles para utilizarse. 

Figura 5: Imágenes con TAG

En la imagen de la Figura 5 podemos ver diferentes imágenes y vemos dos de ATTPwn, las cuales son diferentes versiones. El TAG ayuda a poder identificarlas claramente.

Nueva GUI y ejemplo

Ahora mismo, como novedad, estamos trabajando en una nueva interfaz gráfica que podamos tener en el proyecto de cara a la BlackHat USA 2020 y hoy mostraremos un poco de lo que tenemos.

Figura 7: Nuevo GUI para ATTPwn

Si vemos el paper de ATTPwn  podemos ver que la antigua GUI tiene el mismo flujo que la anterior. Las mejoras vienen dadas en su aspecto y en la experiencia del usuario, en ciertos aspectos.

Figura 8: Información de un Warrior

Como se puede ver en el ejemplo, éstas son las nuevas tarjetas disponibles, aunque aún pueden cambiar en algún detalle. Cuando seleccionamos una amenaza, y como veréis en el vídeo de más adelante, podemos seleccionar las técnicas a utilizar y comprobar si han tenido éxito o no.

Figura 9: Control del módulo de Adversary Emulation

En la vista de resultados, tenemos dos posibilidades: una vista ejecutiva que muestra el estado de las tareas/técnicas y si el resultado es satisfactorio o no y una segunda vista técnica en la que se muestra el detalle de la ejecución y se puede ir observando el “datastore”.

Figura 10: Control del flujo de emulaciones

El “datastore” es una pequeña base de datos dónde se almacenan los elementos, como direcciones IP, puertos, usuarios, hashes, etcétera, que pueden ser utilizados por una técnica posteriormente dentro de la misma amenaza. Creemos que eso es una de los valores añadidos de ATTPwn, ya que permite que una amenaza vaya aprendiendo con la ejecución de técnicas y pueda aprovechar las técnicas posteriores en su máximo esplendor.

Figura 11: Demo de ATTPwn 

Aquí os dejo un vídeo en el que primero se ve la nueva GUI y la configuración de una amenaza basándonos en técnicas. Es una amenaza personalizada, aunque podemos tomar amenazas “de ejemplo” cómo se puede ver en el vídeo.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 12: Contactar con Pablo González

Mi primera experiencia arreglando una red de ordenadores como freelance con 21 o 22 años

Durante mis años mozos, cuando aún comenzaba a trabar en el mundo de la informática y hacía un poco de todo, me pasó una historia que marcaría el futuro de mi trabajo en el mundo de la consultoría Troubleshooting. Ese tipo de trabajos en los que te llaman porque hay un problema que no han sabido solucionar y te toca descifrar a ti. 

Figura 1: Mi primera experiencia arreglando una red
de ordenadores como freelance con 21 o 22 años

Tengo muchas historias curiosas de mis consultorías tecnológicas, y reconozco que son súper interesantes, porque aprendes mucho, y descubres cómo cuantos más conocimientos tengas de todo, más fácil, y más rápido se encuentra el problema. Al final, es como resolver un puzzle y es divertido. 

Los que han trabajado en soporte resolviendo casos saben bien a lo que me refiero, porque es como descifrar un misterio en cada uno de los expedientes que además aportan dos cosas a tu vida. La primera es que te dejan la satisfacción de resolver un misterio y la segunda es que siempre te enseñan algo. Se nota mucho las personas que han tenido que hacer este tipo de trabajo y la que siempre ha estado en el lado del Power Point o el púlpito de los blogs y las RRSS. 

El caso que os voy a contar no es extremadamente complejo para nada, pero sí que es significativo por lo joven que era yo, lo que aprendí de aquella noche, y lo que le enseñó al dueño de la empresa que me llamó sobre lo que es la tecnología. Desde entonces, cuando he ido a resolver un problema gordo – y he tenido algunos muy jodidos con servidores de correo electrónicos de Exchange que no echaban e-mails a los buzones o una infraestructura de VPNs con servidores CISCO en cluster que daban conectividad a un FireWall-ONE que había que migrar y que dejaron de levantarse paralizando una multinacional -, siempre he aplicado lo que aprendí esa noche. 

Después de esta larga introducción – recuerda que estás leyendo un blog y la lírica, la estética y la narrativa son importantes – os pongo en situación. Yo tendría 21 o 22 años, y comenzaba a trabajar haciendo pequeñas cosas con los ordenadores. Sería el año 1996-1997, y me llamaron para ir un domingo a las 22:00 de la noche a una dirección de una empresa en la ciudad de Fuenlabrada, porque tenían un problema con la red. 

En aquellos momentos las redes de las PyMes podían ser redes en MS/DOS con servidores Novell Netware, redes con Windows NT 3.51 o 4 y puestos de trabajo de todo tipo de Windows, o incluso redes de trabajo en grupo con Windows 3.11 o 95. Y los cableados podían ser coaxial o RJ45 con algún HUB o Switch. Y luego algún router de conexión a Internet, o un modem con la conexión compartida por medio de algún Proxy (Web y Socks), y luego un poco NetBEUI con su sistema de nombres NetBIOS, TCP/IP o IPX. Y todo lo que yo tenía es… .que la red no funcionaba. 

Cuando iba hacia el sitio me sentía como yendo al matadero. No os tengo que explicar que no llevaba mucho tiempo trabajando, así que no tenía mucha experiencia. Estaba seguro que aquel error, fuera el que fuera, iba a encontrármelo por primera vez en mi vida. Seguro. Así que iba con más miedo que vergüenza. 

Cuando llegué allí me esperaba en una especie de casa-chalet reconvertida a oficina el dueño de la empresa muy nervioso. Estaba atacado, porque según él tenía que trabajar el lunes y la red no funcionaba, y los equipos no podían acceder al servidor Novell Netware (horror), para ver los documentos, así que yo era su última esperanza. 

Acojonado estaba. 

Me dijo que los técnicos habían montado la red, habían dejado todo funcionando, que apagaron los ordenadores, y que cuando los encendieron nada estaba bien y no se podía acceder a ningún documento. Y me dejó la red a mí para que la arreglara: “¿Por dónde quieres empezar?” 

Ni puta idea de qué coño podía haber pasado. ¿Tenía que repasar todo paso por paso? Pues sí. Con la información que tenía no había mucho más, y aquello prometía ser una noche larga para aprender a configurar un servidor Novell Netware en detalle. Así que me dieron ganas de empezar a llorar y salir de allí corriendo… pero… ¿Y si no era tan complicado? 

Según el dueño de la empresa lo habían dejado todo funcionando, así que era alguna cosa que había desconfigurado la red. Solo había que averigüar qué. Además, hacía no mucho tiempo el tener paciencia y aprender cómo funcionaban las cosas logró que me dieran el voluntariado en mi instituto por arreglar el sistema de notas y conseguir que las actas se entregaran a tiempo con solo seguir los pasos de un .BAT. Había que intentarlo. 

Encendió el servidor de Novell Netware… y todo arrancó bien. Encendió uno de los equipos, abrió el Word Perfect para abrir uno de los documentos y… el documento no estaba disponible. ¿Qué podría estar pasando? ¿Sería un problema de seguridad con permisos sobre los documentos? ¿Sería un problema de red? ¿Y si es de red sería de configuración o de conexión? 

Como os podéis imaginar, mi primera reacción fue toquetear todos los protocolos de red para ver cuáles eran los que se estaban utilizando en esa red y cómo estaban configurados. En esos entornos se daban casos muy divertidos donde se conectaba a Novell Netware por IPX, pero entre los equipos de la misma red se utilizaba NetBEUI, pero si salían a Internet por un Proxy se hacía por TCP/IP. 

Así que entré a ver la configuración de la pila de protocolos en el cliente para tomar datos de cómo estaba montado, pero no toqué nada. Esto es algo que aprendí ese día porque si lo hubiera hecho la abría liado gorda, y que desde entonces he aplicado. Como los médicos, se opera solo cuando se sabe qué hay que operar, mientras tanto solo se hacen pruebas y se toman datos del paciente. 

Figura 2: Libro de Ataques en redes de datos IPv4 & IPv6 3ª Edición

Yo sabía entonces de redes bastante, pero aún estaba lejos de saber que un día iba a acabar escribiendo el libro de Ataques en redes de datos IPv4&IPv6 con todos los ataques de IPv6, y los ataques con servidores Proxy, etcétera. Aún me quedaba para empezar a tomarme en serio la Seguridad Informática y el Hacking,  pero me había puesto mucho las pilas después de la entrevista de trabajo que me habían hecho un tiempo atrás en la que fui incapaz de contestar una respuesta coherente de redes.

Los protocolos parecían bien, pero no había red, así que el problema debía ser físico. Por supuesto, mis conocimientos de redes me decían que estaban las cosas bien configuradas, y entendía para que se usaba el protocolo IPX, para qué TCP/IP, por qué había un Proxy configurado en TCP/IP y por qué había un protocolo llamado NetBEUI hay funcionando en el stack, así que decidí buscar el error en otro sitio. Me fui al equipo que hacía de servidor Proxy para conectarse a Internet y navegué a una página desde él, el modem y la conexión a Internet funcionaba. Así que ahora podía probar los mensajes de error de TCP/IP conectándome al Proxy desde el equipo con Word Perfect. El error era “Network Error”.

Al final, el cliente con Word Perfect se quería conectar al servidor de ficheros Novell Netware y lo haría por IPX, pero quería saber si el medio físico estaba funcionando, y para eso el mejor protocolo era TCP/IP que los mensajes de error de NetBEUI, si has trabajado con él, eran confusos.

Pues nada, a ver qué cable tenía mala conexión en la red, que estaba en BUS con cable coaxial. No había HUB, RJ-45 o Swich. Un BUS en coaxial como medio físico. Pues nada a revisar cables, T’s y ver cuál estaba mal. De nuevo, organicé unas pruebas muy sencillas.

Saqué un tapón terminador de mi mochila - por supuesto, siempre llevaba varios porque daba clases en aulas en red y eran propensos a "desaparecer" - y acorté la red al servidor Proxy y al siguiente equipo del BUS. Para ello solo había que sacar el cable que llevaba al equipo 3 y puse el tapón. Reinicié el equipo, y mágicamente navegó por Internet.

Ale, resuelto el misterio. Ahora… ¿cuál era el cable, la tarjeta o la T que fallaba? Podría haber tardado una horita o dos buscando el punto de ruptura, pero en ese momento el empresario me dio una pista al preguntarme:

- “¿Para qué es ese tapón?”

Hoy en día, cualquier pregunta así hecha en un entorno de troubleshooting es una pista que no debes dejar escapar.

- “Pues es donde rebota la señal y es necesario que haya uno al final de cada extremo. ¿Me enseñas donde está el otro extremo de la red?”

Tras hablar un poco, y entender lo que yo quería, me llevó al último equipo y allí estaba el misterio. Había un cable que no tenía T y que se conectaba directamente a la salida coaxial de la tarjeta de red. Lo miré, y le dije:

- “Si esto ha estado así es imposible que esta red haya funcionado cuando se fueron los técnicos”.

Entonces el hombre dudó, sudó un poco, y me dijo:

- “Es que este equipo estaba en otro sitio y tuvimos que hacer un cable más largo, y llamé a un vecino que era electricista y me hizo este cable que es más largo y lo conecté yo. Pensé que la T era como un ladrón de enchufes, y pensé que, como no iba a enchufar más equipos… pues mejor que sin T”.

Lo miré y le dije:

- “… y tapón. La T es solo importante porque hay que poner el tapón.”

Resolví el misterio. El hombre se pudo muy contento y me pago – poquísimo, porque me pagó solo por el tiempo -, pero aprendí mucho. Primero cogí confianza en lo que sabía. Me di cuenta de que las cosas que había aprendido se podían aplicar. Saber configurar los drivers en un sistema operativo, conocer los protocolos de red, el hardware y el software, te eran útiles en esos momentos.

También aprendí que no debía tocar nada hasta tener toda la información, y que en este caso, el hombre del problema no estaba dando todos los datos porque él no los consideraba importantes. Pero el único que en ese momento tenía criterio para saber si eran útiles o no era yo. A pesar de ser un joven veinteañero.

Desde entonces aprendí que en un proceso de troubleshooting necesitas muchos datos antes de tocar nada, así que aprendí a preguntar mucho, anotar la pregunta y las respuestas, y probar una a una todas las hipótesis para descartar cosas, una a una. Encontrar el tornillo que hay que apretar exige haber hecho mucho trabajo antes.

Figura 3: El libro de "Wardog y el mundo", nuestro querido BOFH
(Bastard Operator From Hell) escrito por el propio Wardog

Para mí fue una buena experiencia de aprendizaje y creo que para todos los que hacemos tecnología, entender en detalle cómo funcionan cosas a bajo nivel es crucial. Y la gente que ha pasado por soporte en las empresas o ha hecho consultoría de Troubleshooting… tiene mi mayor respeto, por eso creo que me gusta tanto, tanto, tanto el libro de Wardog y El Mundo. Los Bastard Operators from Hell han tocado mucho troubleshooting lidiando con falta de información de los usuarios.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Amigos, profesionales, bloggers, podcasts y CONs de Hacking en MyPublicInbox #MyPublicInbox @mypublicinbox1

Hoy sábado aprovecho para haceros una actualización de cómo está avanzando el proyecto de MyPublicInbox en su mes número 9 de vida, donde el número de usuarios no para de crecer. Esto nos hace muy felices, pero sobre todo nos hace ilusión ver la cantidad de conexiones respetuosas con el los perfiles públicos de la plataforma que se están produciendo. El movimiento de Tempos crece de una manera muy acelerada y mola ver que para la gente es útil.

Figura 1: Amigos, profesionales, bloggers, podcasts y CONs de Hacking en MyPublicInbox

No os puedo compartir aún muchos detalles, porque estamos en medio de un proceso de aceleración, pero sí que cuando vemos cómo la gente está utilizando la plataforma, vemos que la curva crece día a día en estos nueve meses dejando una senda de crecimiento que nos impacta bastante. Os dejaré más datos en breve que merece la pena analizarlo.

Figura 2: Contactar con Ferran Adrià

Y mientras tanto, más amigos, profesionales y organizaciones como las las CONs de Hacking, blogs & bloggers, o podcasters pasan a tener su buzón público de contacto a través de MyPublicInbox. Hoy os traigo algunos de los que se han abierto un canal de contacto público en el servicio, pero puedes ver a los más destacados por categorías en la web de Perfiles Públicos Destacados.

Figura 3: Contactar con Rudy Fernández

Entre ellos, últimamente hemos abierto cuenta a gran Ferran Adrià, a nuestro campeón del mundo de baloncesto Rudy Fernández o al único e inigualable David Broncano, pero también se han dado de alta muchas otras profesionales que puedes ver en la categoría de Música, de Criptomonedas, Comunicación,  Escritores o Cine, por poneros algunos ejemplos de las categorías que puedes revisar.

Figura 4: Contactar con David Broncano

En nuestro caso, hemos hecho unas secciones especiales para los que disfrutáis de las seguridad informática y el hacking, como son las sección de CONs-Hacking para que podáis contactar con las organizaciones y organizadores de eventos de hacking y tener información directa de cómo comenzar en este mundo, de cómo participar en sus eventos, como colaborar o cómo ser uno de los patrocinadores de sus actos.

Figura 5: Perfiles Públicos Destacados en Categoría de Blogs

Lo mismo con las sección de periodistas y la sección de bloggers. Si tienes un trabajo y quieres darle visibilidad. Si te gustaría publicar un post en El lado del mal, en HackPlayers, Flu-Project, Cyberhades, etcétera, puedes contactar con ellos a través de la plataforma de forma respetuosa.

Figura 6: Perfiles Públicos Destacados en Categoría CONS-Hacking

Y también para tener contacto con podcats, con escritores de libros, con gente del mundo de la radio, profesionales de la televisión, presentadores, etcétera. Una familia cada vez más grande en MyPublicInbox a la que puedes contactar de manera respetuosa con su tiempo.

Figura 7: Perfiles Públicos Destacados en Categoría Periodistas

Por último, para los que tienen un buzón - si quieres ser un Perfil Público y tener tu buzón tienes información en la web - desarrollamos una serie de servicios para ayudar a todos los que estén en la plataforma a mejorar la experiencia de usar Internet para desarrollar más y mejor su actividad profesional, como ya os dejé en el otro artículo.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Protocolos utilizados en Sistemas de Control Industrial: Desde sus inicios hasta la Raspberry Pi (Parte 1 de 2)

Desde mediados del Siglo XVIII, época en la que dio comienzo la revolución industrial, el ser humano ha basado gran parte de su economía en la industria. Con la llegada de las máquinas de vapor y los nuevos avances se logró optimizar la producción en el campo y desarrollar maquinas como los barcos de vapor o el ferrocarril para prescindir del esfuerzo de los trabajadores. 

Figura 1: Protocolos utilizados en Sistemas de Control Industrial:
Desde sus inicios hasta la Raspberry Pi (Parte 1 de 2)

Años después aparecieron los motores de combustión interna y la energía eléctrica, con la que se iluminaron las calles y lo que supuso un antes y un después en la historia de la humanidad. Sin embargo, no sería hasta 1908 cuando llegaría el invento que revolucionaria la industria parta siempre, la cadena de montaje. 

Figura 2: Cadena de montaje en Ford

Con este nuevo sistema de producción diseñado por Henry Ford (basado en ideas Tayloristas) se logró reducir los costes y acelerar la producción del Ford modelo T. Aunque este nuevo proceso de producción no tardase en dar lugar a numerosas huelgas por las condiciones y los salarios de los trabajadores ha ido evolucionando hasta la actualidad llegando a convertirse en la piedra angular de distintos sectores de la industria. 

Figura 3: Jerarquía de control de sistemas

Durante los comienzos de la industria las máquinas utilizadas en las cadenas de producción estaban basadas en la mecánica y la neumática. Gracias a los grandes avances del ultimo siglo, sobre todo en el campo de la electrónica, informática y robótica ahora es posible automatizar la inmensa mayoría de estos procesos de producción. Aquí es donde entran los protocolos de comunicación industrial, a continuación, os explicaremos que son, cómo funcionan y en qué consisten algunos de los protocolos de comunicación más utilizados en la actualidad. 

Protocolos de Comunicación Industrial 

Los protocolos de comunicación son esencia un conjunto de reglas que permiten la transferencia e intercambio de datos entre los distintos dispositivos que forman parte de una red. Y estos son un punto fundamental en la seguridad de todo el proceso, y por eso es tan importante entender bien cómo se auditan y fortifican en sistemas de control industrial e infraestructuras críticas, como hemos visto en el caso de Ripple20.

Figura 4: Libro Infraestructuras Críticas y Sistemas Industriales:
Auditoría de Seguridad y Fortificación de Juan Francisco Bolivar

Al igual que las cadenas de producción estos protocolos han ido evolucionando con los años y con la llegada de microprocesadores cada vez más potentes. Una practica bastante común entre las empresas de nuestro país es el uso de células de trabajo individuales (sin comunicación entre sí). Cada una de estas células tiene una función concreta, pero forman parte de un mismo proceso de producción, esto hace imprescindible que haya un sistema de comunicación con el que coordinar el trabajo de las distintas células.

Figura 5: Estructura de una red de control con PLCs, actuadores y sensores

En la escala mas baja de este sistema de comunicación podemos encontrar los buses de campo, estos son sistemas de comunicación (o control) que simplifican enormemente los procesos de instalación y operación de máquinas y otros equipos como PLC´s, transductores, actuadores y sensores utilizados habitualmente en los distintos procesos de producción.

Desde hace varios años se ha trabajado en el desarrollo de un sistema de comunicación industrial universal con el que sea posible controlar todos estos dispositivos, sin embargo, no ha sido posible hasta la fecha. Los protocolos de control industrial mas conocidos son los siguientes:

Protocolo HART

Este protocolo se caracteriza por reunir información en formato digital a través de una señal analógica comprendida entre los 4 y los 20 miliamperios en corriente continua. La señal digital utiliza las frecuencias individuales de 1200 y 2200 hertzios que se asocian a los dígitos 1 y 0 (sistema binario) y que en conjunto crean una onda sinusoidal que se superpone al flujo de la corriente.

Como la seña promedio de este tipo de ondas es 0 no existe ningún elemento que interfiera con la señal analógica de 4-20 mA y es posible seguir utilizando la variación analógica para controlar el proceso.

Protocolo MODBUS:

Este es probablemente el protocolo más conocido de los que os hablaremos hoy, permite el control y supervisión de procesos SCADA (con control centralizado). Es capaz de recoger datos e información de distintos dispositivos como sensores de presión o humedad y comunicar los resultados a un ordenador. Cada dispositivo de la red cuenta con una dirección única para facilitar su identificación, a pesar de que en la red Modbus cualquier dispositivo pueda enviar ordenes lo habitual es que haya un dispositivo maestro que se encarga de dirigir a los demás dispositivos enviándoles ordenes concretas. 

Figura 6: Protocolo Modbus

Existen distintas versiones de este protocolo para puerto serie y ethernet (Modbus/TCP) y existe una gran variedad de módems compatibles con este protocolo además de algunas implementaciones para realizar conexiones Wireless (como en el caso de la Raspberry Pi, caso practico del que os hablaremos en la segunda parte de esta serie de artículos).

PROFIBUS (Process Field Bus):

En este caso no encontramos frente a un estándar de comunicaciones de alta velocidad para bus de campo, fue desarrollado por varias empresas alemanas a finales de los 80 (entre las que se encuentras Bosch o Siemens). Este protocolo cuenta con tres variantes:

+Profibus DP-V0: enfocado a sensores o actuadores que están conectados a un procesador o terminal. 

+Profibus DP-V1: enfocado la comunicación acíclica de datos, orientada a transferencia de parámetros, es muy utilizado en la industria química.

+Profibus DP-V2: enfocado a la comunicación entre aplicaciones mas complejas, como las células de proceso o dispositivos de automatización.

FF (Foundation Fieldbus):

Este es un protocolo de comunicación digital y de dos vías enfocado a la automatización de procesos y cuenta con dos variaciones:

+Fieldbus H1: proporciona alimentación y comunicación entre el host y los instrumentos de campo a través de cableado. Trabaja a una velocidad de 31,25 kbit/seg.

+Fieldbus HSE: Proporciona únicamente comunicación a sistemas que utilizan cableado ethernet estándar. Trabaja a una velocidad de 100 kbit/seg.

Figura 7: FieldBus

DEVICENET:

Por último os hablamos de Devicenet, este protocolo se utiliza habitualmente en el sector de la automatización para el intercambio de información entre dispositivos de control. A pesar de estar diseñado para conectar dispositivos en una red de bajo nivel también puede utilizarse para conectar algunos controladores o PLC´s de alto nivel. Su característica principal es que proporciona información adicional acerca del estado de la red en la que está desplegado (al igual que el sistema CAN Bus).

Ahora que ya sabes un poco mas acerca de los protocolos de control industrial te invitamos a que sigas la segunda parte de esta serie de artículos en la que explicaremos cómo es posible implementar algunos de estos protocolos en algunos dispositivos como la Raspberry Pi. Nos vemos en la segunda parte.

Autor: Sergio Sancho Azcoitia, Security Researcher en el equipo de Ideas Locas de CDCO

Cursos en Julio de @HackBySecurity con libros de @0xWord y Tempos de @MyPublicInbox1

En breve llegamos al mes de Julio, donde se van a realizar tres Cursos Online de HackBySecurity que comienzan el día 6, 13  20 de Julio para los que queráis formaros en Ethical Hacking, Pentesting y Seguridad en Cloud, y Creación de Exploits, disciplinas muy demandadas hoy en día en el mercado laboral, como ya sabes si estás leyendo este blog.

Figura 1: Cursos en Julio de HackBySecurity
con libros de 0xWord y Tempos de MyPublicInbox

Estos tres cursos, tienen un descuento de verano con el cupón VERANO50 que si lo utilizas te dará un 50% de descuento, y llevan incluidos cada uno de ellos un libro de 0xWord, y 200 Tempos de MyPublicInbox.com para todos los alumnos, que se entregarán nada más registrarse en el curso.

Figura 2: Contactar con Miguel Ángel Martín Peña, CEO de Hack By Security

Con esos Tempos puedes contactar con los profesores de los cursos una vez terminada la formación para preguntar dudas más adelante, o para contactar con cualquiera de los perfiles públicos que tienes en la plataforma, donde tienes hackers, expertos en seguridad informática, y personas relevantes. Las formaciones que tienes en Julio son:

- CSIO (Curso de Seguridad Informatica Ofensiva) : A partir del 6 de Julio da comienzo en este curso online de seguridad informática ofensiva donde el alumno adquirirá los conocimientos y habilidades necesarias para realizar pruebas de penetración y auditorías de seguridad informática pudiendo llegar a desempeñar puesto como el de hacker ético, pentester o auditor de ciberseguridad. Se le introducirán desde los conceptos de hacking básicos hasta la creación de sus propios exploits, pasando por las técnicas de ataque y herramientas más avanzadas y efectivas.

Figura 3: Curso Online de Seguridad Informática Ofensiva

Además, el alumno tendrá como complemento del mismo el libro de Metasploit para Pentesters Gold Edition. Este Curso Online de Seguridad Informática Ofensiva en HackBySecurity es una de las mejores opciones si lo que estás es buscando formarte profesionalmente para trabajar de pentester, y además quieres un modelo flexible de formación. 

Figura 4: Metasploit para Pentesters Gold Edition

- CNCC (Ciberseguridad  y Normativa en Cloud Computing): El 13 de Julio da comienzo este curso, centrado en formar profesionales que sepan de seguridad en entornos de Cloud Computing. La computación en la nube ofrece inmensos beneficios potenciales en agilidad, flexibilidad y economía. Las organizaciones pueden moverse más rápido (ya que no tienen que comprar y aprovisionar hardware, y todo está definido por software), reducir el tiempo de inactividad (gracias a la elasticidad inherente y a otras características de la nube), y ahorrar dinero (debido a la reducción de los gastos de capital y una mejor vinculación entre la demanda y capacidad).  

Figura 5: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

El objetivo de este curso es proporcionar un lenguaje común y la comprensión de la computación en la nube para profesionales de la seguridad, destacando las diferencias entre la nube y la computación tradicional, y ayudar a orientar a los profesionales de seguridad hacia un enfoque de la adopción de la nube nativa que resulten en una mejor seguridad (y esos otros beneficios), en lugar de crear más riesgos. Todos los asistentes recibirán el libro de Cifrado de las Comunicacione Digitales: De la cifra clásica a RSA 2ª Edición

- CSCE (Curso de Seguridad de Creación de Exploits) El próximo 20 de Julio da comienzo un curso de nivel intermedio en el que se va a explicar cómo construir exploits para vulnerabilidades localizadas. Es decir, cómo weaponizar vulnerabilidades descubiertas, así que es un curso de nivel intermedio ya que debes tener conocimientos previos de pentesting para saber cómo funciona los bugs, los exploits y la automatización de la explotación de vulnerabilidades.

 

Figura 6: Curso de Seguridad de Creación de Exploits

 

Este libro lleva como material de estudio y acompañamiento el libro de Linux Exploiting de 0xWord donde se explican las metodologías de descubrimiento y explotación de vulnerabilidades en sistemas GNU/Linux.

Figura 7: Linux Exploiting de 0xWord

Estas tres formaciones te ayudarán a ponerte al día para entrar al mercado laboral en el área de seguridad informática, una de las profesiones más demandadas hoy en día, y además así podrás sacar el máximo de este verano de "Nueva Normalidad", donde estar muy preparado es fundamental para el futuro profesional.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Ripple20: Serios fallos de seguridad en el mundo de los Sistemas Industriales e Infraestructuras Críticas

Hace más de dos décadas que existe una empresa de software llamada Treck Inc., de la cual posiblemente nunca has oído hablar pero posiblemente alguno de sus productos estén implementados en los dispositivos que utiliza tu empresa u organización. Esta compañía, centrada sobre todo en el desarrollo de librerías para la implementación a bajo nivel de la pila de protocolos TCP/IP, basa todo éxito en el desarrollo de frameworks para todo tipo de dispositivos IoT.

Figura 1: Ripple20: Serios fallos de seguridad en el mundo de los
Sistemas Industriales e Infraestructuras Críticas

El éxito de su producto es tal que grandes fabricantes de de “aparatos” como, por ejemplo, impresoras, todo tipo de dispositivos industriales, SmartHome, dispositivos para entornos médicos, etcétera, llevan años utilizándolo. Y no es para menos, ya que sus librerías facilitan muchísimo el trabajo de del desarrollador a la hora de conectar cualquier dispositivo a la red de redes.

Figura 2: Libro Infraestructuras Críticas y Sistemas Industriales:
Auditoría de Seguridad y Fortificación de Juan Francisco Bolivar

Es casi imposible rastrear el número real de fabricantes de hardware IoT que han comprado y/o utilizado las librerías de pila TCP/IP de Treck. Ya sea por la gran cantidad de clientes o simplemente porque algunas empresas directamente fueron compradas por otras, su número es difícil de cuantificar. Lo que está claro es que son compañías entre las que podemos encontrar a HP, Intel, Schneider Electric, Caterpillar, etcétera (sólo por nombrar algunas de las más conocidas) que han vendido sus productos con dichas librerías implementadas, a otras que incluso tienen Infraestructuras Críticas (como Transporte, Energía, Hospitales, etcétera) como clientes.

Figura 3: Juan Francisco Bolivar, especialista en Seguridad de
Sistemas Industriales e Infraestructuras Críticas

Como cualquier dispositivo IoT, tenga la función que tenga, necesitará conexión a la red de algún tipo, esta librería se ha hecho tremendamente popular. Por cierto, si quieres saber y entender el mundo de la seguridad IoT de las Infraestructuras Críticas, no puedes perderte el libro de uno de los buenos expertos en la seguridad de ellas, Juan Francisco Bolivar, llamado “Infraestructuras críticas y sistemas industriales: Auditorías de seguridad y fortificación”, de la editorial 0xWord. 

OWASP no falla … 

Antes de entrar en materia sobre qué ha ocurrido con esta empresa o más bien con el producto que desarrolla, vamos a echar un vistazo al OWASP TOP 10 de aplicaciones y de APIs. Todos conocemos estos listados de OWASP los cuales nos permiten tener una visión de los mayores problemas de seguridad web orientados a desarrolladores.

En los puestos 6 y 7 respectivamente, podemos encontrar el término “Security Misconfiguration” el cual describe los problemas relacionados con la configuración insuficiente de seguridad (o la no actualización de los mismos entre otros) y en el OWASP Top 10 de aplicaciones, en el puesto número 9 podemos encontrar otra vulnerabilidad que definen como “Using componentes with known vulnerabilities” (utilizar componentes con vulnerabilidades conocidas).

Figura 4: Sectores Industriales afectados por Ripple20

Todas tienen algo en común, y es el que creador de la aplicación o dispositivo, por mucho esfuerzo que haya puesto en programar código seguro para su programa, si utiliza una librería, framework, sistema operativo, etcétera, que tenga vulnerabilidades (presentes o futuras por no actualizar el código), todo el esfuerzo por securizar nuestro producto se irá al traste.

¿Qué es Ripple20?

Pues esto es justo lo que ha ocurrido con Ripple20 (ripple significa “onda” y debido a que puede afectar a toda la “supply chain” o cadena de suministro, le han dado este nombre) en el que el mundo de la Ciberseguridad y del IoT están aún asimilando cómo enfrentarse a las 19 vulnerabilidades que pueden llegar a afectar a millones de dispositivos repartidos todo el mundo. La empresa JSOF ha descubierto estos zero-days en la librería de la pila TPC/IP de Treck, incluyendo algunos con los temidos ataques tipo RCE.


Figura 5: ElevenPaths Radio "Actualidad": Asegurando la Cadena de Suministros
Todavía no se saben todos los detalles técnicos en profundidad ya que lo presentarán en la próxima edición de BlackHat USA (donde por cierto también estaremos nosotros en la sección Arsenal, presentando ATTPWN). De las vulnerabilidades encontradas, 4 son críticas que incluyen RCE (con una puntuación CVSS mayor o igual a 9), otras 4 tienen una puntuación CVSS mayor o igual a 7, finalmente 11 con menor impacto donde se pueden encontrar security leaks (fugas de información) y DoS, entre otros.

Un ejemplo, el CVE-2020-11896
Este CVE-2020-11896 sirve para etiquetar una vulnerabilidad crítica en la librería Treck que permite RCE realizado por un atacante que pueda enviar paquetes UDP a un puerto abierto del dispositivo objetivo (por cierto, con una puntuación de CVSS de 10, la máxima). Para que este ataque tenga efecto, es necesario que el dispositivo soporte fragmentación IP con tunneling.

Figura 6: Libro de "Ataques en redes de datos IPv4 & iPv6" 3ª Ed
 en 0xWord, de Chema Alonso, Pablo González y Juan Luis Rambla.

A pesar de todo, si este dispositivo no cumpliera estos requisitos, sería posible realizar en su lugar un ataque DoS. En general, lo que ocurre es que la pila TCP/IP de la librería de Treck no gestiona correctamente los fragmentos IPv4 sobre un túnel IP-in-IP. Esto permitiría que un atacante (sin autenticar) pudiera obtener acceso a información localizada en el heap de la memoria.

Figura 7: Digi Connect ME 9210 utilizado en las pruebas

En el paper publicado por JSOF se ofrece en detalle la raíz teórica de esta vulnerabilidad y su funcionamiento. Para explotarla han utilizado un dispositivo Digi Connect ME 9210 para implementar la PoC del RCE. Este dispositivo tiene la forma de un conector RJ-45 pero es realmente un sistema ultra compacto que incluye CPU, un sistema operativo (Linux) y las librerías Treck de la pila TCP/IP.

Figura 8: Papper de Ripple20

El resto de las vulnerabilidades más importantes son:

• CVE-2020-11897 - CVSSv3 score: 10 - Similar a la vulnerabilidad 11896 solo que esta vez utilizando la misma técnica con paquetes IPv6.

• CVE-2020-11898 - CVSSv3 score: 9.8 - Manejo impropio de la longitud de los parámetros de inconsistencia en IPv4/ICMPv4 podría exponer información sensible.

• CVE-2020-11899 - CVSSv3 score: 9.8 - Validación impropia en IPv6 cuando se está gestionando un paquete enviado por un atacante en la red no autorizado, la cual puede exponer información sensible.

¿Cómo se solucionan?
JSOF ha estado trabajando con varias organizaciones como CERT/CC, CISA y la FDA entre otras, para ver cómo solucionar este problema realizando un parcheo o actualización de software. La misma empresa Treck ha creado varios parches de seguridad para solucionar este problema, pero aquí nos encontramos con otra problemática, y es el acceso a dichos dispositivos IoT. 

Algunos dispositivos IoT no son fáciles de actualizar, ya sea por su peculiaridad configuración de hardware específico, relevancia en la infraestructura (no se pueden apagar o reiniciar tan fácilmente) o simplemente porque llevan tanto tiempo si actualizarse que la nueva actualización puede dejar inoperativo al aparato en sí (incompatibilidad). En estos casos sólo resta minimizar la amenaza de alguna forma externa.

Figura 9: Sala de control "vintage" de una Central Nuclear sovietica

Para mitigar este problema de seguridad el primer paso debe de ser buscar y catalogar aquellos dispositivos que estén afectados por alguna de estas vulnerabilidades. El siguiente paso será actualizar siempre que sea posible el dispositivo con los parches publicados por Treck. En caso de no ser posible, la solución será segmentar, aislar y sobre todo controlar todo el acceso de red desde y hacia el dispositivo vulnerable, para detectar posibles ataques. 

Pero una cosa es segura, si un atacante es capaz de acceder a este dispositivo, ya sea desde la red local o desde Internet, el primer problema lo tienes en la seguridad de tu arquitectura permitiendo que este usuario pueda alcanzar dicho aparato.

¿Es tan preocupante?
Las vulnerabilidades Ripple20 son importantes, muy importantes, pero hay también que rebajar un poco la alarma y mirar con perspectiva. No es la primera vez que vemos un titular de este tipo que muestra un escenario apocalíptico. Ya nos pasó por ejemplo con Meltdown y Spectre y aquí seguimos todos trabajando sin problema (aunque es cierto que el problema de estas vulnerabilidades era su muy difícil implementación, en el caso de Ripple20 parece que es más sencilla de implementar).

Por lo tanto, precaución, seguir los pasos recomendados por el fabricante para parchear los dispositivos (siempre que se pueda) y calma, mucha calma. Para poder explotar alguna de estas vulnerabilidades el atacante necesita una conexión directa con el dispositivo afectado o con una ruta creada desde Internet hacia otra interna y de aquí al dispositivo.

Por lo tanto, otro de los pasos a ejecutar tiene que ser detectar cuáles de estos dispositivos tiene conexión a Internet, y una forma sencilla si usamos SHODAN buscando la cadena “Treck” (aunque afinando más por modelos, características y usando la API de Shodan, podemos concretarlo más). Pero “lo normal” es que un dispositivo de una Infraestructura Crítica no tenga acceso directo a Internet, por lo tanto, habría que potenciar los controles de acceso local a red donde se encuentre.

La buena noticia es que JSOF reportó directamente al fabricante estas vulnerabilidades, dos ellas de forma anónima y esto ha permitido la rápida creación de los diferentes parches de seguridad. Además, tampoco han publicado ninguna PoC (al menos el código) donde se implemente este tipo de ataque, tendremos que esperar a la BlackHat para verlo, lo bueno es que la mayoría de los dispositivos (o eso esperamos) ya estarán parcheados.

Resumiendo, como en la mayoría de los problemas de seguridad, el primer paso es tener toda nuestra infraestructura segura en general. Luego, para estas vulnerabilidades, la solución pasa por actualizar las librerías, pero justo en este caso, no es posible aplicarlos en todos los dispositivos por lo que provoca la activación de una capa adicional de seguridad centrada esta vez en la monitorización y los controles de red donde se encuentre el aparato.

Finalmente, y a modo de moraleja, que una implementación funcione bien durante años no quiere decir que esté exenta de problemas de seguridad, por lo que es necesario auditarla y actualizarla de forma periódica. Pero también es nuestra misión tener controladas esas librerías y comprobar que se actualicen periódicamente, aunque esto es un poco más complicado en el caso del IoT. Pero vamos, si tienes un dispositivo IoT SteamPunk ;) que no has tocado durante veinte años aunque funcione bien … seguro que alguna “pequeña” actualización habrá necesitado en todo este tiempo ¿verdad? ;)

Happy Hacking Hackers!!!
Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox