Explicando los fallos en el arranque seguro de un Google Nest

Bolas chinas concéntricas Seguimos con las entradas veraniegas. Esperamos que sirvan para hacerse una idea (no es necesario comprender todos los detalles) de lo complejos que pueden llegar a ser algunos fallos y los ataques correspondientes.

En este caso hablamos de Breaking Secure Boot on Google Nest Hub (2nd Gen) to run Ubuntu.

Las técnicas son variadas y utilizan algo de lo que hemos hablado de vez en cuando, el fuzzing, por ejemplo. No se trata de una contaminación a lo loco, sino con objetivos bastante concretos.

We build a fuzzing harness that injects data in blk_dread (function that reads data from a block device), and triggers execution by calling fat_read_file.

Luego, siguen con la técnica para probar con parámetros que un atacante podría controlar.

In a second phase, we extend the fuzzing to the initialized state since some parameters can be controlled by the attacker. For example, the USB Mass Storage driver sets multiple parameters in structure blk_desc that describe the detected block device in initialized state.

Y algunas cosas más, claro.

En las conclusiones nos cuentan cómo todo este proceso les llevó a encontrar un puerto USB inesperado. Desde allí se podía arrancar con un dispositivo externo, y luego aprovechar otros fallos existentes.

Hardware exploration led to uncovering an unexpected USB port. Software exploration revealed that it can boot from an USB Mass Storage device. Bug hunting exposed a stack overflow vulnerability in the DOS partition parser.

Un análisis de los fallos que permitían infectar teléfonos de NSO

Dibujos Este invierno estuvimos muy ocupados pensando en Pegasus y cómo permitía atacar teléfonos de personas importantes para obtener su información. Rápidamente salieron análisis de algunos fallos que permitían estos ataques y, por ejemplo, en A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution . Me pareció una delicia leerlo y cómo es el nivel de sofisticación de este tipo de ataques: un mensaje recibido a través de iMessage, que aprovechan que el programita muestra en ciclo sin fin algunas animaciones en formato GIF, pero utiliza un método auxiliar al que le pasa la imagen; este método trata de averiguar el formato del fichero, independientemente de la extensión y, por lo tanto esto abre la puerta a que alguien pueda mandar un fichero con extensión .gif que no lo sea y provocar que el iMessage haga algo con él.

En este caso, se utilizaba un fichero PDF porque el subsistema en cuestión tenía un fallo que permitía aprovecharlo para … ejecutar Javascript. Puede que haya alguien que esté ya perdido, pero la cosa es todavía más compleja, porque se aprovechan ciertos trucos de compresión de PDFs y algún truco más.

Lo dicho, una lectura muy entretenida.

Errores en Java por falta de verificación... ¿multiplícate por cero?

Techo y sus refuerzos

En Oracle Java wins ‘crypto bug of the year’ for bypass flaw nos hablan de un fallo de Java (versiones entre la 15 y la 18) en la validación de ls firmas ECDSA que permitiría a los ‘malos’ firmar ficheros como si fueran legítimos.

Java versions 15 to 18 contain a flaw in its ECDSA signature validation that makes it trivial for miscreants to digitally sign files and other data as if they were legit organizations.

ECDSA es Elliptic Curve Digital Signature Algorithm (criptografía sobre curvas elípticas.

Y el problema parece ser que no se hace una comprobación de que los datos son correctos (concretamente, que la coordenada x aleatoria y la prueba de firma son distintas de cero. Una firma de (0,0) validaría cualquier mensaje.

ECDSA doesn't sanity check that the random x coordinate and signature proof are nonzero; a (0,0) signature validates any message.

El problema es que este fallo es muy fácil de explotar (además de un fallo evidente de programación).

What’s particularly interesting about this issue is that it’s incredibly easy to exploit, and an obvious programming error.

Las firmas ECDSA son una pareja de números (r,s), y para verificar la firma se realizan operaciones matenáticas que incluyen un hash (huella) de los datos, la clave pública de la organización o persona que firma los datos, que son estos valores r y s. En un lado de la ecuación está la r y en el otro la r y la s. Ambos lados deben dar el mismo resultado para pasar la prueba.

Both sides of this computation must equal for the signature check to pass.

Por lo tanto, para que una firma sea válida no puede tener los valores 0 porque en las operaciones hay multiplicaciones por estos valores.

In theory, for a signature to be valid, (r, s) cannot be (0, 0) because some of the math involves multiplying these numbers with other values.

Pero cuando hay ceros y multiplicaciones o divisiones (este caso es todavía peor, porque la división por cero no produce errores aquí). En el caso de las multiplicaciones el resultado es cero.

You don’t need to know a lot of mathematics to know that anything multiplied by zero equals zero. One part of the calculation involves dividing by s - but, unfortunately, in a way that doesn’t generate an error if you divide by zero.

El diablo está en los detalles.

La documentación de las APIs. El caso de gov.uk

Centro de Exposiciones del Centro de Conocimiento sobre servicios públicos electrónicos. Telegramas y avisador. Los sitios del Gobierno de Gran Bretaña son un ejemplo de gestión de la información, apertura y muchas más cosas. En [ Documenting APIs. Structuring, designing and publishing your API documentation]}(https://www.gov.uk/guidance/how-to-document-apis) hablan de sus APIs y cómo estructuran, diseñan y publican la documentación relevante.

No voy a entrar en detalles pero el índice habla de comprender las necesidades de los usuarios, estructurar la documentación, escribirla, ayudar a los usuarios a navegar por ella, publicarla y comprobarla.

Muy interesante.

Escribiendo programas maliciosos en el registro del sistema

Expo. Máscara Cualquier cosa que pueda ser escrita o leída por un programa será utilizada para intentar atacarnos. Un ejemplo curioso es Hackers are now hiding malware in Windows Event Logs donde nos cuentan como algunos atacantes están usando el registro de actividad de Windows para esconder programas maliciosos que después serán activados y utilizados para infectar nuestro sistema.

Se trataría de una campaña dirigida, con un grado alto de personalización, pero también uso de herramientas disponibles por ahí.

The investigation revealed that the malware was part of a “very targeted” campaign and relied on a large set of tools, both custom and commercially available.

En particular, la inserción de programas maliciosos para la shell en los registros de actividad de los servicios de gestión de claves.

One of the most interesting parts of the attack is injecting shellcode payloads into Windows event logs for the Key Management Services (KMS), an action completed by a custom malware dropper.

El ataque se basaría en utilizar una DLL (Dynamic Link Library) que permitiría escribir en el registro el código malicioso.

The dropper copies the legitimate OS error handling file WerFault.exe to ‘ C:\\Windows\\Tasks ‘ and then drops an encrypted binary resource to the ‘ wer.dll ‘ (Windows Error Reporting) in the same location, for DLL search order hijacking to load malicious code.

Una vez instalado, busca si encuentra alguna señal de que ya se ha realizado la infección. Si no es así, comienza a escribir el código malicioso en bloques de 8Kb, que después serán combinados para formar el código para la siguiente fase del ataque.

Legezo says that the dropper’s purpose is to loader on the disk for the side- loading process and to look for particular records in the event logs (category 0x4142 - ‘AB’ in ASCII. If no such record is found, it writes 8KB chunks of encrypted shellcode, which are later combined to form the code for the next stager

Interesante.