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!

Crónica RootedCon 2019: Día 2

Hoy hemos tenido otra jornada muy intensa en la RootedCon 2019. Además, dos libros han tenido una buena relación en este día. Uno, el libro de Pablo F. Iglesias (@PYDotCom) "25 + 1 relatos distópcos", que ya que le iba a ver me lo llevé para que me lo dedicara. Y el otro ha sido la compra de un libro recién salido de 0xWord (@0xWORD) "Arduino para hackers: pocs & hacks just for fun" que de chiripa he leído en el desayuno que salía a la venta justo hoy. Y he podido adquirirlo casi cuando Nuria y Noelia estaban montando el stand de venta de libros. Recién salido del horno como se dice.

La primera charla, "I know you P4$$word (and if not, I can guess it)", la han dado Pablo Caro Martín y Jaime Sánchez.

RootedCon 2019 - Pablo Caro Martín y  Jaime Sánchez - I know your password (and if not I will guess it)
RootedCon 2019 - Pablo Caro Martín y  Jaime Sánchez - I know your password (and if not I will guess it)
Han explicado la razón por la que han hecho el proyecto que van a presentar, comenzando por varios leakages muy históricos y épicos (varios de Yahoo, Asley Madison, Friend Finder, Badoo y muchos otros). Después han dado también una pincelada de la historia del crackeo de contraseñas sin dejarse Jhon the Ripper, HashCat, las rainbow tables, diccionarios, etc. También han recordado el uso de SpyCloud y de HaveIBeenPwned o las diferencias entre encoding, hasing y cifrado. Ni que decir tiene que tampoco se han olvidado de mencionar los términos de keyspace, hashrate y cracking time. Además de mostrar más términos muy comunes en el descubrimiento de contraseñas (diccionario, fuerza bruta, ataques de máscara, reglas) han puesto varios ejemplos del tiempo que se tardaría en romper una contraseña para recuperarla. Una de ellas hasta 4 años. La herramienta que nos han mostrado, Kaonashi es una interfaz web que permite buscar todos los leakages recuperados y ver los datos en claro a partir de los filtros deseados. Así se obtiene una inteligencia de cómo una persona determinada construye sus contraseñas lo que permitiría reducir los tiempos de crackeo cuando otras técnicas no han funcionado. Y así, poco a poco ir afinando las máscaras y reglas que se apliquen en las herramientas de crackeo. Han puesto ejemplos relacionados con el encoding de las contraseñas (ASCII vs UTF-8) y su relación con cómo se pueden escribir ciertas palabras en algunos idiomas los cuales tienen varias grafías para el mismo vocablo.

Después de esta charla, el equipo de PWC (@pwc_espana) formado por César Tascón Álvarez, Juan Carlos Díaz y Javier Urtiaga nos han hablado de una respuesta ante incidentes en la que participaron para ayudar a un cliente suyo.


Cada uno de ellos actuando como el equipo al que pertenecían en dicho incidente: blue, orange y red. El incidente en cuestión era muy crítico dado que era una compañía de gas. y mucho más teniendo en cuenta que era fuera de España (República de Abssetia). Su primera idea era bajar las probabilidades del ataque que se sospechaba que se iba a producir o en la medida de lo posible aminorar las consecuencias de producirse el mismo. Siempre sospechando que había un insider dentro por lo que todas sus actuaciones se hacían con toda la discreción posible. Hicieron una hoja de ruta de cinco pasos, para los cuales cada miembro del equipo tenía unas tareas determinadas. 1) Ver el estado actual nada más llegar monitorizando todos los datos posibles internos y públicos además de acotar la superficie de ataque. 2) Protección, detección, respuesta y recuperación de los entornos dañados en el caso de producirse el incidente que se preveía inminente. Además de estudiar un posible contraataque por parte de "rojo". Coordinación total entre los tres equipos. 3) Aquí intentaron buscar al insider y capturarlo. Blue seguía protegiendo, detectando y de ser necesario responder. Sobretodo conseguir que los backups no se pudieran comprometer para poderlos usar cuanto antes de ser necesario. Seguían la regla de no confiar en nadie. Se encontraron un controlador de dominio con un comportamiento muy raro que descargó cosas raras. Montaron un honeypot en el que el atacante cayó. 4) Para la toma de control nos contaron que tuvieron discusiones entre los distintos equipos de cómo actuar. Aquí desconectaron todos los elementos y sistemas para poco a poco irlos poniendo en producción revisando que estaban "limpios". Además, ya tenían identificado al atacante pudiendo hacerle un forense. 5) Restauración de los sistemas y puesta a punto dado que algunos llevaban muchisimo tiempo sin actualizar revisando que estaban bien. 

