lunes, 15 de julio de 2019

Simulador de expresiones regulares

Uno muy, muy rápido.

Un simulador para hacer expresiones regulares y ver con colorines qué se selecciona realmente es este que enlace aquí abajo:

https://regex101.com/


Al menos para python me ha venido muy bien y quiero tenerlo por aquí (hasta que se me olvide que lo tenía) por si algún día me hace falta encontrarlo de nuevo.

Además de python también lo ejecuta con otros tres o cuatro lenguajes más. Esto ahorrará mucho ensayo y error. Además, da bastantes pistas de qué parte se está detectando y cuál no.

viernes, 21 de junio de 2019

/etc/resolv.conf: se sobreescribe

A ver si me sale corto este post.

Esta es la típica solución que cuesta mucho encontrar, uno cree que se acordará de la solución y tiempo después la necesita y se ha olvidado.

Problema que llevo queriendo solucionar desde hace mucho tiempo: el fichero /etc/resolv.conf de un Debian que tengo instalado se me sobreescribe. Todo el tiempo que he querido solucionarlo he intentado quitar distintos servicios que ya ni me acuerdo. Pero me he encontrado con que una persona ha mostrado distintas soluciones al problema.

Una de ellas me ha permitido solucionarlo encontrándome con que mi resolv.conf era un enlace a un fichero de NetworkManager. En mi caso, su solución la he aplicado modificando directamente /etc/NetworkManager/NetworkManager.conf.

Ojo, que ese mismo enlace tiene más soluciones.

En el segundo enlace dan unas pocas pistas más. Pero habiéndolo solucionado con el primero poco más he leído del segundo (a parte de que he llegado a este a partir del segundo).

Espero que en algún momento os sea de utilidad.

domingo, 2 de junio de 2019

Compartiendo impresoras por internet

Hoy he adquirido una impresora láser multifunción por Wallapop. Un trasto que de sólo transportarlo a pulso del coche (que no he podido aparcar excesivamente cerca de casa) ya me he ahorrado un día de entrenamiento en el gimnasio.

El caso: se me ha ocurrido hacer una búsqueda de su márca (XXX) y modelo (YYY) para ver temas de configuraciones (manual), tóner, ruidos raros que no me pareció oir cuando la han probado... El tema es que el primer resultado era el manual en PDF de la propia página del fabricante. Y para mi sorpresa había varias direcciones IP después. No sé por qué se me ha ocurrido acceder a ellas (cenutrio de mí, todo sea dicho). Y me he encontrado... ¡Con un panel de control del servidor web de la propia impresora!

Ahora que sigo fijándome en la búsqueda: he puesto el nombre completo entrecomillado "XXX YYY" problema para solucionar

Sí, ya sé que esto se podría hacer en Shodan. Pero no me hubiera imaginado nunca que una búsqueda tan básica me hubiera dado un resultado de este tipo en la segunda entrada. Como hubiera dicho Eugenio en un chiste "Cosa curiosa Rusia".

Seguiré configurando el cacharro y si me encuentro más cosas del aparato, aviaré por aquí. Por cierto: tengo pendiente un artículo que tengo a medias del Grandstream. Ya veré cuándo puedo jugar con el teléfono y lo documento.

miércoles, 15 de mayo de 2019

Rsyslog: Logrotate

Voy a añadir una opción más a la configuración que hice recientemente para rsyslog. Para poder ver los datos que se envían desde el dispositivo que estamos analizando al servidor de logs correctamente, el hecho de que esté lleno de resultados de hace días no ayuda nada. Para ello se usa logrotate.

¿Cómo lo he configurado? Bien. He encontrado que existe un fichero en /etc/logrotate.conf y otros ficheros dentro de la carpeta /etc/logrotate.d/. De los ficheros que aparecían estaban asteriskdpkgsambarsyslog.

Para forzar a que se cambien los ficheros diariamente para los dos aparatos que me interesa analizar, el SPA3102 y el teléfono Grandstream he incluido las siguientes líneas en el fichero de rsyslog:

