5Ghoul: The 14 Shambling 5G Flaws Used For Disruptive Attacks On Smartphones

December 13, 2023 by Maya Posch 5 Comments

A team of researchers from the ASSET Research Group in Singapore have published the details of a collection of vulnerabilities in the fifth generation mobile communication system (5G) used with smartphones and many other devices. These fourteen vulnerabilities are detailed in this paper and a PoC detailing an attack using a software defined radio (SDR) is provided on GitHub. The core of the PoC attack involves creating a malicious 5G base station (gNB), which nearby 5G modems will seek to communicate with, only for these vulnerabilities to be exploited, to the point where a hard reset (e.g. removal of SIM card) of the affected device may be required.

Hardware Setup for 5Ghoul PoC testing and fuzzer evaluation. (Credit: Matheus E. Garbelini et al., 2023)

Another attack mode seeks to downgrade the target device’s wireless connection, effectively denying the connection to a 5G network and forcing them to connect to an alternative network (2G, 3G, 4G, etc.). Based on the affected 5G modems, the researchers estimate that about 714 smartphone models are at risk of these attacks. Naturally, not just smartphones use these 5G modem chipsets, but also various wireless routers, IoT devices, IP cameras and so on, all of which require the software these modems to be patched.

Most of the vulnerabilities concern the radio resource control (RCC) procedure, caused by flaws in the modem firmware. Android smartphones (where supported) should receive patches for 5Ghoul later this month, but when iPhone devices get patched is still unknown.

Hilarious Security Flaw In Counter Strike 2 Is Now Patched

December 12, 2023 by Lewin Day 17 Comments

Normally, when we talk about video games having bugs, it’s some kind of item duplication glitch or a hilarious failure in the jacket equip code of some tedious ~~first-person-shooter~~ online wardrobe simulator. Counter-Strike 2 has had a more embarrassing faux-pas, however, with a security hole allowing bad actors to theoretically capture the IPs of their fellow players in a server. You won’t believe how this came to happen.

The exploit has already been making its way around the forums, with one [Crouch9706] raising the alarm. It’s all down to the way Counter-Strike 2 renders the names that players have entered in their Steam gaming profiles. In certain menus and other parts of the UI, the game will actually parse HTML in a player’s name. Typically, the way to trigger it is to join a game and vote to kick yourself. This brings up a dialog for other players that shows them your player name and parses the HTML. The only limitation is you only get 32 characters for your HTML.

There’s a nifty little extra trick to this, though, in that you can use this technique to snag another player’s IP. By putting in HTML that links to your own server, you can log any player IPs that connect to the server seeking an image, for example.

Of course, it’s not the biggest risk, with many players being behind ISPs that use CGNAT, making the harvested IPs rather useless. However, this sort of unexpected code injection is really not acceptable from a security standpoint. At the very least, it has the potential to expose players to nasty imagery.

Word on the street (Nitter) is that the exploit has now been patched. Meanwhile, if you’re working on a game that for some mad reason, executes code based on player names or any other such data, consider patching your work ASAP. If you find similar exploits in the wild, don’t hesitate to hit up our tipsline—and notify the developers, too!

Update On The BLUFFS Bluetooth Vulnerability

December 2, 2023 by Maya Posch 14 Comments

As we first reported in yesterday’s weekly security post, researchers at EURECOM have revealed the details (PDF, references) of a new man-in-the-middle (MITM) attack on Bluetooth 4.2 through 5.4, which has been assigned CVE-2023-24023. Like preceding CVEs, it concerns the session authentication between Bluetooth devices, where the attacker uses spoofed paired or bonded devices to force the use of a much shorter encryption key length.

The name of this newly discovered vulnerability is BLUFFS (Bluetooth Forward and Future Secrecy), where forward and future secrecy are important terms that refer to the protection of secure sessions against compromise in the past (forward, FoS) and future (FuS). The CVE presentation notes that the Bluetooth specification does not cover either FuS or FoS. In total two new architectural vulnerabilities were discovered, both of which attack the security key.

The Bluetooth SIG has released a statement regarding this attack method. Although serious, it would seem that the core issue is that some implementations allow for encryption key lengths below 7 octets:

Continue reading “Update On The BLUFFS Bluetooth Vulnerability” →

This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints

December 1, 2023 by Jonathan Bennett 18 Comments

We’re back! And while the column took a week off for Thanksgiving, the security world didn’t. The most pressing news is an issue in Owncloud, that is already under active exploitation.

The problem is a library that can be convinced to call phpinfo() and include the results in the page response. That function reveals a lot of information about the system Owncloud is running on, including environment variables. In something like a Docker deployment, those environment variables may contain system secrets like admin username and password among others.