Un año más, Alfonso Muñoz (@mindcrypt) ha tenido la oportunidad de contarnos otro sus estudios que tanto esfuerzo le lleva. 

RootedCon 2019 - Alfonso Muñoz - Reviving Homograph attacks using (deep learning) asteroids
RootedCon 2019 - Alfonso Muñoz - Reviving Homograph attacks using (deep learning) asteroids
Se busca usar machine learning para aplicarlo a la seguridad ofensiva en los ataques clásicos tipo nmap, SQLMap, Deep Exploit, etc. Tampoco se ha dejado en el tintero los PassCAN, herramienta que permite hacer mutación en passwords. Con respecto a estas últimas tenemos los ataques unicode y homográficos (confusables) en los que dos representaciones muy similares (si no iguales) realmente son letras distintas. Por ejemplo, para las grafías de otros idiomas como el cirílico. Un ejemplo de algunos de estos ataques anteriores es representar la "S" en ASCII o en unicode. Nos ha hablado del estándar punycode que fuerza a que los caracteres unicode se muestren de otra forma a los usuarios y que estos no se lleven a engaño pensando que lo que se les muestra es una información cuando se trata de otra. Ha conseguido generar un diccionario de este tipo de confusables con machine learning comparando "visualmente" los caracteres ASCII con unicode.  Ha presentado su herramienta uriDeep. También ha enseñado tres casos reales donde se pueden usar este tipo de ataques: en URLs (maliciosas), en el plagio de textos (por ejemplo, en tesis doctorales) y en la esteganografía. Para esos ejemplos ha enseñado el comportamiento de los navegadores y de los clientes web de distintos correos gratuitos. Por no olvidarnos de las distintas mensajerías instantáneas como Skype, Twitter, WhatsApp, etc). O la posibilidad de poder engañar a PlagScan y Turnitin, herramientas que buscan plagios en los documentos que se les mandan. Ha dejado caer la pregunta el por qué después de tanto tiempo que se conocen estos ataques siguen saliendo a la luz.

La siguiente charla la ha dado Gianluca D'Antonio (@infosecadvocate). 


RootedCon 2019 - Gianluca D'Antonio - Working cybersecurity: truths and lies behind the trincee
RootedCon 2019 - Gianluca D'Antonio - Working cybersecurity: truths and lies behind the trincee
De las primeras que comenta es que los encargados de buscar las ofertas de trabajo para perfiles de seguridad no saben nada. Ha dado algunas pinceladas de los números de las posiciones y ofertas de empleoen ciberseguridad. Además de no dejarse los perfiles que hay en auge ahora mismo. Es muy necesario que se les explique las cosas a los gestores que no saben. Además, no se ha olvidado de las posiciones imposibles que se piden (un ejemplo que no ha puesto exactamente, pero como ejemplo: joven de 25 años con 10 años de experiencia en...). Nos ha enseñado un robot tipo IoT, Pilos, que suministraba las pastillas necesarias (los medicamentos recetados por el doctor de cabecera) y que guardaba en los servidores del fabricante todos los datos de salud y clínicos. Dicho aparato no se llegó a vender por los problemas de seguridad que tenía porque nadie se molestó en analizarlo. Todo a colación de lo que ya se ha contado en otras Rooted: se montan electrodomésticos de estos sin tener a nadie capacitados que tengan en cuenta la seguridad. Ha hablado de cómo se percibe a un profesional y ha recomendado dos libros: "The future of world affairs technology volume one" por Abishur Prakash y "Working in cybersecurity" por Michael Tanji.

Después de comer con Pablo, la organización le ha dado paso al equipo de Mr. Looquer (@mrlooquer) antes de la charla planeada. . 

RootedCon 2019 - Mr Looquer - Attacker is looking at you, don't look the other way
RootedCon 2019 - Mr Looquer - Attacker is looking at you, don't look the other way

Con el título Attacker is looking at you, don't look the other way, permiten a partir de tu conexión saber un scoring de seguridad para buscar qué tienes expuesto en tu red. Se ha mencionado openscoring.org. La idea es buscar qué se tiene expuesto sin querer. Además de poder poner un dominio que te analiza se puede usar con los servidores cloud (AWS, Azure, Google Cloud). 