/var/log/spa3102.log
/var/log/grandstream.log
{
        rotate 31
        daily
        dateext
        missingok
        notifempty
}

Las notas que puedo hacer al respecto:

  • rotate: número de ficheros que quiero que se me generen.
  • daily: quiero que se hagan diariamente.
  • dateext: concatenar la fecha en los ficheros cuando se copian en vez de usar números.
  • missingok: Por lo que he entendido, si el fichero de log (¿original?) falta, no se genera ningún error.
  • notifempty: no rotar el fichero cuando este esté vacío.

Como no me terminaba de convencer hacer la prueba con todo lo que contiene rsyslog he decidido copiar y pegar la configuración aquí mostrada, sólo para Grandstream, en su propio fichero.

Después de la configuración he ejecutado la siguiente instrucción:

#logrotate -f -v /etc/logrotate.d/grandstream.conf

El resultado, además de rotar ficheros que no se habían tocado en mucho tiempo, es que me ha concatenado al fichero /var/log/grandstream.log la fecha, pero no me ha generado otro nuevo. Si miro su contenido, puedo ver que en dicho fichero se siguen guardando datos. Esto me hace preguntarme: ¿Me concatenará siempre la fecha o será sólo hoy? 

---

Si bien cuando empecé escribiendo este artículo, el sistema no se comportó como esperaba, me esperé unos días más para ver qué sucedía. ¿Qué tengo ahora? 

Ahora sí que tengo los ficheros con su nombre original y sus copias diarias con la extensión de "-aaaammdd" (año, mes, día). El único problema: no se están haciendo en el momento adecuado, por lo que tengo ficheros que dicen que son, por ejemplo, del día 15, que contienen datos del 14 y del 15. :
Así, tengo:
  • grandstream.log-20190515: registros de las 6H del 14 a las 6H del día 15.
  • grandstream.log: a partir de las 6H del día 15.
Ejecutando:

#cat /var/lib/logrotate/status

Es posible ver cuándo se rotó cada fichero. Y, en efecto, las horas cuadran con respecto al desfase mostrado en los logs que necesito analizar. Repasando el comando de más arriba:

#logrotate -dfv /etc/logrotate.d/grandstream.conf

Gracias a que he revisado con más detenimiento el resultado de su ejecución he podido corregir algunos de los ficheros de configuración aquí explicados (pero yo lo muestro sin me avise de errores). 

Con respecto a las horas a las que se produce la rotación ya he encontrado la razón de esa hora tan rara. La rotación se realiza con un cron diario (/etc/cron.daily/). Dentro de esa carpeta, entre otros ficheros, se encuentra el relacionado con logrotate. A su vez, la ejecución de cada uno de los scripts que tiene que lanzar cron, independientemente de que sean diarios, semanales, mensuales... Se hace a través de la configuración que se encuentra dentro de /etc/crontab. Este fichero muestra la hora y minuto que cuadra con la que se muestra en el contenido de los logs al final del más reciente con su extensión de fecha y al principio del que se ha creado.

Lo voy a dejar aquí. Sólo me queda tomar la decisión de dejarlo tal cual, quitar la extensión de fecha (y que me salga la numeración), cambiar la hora para la ejecución de todos los diarios, forzar a que se roten sólo esos ficheros a las 0H (y por lo tanto, al intentar hacerlo de nuevo a las 6H no tendrá efecto)... Ya veré.


Sólo para tener un listado de los distintos sitios que he visitado (y así poder buscar en un posible futuro si es necesario, aunque creo que he perdido alguno):

jueves, 9 de mayo de 2019

Grandstream GXP1405 I: Prensentación

Recientemente me hice con un teléfono VoIP Grandstram GXP 1405, ya deprecated, para incluirlo en mi centralita Asterisk.

Grandstream GXP 1405
Grandstream GXP 1405

