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”

Proposed European Electronic ID Law Raises Concerns

The harmonisation of standards for electronic identification across the EU should normally be soporific enough to send even the most Club-Mate-hyped hacker straight to sleep, but as Computer Weekly reports, discussion of this reform in the EU corridors of power has caused significant unrest among cyber security experts. Just how can providing Europeans with a harmonised digital ID be so controversial? As you might imagine, the devil lies in the detail.

At issue is the eIDAS Regulation, a system which, in the words of its website: “ensures that people and businesses can use their own national electronic identification schemes (eIDs) to access public services available online in other EU countries,” and “creates a European internal market for trust services by ensuring that they will work across borders and have the same legal status as their traditional paper-based equivalents,” and the point of concern lies with its application to websites. The EU want to ensure that Europeans can digitally verify businesses as well as individuals they deal with, and since that includes websites, they want to insert a provision allowing countries to mandate their own trusted root certificates. At a stroke, this opens the potential for state actors to snoop on all encrypted online traffic, something which would compromise the security of all.

Sadly for Europeans, this isn’t the only questionable online regulation effort from that region.

Thanks [Joyce Ng] for the tip.