Si una web falsa te pide datos de tu usuario y contraseña, démosle no uno, sino cientos de datos para inundar sus peticiones

Recibo un correo «de mi proveedor» de correo diciéndome que rápido a toda prisa entre en un enlace que me proporciona e ingrese mi usuario y contraseña o perderé el acceso a mi correo electrónico. ¡Claro! no quiero perder mi correo electrónico así que…

Espera, espera… ¿no sé Rick, a mí me parece falso todo esto?

El primer impulso ante una notificación como esta, o una de nuestro banco, o una de relacionada con un pedido que hemos realizado, es tratar de solucionarlo cuanto antes. Nadie quiere perder su cuenta de correo electrónico o no tener acceso a su cuenta de banco o perder el paquete que estaba esperando.

Pero ante ese primer impulso es conveniente volver a leer el correo y hacerlo con detenimiento y suspicacia, buscando algo que no parece que esté bien del todo.

Los delincuentes por internet inventan toda clase de tretas y formas de conseguir aquello que quieren: dinero, acceso a tus cuentas personales, etc… Así que vamos a volver a leer el correo analizando lo que vemos.

En primer lugar, la dirección de correo del remitente no es de la empresa que dice ser, puede ser un correo de gmail, o puede ser de un correo que se parece al del servicio que dice representar.

Otra cosa a revisar es el enlace en el que dice que pinchemos para que no tengamos problemas. Hay que revisar bien las url de los enlaces. A veces ponen nombre muy similares, o utilizan letras en otros alfabetos que son similares a las letras latinas, pero que cambia todo. Unos ejemplos, no es lo mismo: mail.com que rnail.com o maiI.com o mai|.com o maiil.com (por poner unos ejemplos)

Podrás pensar: «¡Vaya! eso es muy burdo y se ve a la legua que es falso…» no porfies tanto porque en cualquier momento tu también podrías caer, nadie estamos a salvo.

Además pueden utilizar métodos para hacer que veas una cosa y estés pinchando en una url distinta de la que estás viendo.

En mi caso copié la url en la que me instaban a pinchar y lo escribí en un navegador seguro o en una pestaña privada (por ejemplo) y me dirige a una web que nada tiene que ver con la oficial pero que se asemeja mucho. Mismos colores, mismos logos, misma apariencia…

Y claro me pide mi usuario y contraseña para entrar. Todo se parece (menos la url, detalle clave) así que… ¿no sé Rick, parece falso? Y lo era, más que las promesas de un político.

Metí unas credenciales falsas, le dí a enviar y… Una vez que consiguen lo que buscan, me redirigió de nuevo y esta vez ya sí a la web oficial de mi proveedor de correo.

Es decir, de esta manera han conseguido mi nombre de usuario y contraseña de mi servicio de correo que yo les he entregado sin saberlo…

Lo primero es denunciar la estafa. En mi caso me puse en contacto con mi proveedor de correo y abrí un Ticket con una incidencia, me pidieron los datos y el cuerpo del correo y me dieron las gracias.

También se puede denunciar la web de phising a otros medios oficiales, en España por ejemplo en Incibe.

Pero ya que los delincuentes andan buscando datos ¿Por qué no inundad sus peticiones con cientos de datos ficticios? Así no sabrán qué es cierto o falso… ¿No sé Rick, parece buena idea?

En primer lugar, vamos a la web falsa y abrimos la consola de desarrollador de nuestro navegador con F12 (en Firefox por lo menos es así). Vamos a la sección de Red e introducimos unos datos falsos en la web. En mi caso metí un correo con un formato erróneo para poder ver la petición POST que envía el navegador.

Captado el diálogo al enviar unos datos, vemos que hay una petición POST, pulsamos botón derecho sobre ella y seleccionamos copiar valor como CURL.

Copiados esos datos como una petición CURL, podremos ejecutarla en una terminal en nuestro equipo mediante curl. Pero antes modificamos alguna cosa, como el useragent, el idioma, y alguna cosa más… La ejecutamos y también funciona, igual que en el navegador. Así que ahora es cuestión de automatizar ese envío de datos mediante un script en Bash.

Pero vamos a sofisticarlo un poco. Crearemos un archivo de texto con un montón de correos falsos y otro con un montón de contraseñas falsas, para que la petición curl envíe cada vez una distinta a la web de phising.

El script no lo he hecho yo, le he pedido a una IA que lo realice por mí y así ha quedado el script:

#!/bin/bash

# Archivos de correos y contraseñas
correos_file="correos.txt"
contrasenas_file="contrasenas.txt"

# Leer los archivos de correos y contraseñas en arrays
mapfile -t correos < "$correos_file"
mapfile -t contrasenas < "$contrasenas_file"

# Inicializar el contador de ucfid
ucfid_counter=117854344783474804