Como se puede ver es muy sencillo. Tiene para configurar dos líneas, típico botón de poner el altavoz para manos libres, PoE (si bien también trae una fuente de alimentación), permite conectarle una diadema para hablar por micrófono, la (típica) posibilidad de usarlo de switch para ponerle el PC... Vamos, lo más típico que uno se puede encontrar en un trasto de este tipo en una oficina.

Seguro que puede apreciar en la pantalla LCD hay tres llamadas perdidas de unas cuantas pruebas que estuve haciendo. Eso es porque ya lo tengo configurado. Entre otras opciones permite configuración vía http(s). Desconozco por qué pero ayer mismo me dio problemas y tuve que tirar de https, cuyo certificado no está reconocido, pero para el caso, me sirve. 

La configuración manual de la línea 1, que es la que se corresponde con el usuario de la centralita que le he creado, no fue del todo complicada. La recuerdo muy sencilla, a pesar de que para cada línea ofrece muchas opciones.

Yendo a general settings:

Grandstream GXP 1405 - Menú para acceder a General settings
Grandstream GXP 1405 - Menú para acceder a General settings
Y la configuración es muy sencilla: poner la dirección IP, el nombre de usuario (o extensión), contraseña y listo:

Grandstream GXP 1405 - General settings
Grandstream GXP 1405 - General settings

Una vez apliquemos los cambios y volvamos a la sección de inicio, veremos el resultado que tenemos en el pantallazo: una línea conectada y la otra no. Si hubiese algún problema cuando inicie sesión, evidentemente, se quedará en rojo. 

Como apenas he jugado con el aparato, mientras estaba escribiendo este post me he encontrado con algunas cosas que me las estudiaré para ver si merece la pena escribir sobre ellas.

Además del servidor web tiene otro ssh, pero la shell es un simple menú que apenas deja tres cambios que prácticamente serán para acceder vía web.

Grandstream GXP 1405 - Configuración vía SSH
Grandstream GXP 1405 - Configuración vía SSH
Y así es como tengo un juguetito más que, al menos las pruebas que hice, funciona bastante bien. Esperemos que en un caso real también lo haga. 

sábado, 4 de mayo de 2019

Rsyslog v8: actualización

Hace un tiempo hice un post sobre rsyslog. Ahora que creía que lo tenía activo, me he encontrado con que no era así. Posiblemente porque reinstalé el sistema. Ahora que he querido volver a ponerlo me he encontrado con que la configuración es ligeramente distinta y no me termina de funcionar del todo bien.

Primero: en /etc/rsyslog.conf descomentar:

  • module(load="imudp")
  • input(type="imudp" port="514")
