Feliz Navidad 2020

Aunque este año ha sido bastante extraño, espero que estéis bien y que en la medida de lo posible hayáis podido disfrutar de estas fiestas. 

Creo que este año no voy a poner video musical. A lo mejor para felicitar el año nuevo...

MBR2GTP: Convertir disco con MBR a GPT

 Hace mucho tiempo que tendría que haber hecho la conversión de la estructura del disco duro de mi portátil de MBR a GPT. Creo recordar que en su momento quise hacerlo pero tenía que formatearlo y no me apetecía nada. 

Así, hace no más de una semana y pico se me ocurrió buscar cómo se podía hacer y me encontré con algunas páginas que indicaban que a partir de Windows 10 v1709 existía una herramienta llamada MBR2GTP.exe que lo hacía "perfectamente" (entrecomillado porque cuando uno tiene que hacerlo no siempre es tan sencillo como cabría esperar).

Es importante el disclaimer de siempre, por si las moscas: podrías perder tus datos o el sistema. Por lo que tirar de esta herramienta es solo tu decisión y responsabilidad todo lo que pase con ellos.

La primera sorpresa fue que en la búsqueda, una de las primeras entradas era un vídeo en Youtube de Sysadmit. Ya hace mucho tiempo que le tengo en mi feed y está en el listado de blogs a los que sigo.

Normalmente pondría el paso a paso de lo que fui haciendo pero creo que en esta ocasión lo voy a hacer de otra forma. 

Esta herramienta se ejecuta desde un cmd con privilegios de administración. Y se encuentra en %system32%. La ejecución seria

MBR2GTP.EXE [/validate | /convert] /disk:0 /allowFullOS [/logs:rutaLogs]

Con estos parámetros se consigue lo siguiente, si bien algunos son muy intuitivos por su nombre:

• validate: es el modo prueba. Antes de lanzarse a ver si te dejaría como norma general hacer la conversión.
• convert: ejecutar de forma efectiva la conversión
• disk: se indica qué disco duro quieres convertir
• alloFullOS: sobre todo si es el mismo disco duro donde tienes el sistema operativo que estás ejecutando, te obligará a pasar este parámetro. De hecho, si no lo pasas, ya se encargará de recordártelo especificamente.
• logs: Parece ser que lo normal es que te guarde unos logs directamente en %windir%. Yo no fui capaz de encontrarlos y tuve que ponerle este parámetro. Ayuda bastante a debuguear. Te genera cuatro ficheros: diagerr.xml, diagwrn.xml, setupact.log y setuperr.log.

Con una validación sin problemas obtendrías algo así:

mbr2gpt.exe /validate /disk:0 /allowFullOS 

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Pero te puedes encontrar con algún problema:

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Disk layout validation failed for disk 0

Este error puede venir porque tu disco duro en MBR tiene más particiones de las que realmente permite esta herramienta. Sólo funcionará si tienes como máximo 3 particiones. Si tienes una específica para datos ya irían 4: interna oculta del sistema, sistema operativo, recovery... (Ya van tres)... Y la cuarta de datos. 

Aunque el log de error donde lo redirigía no tiene todos los mensajes el que se encuentra en %windir% sí. Para este caso en concreto setuperr.log mostraria:

_datetime_, Error                        ValidateLayout: Too many MBR partitions found, no room to create EFI system partition.

_datetime_, Error                        Disk layout validation failed for disk 0

La solución para continuar con el proceso pasaría por eliminar una partición. Las dos primeras no puedes: te quedarías sin sistema operativo y no podrías arrancarlo. 

Una solución que se encuentra por internet (¡¡pero no la hagas hasta que termines de leer todo el post!!): "he eliminado la partición del recovery y me ha funcionado.". Puede ser una locura que temporalmente se podría pasar por alto... Depende de cada uno si se quiere arriesgar. Sabiendo las consecuencias... Y no se puede eliminar desde dismgmt.msc por lo que habría que utilizar diskpart desde cmd, evidentemente con privilegios de administración.

diskpart
list partition
select partition 3
delete partition override
list partition

Si ejecutas volvemos a ejecutar el validate:

MBR2GPT.EXE /validate /disk:0 /allowFullOS

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Cannot find OS partition(s) for disk 0

Nos da el anterior error. Acabamos de eliminar la partición del recovery ahora nos suelta este otro error.

Las opciones pasarían por:

1. Volver a crear la partición del recovery si es que se eliminó usando diskpart y poniendo el tipo de partición 0x27. Además, quedaría un paso adicional que ahora explicaré.
2. Eliminar la cuarta partición: que puede ser la de datos. Espérate. 

¿He eliminado la partición del recovery?

Llegado el caso de haber eliminado la partición del recovery, aunque se haya creado de nuevo, nos encontraremos con que los logs muestran otros mensajes de error.

_datetime_, Error                        GetOSDeviceVolume: Cannot get NT path for entry.[gle=0x000000ea]

_datetime_, Error                        FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0x000000EA[gle=0x000000ea]

_datetime_, Error                        Cannot find OS partition(s) for disk 0[gle=0x000000ea]

Este mensaje puede despistar mucho. Pensar en que al haber recreado la partición del recovery se quitaría... Y no es así. Me encontré con la solución, pero viendo ahora todo el bloque entero del log, tiene más sentido:

_datetime_, Info                         BCD: Opening store. Flags: 0x0

_datetime_, Info                         BCD: Store path: "\??\GLOBALROOT\device\harddisk0\partition1\Boot\BCD"

_datetime_, Info                         BCD: Loaded hive at BCD00000000

_datetime_, Info                         BCD: Opening object {_ID01_}

_datetime_, Info                         FindOSPartitions: Default boot entry: {_ID02_}

_datetime_, Info                         BCD: Opening object {_ID02_}

_datetime_, Info                         VERBOSE: Device path: \Device\HarddiskVolume2

_datetime_, Info                         VERBOSE: Dos path: \\?\GLOBALROOT\Device\HarddiskVolume2

_datetime_, Info                         FindOSPartitions: Volume name for the default boot entry: \\?\Volume{_ID04_}\

_datetime_, Info                         BCD: Opening object {**_ID05_**}

_datetime_, Error                        GetOSDeviceVolume: Cannot get NT path for entry.[gle=0x000000ea]

_datetime_, Error                        FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0x000000EA[gle=0x000000ea]

_datetime_, Error                        Cannot find OS partition(s) for disk 0[gle=0x000000ea]

El problema radica en que en la base de datos del BCD existía la partición de recuperación, que el ejemplo que pongo está con ID05. Si quieres dejar eliminada esta partición para no tener que cargarte la siguiente, o ya la has eliminado y tirarás con la siguiente, no podrás continuar hasta que no arregles los registros del bcd. La opción que seguí fue eliminar el registro. Y ya lo arreglaría (y lo haré en algún momento) más adelante.

Enumeramos los registros que tiene bcd:

bcdedit.exe /enum /v

Buscamos en el listado que nos muestra el identificador que tiene de etiqueta recoverysecuence y lo eliminamos:

bcdedit.exe /delete {__idDelRecoverySequence__}

Si volvemos a hacer la enumeración ya no lo deberíamos de ver.

Por lo tanto: en este punto, que hemos eliminado la partición de recuperación, ya no habrá acceso a la misma al arrancar: hayas creado una partición con su sistema de ficheros específico o hayas dejado su espacio sin tocar.

Línea de pegote... En algún sitio proponen ejecutar:

bcdboot c:\Windows /f bios /s c:

Pero no funcionará.

¿Elimino la cuarta partición?

Aunque estoy generalizando, este es mi caso: hice un rsync de la partición de datos contra el servidor de backups (actualicé los datos) y la eliminé. Con la diferencia de que después de eliminar la partición fue cuando descubrí el problema del BCD.