# Repetir indefinidamente en un bucle
while true
do
    # Recorrer los correos y contraseñas
    for ((i = 0; i < ${#correos[@]}; i++)); do
        correo="${correos[$i]}"
        contrasena="${contrasenas[$i]}"

        # Mostrar correo y contraseña en pantalla
        echo "                              "
        echo "-----------------------------"
        echo "Enviando solicitud con:"
        echo "Correo: $correo"
        echo "Contraseña: $contrasena"
        echo "-----------------------------"

        # Usamos un heredoc para construir el cuerpo del formulario
        body=$(cat <<EOF
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="_u936047796476098955"

$correo
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="_u260354971547788409"

$contrasena
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="wsite_subject"

 
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="form_version"

2
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="wsite_approved"

approved
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="ucfid"

$ucfid_counter
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9
Content-Disposition: form-data; name="recaptcha_token"

 
------geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9--
EOF
)

        # Realizar la solicitud CURL
        curl 'https://maiilbox-update-form.weebly.com/ajax/apps/formSubmitAjax.php' \
          --compressed \
          -X POST \
          -H 'User-Agent: FckU5.0' \
          -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
          -H 'Accept-Language: en-US;q=0.5,en;q=0.3' \
          -H 'Accept-Encoding: gzip, deflate, br, zstd' \
          -H 'Content-Type: multipart/form-data; boundary=----geckoformboundary4e9cef62ed75d0a9ed272a07f6cf43b9' \
          -H 'Origin: https://maiilbox-update-form.weebly.com' \
          -H 'DNT: 1' \
          -H 'Sec-GPC: 1' \
          -H 'Connection: keep-alive' \
          -H 'Referer: https://maiilbox-update-form.weebly.com/' \
          -H 'Cookie: __cf_bm=SrrLM7EXB3ROlGLjLDVO4nreijE3Sp6L9.q9lm7qN61Vt6cGcjSjfSpbngP.uw19tGoIA; language=en_EN' \
          -H 'Upgrade-Insecure-Requests: 1' \
          -H 'Sec-Fetch-Dest: iframe' \
          -H 'Sec-Fetch-Mode: navigate' \
          -H 'Sec-Fetch-Site: same-origin' \
          -H 'Sec-Fetch-User: ?1' \
          -H 'Priority: u=4' \
          -H 'TE: trailers' \
          --data-binary "$body"

        # Incrementar ucfid
        ((ucfid_counter++))

        # Agregar un sleep para evitar peticiones muy rápidas (opcional)
        sleep 3
    done
done

Ejecutamos esto en la terminal y a disfrutar de enviar un montón de credenciales falsas a la web de phising. Imagina que más gente desde sus equipos creara los archivos de correos y contraseñas y también lo ejecutara en sus equipos… ¿No sé Rick, creo que no estaría mal?

¿Quieren datos? ¡Pues toma unos cuantos!

Recomendaciones

• Revisar siempre muy bien este tipo de peticiones. Tanto el correo desde donde son enviadas como las url a las que hay que hacer clic.
• Tener configurado tu correo para ver los correos en texto plano. Nada de bonitos HTML. En el código HTML se pueden esconder muchas argucias.
• Ante la duda copiar la URL y pegarla en un navegador o editor de texto y revisar bien si es una URL confiable (nada de caracteres raros, nada de cosas añadidas: gmail-eldeverdad.com)
• Primero contactar con el servicio oficial para ver si es una petición válida o un caso de delincuencia.
• Desconfiar y no caer en el miedo actuando de manera impulsiva.
• Reportar los casos encontrados.

Es increíble el trabajo de promoción que está realizando Nate en su blog, dese hace más del tiempo que puedo recordar. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y voy a intentar hacer algo que es simple pero requiere constancia. Traducir sus artículos al castellano utilizando los magníficos traductores lo cual hará que: la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «Cuadrantes y ciclos día/noche – Esta en Plasma». Espero que os guste y, sobre todo, que pueda mantener el ritmo de publicación de Nate Graham (este llega con una semana de retraso por cuestiones personales).

Esquinas inferiores redondeadas – Esta semana en Plasma

Nota: artículo original en Blogs KDE. Traducción realizada utilizando deepl.com. Esta entrada está llena de novedades de la Comunidad KDE. Mis comentarios están entre corchetes y se nota que estamos en periodo vacacional por la brevedad del artículo. Con la publicación de hoy me pongo al día.

Novedades

Plasma 6.5

KWin redondea automáticamente las esquinas inferiores de las ventanas decoradas con brisa. Esta función está activada por defecto, pero puede desactivarse si prefieres el estilo anterior. (Vlad Zahorodnii, enlace 1, enlace 2 y enlace 3) [Lo cierto es que: a) no me había dado cuenta de ese detalles; b) no sé porqué no se había hecho hasta ahora (supongo que alguna cosa técnica debía impedirlo de forma sencilla); c) queda mucho mejor].

Mejoras en la interfaz de usuario