También habrá que asegurarse de que esta línea está descomentada:
  • $IncludeConfig /etc/rsyslog.d/*.conf
Como se puede ver, hasta aquí la única diferencia que hay con respecto a los parámetros antiguos es que ya no se usan "$ModLoad" ni "$UDPServerRun".

A su vez, en /etc/rsyslog.d/ he creado dos ficheros, uno para cada sistema que necesitaba logear. Su contenido:

:FROMHOST-IP, isequal, "_direccion_ip_sistema_" /var/log/_nombre_fichero_.log

& stop

Me he encontrado con un problema: no se me generan los ficheros. Algunas de las cosas que he leído que se podía hacer era ejecutar:

#/etc/init.d/rsyslog rotate

Que a su vez, según he entendido, fuerza a rotar los ficheros de log y a su vez generar los que no estuvieran creados. Pero no han funcionado.

También he querido buscar datos ejecutando rsyslog en modo debug (o eso he entendido al buscar soluciones:

#rsyslog -dn | more

Como son muchas líneas permitirá ver las lineas. Otra opción: mandarlo a un fichero auxiliar y después hacer un pipe ( | ) con grep

Nos permitirá ver que:
  • Se han localizado los ficheros que hemos incluido en /etc/rsyslog.d/ (puedes buscar la cadena "requested to include" o "config parser".
  • El contenido del filtro, al menos de uno de ellos.
Así, se podrá ver si hay algún problema. En mi caso no me ha terminado de ayudar. 

No obstante, uno de los sistemas sí que están guardando datos en /var/log/messages y en /var/log/syslog.

Que se estén guardando datos en estos ficheros para sólo uno de estos sistemas lo único que me indica es que realmente está escuchando. Por lo tanto, tengo que solucionar varios problemas:
  1. Que no se guarden los datos en los otros ficheros: syslog ni messages.
  2. Que se generen los ficheros que quiero.
  3. Que el equipo del los equipos de los que no se están guardando logs sí se guarden.

La verdad, he hecho muchas pruebas con distintos resultados.

En teoría para el número 1 estaba la opción "& stop". Pero como no se generan (generaban), tampoco estoy muy seguro de que esté sirviendo. 

Asegúrate de que la dirección IP del emisor es la correcta ya que en uno de los casos puse la propia del servidor de logs. De las muchas pruebas que he conseguido hacer, he tenido todo tipo de resultados. 

Continuando con la línea "& stop" para solucionar el número 2: he conseguido que se generen los ficheros comentando esa instrucción. Por un lado, hice la prueba de incluir el contenido de los dos ficheros (sin el stop) en la configuración directamente y así sí que se me generaban los dos ficheros. Pero después, si comentaba esas líneas, dejaba de funcionar. 

También hice lo siguiente: reiniciar tirando del cable el equipo que en ningún momento generaba el log. Como no tiene ninguna otra opción para apagar y encender no ha quedado otro remedio que hacerlo así.

Lo extraño: este del que hablo sólo genera el fichero si se reinicia. Aunque se produzca un evento, desconozco el por qué de ese comportamiento.

Como costará entender las soluciones, a ver si las puedo resumir:
  1. Evitar guardar en messages y syslog: A día de hoy no tengo solución viable.
  2. Reiniciar dispositivos si es necesario. Además, aplicar número 3.
  3. No poner "& stop" bajo ningún concepto, al menos para las necesidades básicas.

Aunque juraría que hice pruebas comentando esa línea maldita, no llego a entender por qué habiendo hecho lo mismo que mostré la anterior vez me ha costado tanto hacerlo funcionar.

sábado, 30 de marzo de 2019

Crónica RootedCon 2019: Día 3

Hoy he empezado el día con el despiste de pensar que llegaba tarde pensando que llegaba tarde por el cambio de hora. Ese cambio de hora que se hace entre el sábado y el domingo, y no hoy sábado.

Al llegar he visto a Alberto (@albert0r) y a Chencho (@chencho) de la organización con los que nos hemos hecho un selfie.



Además, me tenían una sorpresa preparada antes de empezar las charlas: subir al escenario para decirme que voy a hacer las crónicas oficiales de RootedCon. Una vez más: ¡¡Muchisimas gracias!! Además, hoy he participado haciendo más preguntas que los otros días (y saliendo de voluntario).

La primera charla la han dado Pablo González (@pablogonzalezpe) y Enrique Blanco (@eblanco_h).

RootedCon 2019 - Pablo González y Enrique Blanco - Autoencoders, GANS y otros chicos del montón
RootedCon 2019 - Pablo González y Enrique Blanco - Autoencoders, GANS y otros chicos del montón
Después de la introducción y de enumerar las cosas con las que hacen pruebas en Telefónica han empezado hablando de las noticias falsas. Si bien han explicado que muchas veces se habla de ellas cuando son escritas, también existen técnicas que permiten poner palabras en boca de otros a través de vídeos. Y para ello se utiliza la IA y el machine learning. Aunque también permiten detectar anomalías en la red o phising. Han descrito los distintos tipos de aprendizaje (inductivo: supervisado, no supervisado y semi-supervisado; reforzado). El módulo de machine learning hace falta entrenarlo y alimentarlo llegando a durar varios días. Además han explicado las redes neuronales, qué son los autoencoders y los GANs (entre dos imágenes, una indubitada se mira si la otra es real o falsa). Con los autoencoders Han hecho una demo con dos vídeos. Con GANs han permitido capturar con una webcam la cara de una persona (¡la mía!) haciendo que parezca que Chema Alonso estaba delante de ella.


También han mostrado una demo en la que se permitiría hacer algo parecido con audio, pero a día de hoy sólo es eficiente cuando se está hablando en inglés o en chino. También han explicado las contramedidas para detectar estas manipulaciones y las fake news. Entre otras, algunos recursos que permiten analizar urls, patrones biométricos, cambios de colores en los píxeles, patrones en el parpadeo de los ojos, etc.

Al final esta charla, Miguel Ángel de Castro Simón (@madecastrosimon) y Pablo San Emeterio (@psaneme) en la que han hablado de los disclousures que se hacen al mandar los e-mails a sistemas de análisis. 

RootedCon 2019 - Pablo San Emeterio y Miguel Ángel de Castro - Another bad e-mail
RootedCon 2019 - Pablo San Emeterio y Miguel Ángel de Castro - Another bad e-mail
Han empezado diciendo que los e-mails deberían de haberse llamado postales porque como se puede ver el contenido sin problema... La charla viene de un análisis que tuvieron que hacer como consecuencia de un malware a un banco pakistaní al les robaron una gran cantidad. En la investigación se encuentran con un e-mail que contiene un adjunto que es un malware y que éste se conecta a una dirección que todavía responde. Nos han nombrado varias herramientas: mail mincer para automatizar la investigación y ésta a su vez se vale de otras. Wildfire, Virustotal, Diario (suya propia a la que nos han dado la opción de poder pedir acceso: diario.e-paths.com). Al almacenar todas herramientas los ficheros se mandan pudieron obtener muchas estadísticas de los e-mails pudiendo analizar todos los datos posibles: asunto, cuerpo, adjuntos, pié (junto con los disclaimers de no lo leas si no es para tí pero ya lo has leído), destinatarios, dominios involucrados... Los distintos sectores a los que afectan los e-mails: gobiernos, industria... Interesante encontrase cómo se subían a estos sitios de búsqueda de malware ficheros confidenciales. Encontraron un malware que atacaba a Vietnam con una forma de ofuscación que generaba un fichero en memoria de una forma bastante peculiar y muy bien ideada. Además, la dirección IP donde se conectaba también estaba activa. Entre otras conclusiones están que los e-mails siguen siendo grandes fuentes de infección y de fuga de datos.

Después del descanso, Gonzalo José Carracedo (@BatchDrake) nos cuenta cómo ha hecho ingeniería inversa para poder contactar con un satélite.

RootedCon 2019 - Gonzalo José Carracedo - Introducción a la ingeniería inversa de señales de radio
RootedCon 2019 - Gonzalo José Carracedo - Introducción a la ingeniería inversa de señales de radio
Una de las motivaciones de la charla es que Irán consiguió capturar un dron militar de EE.UU manipulando las señales de radio que lo controlaban haciéndolo aterrizar limpiamente para, posteriormente, hacerle ingeniería inversa. Antes de empezar en materia ha recordado el código penal para que no se nos olvide que las señales que no estén destinadas al público en general no se pueden escuchar aunque estén ahí bajo pena de una cuantiosa multa. El objetivo es el intentar ver cómo se podría escuchar un satélite meteorológico ruso (Meteor-M nº 2) teniendo tan sólo dos fotos del mismo (si bien él tenía los datos, la idea es encontrarlos como si no se tuviesen). Sabe que está a una órbita determinada (heliosíncrona) y en España la mejor hora de intentar escucharlo sería por la noche. A partir de una de las fotos donde se ve alguien trabajando con el satélite en tierra estima las alturas de los elementos, entre otros las antenas. Sabiendo qué tipo de antenas eran y su altura pudo estimar la frecuencia y construirse una (no sin algunos problemas). Tuvo que usar una herramienta que calcula señales, suscan, a partir de la cual consiguió recuperar tres o cuatro datos más, entre otros los baudios con los que trabajar. Poco a poco consiguió sacar la codificación y los patrones que también hacía falta para poder comunicarse. Con todo, consiguió mostrar y obtener fotos del satélite. Otras herramientas o datos que nos dijo: Irptchop, por un lado. Y el vídeo "iridium" por otro (que tendré que verlo).

Al finalizar la exposición sobre satélites Rafa Sánchez Gómez (@R_a_ff_a_e_ll_o) y Fran Gómez (@ffranz) nos han hablado de IoCs en IPv6.

RootedCon 2019 - Rafa Sánchez Gómez y Fran Gómez - IoCker: When IPv6 met malware
RootedCon 2019 - Rafa Sánchez Gómez y Fran Gómez - IoCker: When IPv6 met malware
El estudio que nos han mostrado está relacionado con el hecho de que los IDSs obvian la revisión de las amenazas relacionadas con IPv6. Se preguntan por qué, dado que ya hay muchos bichos que utilizan las dos versiones de IP. A partir de datos que han ido recopilando han publicado el primer feed de amenazas dual stack: Mr. Looquer IOCFeed. Éste permite estudiar datos de interés para poder crear las normas de filtrado que mejor interesen, todas ellas relacionadas con IPv6. De los datos más importantes están el prefijo con el que estén configuradas las direcciones dado que se han encontrado con prefijos enteros que según los datos recuperados se podrían bloquear directamente. Han recordado la RFC: usar /48 y /64 bits para el prefijo de red. También se ha enseñado un resumen de análisis de ASNs, prefijos y tipos de amenazas encontradas. Herramienta que me parece imprescindible: Hurricane Electric. También han nombrado MrLooquer IPLake con el que harán scoring por ASN y prefijo (en el momento de escribir este artículo no está activo).

Después de comer, Daniel Kachakil (@kachakil) nos ha hablado de funciones del código de Android bastate... Sorprendentes.

RootedCon 2019 - Daniel Kachakil - Android's Download Provider
RootedCon 2019 - Daniel Kachakil - Android's Download Provider
En su ponencia nos cuenta varios CVEs que descubrió analizando el framework de Android. Ha descrito qué son los content providers, los cuales permiten acceder a bases de datos (por ejemplo, SQLite), ficheros... Además de mostrar algunas clases, tanto del propio framework como suyas y ficheros AndroidManifest.xml los cuales permitirían acceder a los datos de otras aplicaciones acorde a los permisos que el sistema tenga definidos, si es que están definidos. Así, definiendo un proveedor de datos estarás dando permiso para que otra aplicación acceda a esos datos en concreto. Ha mostrado cómo implementar tanto el proveedor de datos como el consumidor de los mismos, el cual puede tirar de consultas para lanzar queries, actualizar y eliminar, además del comando adb. Por lo que recomienda ir siempre al respositorio oficial en vez de a los mirrors. Ha puesto un ejemplo de dos códigos (uno actualización, otro delete) que primero ejecuta la acción y después se pregunta si se puede lanzar o no. Nos ha mostrado un código en varios trozos donde están los 3 CVEs: 2018-9468, 2018-9493 y 2018-9543. Aparecen métodos que hacen una llamada a "public download" que no requiere permisos pudiendo obtener y manipular todas las descargas que se deseen. Con estas vulnerabilidades también se podía ejecutar SQL injection en el terminal, pudiendo obtener los datos de la base de datos. También había acceso de un espacio, "my_downloads". Una cabecera que se encontró: QueryRequestHeaders.

Después de esta charla, el equipo de Everis que tenía un stand en el evento para buscar talento nos mostró cómo montó un fake AP. 

RootedCon 2019 - Everis - Fake AP: ingeniería social
RootedCon 2019 - Everis - Fake AP: ingeniería social
Nos mostraron las estadísticas de personas que accedieron a este AP, el cual no tenía ni siquiera salida a internet. Se vio cómo "sólo" cayeron 22 personas conectándose a un punto de acceso público en un evento de hacking. Había un portal cautivo con un e-mail como usuario y una password (la que fuera) al cual algunos cautos mandaron mensajes al que lo hubiera instalado para mostrar que ya sabían que se trataba de una trampa. 

Después ese paréntesis Jaime Peñalba Estébanez (@nighterman) ha empezado con su charla: Kernel exploitation, ¿el octavo arte?

RootedCon 2019 - Jaime Peñalba Estébanez - Kernel exploitation, ¿el octavo arte?
RootedCon 2019 - Jaime Peñalba Estébanez - Kernel exploitation, ¿el octavo arte?
Como ya sabréis, este área en concreto me cuesta mucho. Ha intentado explicar una explotación básica. Ha contado muy por encima qué es el kernel, la memoria virtual y la paginación. Ha hablado de un tipo de vulnerabilidad, "null pointer dereference", relacionada con punteros, y también ha explicado algunas mitigaciones. Las hay hardware, SMAP y SMEP, que están implementadas en el microprocesador, y las hay software, KPTI (kaiser) y SLAB-Allocator. Nos ha enseñado cómo funciona su exploit. Nos ha mostrado mucho código fuente. Ha aplicado un "ataque" de abuso de use after free (UAF) y otro abuso de "race condition" (que esa parte ya me estaba costando sobremanera). Además, ha explicado otros problemas con los que nos podemos encontrar. Entre otros convertir algo no-determinístico en determinístico. Ha hecho una demo en la que aplicando lo expuesto en la charla ha elevado privilegios de un usuario normal a root. También ha recomendado limpiar las cosas para dejarlas como estaban.

La última charla de la temporada 2019 ha sido por parte de David Pérez y José Picó, de Layakk (@layakk) en la que nos han desgranado cómo funciona las comunicaciones (por no usar el término telefonía) 5G.

RootedCon 2019 - David Pérez y José Picó - Seguridad 5G
RootedCon 2019 - David Pérez y José Picó - Seguridad 5G

Han hecho una pequeña introducción hablando de seguridad y de algunos ataques teóricos. Han recordado un poco la historia de las distintas generaciones (incluyendo, aunque fuese entre comillas, la 1G). Para las especificaciones de la 5G han estudiado la release 15, y por lo tanto cualquier actualización posterior podría corregir algunos de los aspectos hoy explicados. 5G busca que todos los dispositivos, sean cuales sean, estén conectados (además de teléfonos, electrodomésticos, coches... lo que sea). Han explicado la arquitectura de 5G, en la que los elementos desaparecen para convertirse en servicios. Además, se ha creado una pila de protocolos, en la que existe autenticación y cifrado. Además de hacerse tunneling en las comunicaciones. La norma establece que se soporte como mínimo tres tipos de redes virtuales (networking slicing o rebanadas): móviles, latencia baja y bajo consumo (IoT), que podrían estar disponibles o no. Es posible estar conectado a dos rebanadas distintas a la vez. Han mostrado algunos ataques que funcionaban en 4G que en ciertos casos muy concretos se podrían llegar a aplicar en 5G. El IMSI ha cambiado de nombre, ahora se le llama SUPI, el cual en la UE está permitido mandarlo en claro en tres casos determinados, entre otros para llamadas de emergencias. También han explicado qué hace falta para que un dispositivo se autentique en la red y los métodos que podría usar para hacerlo. Algunos ataques que han nombrado son el IMSI-Catching (que funcionaba antes del 5G), ToRPEDO, Piercer (para 4G resuelto en 5G) y de trazabilidad. Han nombrado la herramienta Tamarin Prover. Han mostrado un ejemplo en el que la propia red llegue a descartar un nodo suyo (forzando así un DoS sobre ese nodo). Y hay ataques que dada la libertad que da la especificación para su implementación depende de cómo la haya configurado el operador de la red que se puedan aplicar los ataques que nos han descrito.

Y esta ha sido la última jornada de RootedCon 2019. Como siempre, ha sido placer enorme haber venido. Como ya he dicho antes, muchas gracias a la organización por todo. ¡Ah! ¡También a los voluntarios! Espero que la hayáis disfrutado tanto como yo y espero, como todos los años, veros en la siguiente edición. ¡Nos vemos!