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.

Políticas de contraseñas: lo estamos haciendo mal

Cúpula Aunque van apareciendo intentos de sustituirlas y evitarlas, lo cierto es que las contraseñas siguen siendo una forma bien conocida de identificarse y autentificarse en internet.

Da la casualidad de que hace unos días avisaba a un administrador de que su sistema de gestión de cambio de contraseñas tenía algunos problemas. Me considero un friki del tema, y me fijo en detalles que parece que muchos desarrolladores desconocen. No sólo eso, sino que trato de contarlos a todo el mundo que me deja (principalmente nuestros estudiantes, que no les queda otra).

No sólo eso, muchas veces se aplican políticas solo porque las hemos visto por ahí, o nos parece que añaden seguridad (pista: en algunos casos la reducen) en lugar de aprender lo que ya se sabe sobre el tema. Sin embargo observamos permanentemente como, a pesar de ser un método tan utilizado, las empresas lo usan bastante mal.

De eso trata Password policies of most top websites fail to follow best practices que es el trabajo de Kevin Lee, Sten Sjöberg, y Arvind Narayanan, y que nos muestra el lamentable estado de la cosa.

Definen la seguridad definen los situientes criterios:

Permitir menos de 5 de las 40 claves más usadas y fáciles de adivinar.

Allowed 5 or fewer of the 40 most common leaked passwords and easiest-to-guess passwords (e.g., “12345678”, “rockyou”) we tried.

Las claves no podrán ser más cortas de 8 caracteres o utilizar un medidor de calidad que mida correctamente la resistencia a poder ser adivinado en un ataque de un atacante.

Required passwords be no shorter than 8 characters OR employed a password strength meter that accurately measured a password’s resistance to being guessed by an adversary.

Sobre usabilidad, evitar requisitos sobre el tipo de caracteres utilizados.

Usability: Did not impose any character-class requirements (e.g. “at least one digit and one special character”).

¿Resultado? Sólo 15 sitios de los 120 examinados seguían estas prácticas.

En resumen, más de la mitad de sitios (71/120) no comprueban la calidad de las contraseñas y 19 de los que las comprueban no bloquean menos de la mitad de las malas.

More than half (71 / 120) of websites do not check passwords at all, allowing all 40 of the most common passwords we tested (e.g., “12345678”, “rockyou”).

19 more websites block less than half of the most common passwords we tested.

Sólo 23 utilizan medidores de calidad.

Only 23 / 120 websites used password strength meters.

De los 23, 10 de ellos utilizan los medidores simplemente como indicadores hacia la selección de determinados caracteres y no miden si las contraseñas son fáciles de adivinar.

Of those 23, 10 websites misuse meters as nudges toward specific types of characters and do not incorporate any notion of guessability.

54 de los sitios analizados incluyen requisitos sobre los tipos de caracteres.

54 / 120 sites still require specific character classes such as digits or special characters.

Han publicado una tabla resumen en Datos un resumen.

Se puede leer el artículo académico en [PDF] Password policies of most top websites fail to follow best practices.

¿Leerán esta información las personas responsables de estos sistemas? Parece que no suelen hacerlo.

Investigadores de seguridad y persecución legal

Punteros Ser investigador en temas de ciberseguridad siempre ha sido delicado: cuando se descubre algo hay que informar y no siempre esta información es bien recibida. Si nos hacen caso vamos bien pero aún así, es posible que no estén muy dispuestos a aceptar la publicación del fallo. Por otro lado, también hay quien tiene la idea de primero publicar el fallo, sin avisar a nadie, y esto puede ser un problema si los afectados no pueden reaccionar a tiempo. Algunas empresas han creado programas de botines (bug bounty) para favorecer que los investigadores contacten con ellos y hay ciertos protocolos que permiten que todo sea más ‘civilizado’: aviso, tiempo para reaccionar, cobrar (o no), publicar para que todo el mundo lo sepa…

en Cybersecurity researchers no longer will face hacking charges under CFAA nos decían hace unas semanas que ya no será tan fácil atacar a un investigador que divulgue fallos de seguridad; ya había una ley que decía que no se debía perseguir al investigador si se obra de buena fe.

top Justice officials said local U.S. attorneys should not bring charges when “good faith” researchers exceed “authorized access,”