Plasma 6.5

Las barras laterales de Discover y System Monitor son ahora redimensionables. Y también recuerdan el tamaño que elijas en el archivo de configuración de estado, no en el archivo de configuración de ajustes. (Marco Martin, enlace 1, enlace 2 y enlace 3)

El widget de Discos y Dispositivos ahora te permite montar un disco sin comprobar si hay errores, o comprobar manualmente si hay errores sin montarlo. Esto puede ser útil para discos enormes llenos de cosas donde sabes que todo está bien, que de otro modo tardarían un rato en comprobar las actualizaciones mientras se montan. (Bohdan Onofriichuk, enlace) [Supongo que antes se comprobaba siempre].

Se sigue trabajando en un proyecto para mejorar el orden de los resultados de búsqueda en KRunner. Los cambios realizados hasta ahora incluyen no aumentar la prioridad de las aplicaciones KDE y los elementos marcados como favoritos, ya que ambos tendían a hacer que los resultados parecieran más aleatorios. Pronto habrá más cambios; ¡esto no es el final! (Harald Sitter, enlace 1 y enlace 2)

El widget de informe meteorológico de Plasma ahora obtiene los datos meteorológicos inmediatamente al despertar del sueño cuando el ordenador ha estado durmiendo más de 30 minutos. (Bohdan Onofriichuk, enlace) [Creo que es una buena idea para tener la información actualizada, algo que se espera al reactivar el entorno de trabajo].

Cuando empiezas a crear un usuario en la página Usuarios de la Configuración del sistema, ahora hay un botón «Cancelar» en el que puedes hacer clic para detener fácilmente el proceso y volver atrás. (Rémi Piau, enlace) [No suelo hacerlo muy a menudo pero parece intuitivo.]

Gear 25.08.0

En el widget Discos y dispositivos de Plasma, los discos ópticos ya no muestran la opción de abrirlos en el Administrador de particiones, porque no tiene sentido. (Joshua Goins, enlace)

Frameworks 6.17

El componente NavigationTabButton – que se utiliza en varias páginas de Configuración del Sistema, así como en un montón de aplicaciones basadas en QtQuick – ahora utiliza un estilo más obvio para comunicar el foco del teclado, mejorando la accesibilidad. (Devin Lin, enlace)

Corrección de errores importantes

Plasma 6.4.4

Se ha corregido un error que provocaba que la página Controles de volumen (a la que se accede desde la página Sonido de la Configuración del sistema) nunca entrara en modo estrecho cuando se mostraba con un texto más largo de lo que normalmente cabría en la página, lo que podía ocurrir cuando se utilizaban varios idiomas distintos del inglés. (Coche Méven, enlace)

Plasma 6.5

Con el modo HDR activado, el cursor de la pantalla de bloqueo ahora se atenúa de la forma esperada cuando el resto de las pantallas se atenúan. (Xaver Hugl, enlace)

Frameworks 6.17

Se han solucionado algunos problemas de Qt en Kirigami que podían hacer que las aplicaciones se bloquearan al utilizar el renderizado por software. (Vlad Zahorodnii, enlace)

El muy común componente Kirigami.FormLayout utilizado en System Settings y otras aplicaciones KDE ya no parpadea un poco la primera vez que se muestra en una página. (Niccolò Venerandi, enlace)

Otra información de errores destacables:

• 4 bugs Plasma de muy alta prioridad (dos más que la semana pasada). Lista actual de errores
• 32 fallos de Plasma de 15 minutos (uno más que la semana pasada). Lista actual de fallos

Mejoras de rendimiento y aspectos técnicos

Plasma 6.5

Añadidos algunos autotests más para verificar la capacidad de Plasma para cargar varias partes de sí mismo. (Nicolas Fella, enlace 1, enlace 2)

KWin confía menos en la colorimetría proveniente de los datos EDID de las pantallas, porque se equivoca lo suficiente como para que no tenga sentido usarla por defecto. (Xaver Hugl, enlace)

Los datos para el tamaño de la ventana de diálogo de archivo se almacenan ahora en el archivo de configuración de estado, no en el archivo de configuración de ajustes. (Nicolas Fella, enlace)

Cómo puedes ayudar

KDE se ha convertido en algo importante en el mundo, y tu tiempo y contribuciones nos han ayudado a conseguirlo. A medida que crecemos, necesitamos su apoyo para mantener KDE sostenible.

Puedes ayudar a KDE convirtiéndote en un miembro activo de la comunidad e involucrándote de alguna manera. Cada colaborador marca una gran diferencia en KDE – ¡no eres un número o un engranaje en una máquina!

Tampoco tienes que ser programador. Existen muchas otras oportunidades:

• Clasificar y confirmar informes de errores, tal vez incluso identificar su causa raíz.
• Contribuir al diseño de fondos de pantalla, iconos e interfaces de aplicaciones.
• Diseñar y mantener sitios web
• Traducir elementos de texto de la interfaz de usuario a su propio idioma.
• Promover KDE en su comunidad local
• …¡Y un montón de cosas más!