Tras de este inciso empezó la charla que se esperaba después de comer, la de Chema Alonso (@chemaalonso).

RootedCon 2019 - Chema Alonso - A hacker's gotta do what a daddy's gotta do
RootedCon 2019 - Chema Alonso - A hacker's gotta do what a daddy's gotta do
La charla de Chema iba sobre la exposición de los críos que tenemos en la familia a la tecnología. Y la idea del proyecto que nos ha presentado vino por sus hijas. Ha reconocido que las ha expuesto mucho a los gadgets. Nos ha enseñado dos vídeos, en cada uno de ellos venia una de sus niñas. Y ha montado una herramienta y gadget que permite protegerlas cuando están navegando. Nos ha mostrado varios protocolos como SafePost que permite traducir SMSs a una red IP (por ejemplo, si la conexión a internet se cae). O también SecondChannel que trabaja sobre GSM. A partir del gadget que han construido han definido un 2nd factor web browsing. Un móvil se conecta a otro dispositivo y este último es el que encarga de validar que se está recibiendo lo que se espera. Si no es así, el cliente web original mostrará un mensaje que indica al usuario (en el caso en concreto, a sus crías) que tienen que avisar a un adulto. Ha hecho varias demos. 

Al final Chema, Raul Siles (del que ya hablaré de su charla más adelante), Alfonso Muñoz y (¡¡me dejo a alguien!!) nos han contado su proyecto CriptoCert (@criptocert). 

RootedCon 2019 - CriptoCert
RootedCon 2019 - CriptoCert
La primera certificación mundial en la materia sobre criptografía, después de casi dos años de duro trabajo para tenerla lista. El CCN-Cert la reconoce.

Una vez terminaron exponernos la nueva certificación, Daniel Martínez (@dan1t0), que trabaja en IOActive (@ioactive), nos ha hablado de aplicaciones móviles para controlar aparatos en aviones.

RootedCon 2019 - Daniel Martínez - IoP: The Internet of Planes / Hacking millionaires jet planes
Tal y como hemos comentado antes, también lo ha expuesto Dani: el IoT es muy chulo pero suele carecer de seguridad. Y en los aviones se sigue la misma filosofía: muy chulo el control de las cosas en cabina (música, vídeos, temperatura, etc) pero muy poca seguridad. Estos elementos siempre están separados de los controles del propio vuelo. Nos ha hablado de varias aplicaciones móviles que sirven para lo mismo, y ha dado la casualidad de que al destriparlas están hechas por la misma persona/empresa (como si estuviese subcontratada). Las vulnerabilidades pueden afectar tanto al pasaje como al personal de vuelo ya que hay distintos funcionamientos dependiendo del rol que se seleccione en la aplicación. Además de decompilar las aplicaciones ha conseguido simular un entorno como si se encontrase en un avión para poder seguir buscando más fallos dinamicámente y poder explotarlos. Además de aprovecharse de la información que le daba el modo "demo" pudo analizar ese código fuente obtenido al decompilar el .apk y al analizar la red con un sniffer como Wireshark. La herramienta para decompilar utilizada: jadx. Se encontró con que la ejecución de la aplicación está construida en pasos (steps) y según los resultados de cada uno de esos pasos iba tirando del hilo. Descubrió cadenas json y que la aplicación hacía solicitudes de ficheros y carpetas a un servidor ftp llegando a montar la estructura de datos perfecta en uno montado por él mismo engañando a la aplicación. Por lo que, entre otras cosas, la aplicación no validaba que los datos recibidos procedieran de una fuente fiable.

Y la última charla del día la han dado Rául Siles (@dinosec y @raulsiles) y Mónica Salas (@monicasalasbla) y era sobre DNSSEC.

