Lab-based cyber attacks are no serious threat – yet

Most cyber scare stories have more in common with horror fiction than practical reality, and I’m not talking purely about the hyped-up cyber warfare stuff that appears online. Me being me, I’m focussed on the hacking threat stuff.

Admittedly, I have a thirst for oddball cyber security research papers, but there’s a secret to digesting these papers in a way so as not to confuse the theoretical risk with the practical one. There’s a huge difference between fascinating research work, conducted by hugely talented folk, and the practical risk you are likely to be exposed to as a result of it.

This isn’t to say that such research is pointless; far from it in fact. The most technologically fanciful lab-based threats can evolve into very real-world ones, albeit often bearing little resemblance to the original. There are three fascinating pieces of research that stand out, and all fall down as far as the current real-world threat stakes are concerned.

Attack of the mechanical keyboards

Let’s start with Keytap3, which immediately announces it has already evolved somewhat from the original research by Georgi Gerganov. The name also suggests, quite rightly, that this involves typing.

That involvement is an attempt to be able to remotely and quite literally listen in to what you are typing and then convert that audio into written output. It does this by analysing n-gram frequency – the contiguous sequence of items in a sample – of recorded audio clusters.

Gerganov isn’t the first to look into this as a spying methodology, nor will he be the last, and I applaud him for his efforts so far. Despite, I have to say, my not being able to replicate the success he has had in the lab when taking part in a demonstration of the technology. You can try it by visiting the demo website and allowing your typing audio to be analysed.

Gerganov says he doesn’t have access to the recordings, as the test runs within your client browser and none of the data is uploaded or stored by the researcher. This is one of the reasons the results are poor: without the wider input data from a broad, real-world, range of both keyboards and microphones, plus different typing speeds and styles, the experiment is likely to perform best with the variables it understands from the lab development.

“One possible explanation for the results that you observe is that simply Keytap3 is somehow overfitted to my setup or style,” he tells me. “Even though I have tried to keep the implementation as general as possible, without making unnecessary assumptions about the typing style or the devices (keyboard and mic) it is still possible that the algorithm performs well only in the limited set of environments that I have tested it with.”

GGerganov only has two mechanical keyboards and says the results are “pretty good” when using that small set of data points. He would welcome more data from participants of the demo: it’s up to you whether or not to upload the recording after the demo so that he can broaden the input data.

In case you’re wondering, he doesn’t think typing speed is a huge factor. Instead, the main factor is the ability to match key sounds to determine if separate sounds are made by the same key, for example. “Currently, Keytap uses a time-domain cross-correlation metric to match the keys with one another and it is definitely not perfect,” Gerganov says, before adding he was surprised it performs as well as it does. He’s currently working on improving the algorithm using frequency-domain metrics.

‘Ghost touch’ doesn’t send shivers down my spine

Next up is an experimental smartphone threat vector that grabbed my attention by virtue of being one that works with both iPhone and Android devices.

There are always ways into devices, although most of them require either temporary physical ownership of the device or the actual owner to have installed something malicious. Or, in the case of BadUSB attacks, a subtle combination of the two. Rather than ownership of the phone, BadUSB attacks require ownership, or usage of, a malicious memory drive or even a specially crafted data/charging cable. The Wired Ghost Touch (WIGHT) attack model uses the malicious charging port approach. The type of cable is irrelevant, and bypassing data blockers allows attackers to remotely “swipe” the touchscreen.

Researchers from the Zhejiang University, China and two from the Technical University of Darmstadt, Germany, have demonstrated how this works using both a Samsung Galaxy S20 and an Apple iPhone SE, and some other less popular smartphones.

It works by injecting specially crafted “malicious noise” signals that evade noise reduction and voltage management filtering while still impacting the capacitive touchscreen measurement systems. In fact, the researchers say they can perform three attack types by syncing the injected noise with the device touchscreen scanning cycle: a “ghost touch” that doesn’t require physical user input, an “alteration attack” that changes the actually touched position to another, and a denial of service that prevents any touch from being recognised.

I’ve read about previous ghost touch research but that all requires the target device to be screen-down and within a few millimetres of a table or desktop, with some cumbersome equipment installed underneath. For me, that reduces the threat level to negative, as even a highly targeted individual that would merit such attention would almost certainly already have defensive measures in place to defeat it.

The WIGHT model doesn’t require data access permission from the USB cable, which is a plus point, nor does the electromagnetic radiation approach of those under-the-table devices. Instead, by injecting a common-mode signal that can’t be absolutely filtered but still produces a differential-mode signal, thanks to asymmetric circuits, the necessary touchscreen interference can be achieved.

It’s a lot more advanced than Keytap3, but still doesn’t give me the collywobbles, nor should it you, because the touchscreen positioning precision remains in the 50/50 ballpark.

There is one scary aspect to the attack methodology, though. The researchers say that as the attack signal is a high-voltage alternating current, it could give a smartphone user a very nasty shock outside of carefully controlled lab conditions.

Scary in a Minority Report kind of a way

What if your account was compromised before you opened it? Although this might sound like a third entry in the “that doesn’t apply to real-world, labs-based threat research” stakes, it isn’t. This threat vector sounds unbelievable – but it’s actually doable right now. Researchers found that 35 of 75 leading web services were vulnerable in some way or other.

The work, using a Microsoft Security Response Centre (MSRC) grant, was undertaken by independent security researcher Avinash Sudhodanan and Microsoft senior researcher Andrew Paverd. The research paper is well worth a read and a genuine;y worrying one.

Andrew Paverd describes it as a “new class of attacks affecting websites and other online services”. It’s scary precisely because a cyber criminal can gain access to an account before you even create it. It gets worse, in that they could then take over that account once you have. It has a kind of Minority Report feel to it – but is far from a fictional fancy.

Using one of five different attack scenarios, an attacker creates an account for a web service that’s subsequently reactivated by a user and then, having given them time to use the account and add value by way of financial and other data, subsequently retakes control. The five methods require differing scenarios to play out and involve exploiting a weakness in the merging of classic and federated accounts: not signing users out after a password reset; Trojan identifiers; a failure to invalidate email change capability URLs in the password reset process; and by exploiting a non-verifying Identity Provider vulnerability.

It’s all rather complicated, but you can’t ignore the test result of almost half of the service providers targeted falling victim. That said, it’s not a given that it works even beyond that 50/50 test result. It requires a user not to have joined a service yet, the attacker to know that fact along with them wanting to start using it at some point soon, and the email address they will use – which is a stretch.

It also requires the web service in question not to send a verification email to the user-provided address while at the same time preventing any further actions until that verification had been received. Using unique email addresses for every account would also effectively mitigate the success of such an attack, and the ease with which this can be achieved these days it’s a route I’d recommend. Not least as unique email identifiers, especially when also used as account login usernames, makes other attack scenarios harder to pull off as well. Win-win.