¡También puedes ayudarnos haciendo una donación! Cualquier contribución monetaria – por pequeña que sea – nos ayudará a cubrir los costes operativos, salarios, gastos de viaje de los colaboradores, y en general a mantener KDE llevando el Software Libre al mundo.

Para obtener una nueva característica de Plasma o una corrección de errores mencionada aquí, siéntase libre de enviar un commit a la solicitud de fusión correspondiente en invent.kde.org.

La entrada Esquinas inferiores redondeadas – Esta semana en Plasma se publicó primero en KDE Blog.

Es increíble el trabajo de promoción que está realizando Nate en su blog, dese hace más del tiempo que puedo recordar. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y voy a intentar hacer algo que es simple pero requiere constancia. Traducir sus artículos al castellano utilizando los magníficos traductores lo cual hará que: la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «Cuadrantes y ciclos día/noche – Esta en Plasma». Espero que os guste y, sobre todo, que pueda mantener el ritmo de publicación de Nate Graham (este llega con una semana de retraso por cuestiones personales).

Diales giratorios y ciclos día/noche – Esta semana en Plasma

Nota: artículo original en Blogs KDE. Traducción realizada utilizando deepl.com. Esta entrada está llena de novedades de la Comunidad KDE. Mis comentarios están entre corchetes.

Novedades

Plasma 6.5

¡Ya puedes configurar lo que hacen los diales giratorios de tu tableta de dibujo! (Joshua Goins, enlace 1, enlace 2 y enlace 3)

Al compartir la red Wi-Fi actual, ahora también se muestra su contraseña, para que la persona con la que la compartes pueda conectarse fácilmente. (Ivan Tkachenko, enlace) [Útil para ahorrar tiempo].

Mejoras en la interfaz de usuario

Plasma 6.4.3

Se ha mejorado la accesibilidad de la aplicación del Centro de Bienvenida de múltiples maneras. (Nicolas Fella, enlace)

El efecto Lupa de KWin tiene ahora un nivel máximo de aumento, ya que si se sobrepasa se convierte en el efecto Zoom. (Vlad Zahorodnii, enlace) [Vale, no acabo de entender la diferencia].

Se ha mejorado la visualización de bytes sin procesar en las notificaciones de transferencia de archivos. (Kai Uwe Broulik, enlace)

Plasma 6.5

Con la nueva función para cambiar automáticamente los fondos de pantalla entre sus versiones clara y oscura, ahora hay más de una función que hace uso del ciclo día/noche. En consecuencia, el lugar donde configuras tu ubicación para que el sistema sepa qué hora del amanecer y del atardecer debe utilizar se ha trasladado de la página Luz nocturna de Ajustes del sistema a su propia página. El ciclo que configures aquí se utilizará tanto para la Luz nocturna como para el cambio automático del fondo de pantalla y, más adelante, también para el cambio automático del tema o de la combinación de colores, una vez que ambos estén finalizados. (Vlad Zahorodnii, enlace 1 y enlace 2) [Esta funcionalidad cada vez me gusta más].

Los screencasts de ventanas específicas incluyen ahora sus barras de título, bordes y sombras. (David Redondo, enlace)

Corrección de errores importantes

Plasma 6.4.3

Se ha corregido un problema que podía hacer que KWin se bloqueara al pulsar Alt+Tab para salir de ciertos juegos. (Vlad Zahorodnii, enlace) [Importante el trabajo para integrar los juegos en Plasma].

Se ha corregido un problema que podía provocar que KWin se bloqueara al utilizar un lápiz de tableta de dibujo cuando se cerraba una ventana interna. (Vlad Zahorodnii, enlace)

Se ha corregido una regresión que provocaba que el enfoque de la ventana fuera incorrecto tras cambiar de actividad. (Vlad Zahorodnii, enlace)

Se ha corregido un problema muy extraño que causaba que las aplicaciones lanzadas desde Spectacle (por ejemplo, un reproductor de vídeo para ver las grabaciones de pantalla guardadas) estuvieran super duper rotas. (Nicolas Fella, enlace)

Se ha corregido un problema que impedía que las ventanas emergentes de Plasma fueran enfocables si estaba abierta una ventana emergente de una aplicación GTK 4. (David Edmundson, enlace)

El uso de la configuración de clic «Activar y elevar» en Wayland ya no se come los clics mientras está visible una información sobre herramientas. (Vlad Zahorodnii, enlace)

Se ha corregido un problema que provocaba que el cambio de tamaño de la ventana al utilizar un factor de escala fraccionario tuviera un aspecto un poco caótico. (Vlad Zahorodnii, enlace) [Las fracciones, generando problemas desde primaria].