RootedCon 2019 - Mónica Salas y Raul Siles - Hype Potter and the Chamber of DNSSECrets
RootedCon 2019 - Mónica Salas y Raul Siles - Hype Potter and the Chamber of DNSSECrets
Nos han hablado sobre cómo implantar este protocolo y cómo protegerse frente a ataques. Además de hablarnos de escenarios aún viables. Uno de los mayores enemigos de la seguridad es la retrocompatibilidad. Es muy importante centrarse en lo que existe ahora y funciona y olvidarse las cosas muy recientes y muy novedosas (del hype). Dos vulnerabilidades que han sido atajadas por DNSSEC: el MiTM y el DNS (caché) poisoning. Nos han explicado cómo funciona por dentro este protocolo y los han dado los números de su implantación actualmente. Han hablado de un ataque se produjo hace un tiempo a uno de los 13 nodos raiz y conocido como DNSSpionage, pero que finalmente no tuvo éxito por el DNSSEC. Aunque este protocolo tampoco es suficiente porque los registrars de dominios no suelen pedir un segundo factor de autenticacion y la transferencia de dominios no está securizada por el protocolo. Han mostrado los intentos de firmas de varias zonas en unos cuantos dominios que tienen mostrando distintos resultados según sus características, entre otros, dependiendo de los registrars donde se encontraban. Se encontraron con que a la hora de hacer algunos cambios en el sistema (operadores, firmas, etc) el cifrado se deshabilitaba en vez de mantenerlo hasta actualizar a la nueva firma, que podía tardar un tiempo en establecerse. El sitio dnviz.net muestra un diagrama con la cadena de firma. Además, han comparado varios algoritmos de firmas. Han destripado varios campos o flags del protocolo. Además nos han mostrado cómo tuvieron problemas para probar con un router de su operadora los DNSs de CloudFare (1.1.1.1) porque parece ser que había operadores que usaban esa dirección internamente o para redes privadas. Además de descubrir que se forzaba a deshabilitar DNSSEC desde el propio cliente. En vivo y en directo han publicado una herramienta, dnssecchef, que permite manipular el tráfico DNSSEC forzando a que se muestre en el tráfico de red que éste existe (sin que sea cierto) y al revés.

Y esta ha sido segunda jornada de RootedCon 2019. Mañana sábado nos vemos!!







jueves, 28 de marzo de 2019

Crónica RootedCon 2019: Día 1

Un año más  ha tenido lugar la RootedCon, siguiendo con la ya tradición de realizarlo en los cines Kinépolis de Pozuelo, Madrid.

RootedCon 2019 - Entrada a los cines Kinépolis
RootedCon 2019 - Entrada a los cines Kinépolis
Hoy al llegar ya había mucha gente esperando para hacer el check-in, algo que otros años no pasaba.

Después de ver y saludar a todo el equipo que forma la organización y a algunos de los habituales (pero no a todos, y se os ha echado mucho de menos) me he encontrado con algún compañero del trabajo que no me los esperaba. Pero claro, ellos estaban currando y yo de vacaciones.

Un año más, han organizado el evento con diferentes tracks, lo que permite cambiarse de sala por si te interesan más otras charlas.

Como es costumbre, el inicio del evento se hace con la Keynote en la que la organización sale al completo al escenario.

RootedCon 2019 - El equipo de la organización
RootedCon 2019 - El equipo de la organización
Nos han hablado de la unión que hay (y que debería de haber) en la comunidad hacker con las fuerzas y cuerpos de seguridad del estado. Como ejemplo la colaboración que hay cuando ésta viene al evento y el premio otorgado a RootedCon por parte de la Guardia Civil. También nos han dado un pequeño repaso de cómo se vivieron a nivel organizativo las anteriores Rooted. Como no, la importancia de los patrocinadores que sin ellos el evento sería imposible tal y como lo vivimos hoy en día. Evidentemente, también han dado visibilidad a los voluntarios, otra pata imprescindible para llevar a cabo todo el trabajo que hay detrás y que muchas veces no nos damos cuenta. Y para finalizar, nos han instado a que veamos qué se puede hacer con la nueva ley de propiedad intelectual.

Las primeras charlas las he visto en el track principal. La primera la ha hecho Raul Riesco Granadino (@rriescog).

RootedCon 2019 - Raul Riesco - Aproximación algoritmica al talento en ciberseguridad
RootedCon 2019 - Raul Riesco - Aproximación algoritmica al talento en ciberseguridad
Su charla versaba sobre cómo encontrar talento o calcular su coste. En la introducción ha hablado sobre la revisión de estudios (fiables o no) que dicen que hay que controlar el coste para retener el talento. También se ha hablado de los salarios medios. O la obtención de datos a partir de filtraciones o comentarios de diversas personalidades involucradas en RR.HH e inversores. Ha hecho una similitud con un diodo (realmente un transformador) buscando convertir señales negativas en positivas. O lo que es lo mismo, dándole la vuelta a la tortilla. Nos ha hablado de ecuaciones que se podrían emplear para para calcular el valor de una persona, añadiéndole diversas variables a la misma. Después de mostrar la opinión de diversas personas su conclusión es positiva pero no es nada sencillo de calcular. Al final, además de sumar y multiplicar variables también están las exponenciales.