Now, there is a bit of a wrinkle here. There is a public exploit, and according to research done by Greynoise Labs, that exploit does not actually work against default installs. This seems to describe the active exploitation attempts, but the researcher that originally found the issue has stated that there is a non-public exploit that does work on default installs. Stay tuned for this other shoe to drop, and update your Owncloud installs if you have them. Continue reading “This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints” →

Easily Bypass Laptop Fingerprint Sensors And Windows Hello

November 27, 2023 by Maya Posch 30 Comments

The fun part of security audits is that everybody knows that they’re a good thing, and also that they’re rarely performed prior to another range of products being shoved into the market. This would definitely seem to be the case with fingerprint sensors as found on a range of laptops that are advertised as being compatible with Windows Hello. It all began when Microsoft’s Offensive Research and Security Engineering (MORSE) asked the friendly people over at Blackwing Intelligence to take a poke at a few of these laptops, only for them to subsequently blow gaping holes in the security of the three laptops they examined.

In the article by [Jesse D’Aguanno] and [Timo Teräs] the basic system and steps they took to defeat it are described. The primary components are the fingerprint sensor and Microsoft’s Secure Device Connection Protocol (SDCP), with the latter tasked with securing the (USB) connection between the sensor and the host. Theoretically the sensitive fingerprint-related data stays on the sensor with all matching performed there (Match on Chip, MoC) as required by the Windows Hello standard, and SDCP keeping prying eyes at bay.

Interestingly, the three laptops examined (Dell Inspiron 15, Lenovo ThinkPad T14 and Microsoft Surface Pro X) all featured different sensor brands (Goodix, Synaptics and ELAN), with different security implementations. The first used an MoC with SDCP, but security was much weaker under Linux, which allowed for a fake user to be enrolled. The Synaptics implementation used a secure TLS connection that used part of the information on the laptop’s model sticker as the key, and the ELAN version didn’t even bother with security but responded merrily to basic USB queries.

To say that this is a humiliating result for these companies is an understatement, and demonstrates that nobody in his right mind should use fingerprint- or similar scanners like this for access to personal or business information.

This Week In Security: SSH, FTP, And Reptar

November 17, 2023 by Jonathan Bennett 3 Comments

It’s time to strap on our propeller beanies, because we’re going to talk crypto. The short version is that some SSH handshakes can expose enough information for a third party to obtain the host’s private signing key. That key is the one that confirms you are connecting to the SSH server you think you are, and if the key validation fails, you get a big warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The math that makes this warning work is public-private key cryptography. The problem we’re talking about today only shows up in RSA authentication. Specifically those that use the Chinese Remainder Theorem (CRT) to quickly calculate the modulos needed to generate the cryptographic signature. If something goes wrong during that calculation, you end up with a signature that is mathematically related to the secret key in a different way than intended. The important point is that knowing this extra value *significantly* weakens the security of the secret key.

This attack has been known for quite some time, but the research has been aimed at causing the calculation fault through power vaults or even memory attacks like Rowhammer. There has also been progress on using a lattice attack against captured handshakes, to make the attack practical with less known information. The real novel element of this week’s approach (pdf) is that it has been tested against SSH.

The paper’s authors performed weekly scans of the entire IPv4 public network space, capturing the handshake from any listening SSH server, and also had 5 years of historic data to draw from. And the results are mixed. There is a Cisco SSH server string that is extremely common in the dataset, and only once did one of these machines send a miscalculated handshake. Possibly a random ram bit flip to blame. And on the other hand, the string “SSH-2.0-Zyxel SSH server” had so many bad signatures, it suggests a device that *always* sends a miscalculated signature. Continue reading “This Week In Security: SSH, FTP, And Reptar” →

This Week In Security: Find My Keylogger, Zephyr, And Active Exploitation

November 10, 2023 by Jonathan Bennett 7 Comments

Keyloggers. Such a simple concept — you secretly record all the characters typed on a keyboard, and sort through it later for interesting data. That keyboard sniffer could be done in software, but a really sneaky approach is to implement the keylogger in hardware. Hardware keyloggers present a unique problem. How do you get the data back to whoever’s listening? One creative solution is to use Apple’s “Find My” tracking system. And if that link won’t let you read the story, a creative solution for that issue is to load the page with javascript disabled.

This is based on earlier work from [Fabian Bräunlein], dubbed “Send My”. As an aside, this is the worst naming paradigm, and Apple should feel bad for it. At the heart of this cleverness is the fact that Apple used the standard Bluetooth Low Energy (BLE) radio protocol, and any BLE device can act like an Apple AirTag. Bits can be encoded into the reported public key of the fake AirTag, and the receiving side can do a lookup for the possible keys.

A fake AirTag keylogger manages to transfer 26 characters per second over the “Find My” system, enough to keep up with even the fastest of typists, given that no keyboard is in use all the time. Apple has rolled out anti-tracking protections, and the rolling key used to transmit data also happens to completely defeat those protections. Continue reading “This Week In Security: Find My Keylogger, Zephyr, And Active Exploitation” →