Como resumen antes de volver a lanzar MBR2GTP.exe: 

• Partición recovery y su entrada BCD eliminada.
• Partición de datos eliminada sin necesidad de tocar recovery.

¿Ejecucion final?

mbr2gpt.exe /validate /disk:0 /allowFullOS 

MBR2GPT: Attempting to validate disk 0

MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Si ya no se queja aquí, podría aplicar el parámetro convert:

mbr2gtp.exe /convert /disk:0 /allowFullOS

MBR2GPT: Attempting to convert disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Fixing drive letter mapping
MBR2GPT: Conversion completed successfully
Call WinReReapir to repair WinRE
MBR2GPT: Failed to update ReAgent.xml, please try to  manually disable and enable WinRE.
MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

No obstante, parece que hay casos en los que el validate sí que da un OK pero el convert da error. 

Por último hay que configurar la BIOS para que cambie el modo legacy (heredado) a seguro o UEFI.

Además, insta a ejecutar el WinReRepair (¿WinReapir? ¿Eso es una errata?) que ya lo haré en algún momento.

No quiero olvidarme de poner algunos enlaces que pueden ser importantes, por si os fuese de utilidad o para un futuro volver a mirar por si contasen más cosas de las que he puesto aquí:

• Youtube Sysadmit
• Blog Sysadmit: convertir de MBR a GPT sin perder datos.
• IT Army: vídeo1 y vídeo2.
• Microsoft oficial
• Cannot find OS partitions(s) for disk 0: otra manera de solucionarlo. Entiende bien cuál era el problema del autor: no se sabe cuántas particiones tenía. 

Rsync desde Debían liveUSB con Veracrypt

Además de seguir trabajando con el NAS, esta entrada también la voy a escribir con el móvil.

En esta ocasión estaba intentando sincronizar con rsync la carpeta de datos principal con el NAS para hacer un backup como es debido. No voy a negar que aquí también he estado dando muchos bandazos. OpenMediaVault trae por defecto rsync, pero no es sencillo encontrar un port para Windows, ya que el existente tira de CygWin. Algo sí que he encontrado, pero bueno... Cyg* no me entusiasmaba. Otra opción era SyncThing. Que tenía que instalar un dock. Y lo acabé haciendo. Además del cliente para Windows. Pero en mitad de la configuración, cuando se estaban comunicando entre sí, vi unas direcciones IP que no eran internas y cancelé esa operación. 

No sé si fue entre medias intenté tirar de un liveUSB para hacer la sincronización. Sobretodo porque también me podía pasar que al lanzarla, el antivirus decidiese eliminar cosas que no debía. Pero no había forma de montar la partición. Más adelante me dije: "tate!! VeraCrypt!!!".

Así, hoy le he vuelto a dar para tirar otra vez del liveUSB, instalar VeraCrypt y montar la partición.

Yo voy a tirar de Debían. 

Ya lo hagamos antes de arrancar el liveUSB o cuando estemos con el sistema lanzado, nos hará falta VeraCrypt. Yo he descargado varios: tanto el de con de consola como el de GUI. Este último es el que he usado.

Aunque lo he hecho más adelante, no pasa nada por hacerlo ahora. El idioma del teclado. En mi caso lo tenía en inglés y me hacía falta en español. Para esto he seguido las instrucciones de SysAdmit. ¡Muchas gracias!

#apt-get install console-data

#setxkbmap -layout 'es,es' -model pc105

Después, tendremos que instalar VeraCrypt. En mi caso, como me he descargado un instalable .deb he tirado de dpkg.

#dpkg -i veracrypt_XYZ.deb

Podría ir bien. Pero a mí me ha dado unos cuantos problemas por alguna dependencia de librerías. Lo he podido solucionar...

#apt-get update

#apt-get upgrade

;Estos dos siguientes daban error

#apt-get install libwxgtk3.0-gtk3-0v5

#apt --fix-broken install libwxgtk3.0-gtk3-0v5

; Así lo he solucionado

#apt --fix-broken install

Ahora, volvemos a lanzar dpkg:

#dpkg -i veracrypt_XYZ.deb

Y ya sí me ha funcionado la instalación. Por lo que sólo he tenido que lanzar:

#veracrypt

Lo reconozco: lo he hecho con root, y debería de haber probado con el usuario normalito o sudo.

En mi caso estoy tirando de entorno gráfico. Una vez he podido seleccionar la partición y he introducido la contraseña, se me ha montado en /media/veracrypt1. 

Hasta aquí he llegado. Sabiendo que esa es la ruta, me quedaría probar a ejecutar rsync:

$ rsync --dry-run -rahuv /media/veracrypt1 usuario@IP:/recursoCompartido/

Y si no hay problemas, la prueba de sincronización empezará. He tenido que poner la v porque no me ha mostrado nada al finalizar. Si te gusta el resultado, sólo queda volver a lanzarlo sin --dry-run.

[update]

No he podido actualizar esto hasta ahora. Este comando no es que no funcione. Pero te deja los datos en raiz, en una carpeta con el nombre /recursoCompartido/, creándola si es necesario. Sin embargo, anteponiendo rsync://, sí que te lo guardará en la ruta donde el servidor tiene marcado ese recurso compartido.:

$ rsync --dry-run -rahuv /media/veracrypt1 rsync://usuario@IP:/recursoCompartido/

[/update]

Si lo probáis, contadme qué tal os ha ido. O si tenéis más ideas al respecto, también son bienvenidas.

Buscando ficheros duplicados

 Como ya os conté hace apenas unos días estoy configurando OpenMediaVault como servidor NAS. Y después de copiar un montón de datos de los distintos discos con backups hechos a mano no me queda otra que organizar todos los datos. Ya se sabe, en casa del herrero...

Para ello estoy usando varias herramientas. La de dupeguru, que es precisamente la que os conté el otro día, puede servir pero... Realmente no hace las comparaciones por hash, que creo que es sí que es importante. Y buscando la otra que vi y tenía pendiente de probar, rmlint, me he encontrado con un post en el que muestran un listado de más herramientas con comparativas de tiempos y consumo de memoria. 

La entrada en cuestión es esta:

https://www.virkki.com/jyri/articles/index.php/duplicate-finder-performance-2018-edition/

Espero que os sea de utilidad para cuando os haga falta. 

OpenMediaVault y dupeGuru

Hace menos de una semana me instalé en una máquina OpenMediaVault, una distribución Linux para montar un NAS. 

De momento estoy intentando hacerme con el sistema. La idea es hacer backups de los datos, sobre todo de los distintos discos que tengo dispersos. Pero de momento tengo que tener cuidado porque no he podido configurar la redundancia de los discos. Ya veré si acabo contando algo sobre la configuración después de su instalación (como cualquier otro Debian). 

Uno de los módulos que tiene es la posibilidad de instalar containers en de docker. En OpenMediaVault 5 usan Portainer. La verdad, nunca había trabajado con Portainer (realmente nada de docker). Y para la instalación de los distintos stacks (¿son como las imágenes que después puedes pedir que se carguen como si fuesen máquinas virtuales?), que son realmente las aplicaciones con las que se trabajan, se puede hacer pasando la URL de un git, subiendo un fichero de texto escribiendo el contenido de ese fichero en el textarea. Sé que es un poco lío (y cuando lo lea dentro de unos meses me llevaré las manos a la cabeza sorprendiéndome de lo mal que me expreso).

Resumen: quieres instalar una aplicación de docker, escribes una ristra de parámetros con su sintaxis, y si es capaz de encontrarla con esos parámetros, la instala.

Una de las aplicaciones que se proponen para buscar ficheros repetidos es dupeguru. Es muy básica y por lo que he podido averiguar, no verifica los hashes. Ya buscaré otra que lo haga. El problema es que no hay publicada la estructura que hace falta para esta forma de instalar y para esta aplicación.