Después del descanso con unas cuantas conchas Condan tuvimos la oportunidad de conocer a Mar López y Andrés Ruiz del Departamento de Seguridad Nacional (@dsn).

RootedCon 2019 - Mar López y Andrés Ruiz - Descifrando la Seguridad Nacional
RootedCon 2019 - Mar López y Andrés Ruiz - Descifrando la Seguridad Nacional
Según nos dicen, cuentan sólo lo que pueden pero no todo lo que quieren. Está formado por un grupo muy amplio de personas de todas las profesiones incluyendo militares, FCSE, civiles, pintores... Dan una pequeña pincelada de la historia de lo que hoy es el DSN, porque antes ni siquiera se llamaba así. Además de mostrar el número de personas conectadas mundialmente (4.000 M de personas) importante para saber el alcance que esto tiene también mencionaron los dos Consejos (grupo de personas, no recomendaciones) que idean las directivas de seguridad nacional. Es importante buscar conocimiento y talento, sin olvidarse de los ejercicios que hacen con el CiberEurop, conformado por 32 países y 1.000 instituciones). Para este último caso nos mostraron un vídeo simulando un ciberataque a un aeropuerto.

Después de la charla se hizo la entrega de la segunda edición de los premios Antonio Ropero.

La siguiente charla la dio Pablo Estevan (@pestevan) y se titulaba "DECODIFICANDO".

RootedCon 2019 - Pablo Estevan - DECODIFICANDO
RootedCon 2019 - Pablo Estevan - DECODIFICANDO
Nos ha hablado de la detección de ataques, visibilidad y los ataques en sí mismos. La peligrosidad de pensar que se detectará todo (y después estar meses con una intromisión que se ejecuta en muy pocos minutos sin darse cuenta) y que pensar que se es invencible. Por lo tanto, hacen falta herramientas para poder ver esos ataques cuanto antes (esa es la visibilidad). Ha mostrado varias demos con meterpreter y algunas herramientas de su empresa, RSA. Esta herramienta es capaz de interpretar los datos recibidos y los muestra de una forma muy legible. Describe la herramienta después de contar la intromisión que sufrió la empresa allá por 2011. Ha hecho otras demos mostrando que su herramienta también dispone de interfaz web. Esta herramienta desgrana muy bien los datos y lo más importante: "sólo" hacen falta los analistas para revisarlos. 

La siguiente charla la ha dado Francisco Javier Sucunza.

RootedCon 2019 - Francisco Javier Sucunza - N4J: Horizonte de sucesos
RootedCon 2019 - Francisco Javier Sucunza - N4J: Horizonte de sucesos
En su ponencia nos ha desgranado los datos desde el punto de vista del atacante: el perímetro. Nos ha descrito qué son los knowledge graphs y ha explicado que el tipo de base datos Neo4J no tiene nada que ver con las relacionales (SQL). N4J es un tipo de base de datos conocido como cipher. Ha comparado ambas estructuras y nos ha puesto unos cuantos ejemplos de cómo se hacen consultas a unas y otras permitiendo que con las N4J sean mucho más pequeñas y den una foto (casi literal) del resultado que no se podría obtener con SQL. Después de poner varios ejemplos en los que, por ejemplo, dos bancos distintos pueden estar relacionados por encontrarse en el mismo hosting, lo que haría que si se vulnera uno el otro podría acabar cayendo. Resumen: para proteger tu empresa, protege el perímetro. Para proteger el perímetro, conoce tu empresa.

Al finalizar esta charla nos fuimos a comer.

La primera charla después del menú del día la vi en la sala 18, donde Carlos García García (@ciyinet) nos ha hablado sobre cómo hacer pentesting a árboles de confianza en Active Directory.

