Security Posts

Widespread Windows Crashes Due to Crowdstrike Updates

Supongo que muchos os habéis enterado ya del Blue Screen Of Death que ha provocado el EDR de Crowdstrike en todas las máquinas Windows. Supongo que algunos compañeros aún estáis arreglando máquinas o con los planes de contingencia de muchos de los servicios que han dejado de funcionar. Porque sí, ha sido una buena, y en mis grupos con colegas de profesión en otras empresas, se han pasado un viernes y un sábado divertido.
Figura 1: Aprendizajes del Crowdstrike BSOD.¿Debes abandonar Windows?
Se pueden sacar muchos aprendizajes de este caso, y muchos de ellos acercando el ascua a su sardina. También he visto a muchos tecnicoless hablando con recetillas de "Windows malo", "Linux bueno", o "Mac Mejor", como si en GNU/Linux o en MacOs no funcionaran las cosas de manera similar y estuvieran ajenas a estas situaciones. Tecnicoless. Todos tienen su modo protegido, todos tienen sus programas que se han metido en modo protegido y la han liado parda y todos han tenido "Security Nightmares" alrededor de parches. 
Aprendizajes del Crowdstrike BSOD: ¿Debo abandonar Windows?
Os podría contar casos de todos los sistemas operativos, pero no se trata de eso, sino de que el mensaje y los aprendizajes de estos incidentes tengan que venir desde los expertos en tecnología, y no desde los tertulianos y aprovechados que se suben a cualquier trending topic de las redes social para ganar flow con el populismo. Es un problema técnico del que tenemos que aprender cosas y mejorar cosas.
Figura 2: "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición"de Sergio de los Santos en 0xWord.
Instalar cosas que corren en Ring0 siempre es un movida. En las máquinas GNU/Linux, gracias a esta posiblidad, aparecieron los Rootkits, que se migraron exitosamente a Windows y MacOs. Estos bichos malos implicaba que, para defenderte de ellos, había que restringir qué se puede instalar en Ring0, con programas de certificación para los frabricantes de drivers en nivel privilegiado que pudieran extender las funciones de protección en el equipo. Algunos drivers de red, de gestión de dispositivos, de seguridad, necesitan ese nivel de acceso a las funciones del sistema operativo.
Figura 3: Libro de Hardening de Servidores GNU/Linux GOLD Edición(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord
Uno de los certificados es la empresa Crowdstrike, que tiene un EDR (EndPoint Detection & Response) para detectar amenazas de seguridad capturando eventos del sistema operativo y la red y analizándolos en cloud, que desplegó una actualización de ese driver que "funcionaba en el ordenador del programador", pero que hace un acceso a una zona de memoria protegida con el nivel de privilegio de Ring0, lo que implica que no estén activas las protecciones de Ring3 que hubieran tumbado al programa y listo.
Figura 4: Libro de macOS Hacking en 0xWord

Como estaba en Ring0, el sistema operativo, por seguridad y protección de la integridad de los datos, se detiene haciendo un Halt con un BSOD. El despliegue de este agente en Ring0, que se ocupa de detectar amenazas se convirtió en la gran amenaza a la continuidad de negocio, y ahora hay que entrar en planes de contingencia para recuperar todos los sistemas. Con cosas curiosas que nos hacen pensar.
En primer lugar, como es un fallo con un driver defectuoso que se carga en el arranque, implica que los equipos no arrancan. Así que si quieres tomar control del equipo hay que empezar con arranques en "Safe Mode" del sistema operativo, lo que evita que se carguen drivers de terceros en el kernel. Después, se desinstala o actualiza, manualmente o con un script, el driver dichoso. Y una vez hecho esto ya podemos arrancar otra vez el equipo y tener acceso a la red, y a todas las funciones del sistema operativo.
Con este panorama, hay que ver cómo hacer este proceso, que como os podéis imaginar no es desatendido y ni remoto, lo cual es una movida "big time", porque estamos en un mundo de equipos remotos, de máquinas virtuales, de portátiles con USBs restringidos, incluso físicamente, de equipos que no están mapeados, etcétera.  Y no muchas empresas están preparadas para responder.

Figura 5: Cómo gestionar la Seguridad Informática de una empresa
A mí me hizo reflexionar en esta situación sobre muchas cosas. La primera y más evidente es que los procesos de Quality Assurance en los despliegues de las nuevas versiones deben tener mucha más protección contra el error humano. Procesos de Deployment con DevSecOps en entornos de prueba y pre-producción, etcétera. Muy evidente, y es lo que marca la diferencia entre una empresa que quiere hacer productos y servicios digitales y otra que no.
El segundo pensamiento fue, evidentemente, en el programa de certificación de estos drivers en Ring0 y lo que puede significar en el futuro. Los equipos de Microsoft de certificación habrán sentido en sus carnes la importancia de su rol, y los controles para garantizar que no llegué un software en mal estado a miles de millones de máquinas por mucho que esté creado por una empresa certificada, no han sido suficientes. Y esto va a obligar a fortalecer todos estos procesos. Y entender bien, bien, por qué ha pasado. Al final, todos estos fabricantes se convierten en una gigantesca "Supply Chain" de Windows que hay que controlar. Si se instala en Ring0, entones es parte del funcionamiento básico del sistema.
Figura 6: Libro de Hacking iOS:iPhone & iPad (2ª Edicón) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo Gonzáleez y Alejandro Ramos entre otros.
Por otro lado, esto nos puede llevar a entornos como el de iOS, donde Apple se ha negado a dar acceso al nivel protegido de su iPhone o iPad a nadie. Imaginaos un mundo en el que tuviéramos este caso en iPhone, que no tiene para arrancar en modo a prueba de fallos y cargarle con un USB un parche. Hubiera sido un caos mundial espectacular. Así que es probable que vayamos a un mundo Ring0-less para la mayoría de los sistemas operativos, y donde las técnicas de Jailbreak sean una línea que se se desarrolle mucho más, donde los exploits a bajo nivel con instrucciones del microprocesador sean la siguiente línea de batalla, como hemos visto con GhostRace y los Speculative Use-After-Free Exploits.
También estuve pensando que los grandes proveedores de cloud con infraestructuras IaaS jugaban un gran papel, porque seguro que se podría - en muchos entornos - hacer una deshabilitación desde la nube del driver malicioso. Un entorno de DevSecOps en Cloud ha permitido scriptar el arranque en Safe Mode, aplicar el hot-fix, y re-arrancar el servicio, así que los entornos bien afinados de DevSecOps sacando el máximo de Docker & Kubernetes, ha ayudado. También los entornos VDI en Cloud, lo que da mucho que pensar a cuánto de moderna es la arquitectura IT de tu compañía.
Figura 7: Libro de Docker:SecDevOps en 0xWord de
Fran Ramírez, Elías Grande y Rafael Troncoso
Por supuesto, si tus servidores están en IaaS hay un Ring0 del que te tienes que preocupar, pero si tienes toda tu arquitectura tecnológica en PaaS y los servicios en SaaS, pues no hay Ring0 del que preocuparte tú, lo que debería pensarte si aquel Go-To-Cloud con Lift & Shift fue el más adecuado, o era necesario hacer re-ingeniería a Moderm Cloud Apps.
Dicho esto, dentro de los planes de contingencia de tus entornos de Fail-Safe, debes tener todo preparado para que el bug esté en los procesos que corren en Ring0 - e incluso en el Kernel de los sistemas operativos base de tus servicios -, por lo que si tienes una copia completa de tu entorno preparada para tomar el relevo ante una caída como esta, más vale que tengas en mente este caso, porque si te actualizan al mismo tiempo el nodo activo con un bug como este en Ring0, y en el entorno pasivo tienes el mismo bug, pues has hecho un pan como dos tortas.
En fin, muchos aprendizajes y buenos sobre todo lo que en tu empresa podría estar mejor, pero pensar que la solución es "¡pásate a GNU/Linux!" o "Yo uso Mac", y crees que con esto vas a estar libre de que te pase en el futuro... ¡enhorabuena, eres un Tecnicoless!. 
PD: He dejado los libros de 0xWord relativos a la seguridad de los sistemas operativos y la charla de Cómo gestionar la Seguridad Informática de una empresa para que se los recomendéis a todos los Tecnicoless que opinen y den recomendaciones de este tema sin tener ni "·$·$%&%$& idea. Sólo a ellos.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)  


Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com

–prefix and –suffix can now also be filenames. cut-bytes_V0_0_17.zip (http)
MD5: 86D0692C6303248639A740E7A2AC4525
SHA256: D4FCFBD2305D7E5E97AB993741DF95B4565A882B0CD7DBA061D09578A1DDADA7

By Scott Arciszewski Today, AES-GCM is one of two cipher modes used by TLS 1.3 (the other being ChaCha20-Poly1305) and the preferred method for encrypting data in FIPS-validated modules. But despite its overwhelming success, AES-GCM has been the root cause of some catastrophic failures: for example, Hanno Böck and Sean Devlin exploited nonce misuse to inject their Black Hat USA slide deck into the MI5 website. Security researchers have been sounding the alarm about AES-GCM’s weaknesses for years. Nineteen years ago, Niels Ferguson submitted a paper to a NIST project on block cipher modes outlining authentication weaknesses in AES-GCM (although NIST would ultimately standardize it). And earlier this year, Amazon published a paper that detailed practical challenges with AES-GCM and posited that AES’ 128-bit block size is no longer sufficient, preferring a 256-bit block cipher (i.e., Rijndael-256). To address these issues, I propose a new block cipher mode called Galois Extended Mode (GEM for short), which I presented last month at the NIST workshop on the requirements for an accordion mode cipher. AES-GEM improves the security of GCM in every dimension with minimal performance overhead. Important: The current design for AES-GEM is not ready for production use, as some details will likely change in the future. To understand the current design, let’s start by understanding where AES-GCM falls short, and then discuss how we can do better with GEM. How AES works Before we dive in, it may be helpful for some readers to explain some of the terms and concepts used throughout this blog post. AES (Advanced Encryption Standard) is a block cipher widely used to encrypt information. It supports multiple key sizes (128-, 192-, and 256-bit keys) but always operates on 128-bit blocks. AES is the standardized form of the Rijndael family of block ciphers. Rijndael supports other block sizes than 128-bit, but only the 128-bit blocks were standardized by NIST. Modern processors provide dedicated hardware instructions for accelerating AES operations, but the AES key schedule can still negatively impact performance. ECB (Electronic Code Book) mode is the absence of a block cipher mode of operation. It involves computing the block cipher directly on a block of data. ECB mode is not semantically secure, as many cryptographers have demonstrated. For improved security, block ciphers like AES are typically used with a mode of operation. (If not, they almost certainly should be. Get in touch with our cryptography team if you think you’re using ECB to encrypt sensitive data.) CTR (Counter Mode) is a mode of operation for block ciphers wherein an increasing sequence of values is encrypted with the block cipher to produce a pseudorandom keystream. To encrypt data, simply calculate the XOR of each plaintext byte with each corresponding keystream byte. GCM (Galois/Counter Mode) is a block cipher mode of operation that provides authenticated encryption. It is what cryptographers call an AEAD mode: Authenticated Encryption with Additional Data. GCM can provide confidentiality for sensitive data and integrity for both sensitive and public data. AEAD modes are important for designing cryptosystems that are resilient to attackers who attempt to mutate encrypted data in order to study the system’s behavior in hopes of learning something useful for cryptanalysis. GCM is a composite of Counter Mode (CTR) for encrypting the plaintext and a Galois field Message Authentication Code (GMAC), which authenticates the ciphertext (and, if provided, additional associated data). GMAC is defined with a function called GHASH, which is a polynomial evaluated over the authenticated data. The output of GHASH is XORed with an encrypted block to produce the final authentication tag. The authentication key, called H, is calculated by encrypting a sequence of 128 zeroed bits. POLYVAL is an alternative to GHASH that is used in AES-GCM-SIV. The irreducible polynomial used by POLYVAL is the reverse of GHASH’s irreducible polynomial. Many cipher modes (including GCM and CTR) require a number that is used only once for each message. This public number that should never be repeated is called a nonce. Finally, the birthday bound is a concept from probability theory that indicates the likelihood of collisions in a set of random values. In cryptography, it implies that if nonces are selected randomly, the probability of two nonces colliding increases significantly as more nonces are used. For AES-GCM with 96-bit nonces, after about 232 messages, there’s a 1 in 232 chance of a nonce collision, which can lead to security vulnerabilities such as the ability to forge messages. Practical challenges with AES-GCM today The biggest challenge with AES-GCM, as others have pointed out, is that AES only has a 128-bit block size. This has two primary consequences:

1. The size of the public nonce and internal counter is constrained to a total of 128 bits. In practice, the nonce size is usually 96 bits, and the counter is 32 bits. If a larger nonce is selected, it is hashed down to an appropriate size, which has little improvement on security. If you ever reuse a nonce, you leak the authentication subkey and can, therefore, forge messages indefinitely.
2. Above a certain number of blocks encrypted under the same key, an attacker can distinguish between ciphertext and random bytes with significant probability.

When you understand that we’re dealing with powers of two, 96 bits of nonce space may sound like a lot, but if you’re selecting your nonces randomly, you can encrypt only 232 messages before you have a 2-32 probability of a collision. Using a cipher with a larger block size would alleviate this pain point, but it’s not the only way to fix it. The AES block size is not the only problem with AES-GCM in practice. As Niels Ferguson pointed out in 2005, a successful forgery against short tags reveals the authentication subkey. Further, we also learned that AES-GCM has an unexpected property where multiple keys can decrypt the same ciphertext + authentication tag. Its discoverers referred to this problem as Invisible Salamanders because it allowed them to hide a picture of a salamander from an abuse-reporting tool in an encrypted messaging application. Mitigating against Invisible Salamanders in a protocol that uses AES-GCM requires some one-way commitment of the key used. Finally, the maximum plaintext length for a single message in AES-GCM is relatively small: just below 64 GiB. In order to cope with this maximum length, software often decomposes larger messages into shorter frames that fit within this length constraint. This leads to the limited nonce space before the birthday bound being used up much more quickly than if longer messages were tolerable. Introducing AES-GEM Our proposal, Galois Extended Mode, is a modification of GCM (Galois/Counter Mode) that currently addresses most of these weaknesses. However, there is still an open question about which tactic we want to employ to mitigate the last pain point, which I will explain momentarily. At a high level, we propose two variants: AES-128-GEM and AES-256-GEM. We also specify two AEAD constructions using the standard AEAD interface. AES-128-GEM

• Key length: 128 bits
• Subkey length: 128 bits
• Nonce length: 192 bits
• Maximum plaintext length: 261 – 1 bytes
• Maximum AAD length: 261 – 1 bytes
• Tag length: 48 bytes (AEAD) or 16 bytes (without commitment)

AES-256-GEM

• Key length: 256 bits
• Subkey length: 256 bits
• Nonce length: 256 bits
• Maximum plaintext length: 261 – 1 bytes
• Maximum AAD length: 261 – 1 bytes
• Tag length: 48 bytes (AEAD) or 16 bytes (without commitment)

The road from GCM to GEM If you start with the existing design for AES-GCM and make the following changes, you will arrive at the current draft for GEM. Nonce extension First, we need a longer nonce, which we will use for subkey derivation in the next step. For 256-bit keys, a 256-bit nonce is a nice round number. For 128-bit keys, we end up needing 192 bits. In either case, the rightmost 64 bits will be reserved for the actual underlying encryption. The remaining bits (192 bits for AES-256, 128 bits for AES-128) are to be used for subkey derivation. This allows us to amortize the cost of the key derivation and set up an AES key schedule across multiple messages, provided the first (n – 64) bits of the nonce and key are the same. Subkey derivation There are multiple strategies for using AES for key derivation. At Real World Cryptography 2024, Shay Gueron presented DNDK-GCM, which uses an interesting construction to achieve subkey derivation. We want to keep things simple and well-understood. Consequently, we based our key derivation strategy on CBC-MAC since CMAC is already an FIPS-approved MAC (i.e., for AES-CCM). In the case of AES-256, we use two CBC-MAC outputs to derive a 256-bit subkey. However, this approach has one subtly annoying property: The two halves will never produce the same output, so there are, strictly speaking, fewer than 2256 possible outputs. In both variants of GEM, we borrow a trick from Salsa20’s design: XOR the output with the input key to ensure the subkey is indistinguishable from uniformly random to any attacker who doesn’t know the input key. If you don’t know this key, the output is indistinguishable from a random key of the appropriate length. Support for longer messages The reason we needed 64 bits of leftover nonce, rather than 96 as would be typical for GCM, is that our internal counter size is not 32 bits long. It is, instead, 64 bits long. Otherwise, as currently written, GEM behaves identically to what you’d expect from GCM: It uses counter mode for bulk data encryption. Let’s put a pin in that and revisit it in a moment. Improved authentication security Our incumbent design, AES-GCM, is constructed in the following way:

1. Derive an authentication subkey, H, by encrypting an all-cleared block with the key.
2. Calculate GHASH() of the ciphertext, associated data, and a block containing the lengths of both segments (in bits).
3. XOR the output of step 2 with the AES-CTR encryption of a counter block.

Our design is mostly the same, but with an important tweak:

1. Derive an authentication subkey, H, by encrypting an all-set block with the subkey.
2. Calculate GHASH() of the ciphertext, associated data, and a block containing the lengths of both segments (in bits).
3. Encrypt the output of step 2 with AES-ECB, using the input key.
4. XOR the output of step 3 with the AES-CTR encryption of a counter block.

Step 3 directly addresses the weaknesses that Niels Ferguson identified with AES-GCM in 2005. The other changes are implementation details. This tweak offers better security for short tags since the AES encryption of the raw GHASH output bits is a nonlinear transformation that is not invertible without the key. We use the input key rather than the subkey since the only other place the input key is used to encrypt data (i.e., subkey derivation) is never directly revealed. Key commitment Before we tackle GEM’s protection against Invisible Salamander-style attacks, we need to analyze some other subtleties of the design. The component lengths in the final block for both GCM and GEM are both expressed in terms of bits, not bytes, and are restricted to 264 each. This means that, even though GEM could theoretically allow up to 264 blocks (or 268 bytes) of plaintext per message due to its internal counter, we would have to tweak the final GHASH step to accommodate this extra overhead. Instead of doing that, the unreachable values for the internal counter are reserved for the cipher’s internal use. Specifically, the internal counter values that end in 0x02000000 00000000 through 0xFFFFFFFF FFFFFFFF cannot be reached while respecting this 261 – 1 byte limit on the plaintext. The all-set block (0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF) is already used in GEM for the authentication subkey, while the 64-bit trailing nonce + 0xFFFFFFFF 0xFFFFFFFE is used for the counter block, for the final authentication tag calculation. To provide key commitment, the next two blocks down, the nonce + 0xFFFFFFFF 0xFFFFFFFC and 0xFFFFFFFF 0xFFFFFFFD will serve as a commitment value for the key and nonce. We specify two blocks because using one AES block here is not sufficient. Consider the case of AES-256, which has 256-bit keys and 128-bit blocks: by the pigeonhole principle, we expect there to be 2128 different keys that will map a given fixed plaintext value into a fixed ciphertext value. Therefore, a single block is not sufficient for commitment. However, no such pigeonhole consideration is necessary for two successive blocks, assuming the block cipher is secure. In this way, we can quickly generate a commitment value for a given key and nonce. In the AEAD interface, the commitment is appended to the authentication tag. Both must be compared to their recomputed values, in constant-time, when decrypting messages. AES-GEM’s performance characteristics Although we’ve addressed most of GCM’s pain points, the actual performance impact of GEM is minimal. AES-256-GEM:

• Key derivation: four additional blocks of AES encryption, some XORs, one additional key schedule
• Authentication: one additional block of AES encryption
• Key commitment: two additional blocks of AES encryption

AES-128-GEM:

• Key derivation: two additional blocks of AES encryption, some XORs, one additional key schedule
• Authentication: one additional block of AES encryption
• Key commitment: two additional blocks of AES encryption

Since AES is very fast these days due to hardware acceleration, this performance impact should be mostly unnoticeable in all but the most performance-sensitive of applications. In those cases, the key derivation performance cost can be amortized across up to 232 different messages if the derived subkey is cached. Polishing AES-GEM There is one final issue that the current draft of GEM does not sufficiently address, but we hope to discuss this issue at the NIST workshop and will certainly address it in the final design. Although our draft GEM construction allows for longer messages than GCM, the AES block size makes it risky to use as-is. The primary concern is that encrypting a very long message would give an attacker a significant advantage in distinguishing AES-GEM ciphertexts from sequences of random bytes. (This is one of the concerns raised in Amazon’s 2024 paper.) There are a few ways we can polish GEM to address this weakness, which have different performance characteristics and trade-offs. Wide block PRPs Over the years, many cryptographic designs have used wide block PRPs, such as AES in XTS mode, to securely encrypt more than the AES block size would normally allow. Since XTS is widely used in disk encryption, this method would likely prove secure. However, XTS mode is not currently standardized for use cases aside from disk encryption. Hierarchical key derivation What if, instead of using the subkey directly, we used the upper 32 bits of the internal counter to select a different value from the reserved nonce space, encrypt that, and derive a new subkey every 236 bytes? Then, we encrypt using this subkey for only the remaining 32 bits of the counter, which is analogous to what AES-GCM has been doing for decades. This sub-subkey derivation could be constructed similarly to the key commitment:

• For AES-256-GEM, encrypt 32 bytes derived from the reserved nonce space, and use these as the actual CTR key.
• For AES-128-GEM, encrypt 16 bytes derived from the reserved nonce space (but a distinct nonce space from what AES-256-GEM would select), and use it as the actual underlying CTR key.

This is an attractive option for multiple reasons. Most importantly, this tactic would sidestep the PRP distinguisher problem in a very direct way. It also doesn’t depend on any non-standard designs (like XTS mode). You could build the whole thing with FIPS approved components, as we did with the rest of our draft design for AES-GEM. The downside? This approach does incur yet another key schedule, every 236 bytes of plaintext. This probably still amortizes well, but is worth keeping in mind. Total performance cost of AES-GEM with hierarchical key derivation AES-256-GEM:

• Key derivation: four additional blocks of AES encryption, some XORs, one additional key schedule
• Additional key derivation every 236 bytes of plaintext: two additional blocks of AES encryption, one additional key schedule
• Authentication: one additional block of AES encryption
• Key commitment: two additional blocks of AES encryption

Total additional overhead for a 1 GB plaintext: seven blocks of AES-256, two additional AES-256 key schedules Total additional overhead for a 1 TB plaintext: 37 blocks of AES-256, 17 additional AES-256 key schedules AES-128-GEM:

• Key derivation: two additional blocks of AES encryption, some XORs, one additional key schedule
• Additional key derivation every 236 bytes of plaintext: one additional block of AES encryption, one additional key schedule
• Authentication: one additional block of AES encryption
• Key commitment: two additional blocks of AES encryption

Total additional overhead for a 1 GB plaintext: five blocks of AES-128, two additional AES-128 key schedules Total additional overhead for a 1 TB plaintext: 21 blocks of AES-128, 17 additional AES-128 key schedules Other ideas There may be yet another option that we haven’t imagined yet. Finding the best trade-off, especially when considering hardware design, is one reason why we’re presenting GEM at the NIST workshop. Cutting the GEM The IETF’s CFRG is currently discussing an RFC draft for a modified variant of AES-GCM that is secure for short tags, called GCM-SST. Their design uses POLYVAL rather than GHASH, for performance reasons, and uses a second authentication key (Q) with a second POLYVAL, which is all XORed together. Unsurprisingly, this additional XOR doesn’t significantly protect against the weakness of short tags in AES-GCM (although it does make the usual attack more expensive). Our initial design for GEM uses the AES block cipher to permute the GHASH output rather than simply introducing an additional linear operation (XOR) to the polynomial output. We are interested in partnering with other industry leaders to deliver a variant of GEM that emphasizes the short tag use case (i.e., WebRTC). This hypothetical variant (CUT-GEM, tentatively) could use POLYVAL instead of GHASH and use an epoch-based subkey derivation schedule to reduce the performance hit on each packet. Where can I learn more about AES-GEM? More information about AES-GEM is available on our GitHub!

Authored by Willem Zeeman and Yun Zheng Hu This blog is part of a series written by various Dutch cyber security firms that have collaborated on the Cactus ransomware group, which exploits Qlik Sense servers for initial access. To view all of them please check the central blog by Dutch special interest group Cyberveilig Nederland [1] The effectiveness of the public-private partnership called Melissa [2] is increasingly evident. The Melissa partnership, which includes Fox-IT, has identified overlap in a specific ransomware tactic. Multiple partners, sharing information from incident response engagements for their clients, found that the Cactus ransomware group uses a particular method for initial access. Following that discovery, NCC Group’s Fox-IT developed a fingerprinting technique to identify which systems around the world are vulnerable to this method of initial access or, even more critically, are already compromised. Qlik Sense vulnerabilities Qlik Sense, a popular data visualisation and business intelligence tool, has recently become a focal point in cybersecurity discussions. This tool, designed to aid businesses in data analysis, has been identified as a key entry point for cyberattacks by the Cactus ransomware group. The Cactus ransomware campaign Since November 2023, the Cactus ransomware group has been actively targeting vulnerable Qlik Sense servers. These attacks are not just about exploiting software vulnerabilities; they also involve a psychological component where Cactus misleads its victims with fabricated stories about the breach. This likely is part of their strategy to obscure their actual method of entry, thus complicating mitigation and response efforts for the affected organizations. For those looking for in-depth coverage of these exploits, the Arctic Wolf blog [3] provides detailed insights into the specific vulnerabilities being exploited, notably CVE-2023-41266, CVE-2023-41265 also known as ZeroQlik, and potentially CVE-2023-48365 also known as DoubleQlik. Threat statistics and collaborative action The scope of this threat is significant. In total, we identified 5205 Qlik Sense servers, 3143 servers seem to be vulnerable to the exploits used by the Cactus group. This is based on the initial scan on 17 April 2024. Closer to home in the Netherlands, we’ve identified 241 vulnerable systems, fortunately most don’t seem to have been compromised. However, 6 Dutch systems weren’t so lucky and have already fallen victim to the Cactus group. It’s crucial to understand that “already compromised” can mean that either the ransomware has been deployed and the initial access artifacts left behind were not removed, or the system remains compromised and is potentially poised for a future ransomware attack. Since 17 April 2024, the DIVD (Dutch Institute for Vulnerability Disclosure) and the governmental bodies NCSC (Nationaal Cyber Security Centrum) and DTC (Digital Trust Center) have teamed up to globally inform (potential) victims of cyberattacks resembling those from the Cactus ransomware group. This collaborative effort has enabled them to reach out to affected organisations worldwide, sharing crucial information to help prevent further damage where possible. Identifying vulnerable Qlik Sense servers Expanding on Praetorian’s thorough vulnerability research on the ZeroQlik and DoubleQlik vulnerabilities [4,5], we found a method to identify the version of a Qlik Sense server by retrieving a file called product-info.json from the server. While we acknowledge the existence of Nuclei templates for the vulnerability checks, using the server version allows for a more reliable evaluation of potential vulnerability status, e.g. whether it’s patched or end of support. This JSON file contains the release label and version numbers by which we can identify the exact version that this Qlik Sense server is running. Figure 1: Qlik Sense product-info.json file containing version information Keep in mind that although Qlik Sense servers are assigned version numbers, the vendor typically refers to advisories and updates by their release label, such as “February 2022 Patch 3”. The following cURL command can be used to retrieve the product-info.json file from a Qlik server: curl -H "Host: localhost" -vk 'https://<ip>/resources/autogenerated/product-info.json?.ttf' Note that we specify ?.ttf at the end of the URL to let the Qlik proxy server think that we are requesting a .ttf file, as font files can be accessed unauthenticated. Also, we set the Host header to localhost or else the server will return 400 - Bad Request - Qlik Sense, with the message The http request header is incorrect. Retrieving this file with the ?.ttf extension trick has been fixed in the patch that addresses CVE-2023-48365 and you will always get a 302 Authenticate at this location response: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 302 Authenticate at this location < Cache-Control: no-cache, no-store, must-revalidate < Location: https://localhost/internal_forms_authentication/?targetId=2aa7575d-3234-4980-956c-2c6929c57b71 < Content-Length: 0 < Nevertheless, this is still a good way to determine the state of a Qlik instance, because if it redirects using 302 Authenticate at this location it is likely that the server is not vulnerable to CVE-2023-48365. An example response from a vulnerable server would return the JSON file: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 200 OK < Set-Cookie: X-Qlik-Session=893de431-1177-46aa-88c7-b95e28c5f103; Path=/; HttpOnly; SameSite=Lax; Secure < Cache-Control: public, max-age=3600 < Transfer-Encoding: chunked < Content-Type: application/json;charset=utf-8 < Expires: Tue, 16 Apr 2024 08:14:56 GMT < Last-Modified: Fri, 04 Nov 2022 23:28:24 GMT < Accept-Ranges: bytes < ETag: 638032013040000000 < Server: Microsoft-HTTPAPI/2.0 < Date: Tue, 16 Apr 2024 07:14:55 GMT < Age: 136 < {"composition":{"contentHash":"89c9087978b3f026fb100267523b5204","senseId":"qliksenseserver:14.54.21","releaseLabel":"February 2022 Patch 12","originalClassName":"Composition","deprecatedProductVersion":"4.0.X","productName":"Qlik Sense","version":"14.54.21","copyrightYearRange":"1993-2022","deploymentType":"QlikSenseServer"}, <snipped> We utilised Censys and Google BigQuery [6] to compile a list of potential Qlik Sense servers accessible on the internet and conducted a version scan against them. Subsequently, we extracted the Qlik release label from the JSON response to assess vulnerability to CVE-2023-48365. Our vulnerability assessment for DoubleQlik / CVE-2023-48365 operated on the following criteria:

1. The release label corresponds to vulnerability statuses outlined in the original ZeroQlik and DoubleQlik vendor advisories [7,8].
2. The release label is designated as End of Support (EOS) by the vendor [9], such as “February 2019 Patch 5”.

We consider a server non-vulnerable if:

1. The release label date is post-November 2023, as the advisory states that “November 2023” is not affected.
2. The server responded with HTTP/1.1 302 Authenticate at this location.

Any other responses were disregarded as invalid Qlik server instances. As of 17 April 2024, and as stated in the introduction of this blog, we have detected 5205 Qlik Servers on the Internet. Among them, 3143 servers are still at risk of DoubleQlik, indicating that 60% of all Qlik Servers online remain vulnerable. Figure 2: Qlik Sense patch status for DoubleQlik CVE-2023-48365 The majority of vulnerable Qlik servers reside in the United States (396), trailed by Italy (280), Brazil (244), the Netherlands (241), and Germany (175). Figure 3: Top 20 countries with servers vulnerable to DoubleQlik CVE-2023-48365 Identifying compromised Qlik Sense servers Based on insights gathered from the Arctic Wolf blog and our own incident response engagements where the Cactus ransomware was observed, it’s evident that the Cactus ransomware group continues to redirect the output of executed commands to a True Type font file named qle.ttf, likely abbreviated for “qlik exploit”. Below are a few examples of executed commands and their output redirection by the Cactus ransomware group: whoami /all > ../Client/qmc/fonts/qle.ttf quser > ../Client/qmc/fonts/qle.ttf In addition to the qle.ttf file, we have also observed instances where qle.woff was used: Figure 4: Directory listing with exploitation artefacts left by Cactus ransomware group It’s important to note that these font files are not part of a default Qlik Sense server installation. We discovered that files with a font file extension such as .ttf and .woff can be accessed without any authentication, regardless of whether the server is patched. This likely explains why the Cactus ransomware group opted to store command output in font files within the fonts directory, which in turn, also serves as a useful indicator of compromise. Our scan for both font files, found a total of 122 servers with the indicator of compromise. The United States ranked highest in exploited servers with 49 online instances carrying the indicator of compromise, followed by Spain (13), Italy (11), the United Kingdom (8), Germany (7), and then Ireland and the Netherlands (6). Figure 5: Top 20 countries with known compromised Qlik Sense servers Out of the 122 compromised servers, 46 were not vulnerable anymore. When the indicator of compromise artefact is present on a remote Qlik Sense server, it can imply various scenarios. Firstly, it may suggest that remote code execution was carried out on the server, followed by subsequent patching to address the vulnerability (if the server is not vulnerable anymore). Alternatively, its presence could signify a leftover artefact from a previous security incident or unauthorised access. While the root cause for the presence of these files is hard to determine from the outside it still is a reliable indicator of compromise. Responsible disclosure by the DIVD
We shared our fingerprints and scan data with the Dutch Institute of Vulnerability Disclosure (DIVD), who then proceeded to issue responsible disclosure notifications to the administrators of the Qlik Sense servers. Call to action Ensure the security of your Qlik Sense installations by checking your current version. If your software is still supported, apply the latest patches immediately. For systems that are at the end of support, consider upgrading or replacing them to maintain robust security. Additionally, to enhance your defences, it’s recommended to avoid exposing these services to the entire internet. Implement IP whitelisting if public access is necessary, or better yet, make them accessible only through secure remote working solutions. If you discover you’ve been running a vulnerable version, it’s crucial to contact your (external) security experts for a thorough check-up to confirm that no breaches have occurred. Taking these steps will help safeguard your data and infrastructure from potential threats. References

1. https://cyberveilignederland.nl/actueel/persbericht-samenwerkingsverband-melissa-vindt-diverse-nederlandse-slachtoffers-van-ransomwaregroepering-cactus ︎
2. https://www.ncsc.nl/actueel/nieuws/2023/oktober/3/melissa-samenwerkingsverband-ransomwarebestrijding ︎
3. https://arcticwolf.com/resources/blog/qlik-sense-exploited-in-cactus-ransomware-campaign/ ︎
4. https://www.praetorian.com/blog/qlik-sense-technical-exploit/ ︎
5. https://www.praetorian.com/blog/doubleqlik-bypassing-the-original-fix-for-cve-2023-41265/ ︎
6. https://support.censys.io/hc/en-us/articles/360038759991-Google-BigQuery-Introduction ︎
7. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2110801 ︎
8. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2120325 ︎
9. https://community.qlik.com/t5/Product-Lifecycle/Qlik-Sense-Enterprise-on-Windows-Product-Lifecycle/ta-p/1826335 ︎

To consolidate all of our security intelligence and news in one location, we have migrated Naked Security to the Sophos News platform.