Se ha corregido un problema que provocaba que el lector de pantalla Orca no funcionara del todo bien al pulsar repetidamente las teclas de navegación estructurales. (Michael Weghorn, enlace)

El widget Minimizar todas las ventanas vuelve a funcionar en X11. (Marco Martin, enlace) [Aún se cuida X11, al menos, que no pierda funcionalidades].

El efecto KWin «Atenuar inactivos» ya no atenúa también los conmutadores Alt+Tab. (Vlad Zahorodnii, enlace)

Adaptado nuestro código a un cambio de Qt que causaba que la pantalla de bloqueo a veces mostrara la interfaz de usuario y la solicitud de contraseña inmediatamente, en lugar de sólo después de cualquier interacción. (Marc Payne, enlace) [Solucionando un potencial problema de privacidad y seguridad].

Plasma 6.5

Se ha corregido un problema que impedía cambiar el fondo de la pantalla de inicio de sesión de SDDM por una nueva imagen con el mismo nombre de archivo que la anterior. (Amy Rose, enlace)

Se ha corregido un problema que provocaba que los mensajes de autenticación rechazaran de forma inapropiada cualquier texto ya introducido, incluso si no lo habías aceptado todavía, sino simplemente porque el sistema PAM subyacente estaba tardando mucho. (Secureblue, enlace)

Frameworks 6.17

Se ha corregido un problema que causaba que el menú de arrastrar y soltar a veces no apareciera cuando se esperaba al soltar archivos desde Dolphin en el escritorio Plasma. (Akseli Lahtinen, enlace)

Otra información de errores destacables:

• 4 bugs Plasma de muy alta prioridad (dos más que la semana pasada). Lista actual de errores
• 31 fallos de Plasma de 15 minutos (dos más que la semana pasada). Lista actual de fallos

Mejoras de rendimiento y aspectos técnicos

Plasma 6.4.3

Corregida una fuga de memoria en KWin. (Vlad Zahorodnii, enlace) [Estos errores son el origen de muchos cuelgues inexplicables].

Plasma 6.5

Ahora puede kioclient mkdir para crear un directorio pasando por el sistema KIO. (Bernardo Gomes Negri, enlace)

Frameworks 6.17

Rendimiento y eficiencia ligeramente mejorados para todas las aplicaciones KDE basadas en QtQuick – incluyendo aplicaciones Plasma como System Settings, Discover y Spectacle. (David Edmundson y Marco Martin, enlace 1 y enlace 2)

Cómo puedes ayudar

KDE se ha convertido en algo importante en el mundo, y tu tiempo y contribuciones nos han ayudado a conseguirlo. A medida que crecemos, necesitamos su apoyo para mantener KDE sostenible.

Puedes ayudar a KDE convirtiéndote en un miembro activo de la comunidad e involucrándote de alguna manera. Cada colaborador marca una gran diferencia en KDE – ¡no eres un número o un engranaje en una máquina!

Tampoco tienes que ser programador. Existen muchas otras oportunidades:

• Clasificar y confirmar informes de errores, tal vez incluso identificar su causa raíz.
• Contribuir al diseño de fondos de pantalla, iconos e interfaces de aplicaciones.
• Diseñar y mantener sitios web
• Traducir elementos de texto de la interfaz de usuario a su propio idioma.
• Promover KDE en su comunidad local
• …¡Y un montón de cosas más!

¡También puedes ayudarnos haciendo una donación! Cualquier contribución monetaria – por pequeña que sea – nos ayudará a cubrir los costes operativos, salarios, gastos de viaje de los colaboradores, y en general a mantener KDE llevando el Software Libre al mundo.

Para obtener una nueva característica de Plasma o una corrección de errores mencionada aquí, siéntase libre de enviar un commit a la solicitud de fusión correspondiente en invent.kde.org.

La entrada Diales giratorios y ciclos día/noche – Esta semana en Plasma se publicó primero en KDE Blog.

Me complace compartir el I Journal “Safe and free” 2025, un nuevo evento en línea para seguir difundiendo y divulgando el Software Libre para todo el mundo. Una jornada con 4 ponentes hablando de 4 temas, tanto para usuarios noveles como a avanzados.

I Journal “Safe and free” 2025

El pasado mes de noviembre de 2024 se celebró el III Seminario Anual GNU/Linux. De esta forma todos los fines de semana de noviembre tuvimos una cita con el mundo GNU/Linux en forma de ponencias en directo con divulgadores de todo el mundo hispano hablante con la nueva edición del seminario Anual GNU/Linux.

De esta forma, la Comunidad OpenShield organizó 8 presentaciones con las que iniciarse, aprender, profundizar y, en general, conocer un poco más el abanico de posibilidades que te ofrece el mundo del Conocimiento Libre al módico precio de un poco de tu tiempo (que no es poco).

El objetivo de este evento era mostrar, enseñar y demostrando las bondades de Linux, GNU/Linux, objetivo que se repite es mes de julio en forma de única jornada.