RootedCon 2019 - Carlos Garcia Garcia - Pentesting Active Directory Forests
RootedCon 2019 - Carlos Garcia Garcia - Pentesting Active Directory Forests
La introducción ha ido sobre las razones por las que hay que hacer ese pentesting y alguna herramienta que va a usar en sus demos (powerview). Ha recordado los tipos de relaciones de confianza que nos podemos encontrar, la direccionalidad (unidireccionales y bidireccionales) y el término de transitividad. Todas las relaciones de confianza en un árbol son bidireccionales y transitivas. Por lo que todos los dominios podrían acabar recuperando datos de todos. Hay que revisar las relaciones porque podrían llevar más tiempo del deseado configuradas o porque se desconoce si se están compartiendo cosas no deseadas. Nos ha diferenciado entre autenticación por NTLM y Kerberos. Para hacer la enumeración de los datos que se desean buscar hay que tener en cuenta los dominios y las relaciones, los privilegios del usuario actual y los privilegios de otros usuarios en otros dominios. Nos ha mostrado varias técnicas según la relación del dominio que deseamos comprometer con respecto al dominio desde donde nos encontramos. Ha hecho muchas demos, entre las que se encuentran ataques de pass the hash.

Al finalizar esta charla, en la misma sala 18, Lorenzo Martínez (@lawwait) nos ha desgranado cómo hacer un forense en una máquina Linux encendida. 

RootedCon 2019 - Lorenzo Martínez - DFIR Linux: My Way!
RootedCon 2019 - Lorenzo Martínez - DFIR Linux: My Way!
Como suele explicar, siempre se empieza con el estado inicial de la máquina a analizar. Si está apagada, se deja apagada, si está encendida, se deja encendida para recuperar los datos en vivo y después de apaga. Su charla iba sobre cómo recuperar todos los datos necesarios de una máquina Linux viva utilizando un kit de herramientas que ha montado que permite recuperar todos los datos importantes. Pero antes de presentarla ha contado lo relativamente fácil que es recuperar los datos importantes en un entorno vivo de Windows con unas herramientas de botón gordo. Ha remarcado las dificultades que hay para poder hacer un volcado de memoria y además de enseñar cómo se usa el kit de forense Linux que ha construido ha presentado un repositorio donde están los headers módulos para kernels de varios sistemas que se van actualizando cada poco tiempo con la idea de que en la medida de lo posible se puedan utilizar a la hora de querer hacer el volcado de RAM con LimPmem y LiME. ¡Casi me lo dejo! También ha explicado la posibilidad de utilizar este mismo kit para hacer un forense en la nube.

Una vez Lorenzo terminó su charla hicimos un último descanso.

Ya, en el último bloque, pudimos asistir a la charla de Manuel García Cárdenas y Álvaro Villaverde Prado con el título "Beam me up, Scotty".

RootedCon 2019 - Manuel García y Álvaro Villaverde - Beam me up, Scotty!
RootedCon 2019 - Manuel García y Álvaro Villaverde - Beam me up, Scotty!
Su ponencia viene de un desafío de pentesting que les pusieron en su empresa. Les dijeron que no podían copiar y pegar datos, ni siquiera del navegador. Lo que se encontraron (y no les dijeron) es que también tenían cierto tipo de ficheros capados a la hora de descargarlos de Internet. Por lo que tenían que conseguir "teletransportar" (de ahí el nombre de la charla) las herramientas o programas que necesitaban. Para ello convirtieron esos ejecutables en base64 y se las buscaron para enviárselas y poderlas descargar. Varias soluciones: los trozos ponerlos en carpetas y comprimir todo el paquete, meter los trozos en los metadatos de imágenes (buscando que encajasen en la medida de lo posible en lo que a tipo se refiere) y una tercera opción la denominaron "fileless" o lo que termina siendo lo mismo, tener el ejecutable en memoria. Nos mostraron demos de cada una de estas opciones y nos contaron qué esperan hacer para más adelante. También enseñaron un pequeño guiño en el que podía ver cómo la foto que uno de ellos mandó a la organización contenía una imagen ASCII.

Para acabar el RootedPanel en el que estuvo la "vieja guardia" o lo que son lo mismo, los hackers históricos. 

RootedCon 2019 - RootedPanel - Hackers Históricos

Los hackers históricos: Ramón Ramírez Palomares, Jordi Murgó Ambou, Antonio López Muñoz, Juan Manuel Rey Portal y Andrew han respondido a las preguntas de Román. Cada uno de ellos ha contado cómo comenzó en el mundillo del hacking. Algunos formando parte de grupos como Tanis o HispaHack. También han respondido qué les hace diferentes a cada uno o si hicieron alguna liada (eso sí, ya prescrita). Una pregunta muy importante ha sido si la ideología de un activista forma parte de la vida de un hacker. 

Y esta ha sido la primera jornada de RootedCon 2019. Mañana nos espera otro día muy intenso y seguro que igual de bueno que el hoy.