El problema es que esa buena fe puede que no esté muy claro lo que es y parece que van un poco más allá diciendo que se habla de buena fe cuando el objetivos es mejorar la seguridad de los sitios, programas o dispositivos y no la obtención de dinero.

The guidance defines good faith to mean research aimed primarily at improving the safety of sites, programs or devices, as opposed to exploration aimed at demanding money in exchange for withholding disclosure or exploitation of a security flaw.

Esto no impedirá (claro) que las empresas traten de atacar a los investigadores, y que los encargados de perseguir estos delitos hagan lo que consideren oportuno. Pero también es cierto que este tipo de indicaciones federales suelen ser respetadas.

Companies can still sue those who claim to be acting in good faith, and officials could continue to charge hackers under state laws that often echo the CFAA. But most state prosecutors tend to follow federal guidance when their laws are similar.

Como decíamos arriba, muchas empresas ya pagan a los investigadores cuando les indican fallos de seguridad relevantes:

Many companies now pay bug bounties to researchers who find flaws and report them directly or through programs managed by outside companies like Bugcrowd and HackerOne, which hailed the new U.S. policy.

Pero también es cierto que hay vulnerabilidades que se quedan sin conocer por miedo a la persecución.

Other vulnerabilities have never been disclosed or fixed because of fear of prosecution, said Andrew Crocker, a lawyer at the nonprofit Electronic Frontier Foundation who often advises hackers.

Sería mejor hacer una ley nueva, en lugar de utilizar una tan antigua.

Security experts said they would prefer that Congress overhaul the 35-year-old law, since judges apply the existing law as they see fit and especially since another Justice Department could reverse the policy.

Cuando el desarrollador quiere llamar la atención sobre la cadena de suministro

Accionadores de cambio de agujas Estamos viendo ataques que no habíamos visto nunca. En este caso, el desarrollador de un proyecto lo boicotea para llamar la atención o mostrar su enfado por el estado de las cosas: Dev corrupts NPM libs ‘colors’ and ‘faker’ breaking thousands of apps

Los usuarios de bibliotecas populares, como ‘colors’ y ‘faker’ descubrieron de manera desagradable que alguien las había cambiado y sus programas empezaban a mostrar cosas diferentes de lo esperado:

Users of popular open-source libraries ‘colors’ and ‘faker’ were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.

Algo simple, como introducir un bucle infinito:

The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on ‘colors’ and ‘faker.’

Mostraban basura, y diversos mensajes.

… were left stunned on seeing their applications print gibberish messages on their console.

Había una componente revindicativa y de protesta, frente a todas esas empresas que utilizan los programas de software libre sin contribuir.

The reason behind this mischief on the developer’s part appears to be retaliation-against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.

La cuestión, claro, es que el software libre funciona así: se publica y lo usa quien quiere (y para lo que quiere) así que igual este desarrollador se equivocó en la forma de distribuir su trabajo.

“If you have problems with business using your free code for free, don’t publish free code. By sabotaging your own widely used stuff, you hurt not only big business but anyone using it. This trains people not to update, ‘coz stuff might break.”

Hay una componente que siempre veremos cuando utilizamos servicios de tercero y es que GitHub le suspendió la cuenta:

GitHub has reportedly suspended the developer’s account.

Lo que provoca la paradoja de dejar al desarrollador sin acceso a su propio proyecto. Y a preguntarnos si estamos siguiendo el camino correcto.

“Removing your own code from [GitHub] is a violation of their Terms of Service? WTF? This is a kidnapping. We need to start decentralizing the hosting of free software source code,…

Todo esto tiene algo de relación con el problema de log4j y los problemas que causó en un montón de proyectos que, por supuesto, sólo se quejaban cuando la cosa iba mal.

But, shortly after mass-exploitation of the Log4shell vulnerability, the maintainers of the open-source library worked without compensation over the holidays to patch the project, …

Un debate que probablemente haya hecho pensar a mucha gente sobre estos temas.

Vulnerabilidades, parcheos y quién puede resolver los problemas

Defensa El consejo que siempre le damos a los usuarios es actualizar sus sistemas, para parchear los fallos de seguridad. Típicamente, un sistema actualizado es mucho más robusto frente ataques (inmune no, claro) que uno sin actualizar.