De esta forma os me complace compartir con vosotros que la Academia GNULinux os trae el I Journal «Safe and free» 2025, la cual constara de 4 ponencias de acuerdo al siguiente detalle:

• Baltasar Ortega: Novedades en Plasma 6.4, mejorando el escritorio de la comunidad KDE
• Klaibson Ribeiro: Mi IA, Mis Reglas, Como Onlyoffice trabaja con IA
• José Flores: Deshabilitar cifrados débiles SSH en GNU/Linux
• Angelo Ramirez: Seguridad en thunderbird

Las charlas serán de 25 minutos cada una, con 10 minutos de diferencia entra una y otra. Os esperamos.

IMPORTANTE: La hora está referida a la de Perú, para la península Ibérica se empieza a las 21:00 horas, una menos en canarias.

La entrada I Journal “Safe and free” 2025 se publicó primero en KDE Blog.

Me complace compartir el I Journal “Safe and free” 2025, un nuevo evento en línea para seguir difundiendo y divulgando el Software Libre para todo el mundo. Una jornada con 4 ponentes hablando de 4 temas, tanto para usuarios noveles como a avanzados.

I Journal “Safe and free” 2025

El pasado mes de noviembre de 2024 se celebró el III Seminario Anual GNU/Linux. De esta forma todos los fines de semana de noviembre tuvimos una cita con el mundo GNU/Linux en forma de ponencias en directo con divulgadores de todo el mundo hispano hablante con la nueva edición del seminario Anual GNU/Linux.

De esta forma, la Comunidad OpenShield organizó 8 presentaciones con las que iniciarse, aprender, profundizar y, en general, conocer un poco más el abanico de posibilidades que te ofrece el mundo del Conocimiento Libre al módico precio de un poco de tu tiempo (que no es poco).

El objetivo de este evento era mostrar, enseñar y demostrando las bondades de Linux, GNU/Linux, objetivo que se repite es mes de julio en forma de única jornada.

De esta forma os me complace compartir con vosotros que la Academia GNULinux os trae el I Journal «Safe and free» 2025, la cual constara de 4 ponencias de acuerdo al siguiente detalle:

• Baltasar Ortega: Novedades en Plasma 6.4, mejorando el escritorio de la comunidad KDE
• Klaibson Ribeiro: Mi IA, Mis Reglas, Como Onlyoffice trabaja con IA
• José Flores: Deshabilitar cifrados débiles SSH en GNU/Linux
• Angelo Ramirez: Seguridad en thunderbird

Las charlas serán de 25 minutos cada una, con 10 minutos de diferencia entra una y otra. Os esperamos.

IMPORTANTE: La hora está referida a la de Perú, para la península Ibérica se empieza a las 21:00 horas, una menos en canarias.

La entrada I Journal “Safe and free” 2025 se publicó primero en KDE Blog.

Sigo con la séptima entrada de este año de la iniciativa #viernesdeescritorio. Bienvenidos a mi escritorio Plasma de julio 2025, realizado sobre ordenador portátil, un Slimbook Pro, con el que llegamos a las 62 entregas compartiendo «Mi escritorio» de forma mensual (ya son muchos meses que mi troll no me visita. No lo echo de menos).

Mi escritorio Plasma de julio 2025 #viernesdeescritorio