Para ver si podía instalarla del mismo modo que lo hice con una anterior que sí lo tenían publicado lo que intenté hacer es basarme en los sus parámetros y después cambiar o añadir los valores necesarios.

Este es el resultado:

---
version: "2.1"
services:
  dupeguru:
    image: jlesage/dupeguru
    container_name: dupeguru
    environment:
      - PUID=XYZ
      - PGID=ZYP
      - TZ=Europe/Madrid
    ports:
      - 5800:5800
      - 5900:5900
    volumes:
      - /srv/dev-disk-by-_______/dirConfigs/dupeguru:/config
      - /srv/dev-disk-by-_______/carpetaVirtualRaiz:/storage
      - /srv/dev-disk-by-_______/trash:/trash
    restart: unless-stopped

El PUID y el GUI se consiguen accediendo por ssh al servidor, y ejecutando

#id usuarioDeseado

Así se obtienen el id de usuario y de grupo principal.

Aunque me estoy adelantando un poco: en OpenMediaVault se trabaja con carpetas compartidas. Al final son carpetas virtuales que están asociadas a un disco duro y a una ruta dentro de ese disco duro. Realmente esa carpeta está asociada a una ruta, y es la que se corresponde con

/srv/dev-disk-by-_label_o_ID_del_disco/carpeta

Para esta aplicación, el puerto 5800 está asociado al acceso a la aplicación vía web y el 5900 está para acceder por VNC.

