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.

This Week In Security: 1Password, Polyglots, And Roundcube

This week we got news of a security incident at 1Password, and we’re certain we aren’t the only ones hoping it’s not a repeat of what happened at LastPass. 1Password has released a PDF report on the incident, and while there are a few potentially worrying details, put into context it doesn’t look too bad.

The first sign that something might be amiss was an email from Okta on September 29th — a report of the current list of account administrators. Okta provides authentication and Single Sign-On (SSO) capabilities, and 1Password uses those services to manage user accounts and authentication. The fact that this report was generated without anyone from 1Password requesting it was a sign of potential problems.

And here’s the point where a 1Password employee was paying attention and saved the day, by alerting the security team to the unrequested report. That employee had been working with Okta support, and sent a browser session snapshot for Okta to troubleshoot. That data includes session cookies, and it was determined that someone unauthorized managed to access the snapshot and hijack the session, Firesheep style.

Okta logs seemed to indicate that the snapshot hadn’t been accessed, and there weren’t any records of other Okta customers being breached in this way. This pointed at the employee laptop. The report states that it has been taken offline, which is good. Any time you suspect malicious action on a company machine, the right answer is power it off right away, and start the investigation.

And here’s the one part of the story that gives some pause. Someone from 1Password responded to the possible incident by scanning the laptop with the free edition of Malwarebytes. Now don’t get us wrong, Malwarebytes is a great product for finding and cleaning the sort of garden-variety malware we tend to find on family members’ computers. The on-demand scanning of Malwarebytes free just isn’t designed for detecting bespoke malicious tools like a password management company should expect to be faced with.

But that turns out to be a bit of a moot point, as the real root cause was a compromised account in the Okta customer support system, as revealed on the 20th. The Okta report talks about stolen credentials, which raises a real question about why Okta support accounts aren’t all using two-factor authentication.

Continue reading “This Week In Security: 1Password, Polyglots, And Roundcube”

This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!

Google Chrome has done a lot of work on JavaScript performance, pushing the V8 engine to more and more impressive feats. Recently, that optimization has one more piece, the Maglev compiler, which sits between Sparkplug and TurboFan, as a mid-tier optimization step. With a Just In Time (JIT) system, the time saving of code optimization steps has to be carefully weighed against the time costs, and Maglev is another tool in that endless hunt for speed. And with anything this complicated, there’s the occasional flaw found in the system. And of course, because we’re talking about it here, it’s a security vulnerability that results in Remote Code Execution (RCE).

The trick is to use Maglev’s optimization against it. Set up a pair of classes, such that B extends A. Calling new B() results in an attempt to use the constructor from A. Which works, because the compiler checks to make sure that the constructors match before doing so. There’s another way to call a constructor in JS, something like Reflect.construct(B, [], Array);. This calls the B constructor, but indicates that the constructor should return an Array object. You may notice, there’s no array in the A class below. Tricking the compiler into using the parent class constructor in this fashion results in the array being uninitialized, and whatever happens to be in memory will set the length of the array. Continue reading “This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!”