DIY laser microphone on cutting mat

Spy Tech: Build Your Own Laser Eavesdropper

Laser microphones have been around since the Cold War. Back in those days, they were a favorite tool of the KGB – allowing spies to listen in on what was being said in a room from a safe distance. This project by [SomethingAbtScience] resurrects that concept with a DIY build that any hacker worth their soldering iron can whip up on a modest budget. And let’s face it, few things are cooler than turning a distant window into a microphone.

At its core this hack shines a laser on a window, detects the reflected light, and picks up subtle vibrations caused by conversations inside the room. [SomethingAbtScience] uses an ordinary red laser (visible, because YouTube rules) and repurposes an amplifier circuit ripped from an old mic, swapping the capsule for a photodiode. The build is elegant in its simplicity, but what really makes it shine is the attention to detail: adding a polarizing filter to cut ambient noise and 3D printing a stabilized sensor mount. The output is still a bit noisy, but with some fine tuning – and perhaps a second sensor for differential analysis – there’s potential for crystal-clear audio reconstruction. Just don’t expect it to pass MI6 quality control.

While you probably won’t be spying on diplomats anytime soon, this project is a fascinating glimpse into a bygone era of physical surveillance. It’s also a reminder of how much can be accomplished with a laser pointer, some ingenuity, and the curiosity to see how far a signal can travel.

Continue reading “Spy Tech: Build Your Own Laser Eavesdropper”

Firefox logo displayed on screen

Add WebUSB Support To Firefox With A Special USB Device

RP2040-based Pico board acting as U2F dongle with Firefox. (Credit: ArcaneNibble, GitHub)
RP2040-based Pico board acting as U2F dongle with Firefox. (Credit: ArcaneNibble, GitHub)

The WebUSB standard is certainly controversial. Many consider it a security risk, and, to date,  only Chromium-based browsers support it. But there is a workaround that is, ironically, supposed to increase security. The adjacent Universal 2nd Factor (U2F) standard also adds (limited) USB support to browsers. Sure, this is meant solely to support U2F USB dongles for two-factor authentication purposes, but as [ArcaneNibble] demonstrates using U2F-compatible firmware on a Raspberry Pi RP2040, by hijacking the U2F payload, this API can be used to provide WebUSB-like functionality.

Continue reading “Add WebUSB Support To Firefox With A Special USB Device”

My Scammer Girlfriend: Baiting A Romance Fraudster

Nobody likes spam messages, but some of them contain rather fascinating scams. Case in point, [Ben Tasker] recently got a few romance scam emails that made him decide to take a poke at the scam behind these messages. This particular scam tries to draw in marks with an attached photo (pilfered from Facebook) and fake personal details. Naturally, contacting scammers is a bad idea, and you should never provide them with any personal information if you decide to have some ‘fun’.

The games begin once you contact them via the listed email address, as they’re all sent from hacked/spoofed email accounts. After this you have to wait for the scammers to return to the campaign on their monthly cycle, so give it a few weeks. Analyzing image metadata provides some clues (e.g. the FBMD prefix in IPTC tags set by Meta, as well as timezone info). The IP address from the email headers pointed to a VPN being used, so no easy solution here.

After establishing contact, the scammers try to coax the mark into ‘helping’ them move to their country, with Skype out-call numbers received on [Ben]’s burner phone that seem designed to add to the realism. Then ‘disaster’ strikes and the mark is asked to transfer a lot of money to help their new ‘love’. Naturally, [Ben] wasn’t a gullible mark, and set up a few traps, including a custom domain and website that’d log any visitor (i.e. the scammer).

Continue reading “My Scammer Girlfriend: Baiting A Romance Fraudster”

This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

Continue reading “This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE”

The ESP32 Bluetooth Backdoor That Wasn’t

Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on  the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.

To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.

The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).

Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.

This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack

The fine researchers at Google have released the juicy details on EntrySign, the AMD Zen microcode issue we first covered about a month ago. And to give away the punchline: cryptography is hard. It’s hard in lots of ways, but the AMD problem here is all about keeping track of the guarantees provided by cryptographic primitives.
Continue reading “This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack”

An excerpt from the website, showing the nRootTag block diagram and describing its structure

Hijacking AirTag Infrastructure To Track Arbitrary Devices

In case you weren’t aware, Apple devices around you are constantly scanning for AirTags. Now, imagine you’re carrying your laptop around – no WiFi connectivity, but BLE’s on as usual, and there’s a little bit of hostile code running at user privileges, say, a third-party app. Turns out, it’d be possible to make your laptop or phone pretend to be a lost AirTag – making it and you trackable whenever an iPhone is around.

The nroottag website isn’t big on details, but the paper ought to detail more; the hack does require a bit of GPU firepower, but nothing too out of the ordinary. The specific vulnerabilities making this possible have been patched in newer iOS and MacOS versions, but it’s still possible to pull off as long as an outdated-firmware Apple device is nearby!

Of course, local code execution is often considered a game over, but it’s pretty funny that you can do this while making use of the Apple AirTag infrastructure, relatively unprivileged, and, exfiltrate location data without any data connectivity whatsoever, all as long as an iPhone is nearby. You might also be able to exflitrate other data, for what it’s worth – here’s how you can use AirTag infrastructure to track new letter arrivals in your mailbox!