Esta va a ser la sexagésimasegunda (62 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 6 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante.

De nuevo lo realizo de nuevo sobre mi Slimbook Pro, el cual tiene instalado un KDE Neon con Plasma 6.4.2, sobre una versión de KDE Frameworks 6.15.0 y una versión de Qt 6.9.0. El servidor gráfico es Wayland y el Kernel es 6.11.0-29-generic (64 bits).

En este equipo utilizo un aspecto bastante muy oscuro, con el tema global básico Brisa Oscuro e iconos estándar (Brisa Oscuro). La barra de tareas a la izquierda se ha quedado para siempre. En ella he puesto un plasmoide llamado Weather Widget Plus, bajo del reloj de la barra de tareas, que me indica la temperatura del exterior de mi casa y me hace la previsión para unos días. Ade,ás, abajo he puesto selector de colores y un pequeño bloc de notas.

Para el fondo tengo una novedad: he puesto un widget llamado Random AI Wallpaper que me pone un fondo aleatorio, generados por alguien gracias a la IA y de calidad (la IA puede genera fondos pero que sean de calidad es decisión de una persona), y que se guardan en un Gitlab. Pronto en el blog.

Y para finalizar, he cambiado mi reloj de escritorio por otro creado por una desarrollador de Plasma que me indica la hora aproximada, que queda estupendo en temas oscuros. Una maravilla y, además, es exclusivo.

El resultado de mi escritorio Plasma de julio de 2025 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de julio 2025 #viernesdeescritorio se publicó primero en KDE Blog.

Comparto en el blog la respuesta de la defensora del oyente sobre el bloqueo a aplicaciones de terceros a los podcasts de RTVE y RNE. Spoiler: No son buenas noticias

Ayer mismo publiqué en el blog un artículo sobre mi experiencia a la hora de reproducir podcasts de la radio pública del estado español.

• https://victorhckinthefreeworld.com/2025/07/16/rtve-bloquea-sus-podcats-a-la-aplicacion-antennapod/

En el artículo describía cómo desde hace unos días o semanas, mi reproductor de podcasts en el móvil no podía reproducir los podcats públicos creados por un medio público y estatal como es Radio Naciona del España (RNE).

Y también comenté que había expresado mi queja a la defensora del oyente sobre el hecho de que desde el medio público se coartase de esa manera el acceso a su contenido (contenido público realizado con dinero público).

Pues bien, la defensora del oyente ha respondido, y la respuesta que ha dado (nada nuevo) no te va a gustar.

Primero comparto la queja que le envié:

Hola.
Desde hace un tiempo vengo comprobando que mi reproductor de podcasts en Android no funcionaba con los podcasts de RTVE. Estoy suscrito a unos cuantos, por ejemplo: El sótano de RNE3, Raíz de 5 de RNE5, y algunos otros. Pero mi reproductor funciona correctamente con otros podcasts, por ejemplo de la SER, y otros independientes.
Al principio lo achacaba a un problema de conexión o similar, después de comprobar varias cosas durante días, veo que parece ser que la web de RTVE rechaza los podcasts escuchados con cierta aplicación de software libre que es la que utilizo para escuchar mi colección de podcasts.
Es decir, RTVE, está en contra de la neutralidad de la red al coartar el contenido público usando ciertas herramientas. El medio público ofrece su contenido, pero con restricciones para ciertos usuarios. Pero no del todo, porque desde mi portátil sí puedo escuchar los podcats sin problema.
¿Hay alguna causa que justifique dicho comportamiento selectivo?

A continuación comparto la respuesta de la defensora del oyente a mi queja:

Gracias por escribirnos.

Lamentamos su malestar. Desde la Subdirección de Innovación y Productos Digitales de RTVE nos aportan la siguiente explicación sobre este asunto por el que nos han preguntado muchos usuarios como usted en esta Oficina de la Defensora:

"A partir de ahora, la descarga de audios solo está habilitada desde la aplicación oficial de RNE para garantizar la calidad, la correcta atribución del contenido y el cumplimiento de los derechos de autor y de difusión.
Permitir la descarga desde aplicaciones de terceros (no oficiales) dificultaría asegurar que los contenidos se distribuyan con la calidad y el contexto adecuados, además de poder vulnerar los acuerdos editoriales y de derechos que protegen tanto a los creadores como a la propia emisora.
Esta medida responde a dos motivos principales: por un lado, no podemos conocer ni contabilizar el uso real de nuestros contenidos en esas plataformas, lo que dificulta ofrecer un servicio de calidad y valorar correctamente el alcance. Por otro, el consumo a través de terceros genera un coste directo para RNE (especialmente en términos de CDN), sin ningún beneficio asociado ni control sobre la experiencia del usuario.
Por ello, para garantizar un servicio sostenible y de calidad, los contenidos solo estarán disponibles para descarga y escucha dentro de RNE Audio y en aquellas plataformas con las que exista un acuerdo".
Le agradecemos su interés y participación.
Reciba un cordial saludo.

Lo que entiendo es que a partir de ahora RNE únicamente permitirá el acceso a los podcats de su programación desde la aplicación oficial de RNE.

El contenido es público y pagado con dinero público (vuelvo a recalcar ese hecho) pero sólo podremos hacerlo desde su aplicación desarrollada con dinero público y que no es software libre y solo está disponible en plataformas privativas (nada de f-droid).

También entiendo que igual que en mi portátil por medio de Amarok, estaba suscrito a los podcasts para oirlos en mi equipo, tampoco esto será posible a partir de ahora, teniendo que acceder a su web y reproducirlos desde su reproductor en su página.

Es totalmente injusto que un medio público utilice un medio de difusión público como son los podcats y lo encierre no permitiendo el libre acceso a su contenido.

Las excusas son el poder tener un control de las descargas, acuerdos editoriales, derechos de autor, coste extra para RNE.

¿De verdad con una herramienta de terceros no tienen un acceso al número de descargas de cada audio para tener una trazabilidad de lo más escuchado?

Sobre las demás excusas para imponer ese recorte a la hora de difundir su contenido no tengo más comentarios, con los derechos de autor hemos topado. De acuerdo que hay que proteger esos derechos de autor, pero me temo que más que querer proteger al autor, lo que quieren es proteger a quien gana dinero con el contenido creado con el autor, que no siempre es bien pagado.

Por tanto, ya lo sabes. A partir de ahora parece ser que sólo podrás escuchar sus audios desde la aplicación oficial, su web o aquellas aplicaciones con las que hayan llegado a un acuerdo.

¿Quizás pronto su programación en directo por radio en FM sólo estará disponible para los receptores de radio que ellos aprueben y con los que lleguen a un acuerdo? ¿qué más restricciones tiene en mente un medio público a la hora de difundir su contenido? Lo veremos en próximas entregas.

Si vuestra aplicación de podcats también se ha visto afectada por esta restricción, que parece ser que pronto serán todas, menos las aprobadas por el ente, podéis también enviar una queja y ver si el medio cambia de opinión…

• https://www.rtve.es/rtve-responde/participacion/

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID 'none' 'tpm2-device=auto'

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

Protecting against rogue devices in openSUSE with Full Disk Encryption

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID ‘none’ ‘tpm2-device=auto’

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

El pasado 17 de junio fue lanzado Plasma 6.4, que en palabras de sus desarrolladores, nos ofrece un escritorio más fluido, amigable y útil. Lo anuncié conveniente en el blog pero solo fue un anticipo de lo que nos ofrecía. Es el momento de profundizar en sus novedades como las mejoras en las capturas y grabación de la pantalla en Plasma 6.4, un gran impulso a una herramienta que se está convirtiendo en algo imprescindible para cualquier creador de contenido.

Mejoras en las capturas y grabación de la pantalla en Plasma 6.4

Spectacle está siguiendo la estela de Dolphin en relación con su antecesor y está obteniendo la etiqueta de mejor aplicación para capturar pantallas de cualquier sistema operativo a pesar de que deriva de otra aplicación, KSnapShot, que casi tenía ganado ese título, como así lo ha logrado Dolphin respecto a Konqueror.

De esta forma, en Plasma 6.4 Spectacle, tiene un aspecto muy distinto en Plasma 6.4 (para mejor) ya que se centrar en lo que es: un capturador y registrador del escritorio.

Así que ahoraal pulsar la tecla ImprPant para abrir Spectacle directamente en el modo de captura de pantalla: arrastra un cuadro para seleccionar una zona de la pantalla, o bien pulse Intro inmediatamente para que Spectacle capture una instantánea de la totalidad de la pantalla.

También puede empezar a hacer anotaciones de inmediato, dibujando flechas, difuminando secciones o añadiendo texto explicativo, entre otras cosas.

Por último, la calidad se ha mejorado de forma impresionante en las grabaciones de la pantalla que usan el formato WebM y en las capturas de pantallas que usan un escalado fraccionario.

Más información: KDE

Las novedades de Plasma 6.4

El entorno de trabajo ya está disponible en muchas distribuciones, así que es un buen momento para describir telegráficamente comento algunas de sus novedades:

• Mejoras en el widget Bluetooth: Identifica más tipos de dispositivos y muestra nombres reales durante el emparejamiento.
• Coherencia visual: Los widgets de Diccionario y Navegador Web ahora usan iconos simbólicos para un aspecto más uniforme.
• Navegación mejorada por teclado: Optimización de la navegación y selección mediante teclado en menús y widgets.
• Modernización de KMenuEdit: Interfaz renovada y simplificada para editar el menú de aplicaciones.
• Mejoras en accesibilidad: El widget Calculadora anuncia resultados a lectores de pantalla y se mejora la navegación accesible.
• Gestión avanzada de paneles y monitores: Mejoras en la disposición y comportamiento de pantallas y paneles.
• Mejoras de rendimiento: Optimización de la suavidad del cursor y reducción del uso innecesario de CPU en el Monitor del Sistema.
• Mejoras en el widget Fifteen Puzzle: Se han realizado ajustes funcionales y visuales en este widget de juego clásico, ofreciendo una experiencia más fluida y atractiva.
• Actualización de Discover: El centro de software ahora muestra información más clara sobre el estado de las actualizaciones y mejora la gestión de aplicaciones Flatpak y Snap.
• Nuevas opciones en la configuración del sistema: Se han añadido controles más detallados para la personalización de temas y efectos visuales, facilitando la adaptación del entorno a las preferencias del usuario.
• Notificaciones mejoradas: El sistema de notificaciones es ahora más fiable y permite una mejor gestión de mensajes persistentes y temporales.
• Soporte ampliado para pantallas táctiles: Plasma 6.4 mejora la respuesta y precisión en dispositivos con pantalla táctil, optimizando gestos y controles táctiles.
• Optimización de Wayland: Se han corregido errores y mejorado la estabilidad y el rendimiento bajo el servidor gráfico Wayland, acercándolo a la paridad con X11.
• Mejoras en la gestión de energía: Nuevas opciones y mayor eficiencia en la gestión del consumo energético, especialmente en portátiles, para prolongar la autonomía y reducir el uso de recursos.

La entrada Mejoras en las capturas y grabación de la pantalla en Plasma 6.4 se publicó primero en KDE Blog.