Hilarious Security Flaw In Counter Strike 2 Is Now Patched

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

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

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

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

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

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”

This Week In Security: CVSS 4, OAuth, And ActiveMQ

We’ve talked a few times here about the issues with the CVSS system. We’ve seen CVE farming, where a moderate issue, or even a non-issue, gets assigned a ridiculously high CVSS score. There are times a minor problem in a library is a major problem in certain use cases, and not an issue at all in others. And with some of those issues in mind, let’s take a look at the fourth version of the Common Vulnerability Scoring System.

One of the first tweaks to cover is the de-emphasis of the base score. Version 3.1 did have optional metrics that were intended to temper the base score, but this revision has beefed that idea up with Threat Metrics, Environmental Metrics, and Supplemental Metrics. These are an attempt to measure how likely it is that an exploit will actually be used. The various combinations have been given names. Where CVSS-B is just the base metric, CVSS-BT is the base and threat scores together. CVSS-BE is the mix of base and environmental metrics, and CVSS-BTE is the combination of all three.

Another new feature is multiple scores for a given vulnerability. A problem in a library is first considered in a worst-case scenario, and the initial base score is published with those caveats made clear. And then for each downstream program that uses that library, a new base score should be calculated to reflect the reality of that case. Continue reading “This Week In Security: CVSS 4, OAuth, And ActiveMQ”