Un par de informes sobre ciberseguridad del año 2022

Riazor y nubes

Hace años comentaba informes que iba leyendo de vez en cuando, pero ahora lo había dejado un poco abandonado. No es que pretendar comentarlos ahora, pero estuve echando un vistazo a un par de ellos y creo que vale la pena echarles un ojo y,por lo tanto, enlazarlos.

Me parece interesante porque nos habla del contexto local.

Para mi tiene el interés de hablar de la nube, es más cortito que el otro.

La codificación de los mensajes y el phishing

Escultura

Se habla poco de los problemas que puede traernos la codificación de un mensaje, texto lo que sea… Algunos sistemas intentarán interpretarla como si estuviera escrita en la codificación que esperan, otros la mostrarán sin más, en algún caso puede haber algún tipo de interpretación.

De esto nos habla Brian Krebs en Teach a Man to Phish and He’s Set for Life y un caso de este estilo en el nombre de un fichero: el recpetor trataba de cambiar el nombre, pero se encontraba con que las flechas de movimiento dentro del texto se movía en sentido contrario al que debían:

For example, when he downloaded and tried to rename the file, the right arrow key on the keyboard moved his cursor to the left, and vice versa.

La cosa tiene hasta un nombre y es lo que se llama anulación de derecha a izquierda (right-to-left override) y tiene todo el sentido para idiomas como árabe, hebreo … Se lleva a cabo mediante un caracter especial, que se abrevia como RLO.

The file included in this phishing scam uses what’s known as a “right-to-left override” or RLO character. RLO is a special character within unicode — an encoding system that allows computers to exchange information regardless of the language used — that supports languages written from right to left, such as Arabic and Hebrew.

Esto puede dar lugar a situaciones donde vemos un fichero que se llama “lme.pdf” (un PDF, potencialmente poco peligroso) pero que en realida es “fdp.eml” (un mensaje de correo, más peligroso).

Look carefully at the screenshot below and you’ll notice that while Microsoft Windows says the file attached to the phishing message is named “lme.pdf,” the full filename is “fdp.eml” spelled backwards. In essence, this is a .eml file — an electronic mail format or email saved in plain text — masquerading as a .PDF file.

Cuando abrimos el mensaje como si fuera un PDF, se abre como un mensaje de correo, muestra una página en HTML y nos redirige, a través de algún sistema de redirecciones que oculta el destino final, a algún sitio donde no querríamos ir.

Opening the .eml file generates a rendering of a webpage that mimics an alert from Microsoft about wayward messages awaiting restoration to your inbox. Clicking on the “Restore Messages” link there bounces you through an open redirect on LinkedIn before forwarding to the phishing webpage.

El resto, ya lo podemos imaginar, puede ser cualquier petición de datos ilegítimos que nos produzcan algún problema más adelante.

Comprendiendo mejor las baterías

Cambio de batería.

No me llevo bien del todo con la electrónica y el hardware. Eso no me impide comprender lo importante que es y admirar entradas como Understanding Battery Performance of IoT Devices donde un experto nos desgrana los detalles importantes de la baterías.

Casi al principio ya dice que el tema de las baterías es complicado:

But batteries are hard

Después habla de la temperatura, el uso, y muchas otras consideraciones.

Para guardar.

La superficie de ataque de la Inteligencia Artificial

Detalle pasaje de madera de la torre

Cuando introduces un nuevo sistema añades toda una panorámica de posibilidades donde un atacante puede intentar hacer algo. Cuantas más son las posibilidades, mayor es lo que llamamos la superficie de ataque.

En The AI Attack Surface Map v1.0 Daniel Miessler nos da pistas sobre todos los sitios donde un atacante podría intentar obtener alguna ventaja cuando hablamos de la inteligencia artificial.

This resource is a first thrust at a framework for thinking about how to attack AI systems.

Habla de los componentes (modelos, preguntas, índices, memoria, cadenas, agentes, …) y luego habla de algunos ejemplos de ataques posibles (inyección de preguntas, prompts, ataques al entrenamiento, …).

Interesante.

Las vulnerabilidades y su estudio para mejorar la seguridad

Catedral de Santa Cecilia. Detalle superior.

En 2022 0-day In-the-Wild Exploitation…so far Maddie Stone del proycto Google Project Zero habla de los fallos de día cero (fallos para los que todavía no hay una actualización que resuelva el problema) y cómo son.

Empieza diciendo que en junio de 2022 había 18 de estos fallos detectados y que estaban siendo utilizados por los malos, pero que la mitad de ellos eran simplemente variantes de fallos anteriores que no habían sido adecuadamente resueltos. Esto significa que podrían haberse evitado si el arreglo hubiera podido realizarse con más cuidado.

As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022. When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests.

Esto es totalmente contradictorio con la idea que tenemos a veces de que estos fallos son muy sofisticados y tecnológicamente avanzados.

When people think of 0-day exploits, they often think that these exploits are so technologically advanced that there’s no hope to catch and prevent them.

El problema es que cuando se encuentran este tipo de fallos no suele disponerse de la tranquilidad y el tiempo necesario para solucionarlos bien y lo que se hace es evitarlos de la mejor manera posible que sea rápida y luego ya no hay más tiempo ni interés en mejorar esa solución.

Haría falta encontrar la verdadera causa del problema y cómo se ha podido llegar a introducir el fallo.

Understanding the underlying vulnerability that is being exploited. Also tries to understand how that vulnerability may have been introduced.

Haría falta analizar las posibles variantes del problema que podrían afectarnos: buscar el mismo patrón en otros lugares, y hacer mejores comprobaciones.

Looking for other vulnerabilities similar to the reported vulnerability. This can involve looking for the same bug pattern elsewhere, more thoroughly auditing the component that contained the vulnerability, modifying fuzzers to understand why they didn’t find the vulnerability previously, etc.

Habría que analizar el parche (la solución) para estar seguros de que resuelve el problema de manera completa.

Analyzing the proposed (or released) patch for completeness compared to the root cause vulnerability.

Finalmente, comprender cómo se realiza el ataque y cómo se usa el fallo, para taratar de resolver no sólo el fallo, sino también mitigar la posibilidad de que se utilicen técnicas similares en otros contextos.

Understanding the primitive gained from the vulnerability and how it’s being used. While it’s generally industry-standard to patch vulnerabilities, mitigating exploit techniques doesn’t happen as frequently.

Todo ello, claro, compartido de manera transparente por los afectados, de forma que todo el mundo pueda aprender de esos problemas.