Así, tuve mucha suerte y después de poner estos datos (y algunos problemas como, por ejemplo, no poner en el textbox el nombre del stack y el valor de algunos parámetros (como la versión, no sirve la 3) conseguí que funcionase. 

Yyyyy... ya está. Aquí lo tenemos. 

Para cualquier duda o problema por favor, avisadme. Pero como comento, en esto de los dockers soy bastante nuevo. No obstante, se hará lo que se pueda. También, como de costumbre, las aportaciones también son muy bienvenidas. 

Arrancando UEFI en PCs HP

Pero post que escribo desde el móvil. Con los riesgos que ello conlleva.

Me ha llegado una máquina que no se iba a usar más para su propósito inicial y por sus características me dije que sería estupenda para hacerme un NAS. Ya veré si publico algo al respecto.

Este ordenador es una (mini-) torre HP. Y la verdad, al abrirla... No termina de darme todo lo que me haría falta, pero para empezar voy a darla por válida.

El problema que me he encontrado, tanto a la hora de arrancar el USB de instalación como el sistema ya instalado ha sido que la configuración del UEFI impedía iniciarlos.

Para el USB incluso tuve que probar a poner el modo no seguro (legado o legacy) sin ningún éxito. Pero si en el POST, al encender la máquina, le damos a la tecla escape (ESC) nos muestra un menú. Y en ese menú nos ofrece seleccionar con los cursores opciones como "Menú de inicio" o "Ejecutar aplicación EFI". En un principio, con mínimo una de ellas, se debería de poder arrancar el dispositivo.

Una vez instalado el sistema, me he encontrado con que tenía que seleccionar la segunda opción sí o sí. Cada vez que se apague o reinicie el sistema. Y eso es inasumible con un ordenador que no debería de tener ni teclado, pantalla o ratón.

En algunas búsquedas no se daban muchas pistas a parte de la queja (con razón) contra el fabricante de dificultar (casi imposibilitar) a los compradores la decisión de qué arrancar y qué no. (Opinión: No digo que no se pueda poner una protección, pero de ahí a casi impedirlo...). 

Las últimas que he encontrado proponen una solución... Un workaround. Se trata de hacer una copia del fichero UEFI que instala el sistema operativo en cuestión en una ruta predeterminada.

#mkdir /boot/EFI/boot/

#cp /boot/EFI/__nombreX_/grubx64.efi /boot/EFI/boot/bootx64.efi

Sólo quedaría asegurarse de que los permisos de la nueva carpeta y del fichero son los mismos. Sólo por precaución.

Y ya estaría. Al reiniciar, no debería de dar ningún problema.

Estoy viendo que algunos cambios en el arranque podrían afectar, ya que en el setup, menú configuración de arranque seguro, las dos opciones , compatibilidad heredada y arranque seguro se están quedando deshabilitadas. 

No sé. En principio, así deberías de poder arrancar sin ningún problema. En mi caso ahora voy a formatear el disco que tenía esta máquina. 

Espero que para en caso de necesidad os sea de utilidad. De todas formas, si tenéis más ideas para solucionar este problema, bienvenidas sean.

****

https://askubuntu.com/questions/554690/hp-uefi-doesnt-boot-ubuntu-automatically

https://ubuntuforums.org/showthread.php?t=2392797

Trasteando con discos duros

Una vez más, voy a escribir esta entrada con el móvil. No creo que sea muy larga. A ver qué sale.

Por cierto, y antes de empezar, como de costumbre el disclaimer típico en estos casos: cualquier intento de repetir lo que aquí se muestre puede llevar a perder los datos (o con mucha suerte, recuperarlos). Si quieres hacerlo es bajo tu riesgo y responsabilidad.

Hacía mucho tiempo que quería hacer cosas con discos duros. Realmente quería destruirlos, algo que es relativamente fácil. Los que tenía, también llevaban almacenados muchísimo tiempo. Además, dos de ellos eran pareja: exactamente iguales. Y al intentar ver qué contenían... Uno encendía pero hacía "clicks" y el otro ni se movía.

La primera idea fue cambiar las dos interfaces (en este caso, IDE). 

Y, en efecto, funcionó. Además, conseguí ver el contenido del disco con su interfaz nueva.

El siguiente paso: arreglar los clicks. 

Siempre se ha dicho que nunca enciendas el disco duro abierto. Que hay que hacerlo en una sala ¿blanca? (¿Limpia?); Vamos: una sala preparada para que no haya X partículas de polvo en Y metros cuadrados. Y eso en una casa... Buscaré información porque he visto algún vídeo donde dicen que mostrarán en otro cómo montar una caja que cumpla esa función.

En mi caso, lo voy a hacer a la aventura. No pasa nada porque pierda estos datos. Pero ya digo que de las pruebas que he hecho y las herramientas disponibles, no he conseguido nada.

Estos son los discos duros abiertos:

Posiblemente por el efecto de mi propio reflejo no se perciba muy bien. Pero... ¿Sabrías decirme qué disco tiene el problema de los clicks? ¿Izquierda o derecha? Eso es: el de la izquierda. Se puede apreciar una circunferencia en el centro que no aparece en el disco de la derecha.

La landing zone está en el interior del plato (sólo tienen uno). Además, aunque sólo tiene un cabezal (para leer por ambas partes del plato) está preparado para que a la hora de fabricar con más cilindros puedan usar la misma pieza. Debajo podrían caber más:

Aquí me encuentro con varios problemas.

Uno es averiguar qué le pasa o por qué el motor del cabezal no va bien. 

Otro, es intentar poner el cabezal del que funciona en este que no lo hace. Para eso tengo que conseguir mover todo el cabezal hacia afuera. A su vez: me hará falta poner un se parador de cabezales en ambas piezas. ¿Cómo es ese separador? Es... Como una hilera de terminaciones de las bridas. Se ponen entre medias de ambos lados del cabezal. Y después, con mucho cuidado, se tendría que desplazar hacia afuera. Y yo no tengo de eso. Además, cabe la posibilidad de que esa pieza negra con el número de serie entorpezca (o haya que desmontarla también). 

En teoría, y por lo que he visto en algún vídeo: se sujeta el centro de los platos con un destornillador y con otra herramienta y mucho cuidado (además del separador ya puesto) tira hacia afuera. 

Después operar con lo que se quisiera. Si es que los cabezales no volvieron a la landing zone que debía de estar fuera, ver si se pueden recuperar los datos. O intercambiar los platos y llevarlos a otra caja (sin descuadrar los: la posición de unos con los otros también es crucial). O al revés: quitarle todo el motor de los cabezales y ponerle otros.

Como veis, ahora mismo, no tengo herramientas no toda la experiencia para hacerlo. No obstante, si alguno la tiene y quiere compartir al respecto, bienvenido sea.

ESP8266MOD muestra caracteres raros

Hace tiempo, en  un evento, creo que fue en una Navaja Negra, se hizo un taller sobre Arduino. Y nos dijeron que compráramos varios módulos y cosillas.  Entre otros uno para wifi. El que me acabó llegando cuando busqué el ESP8266 (el chip indica: ESP8266MOD) es el modelo de WebMos D1. La verdad, aún me cuesta muchíiimo identificarlos (y mira que no es muy difícil). 

Haciendo pruebas, a parte de la dificultad que parece que está teniendo para conectarse a mi Mikrotik (o mantenerse conectado) en algún momento aparecían caracteres raros pero no les dí ninguna importancia. Hasta que después de hacer una prueba más o menos real en la que, a pesar de todas las precauciones tomadas, podía freír el módulo sin apenas pestañear. Y no funcionó. Fue cuando volví a ponerlo en el PC para actualizar el código fuente cuando empecé a fijarme más en esa ristra de caracteres que aparecían en el monitor serie y que no tenían ningún sentido. Unos caracteres raros o extraños de los que salen cuando se intenta imprimir por pantalla un binario.

En este punto es cuando uno empieza a temer que se ha cargado el bicho. Y dada la situación actual no sería fácil que llegase otro más o menos rápido. Me puse a comentar código a subir otro que ya sabía que funcionaba... Pero seguían saliendo en cuanto arrancaba. Porque después me imprimía bien el resto de datos.

Ya muy mosqueado, hice una búsqueda. Con la magnífica suerte de encontrar mucho más rápido de lo esperado la solución.

Las palabras clave de mi búsqueda:

esp8266mod console shows strange characters

Según los resultados: este módulo tiene un reloj (bueno, dicen cristal) que por defecto no va a 40MHz, y que permitiría comunicarse a 115.200 baudios, sino a 26Mhz, lo que fuerza a que vaya a 74880. Si en el monitor serie, en el combo box de velocidad, se le indica justo esta, al reiniciar el módulo, y por arte de magia, aparecerán los datos.

La fuente que me ayudó a solucionarlo y a su vez la fuente de donde lo ha obtenido.

Espero que os sea de utilidad por si en algún momento os hace falta.

Failed to start raise network interfaces

Hace mucho tiempo que recuperé un PC y me puse a reconfigurarle una Debian. Además del lío que tengo montado para dejarle un kernel perfecto (para mí), que me está llevando bastante más tiempo de lo que invertí en mis primeros pinitos con Gentoo, la lié bien con la configuración de la tarjeta de red.

El resumen: entre configuraciones del kernel (que esto es otra historia que ya veré si cuento) y toquetear la tarjeta de red, nadas más arrancarlo desde grub me aparecía un mensaje parecido a:

Failed to start Raise network interfaces

Lo que hacía que no cargasen las tarjetas de red y aunque las levantase a mano tampoco funcionaban. Con un poco de tiempo he podido buscar la solución, y no tenía nada que ver con el kernel (pero como lo estaba toqueteando me imaginé que iban por ahí los tiros).

La pena es que las direcciones de las soluciones las cerré por el pequeño afán de quitar pestañas y ventanas abiertas (y aún así tengo un montón más. ¡Muchas!).

Al lío: ¿Qué comandos encontré para debuguear o localizar la solución?  Estos los siguientes comandos (cuyos resultados acabé pasando posteriormente a un fichero para escribir este post).

journalctl -xe

Por lo que recuerdo, y buscando en los resultados, tampoco arrojó mucha luz sobre el problema.

journalctl -u networking.service

A pesar de que este comando me estaba gritando cuál era el problema:

-- Logs begin at Tue 2020-03-17 15:47:36 CET, end at Tue 2020-03-17 19:52:11 CET. --
mar 17 15:47:41 mihostname systemd[1]: Starting Raise network interfaces...
mar 17 15:47:41 mihostname ifup[409]: ifup: /etc/network/interfaces:27: option with empty value
mar 17 15:47:41 mihostname ifup[409]: ifup: couldn't read interfaces file "/etc/network/interfaces"
mar 17 15:47:41 mihostname systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
mar 17 15:47:41 mihostname systemd[1]: networking.service: Failed with result 'exit-code'.
mar 17 15:47:41 mihostname systemd[1]: Failed to start Raise network interfaces.

La típica lectura en diagonal hizo que no lo viera. El fichero /etc/network/interfaces.

systemctl status {systemd-network,systemd-resolved,networking,NetworkManadager}

Este comando, también daba un resultado similar. Y viendo lo que hice después en ese fichero de "log" improvisado que hice, en efecto, aquí me encontré con el problema para solucionarlo:

 systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-resolved.service.d
           └─resolvconf.conf
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-03-17 15:47:41 CET; 4h 13min ago
     Docs: man:interfaces(5)
  Process: 409 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 409 (code=exited, status=1/FAILURE)

mar 17 15:47:41 mihostname systemd[1]: Starting Raise network interfaces...
mar 17 15:47:41 mihostname ifup[409]: ifup: /etc/network/interfaces:27: option with empty value
mar 17 15:47:41 mihostname ifup[409]: ifup: couldn't read interfaces file "/etc/network/interfaces"
mar 17 15:47:41 mihostname systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
mar 17 15:47:41 mihostname systemd[1]: networking.service: Failed with result 'exit-code'.
mar 17 15:47:41 mihostname systemd[1]: Failed to start Raise network interfaces.

El fichero /etc/network/interfaces. En este punto me quedaba revisar qué podía tener mal. Es el típico fichero que has modificado tantas veces que deberías de saberte de memoria cómo se configura pero siempre hay algún pequeño punto que se queda colgando.

En mi caso, los datos importantes que contenía eran:

auto lo

iface lo inet loopback

# The primary network interface

#iface eth0 inet static

allow-hotplug eth0

iface eth0 inet dhcp

#allow-hotplug wlan0

iface wlan0 inet static

        wpa_supplicant

El problema, básicamente: era que el parámetro wpa_supplicant estaba mal. No sé si es porque en algún momento leí que poniéndolo buscaba el fichero de configuración directamente (si fue así me pregunto "¿¿¿por qué lo pensaría???"), ¿me olvidaría de que había que ponerlo? (una vez más, si fue así: ¿por qué no me daría cuenta?) pero, lo más sorprendente es que para verificar si me estaba dejando algo en esta configuración me encontré con que ahora ese parámetro no es así (o al menos, para lo que yo necesitaba). Esta tarjeta la tendría que dejar configurada de esta otra forma:

#allow-hotplug wlan0

iface wlan0 inet static

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Y así dejaría de quejarse. Eso sí, y como curiosidad o anécdota: no conseguí conectarme a la red cableada... Un poco más tarde acabaría crimpando dos cables de red: el de esta máquina y el de otra que también me estaba dando problemas de conexión.

Sólo como histórico para que cuando tenga problemas tan básicos de estos problemas, y aunque no debería de pasarme, me voy a dejar algunos enlaces por aquí:

• NetworkConfiguration
• Network interfaces
• Tarjetas de red wifi /Wifi network interfaces 
• Debian y wpa_supplicant

Crónica jornada III - RootedCon 2020

Tercer y último día de RootedCon 2020. Como de costumbre he llegado antes de lo normal y he podido hablar un rato con Longinos y unos cuantos compañeros más antes de entrar a las charlas.

La primera la han dado David Madrugán (@radiohacking) y José Manuel Vera (@jmveraortiz)

RootedCon 2020 - David Madrugán y José Manuel Vera - El camino de Hacktiago

Han nombrado a varias personalidades históricas consideradas las primeras "hackers": Nevil Maskelyne, René Carmille, Hedy Lamarr... Después de la introducción nos han enseñado unumerables museos por todo el mundo relacionados con las comunicaciones y la criptografía, empezando en Berkley Park (donde Alan Turing ayudó a construir la máquina para descifrar Enigma), viajando a Rusia, Alemania (Berlín), Estados Unidos (las sedes de la CIA, NSA..) y volviendo a distintas localizaciones que tenemos en España y apenas se conocen.

La siguiente ponencia la dio Pepelux (José Luis Verdeguer, @pepeluxx).

RootedCon 2020 - Jose Luis Verdeguer aka Pepelux - Atacando comunicaciones cifradas

Ha empezado explicando cómo funciona el protocolo SIP dando unos cuantos detalles de sus cabeceras. Se ha centrado en la importancia por la que es necesario cifrar las comunicaciones, entre otras, para evitar el robo de credenciales y de la sesión o que nos puedan escuchar las conversaciones. La idea es protegerse de otros usuarios, gobiernos, e incluso, terroristas. Cuando un sistema es abierto, y por lo tanto siempre se pasa por un proveedor, las comunicaciones no se pueden cifrar. Ha remarcado algunas cuestiones como si hay cifrado extremo a extremo o si se sabe quién es el proveedor. Hablando de los cifrados nos ha remarcado dos elementos a los que se les puede aplicar: la señal (por TLS), y la sesión (ya sea por SRTP, Miley, ZRTP o DTLS). Nos ha mostrado distintas combinaciones porque se pueden hacer conexiones cifrando sólo uno de esos dos elementos o ambos a la vez. Nos ha mostrado ejemplos de cada una de las combinaciones mostrando qué se llegaba a analizar desde un wireshark y qué no. Ha terminado hablando y comparando la aplicación Signal del protocolo con el mismo nombre.

Después de estas charlas hemos descansado un ratito pudiendo disfrutar también de alguna concha Codan.

La siguiente ponencia estuvo dividida en dos partes: la primera fue por David Reguera (@fr33project) y Abel Valero Lozano (@sanguinawer).

RootedCon 2020 - David Reguera y Abel Valero - Roapt evil mass storage & Tu-ya aqui?

David nos ha mostrado una placa pequeña, con un conector USB, construida para exfiltrar datos. Puede mandar los datos por RF (frecuencia 433MHz) o guardarlos en una tarjeta micro SD, en una partición oculta. Nos ha contado unas cuantas contramedidas para dificultar el forense del dispositivo, como por ejemplo, cambiar su identificador de tipo de USB (teclado, ratón, etc) como el número de serie. La verdad, cuando se la describía a algunos compañeros más tarde lo hacía comparándola con la ducky, pero no sabría decir si he estado muy acertado (aunque sé que diferencias, haberlas, haylas). Al terminar su parte, Abel nos ha contado que algunos aparatos de IoT necesitan acceder al servidor de su fabricante para funcionar y no pueden hacerlo directamente en local. Nos ha enseñado cómo descubrió que uno de los que tenía montaba un chip ESP8266, empleado para comunicaciones wifi. Y al estar liberada la información de este chip, nos ha ido desgranando cómo extrajo el firmware del apartado, las dificultades y pasos para decompilarlo y finalmente obtener todos los datos necesarios en claro para conectarlo sin depender del servicio del fabricante.

Al acabar esta charla, que se ha alargado un poquito más de lo esperado (cosas que a veces pasan y son inevitables) nos hemos ido a comer.

Una vez ya estuvimos bien comidos, hemos podido asistir a la charla de David Meléndez (@taiksontexas).

RootedCon 2020 - David Meléndez - Protocolos industriales.. carreteras comarcales

David también ha dividido su exposición en dos partes. En la primera nos ha contado cómo descifró el termostato remoto del aire acondicionado de sus padres después de que dejase de funcionar. Nos ha mostrado la circuitería interna, tanto del mando remoto (el termostato) como de la placa del propio aire. Una de las opciones que tenía el circuito del aire es que conectando un cable en un punto determinado se podía encender perfectamente pero a piñon fijo: con unos parámetros determinados por el fabricante, pudiendo salir del paso (encender así o dejarlo apagado). A partir de esos circuitos investigó los chips internos y conectando un osciloscopio pudo descifrar qué comandos mandan cada uno de los botones. Y con esto y un Linux se fabricó su propio termostato. La segunda parte de su charla ha ido sobre sistemas antidrones. Se han enumerado varias formas para controlar drones sin tirar de wifi: RF clásica, LoRa (la verdad, no me suena), 3G/GSM y la idea que ha tenido: por radio FM y la señal RDS. Nos ha explicado cómo funciona RDS mencionando el proyecto PI-FM-RDS. Hay que tener en cuenta que será con un alcance mínimo, tal como funcionan los aparatos bluetooth que emiten por radio FM el audio del teléfono conectado al mismo. Nos ha hecho una demo.

Al terminar David, Ernesto Sánchez (@ernesto_xload) nos ha hablado de vehículos compartidos de movilidad urbana.

RootedCon 2020 - Ernesto Sánchez Pano - Hackeando los sistema de movilidad urbana compartidas

Como muchos de los ponentes, nos ha expuesto las razones por las que inició esta investigación: curiosidad, introducirse en el IoT y el hardware mola. El tema de esta charla ha ido encaminado a la seguridad física de los patinetes eléctricos de alquiler (aunque ha remarcado que se puede aplicar a cualquier otro tipo de vehículo) en lo que respecta a su construcción y a evitar que alguien se los lleve prestados permanentemente. Las razones por las que alguien querría uno de estos aparatos es quedárselo para uno mismo, vender las piezas o saltarse la forma de pago y viajar de gratis. Ha explicado las tripas de los patinetes de uso particular y de los que están destinados al alquiler, incluyendo la evolución física de los mismos (como por ejemplo, que uno de alquiler se pudiera plegar en los inicios y ya no). Su análisis se ha centrado en uno producto en particular, el Segway Ninebot E2. No se ha olvidado de hablar de los controladores y las placas que los alquilados llevan dentro (tracking por GPSs comerciales o normales + redes móviles + bluetooth) o cierres físicos (tornillos de seguridad, tornillos no estándares, remaches, jaulas). También ha hablado de algunos ataques, tanto físicos (como cambio de piezas, aunque algunas sólo se distribuyen a talleres) como "lógicos" (reflasheo de controladoras). Y nos ha hablado de seguridad en comunicaciones bluetooth, redes móviles y GPS (en el que se ha esforzado en insistir que no se manipulen, sobretodo, estas señales que pueden afectar de una forma muy grave a sistemas inesperados y críticos como aviones además de los multazos que puede acarrear).

Y para finalizar, Omar (@omarbv), de la organización, ha presentado los premios Hacker Night 2020 + Yogosha (@YogoshaOfficial) junto a Lucas Varela y Kevin, en los que había en juego 200.000 € de parte de varias empresas del Ibex35 para uno de los bug bounties más especiales que no se habían hecho en España (¿me ha parecido entender a Román que en Europa?).

RootedCon 2020 - Omar, Lucas Varela y Kevin - RootedConn & YogOsha: Premios Hacker Night 2020

Nos han dado cifras: 70 hackers enviaron 74 informes de los cuales 42 han sido aceptados, Y se han entregado más de 10.000 € en premios. Han invitado al clasificado con el mayor premio al escenario, y aunque en ese momento no he podido tomar nota del nombre, ya lo tengo aquí (Carlos, @MrMcCharly). Además del bounty que se ha ganado le han entregado de premio otros 3.000 €.

Y con todo esto, un año más, hemos podido disfrutar de RootedCon. Espero que todo vaya igual de bien que hasta ahora y que el año que viene todos podamos disfrutar de una nueva edición.

Crónica jornada II - RootedCon 2020

Hoy también ha sido un buen día. Después de un pequeño desayuno y leer el periódico han empezado las charlas, incluso con algo de tiempo para dar una pequeña vuelta. Hoy también he podido estar un rato con David y Julián.

Para empezar, Román nos ha presentando la nueva BSO de la organización, compuesta por Vacío Q.

Ahora sí, Roberto Santos (@elmaisbuscado) y Javier Rascón (@jvrrascon) nos han contado un incidente que tuvo un cliente suyo.

RootedCon 2020 - Roberto Santos y Javier Rascón - Rootkit Necurs

El cliente tiene un AV que salta con un fichero que resulta que está firmado por certificado válido para Microsoft y del que apenas hay detecciones. Ese ejecutable resulta que además de bajarse alguna que otra cosilla, exfiltra información del sistema operativo, red y tarjeta gráfica (muy importante) pero no usa persistencia. Además, descartaba algunas versiones de Windows. A medida que iban analizándolo se iban encontrando con que actualizaba la librería del sistema crypt32.dll para poder firmar con sha256. Se encontraron con que el bicho tenía una ejecución en modo kernel y otra en modo user que es la que se comunicaba con el C&C. Y que los datos que iba extrayendo los guardaba cifrados en una clave del registro. Nos han contado unos pocos comandos a los que podía responder y alguna de sus medidas de protección (como por ejemplo, listas negras de procesos, antivirus, etc). Al final nos han enseñado dos herramientas que han hecho para detectar si existe y otra para eliminarlo del sistema (NeCsist y NeCure). La tarjeta gráfica se usaba para minar criptomonedas. 

Cuando acabaron se subió al escenario Alfonso Muñoz (@mindcrypt).

RootedCon 2020 - Afonso Muñoz - Stego attacks by desing

Ha empezado recordando unas cuantas herramientas de estegaNOgrafía (ahora sí!! A ver si de esta forma me acuerdo de escribirlo bien...) y los problemas que dan. También nos ha hablado de dos periodos distintos, antes de 2019 y después de. A partir de aquí nos ha contado la técnica para ocultar código ejecutable en imágenes, y se denomina polyglot. Se trata de un fileless malware: se autoejecuta sólo y hay que conseguir no hacer ruido. Nos ha mostrado distintos ejemplos en imágenes JPEG: con JavaScript, PHP, Powershell & shellcode (ambos, para hacerlo multi plataforma). Hay que conseguir que estos ficheros se puedan abrir de las dos formas (con la del principal y con la del código que se introduce). No sólo se puede hacer con JPEG, sino también lo ha conseguido hacer con un PDF que consiguió subirlo a LinkedIn. Como nota el nombre de una herramienta que ha mencionado: bipolar.

En este punto todos fuimos a desayunar unas conchas Codan.

Después de este descanso Lorenzo Martínez (@lawwait) nos ha presentando una herramienta que ha construido.

RootedCon 2020 - Lorenzo Martinez - WinTriage

Ha empezado hablando de las herramientas que tantas veces nos ha enseñado en sus formaciones de DFIR: Windows Live Response (WLR, de Brimor Labs), IRTriage y CyLR. Como cada una de ellas tenía ciertos problemas (como que WLR mancha mucho la máquina de las evidencias,  invierten mucho más tiempo en cosas que se podrían hacer después, nombres en ficheros que copian imposibles de tracear...) decidió montarse una él mismo que hiciera lo mismo que hacen estas pero arreglando esos problemas que veía que las anteriores tenían. Ahí es donde nace WinTriage (voy, y casi la rebautizo como WinDFIR). Está desarrollada en el lenguaje AutoIT, la selección de las opciones deseadas para extraer es muy modular, ocupa muy poco espacio en memoria, es compatible con XP/W2k3... Así, nos ha hecho varias demos en máquinas virtuales (para extracción en vivo) con w2k3, Win10, windows 2019 y en modo offline montando una imagen en FTK. Eso sí: por licenciamiento de las herramientas de las que tira hay que bajárselas una a una. La pena es que cuando ya estaba respondiendo alguna pregunta me puse muy inquieto porque la gente ya estaba saliendo por la hora y terminé saliendo yo tambien. :( No me gusta nada hacerlo y no me sienta bien. Pero es algo que hay que reconocer.

Al salir de esta charla fui al track principal, la sala 25, para ver la charla de Manuel García Cárdenas (@hypnito) y Jacinto Castillo Solana (@serchi3) que nos iban a hablar de WordPress.

RootedCon 2020 - Manuel García y Jacinto Castillo - WordPress: another terror story

Han expuesto los números de su utilización, siendo el CMS más usado del mundo. Además, también nos han enseñado las estadísticas de los plugins instalados, las vulnerabilidades y de los sitios vulnerados. Nos han mostrado una metodología y análisis de unos cuantos plugins. Ellos han desarrollado una herramienta que se ha encargado de analizar el código fuente de todos los plugins del repositorio de WordPress, a la que han llamado WordPressTerror, y desde la cual se puede ver las estadísticas qué vulnerabilidades son las más presentes, como por ejemplo, SQLi. Esta herramienta ha generado un informe que han mandado a los responsables de WordPress en directo (o lo han intentado, pero han cancelado en el último segundo) haciendo un responsible disclousure.

Cuando terminaron, nos fuimos a comer y a descansar un poquito.

Después de la comida me metí en la charla de Mario Pérez de la Blanca (@mariopdelab).

RootedCon 2020 - Mario Perez de la Blanca - AFDX Twin (manipulando redes de aviónica)

La verdad, esta charla me ha costado mucho, mucho de entender. Además de mostrarnos unos cuantos vídeos corporativos de Airbus (muy chulos, eso sí) y alguno relacionado con el funcionamiento de la presurización de los aviones nos ha hablado de los protocolos de comunicación que utilizan los distintos sistemas internos que llevan los aviones. Nos ha contado varios protocolos antiguos y se ha centrado en el más reciente. El protocolo en concreto se llama AFDX (y se usa una tarjeta ethernet con dos conectores RJ45: twin-ethenet). Siempre hay que tener en cuenta que todos los sensores y sistemas que se conectan van replicados por duplicado y esto hace que sea muy costoso por el peso que conlleva y el espacio que ocupa (que se multiplica por dos). Al dar por hecho que hay confianza en las comunicaciones las colisiones de red son inaceptables. Y es una comunicación full duplex con topología en estrella (y escalable), en la que un cable transmite y otro recibe. Se busca garantizar el servicio, por eso se replican las comunicaciones. Al transmitir dos sistemas a la vez el paquete que primero llega es el que gana.

Al acabar esta charla José Manuel Sacristán (HoneyWell) y Francisco Sucunza (Capgemini) nos han hablado de implantar seguridad IT en entornos industriales (OT).

RootedCon 2020 - José Manuel Sacristan y Francisco Sucunza - Retos de seguridad en la virtualización OT

Han empezado explicando las razones por las que se querría virtualizar en un entorno industrial: espacio, ahorro de energía, solución a la seguridad física, recuperación ante desastres... Han expuesto varios escenarios de virtualización según la sección donde se quiera poner un dispositivo (por ejemplo, en la la DMZ). Una problemática que puede aparecer es que si un firewall tiene que analizar el contenido de un paquete a su vez hace falta que entienda el lenguaje de los sistemas industriales que están instalados (y no siempre es factible o fácil). Los controladores industriales (en este entorno también se llaman PLCs) no se pueden virtualizar en producción y sólo sería factible para hacer pruebas en laboratorio. Después de enumerar más problemas han enseñado qué producto de HoneyWell.

Cuando acabaron pudimos ir a descansar y reunirnos con los compañeros que se habían ido a otras salas.

Después del descanso, se empezó el RootedPanel:

RootedCon 2020 - RootedPanel - Javier Maestre, Cristina Carrascosa, Félix Moreno, Pablo Burgueño

En este hubo cuatro ponentes: Javier Maestre (moderador), Cristina Carrascosa, Félix Moreno y Pablo F. Burgueño. El debate iba sobre DAOs: Organicaziones Autónomas Descentralizadas. La verdad, me ha costado seguirla. Posiblemente porque ya estaba algo cansaete. Han puesto como ejemplo de precedentes de DAO Linux y BitCoin como el primero. Se han enumerado distintos tipos (BitCoin como dinero, ONGs no registradas como "Democracia Real Ya", empresas, resolución de conflictos..). Han hablado de uno específico para hacer intercambio de BitCoins, ya que hasta ahora hacía falta una entidad real (no DAO) para porderlo hacer y esta nueva se llama Bisq, en la que se quiere que cada usuario controle su propio dinero y sus propios datos. También se ha hablado de la personalidad jurídica de una DAO, para que tenga la posibilidad de contratar, denunciar y ser denunciada.

Para finalizar la jornada de hoy se han presentando los premios Antonio Ropero que se entregan a Cryptored, Jorge Ramió y Alfonso Muñoz como representantes del proyecto Criptored (@criptored). Y también han invitado al padre de Antonio.

RootedCon 2020 - Alfonso Muñoz y Jorge Ramió - Criptored es galardonado con el premio Antonio Ropero

Aunque alguna charla me ha costado un poquito más (como también se ha podido ver aquí), hoy no ha estado mal el día. Las jornadas de mañana sábado se esperan igual de interesantes o más.

Crónica jornada I - RootedCon 2020

Un año más he tenido la oportunidad de asistir al evento de seguridad RootedCon. Además, como de costumbre, he llegado bien pronto por lo que he tenido la oportunidad de saludar a la organización (Chencho, Arantxa, Román, Omar, Alberto...) sin ningún problema antes de que llegasen los 1.200 asistentes que de media vienen todos los años. Incluso he podido ayudar a Chencho a enseñarles a los voluntarios cómo identificar a los asistentes. También he podido hablar dos minutos con Nuria y Noelia, de Eventos Creativos. Minutos después me encontraría con Julián (@tXambe) y Joseba (@josepalbors). Además, más adelante, después de una taza de té, nos encontraríamos con David (@esferared). O ver a Pablo (@PYDotCom). ¡Incluso por la tarde me encontraría con Longinos (@l0ngin0x)!


Hemos empezado con la key-note, en la que Román (@patowc) ha sido el maestro de ceremonias.

RootedCon 2020 - Román (y de fondo el resto del equipo RootedCon)

Se ha mostrado un pequeño clip como parodiando el problema del coronavirus. Además de mostrar las fotos de los integrantes de la organización y los valores que la conforman. No se ha olvidado de mostrar los distintos patrocinadores de este año, muy importantes para poder tener todo lo que tenemos al precio que pagamos y que si fuese más caro sería difícil que muchos pudiéramos asistir. También nos ha mostrado la foto de una cepa para hacer la broma de "COVID-19" pero... Era de la Yersina Pestis (peste negra). Y para finalizar ha adelantado un poco el tema del RootedPanel: GoodJob e #include.

La primera exposición la ha hecho Jesús Jara López.

RootedCon 2020 - Jesús Jara López - Live coding

Nos ha explicado qué es el live coding. Se trata de crear música a través de lenguajes de programación y que se ejecutan mientras se codifica por lo que esa composición va evolución en directo. Esta forma de crear música ayuda a desarrollar la creatividad. Nos ha hablado de distintos proyectos que van enfocados a este fin, como es Sonic Pi (otros son tidalcycles, foxdot, extempore, hydra, ixi lang). En general cada proyecto está basado en un lenguaje de programación ya conocido (JAVA, python, C, etc). Es muy importante que el público vea cómo se va codificando la composición en directo por lo que proyectarlo (o mostrar la pantalla del código) es indispensable. El resumen: la transparencia es fundamental. Eso no quita que alguna estrategia pueda estar pregrabada. También nos ha descrito algunas conferencias internacionales, como la ICLC relacionadas con esta práctica. Los conciertos que se hacen con esta música se les llama "retro rave". Y nos ha hecho una pequeña demo que nos ha dejado a (casi) todos con la boca abierta.


Después del concierto Gonzalo Asensio y Pablo Vera nos han hablado de la cerveza "Hackers ciberbeers".

RootedCon 2020 - Gonzalo Asensio y Pablo Vera - Hackers ciberbeers

Han iniciado la charla hablando de un viaje que hicieron a la India y que les dijeron que acabarían haciendo cerveza (quedando ellos bastante... que no se lo creían). Tiempo después acabaron decidiendo hacerla con la condición de tirar de hacerlo como un proyecto de pensamiento lateral y las distintas maneras de solucionar los problemas. Se propusieron varios objetivos: disfrutar haciendo el proyecto (y la cerve), hacer comunidad, una bebida sin ánimo de lucro y respectar tanto el medio ambiente como el comercio local. Para cada paso que necesitaban hacer lo asociaron a algún tipo de ataque o técnica o... (nombre X que se le quiera dar): OSINT y Google Dorks para buscar cómo hacer cerveza, footprinting para buscar fábricas en España, XSS y escalada de privilegios (cambio de fábria a una más grande), scanning (registrar la marca), enumeración, exploiting (los distintos tipos de recetas, bebidas, lúpulos, maltas)... Resumen: nos mostraron la marca de la cerveza y la posibilidad de probarla allí en Rooted.

Al acabar esta charla pudimos hacer un descanso de media horita en el que la mayoría de la gente fue por las famosas conchas Codan. La verdad: yo me esperé un buen rato mientras me comía unas cuantas galletas que me hice hace unos cuantos días.

La primera charla después de este descanso la dio Stefano Maccalia, de RSA.

RootedCon 2020 - Stefano Maccalia - The enemy of your enemy is not your enemy

Después de presentarse ha descrito cómo ataca el equipo de incident response de su empresa las investigaciones en las que se involucran. El caso inicial que nos cuenta es de un cliente gubernamental que se ha encontrado con un problema. Para poder hacer la investigación les montan un entorno a parte para que puedan continuar trabajando mientras que les dejan el entorno real inalterado para poder averiguar cuál es el problema. Además de mostrarnos las evidencias que alertaron al cliente de que algo no marchaba bien también nos ha enseñado capturas de la tabla $MFT que les dio más pistas de por dónde estaba el problema: ficheros interesantes. También se investigaron los eventos del sistema y de los distintos proxys, firewalls... En algunos casos se encontraron con filas eliminadas o alguna máquina con un administrador de sistema y permisos para hacer prácticamente todo. Se encontraron con varios droppers (un fichero procedente de un phissing, que a su vez se descargaba otro...). El resumen: describió un DFIR de un incidente y lo solucionaron. El caso es que a su vez se encontraron con trazas de algo que no cuadraba y el cliente les informó que eran restos de un incidente anterior que ya "habían solucionado". Pero meses después descubren que hay un tráfico BITS raro y la conclusión a la que llegaron tras investigarlo es que un atacante se estaba aprovechando o atacando a otro. Algunos rastros que se encontraron en este segundo caso: una web shell (un tanto especial) en el servidor OWA de la empresa.

En este punto del evento, Francisco Hernández Cuchí, nos ha hecho una metacharla de ciberseguridad.

RootedCon 2020 - Francisco Hernández Cuchí - Metacharla de ciberseguridad

Ha empezado la charla durante unos minutos con una forma cómica. Nos ha hablado de un zero day en el visor de imágenes de Windows. Ha acuñado la frase "los datos también son un programa". La idea que tuvo era que mientras que se distrae a una persona viendo una imagen comprometida por detrás se esté ejecutando el código malicioso. Nos habla de la empresa Zerodium y de su proceso para recibir y pagar los bounties de los zero days encontrados. Pero nunca llegó al final del mismo. Se ha mostrado un vídeo (para mí lo era) que simulaba un Skype a tres. Ha hecho un pequeño juego para que escribamos por Twitter y con ello ha creado una de frases. En las charlas hacer falta ser uno mismo. elegir un logo y lema (si se puede), poner vídeos, elegir imágenes en grupo...

Cuando Francisco hubo terminado nos fuimos todos a comer. Como si en la zona del Kinépolis hubiese pocos sitios (eso sí: tienen que alimentar a 1.200 personas y eso no debe de ser muy fácil).

En la sobremesa, antes de que Chema Alonso (@chemaalonso) empezase, Fernando nos habló de su instituto privado de FP en el que estaban buscando una enseñanza reglada y oficial relacionada directamente con la ciberseguridad y no como contenido adicional.
Tras esa breve inciso, Chema pudo iniciar su exposición.

RootedCon 2020 - Chema Alonso - El club de los poetas muertos

Chema recuerda una broma que publicó en el día de los Santos Inocentes de 2010 relacionada con estegoganografía (nunca sé escribirlo bien) y la FOCA. Y esta charla la planeó en 2015: aquí algunos atacantes posicionaban sus aplicaciones, en un estado inocuo. Para convertir las aplicaciones en malignas se usaban varias formas: actualizando el código fuente, comprando las aplicaciones o incluso robándolas (o un poco de todo). La idea era hacer un proveedor de aplicaciones para hacer un bot. Con el bot se podría perfilar los distintos usuarios que las instalaban. Y para poder mandar los comandos se usaba estego... Vamos, las imágenes. Así, nos ha descrito los permisos de Android de aquel entonces y la problemática que tenían (y siguen teniendo, habida cuenta del número de móviles con las versiones de ese sistema operativo de entonces que siguen instaladas). Con los permisos se podían conseguir el número de teléfono directamente (leyendo, por ejemplo, los SMSs) o directamente la tarjeta SIM. Otra problemática estaba con el sistema OAuth y los ataques tipo SAppo que ya nos contaron en su momento. Nos ha hablado de una herramienta, llamada mASAPP que avisa a las empresas que la tienen contratada que alguna de las aplicaciones que han autorizado en sus propios móviles está a la venta (y por lo tanto, puede acabar con código malicioso por parte del nuevo propietario). Además, también ha puesto énfasis en la problematica que tiene cuando la cuenta de e-mail asociada a la cuenta de desarrollador caduca, por ejemplo, porque esta persona fallezca. Esa cuenta acabaría libre para que cualquiera la pudiera crear y terminar recuperando la contraseña del repositorio de la aplicación. Ha hecho una demo para exfiltrar datos pasando comandos a través de un banner.


Aquí empezamos el RootedPanel: #Include y la fundación GoodJob.

RootedCon 2020 - RootedPanel - #Include y Fundación GoodJob

Se debate sobre las posibilidades que tienen los discapacitados para acceder a trabajos relacionados con la ciberseguridad. Luis Fernández (de la revista SIC) ha hecho de moderador y nos ha hablado de la fundación GoodJob. En el panel han participado Román, Miguel Angel (de Incibe), Yolanda (de Telefónica), Susana (ATOS), Enrique (WestCon) y César (del propio GoodJob). De hecho, César ha empezado con una presentación más en profundidad del proyecto "#include": se busca incorporar al mercado laboral personas que no tienen por qué tener nivel técnico (como un jardinero, ejemplo que han estado poniendo) y que tengan algún tipo de discapacidad. Un proyecto muy ambicioso en el que se quiere dar la formación express (y de choque) de 5 semanas para que esas 100 personas elegidas puedan entrar a trabajar durante un tiempo determinado en una empresa y que en 9 meses acaben en la plantilla de esa empresa. Además de enseñarles, la idea es que no acaben separados de la sociedad. Les hace falta personas con mucha motivación para poder enseñar los conocimientos que les harán falta a estas personas para empezar en ese nuevo puesto. Han recordado que un 70% de las discapacidades son sobrevenidas (accidentes). El cliente quiere resultados. Si se ha reconocido que aunque no lo desean en ocasiones si se produce cierto sesgo o prejuicios. También se ha comentado las posibles barreras que puedan aparecer, incluyendo las herramientas que tengan que utilizar para su día a día. "Todos somos especiales" y es muy importante "el espíritu de superación".

En este punto llegamos a otro descanso, en el que también nos sirvieron unas buenas conchas Codan.

Después de este descanso me he mudado a otra sala donde Yago Jesús (@yjesus), Jose Antonio Esteban y David Revova) nos han hablado de ataques con mandos inalámbricos para coches (y garajes).

RootedCon 2020 - Yago Jesús, José Antonio Esteban y David Revova - Car Hacking

Como se puede ver, nos explicaron todo con un coche en la sala. En el car hacking se usan muchas veces el mismo código fuente que funciona en un coche con los demás (y de vez en cuando, cuela). Nos han hablado de mandos de garaje: desde los que iban por infrarrojos, pasando por los que tiran de radiofrecuencia con un único código (y los problemas que conlleva) llegando hasta los que cambian de código (o ya puestos, los que dicen que cambian pero realmente no cambian: rolling o random). Nos muestran las distintas formas que había de abrir coches: rompiendo el cristal, con un cordel, haciendo el vacío con una pelota de tenis... Y copiando la clave que envía el mando. También explican muy, muy rápido cómo funciona que se detecte que la llave está dentro del coche y no se quede "encerrada" o la distancia del RFID para que se abra (o arranque) sin sacar la llave del bolsillo. Han hecho una demo de apertura del coche. Y otra en la que han arrancado el coche sin estar la llave dentro (en la que le avisará al conductor de ese hecho pero podrá seguir moviéndose). Y han hecho otra demo de GPS spoofing, en la que algún valiente ha dicho que lo ha probado. Además, nos han enseñado un aparato que se conecta al ODB2 del coche y que con una tarjeta SIM se consigue escuchar todo lo que sucede dentro. O esa demo en la que a través de la radio AM/FM han sido capaces de enviar a varias frecuencias muy conocidas un mensaje de audio (por ejemplo, para acordarse de su familia por la pirula te ha hecho otro conductor) o ponerle un stream de música.

Y para finalizar la primera jornada, Gonzalo Carracedo (@batchdrake) nos ha hablado de los protocolos de los contadores digitales.

RootedCon 2020 - Gonzalo Carracedo - Atacando contadores digitales

En esta ocasión Gonzalo nos ha explicado que esta investigación la empezó a partir de otra (de Miguel Seijo, Gregorio López y José Ignacio Moreno). Nos ha explicado cómo funciona el sistema de energía en España (generación, transporte, distribución [donde se encuentran los contadores] y comercialización). Nos explica qué pueden hacer los contadores digitales. Su comunicación está construida o ideada para que funcione por PLC. Por lo tanto, nos termina hablando de dos protocolos PLC muy extendidos y usados: PRIME y DLMS/COSEM. Y cómo está construida su seguridad. Si PRIME tiene dos perfiles y uno de ellos es capaz de migrar al otro que además no aporta ninguna seguridad por ir todo en claro... En la demo tenia montado un sistema de cuatro contadores. Ha usado un kit para hacer las pruebas y le entregaban un sniffer específico. En sus demos y pruebas ha conseguido sacar datos de otros contadores que no se correspondían con sólo el suyo.

Y así ha sido la primera jornada. Mañana viernes (aunque ya hace unos minutos que hemos cambiado el día!) más.