Cuando vamos al entorno coroporativo, eso no siempre es fácil ni posible. Y entonces hacen falta otras estrategias (compartimentalizar, aislar, …). En Patching is security industry’s ‘thoughts and prayers’: ex-NSA man Aitel hablan del tema y afirman que parchear es inútil.

Aitel pointed out that if there were vulnerable devices on a network, then they should be removed and substituted with others, rather than being continuously patched.

De hecho, recomendaba a sus clientes incluir claúsulas permitiendo rescindir los contratos en caso de que se demostrara que los programas tenían muchos fallos.

Aitel said many of his customers had been big financial firms and he had advised that any contracts they signed with software vendors also contain a clause that would enable them to walk out of contracts if any software proved to be overly buggy.

Y, según él, el problema tendría que ver con la (mala) calidad de los programas.

He had harsh words for Microsoft and other big software vendors whom he said had done little to actually mitigate the problems posed by poor-quality software. He also criticised PHP for its numerous security problems.

Finalmente habla de que los gobiernos deberían tomar cartas en este asunto, porque el resto no tendrían capacidad para resolver este tipo de problemas.

Aitel called for vulnerability management, advocating the government as the best entity to handle this. His argument was that no other entity had sufficient power to push back against the lobby of the big software vendors and the security industry.

Bruce Schneier es otro de los que hablan de que las empresas no tienen capacidad para atacar estos problemas, por ejemplo en It’s the Economy, Stupid.

La granulariad, las APIs, y un proxy para solucionarlo

Puerta de Famagusta A veces las APIs (estoy pensando que existe una analogíca ‘clásica’ con los gestores de bases de datos) no nos proporcionan suficiente granularidad a la hora de gestionar los activos digitales (en los gestores de bases de datos suele haber la granularidad, pero no siempre querremos dedicar tiempo a configurar nuestros programas y, además, los permisos de las bases de datos; seguramente un error, pero es lo que se hace a veces).

Sobre este tema y cómo lo gestionaron en su caso nos habla ‘Statgirl Flowers’ en Building a stateless API proxy:

It turns out GitHub’s API has extremely coarse access control on API tokens. For example, imagine if you wanted to write an editor plug-in to turn your Gists into easily-accessible snippets in your editor. People would have to grant your plug-in write access even though it only really needs read access. There’s a big Dear GitHub post on the subject, but this is not uncommon - many APIs have permissions systems that don’t quite always fit the needs of users.

La solución pasa por crear un proxy donde se gestionan los permisos y qué cosas pueden hacer unos programas y otros no.

So what I really want is a token that can read but not write gists. The proxy can issue its own token. It can keep track of the fact that the token is only allowed to read Gists and not write them. When it gets a request for the GitHub API it can check permissions before forwarding the request and the real token to GitHub.

Curioso.

La prioridad de los desarrolladores no suele ser la seguridad

Museo Pedagógico de Aragón. Estoy convencido de que la mayoría de los desarrolladores quieren que su código sea seguro. El problema es que, además, quieren cumplir plazos, sus jefes quieren mantener los costes contenidos, …. y eso lleva a que la seguridad no sea una prioridad.

En 86% of developers don’t prioritize application security nos lo confirmaban. En una encuesta de Secure Code Warrior, el 86% de los desarrolladores no consideraban la seguridad una prioridad de primer nivel.

While many developers acknowledge the importance of applying a security-led approach in the software development lifecycle, 86% do not view application security as a top priority when writing code.

No sólo eso, sino que solamente un 29% de ellos creen que esto debería ser una prioridad.

This is a contributing factor to another major finding – that only 29% of developers believe the active practice of writing code free of vulnerabilities should be prioritized.

Entre los aspectos que deberían ayudar, como no, la formación:

Training remains a major influence over developers’ application of secure coding as 81% are utilizing the knowledge gleaned from training on a near-daily basis.

Las responsabilidades de que esto no se considere una prioridad: cumplir los plazos, desconocimiento, falta de formación al respecto y, finalmente, los fallos que introducen otros.

36% attribute the priority of meeting deadlines as a primary reason their coding still possesses vulnerabilities

33% don’t know what makes their code vulnerable

30% feel that their in-house security training could most be improved if it had more practical training with real world scenarios and outcomes

30% say the biggest concern with the implementation and practice of secure coding is dealing with vulnerabilities introduced by co-workers