Netscape Communicator And SHA-1 Written Into Brexit Agreement

December 28, 2020 by Jenny List 36 Comments

We pity the civil servants involved in the negotiations between the European Union and the United Kingdom, because after tense meetings until almost the Eleventh Hour, they’ve had to cobble together the text of a post-Brexit trade agreement in next-to-no time. In the usual manner of such international agreements both sides are claiming some kind of victory over fish, but the really interesting parts of the document lie in the small print. In particular it was left to eagle-eyed security researchers to spot that Netscape Communicator 4, SHA-1, and RSA encryption with a 1024-bit key length are recommended to secure the transfer of DNA data between states. The paragraphs in question can be found on page 932 of the 1256-page agreement.

It’s likely that some readers under 30 years old will never have used a Netscape product even though they will be familiar with Firefox, the descendant Mozilla software. Netscape were a pioneer of early web browsers, and Communicator 4 was the company’s all-in-one browser and email offering from the late 1990s. It and its successors steadily lost ground against Microsoft’s Internet Explorer, and ultimately faded away along with the company under AOL ownership in the late 2000s. Meanwhile the SHA-1 hashing algorithm has been demonstrated to be vulnerable to collision attacks, and computing power has advanced such that 1024-bit RSA encryption can be broken in a sensible time frame by anyone with sufficient GPU power to give it a try. It’s clear that something is amiss in the drafting of this treaty, and we’d go so far as to venture the opinion that a tired civil servant simply cut-and-pasted from a late-1990s security document.

So will the lawmakers of Europe now have to dig for ancient software as mandated by treaty? We hope not, as from our reading they are given as examples rather than as directives. We worry however that their agencies might turn out to be as clueless on digital security as evidently the civil servants are, so maybe Verizon Communications, current owners of the Netscape brand, could be in for a few support calls.

Better Security, Harry Potter Style

December 25, 2020 by Al Williams 27 Comments

We all know we shouldn’t use 1234 as our password. But we often don’t do the absolute best practice when it comes to passwords. After all, you should have some obscure strange password that is unique for every site. But we all have lots of passwords, so most of us use $pock2020 or something like that. If you know I’m a Star Trek fan, that wouldn’t be super hard to guess. [Phani] writes about a technique called Horcruxing — a term taken from the literary realm of Harry Potter that allowed Voldemort to preserve life by splitting it into multiple parts, all of which were required to bring an end to his villany. [Phani’s] process promises to offer better security than using a single password, without the problems associated with having hundreds of random passwords.

Most people these days use some form of password manager. That’s great because the manager can create 48 character passwords of random words or symbols and even you don’t know the password. Of course, you do know the master password or, at least, you better. So if anyone ever compromised that password, they’d have all your passwords at their fingers. Horcruxing makes sure that the password manager doesn’t know the entire password, just the hard parts of it.

Continue reading “Better Security, Harry Potter Style” →

This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!

December 18, 2020 by Jonathan Bennett 11 Comments

The big story this week is Solarwinds. This IT management company supplies network monitoring and other security equipment, and it seems that malicious code was included in a product update as early as last spring. Their equipment is present in a multitude of high-profile networks, like Fireeye, many branches of the US government, and pretty much any other large company you can think of. To say that this supply chain attack is a big deal is an understatement. The blame has initially been placed on APT42, AKA, the Russian hacking pros.

The attack hasn’t been without some positive effects, as Fireeye has released some of their internal tooling as open source as a result. Microsoft has led the official response to the attack, managing to win control of the C&C domain in court, and black-holing it.

The last wrinkle to this story is the interesting timing of the sale of some Solarwinds stock by a pair of investment firms. If those firms were aware of the breech, and sold their shares before the news was made public, this would be a classic case of illegal insider trading. Continue reading “This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!” →

Remoticon Video: Breaking Encrypted Firmware Workshop

December 11, 2020 by Mike Szczys 6 Comments

If only you could get your hands on the code to fix the broken features on your beloved electronic widget. But wait, hardware hackers have the skills to write their own firmware… as long as we can get the compiled binary into a format the hardware needs.

Luckily, we have Uri Shaked to walk us through that process. This workshop from the 2020 Hackaday Remoticon demonstrates how to decipher the encryption scheme used on the firmware binary of a 3D printer. Along the way, we learn about the tools and techniques that are useful for many encrypted binary deciphering adventures.

Continue reading “Remoticon Video: Breaking Encrypted Firmware Workshop” →

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

December 11, 2020 by Jonathan Bennett 9 Comments

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More” →

Leaking Data By Ultrasound

December 6, 2020 by Lewin Day 19 Comments

Human ears are capable of perceiving frequencies from roughly 20 Hz up to 20 kHz, at least when new. Correspondingly, our audio hardware is designed more or less to target these frequencies. However, there’s often a little extra capability at the upper edges, which [Jacek] shows can be exploited to exfiltrate data.

The hack takes advantage of the fact that most computers can run their soundcards at a sample rate of up to 48 kHz, which thanks to the Nyquist theorem means they can output frequencies up to around 24 kHz — still outside the range of human hearing. Computers and laptops often use small speaker drivers too, which are able to readily generate sound at this frequency. Through the use of a simple Linux shell script, [Jacek] is able to have a laptop output Morse code over ultrasound, and pick it up with nothing more than a laptop’s internal microphone at up to 20 meters away.

[Jacek] enjoys exploring alternative data exfiltration methods; he’s previously experimented with Ethernet leaks on the Raspberry Pi. Of course, with any airgap attack, the real challenge is often getting the remote machine to run the exfiltration script when there’s no existing remote admin access to be had. Video after the break.

Continue reading “Leaking Data By Ultrasound” →

This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex

December 4, 2020 by Jonathan Bennett 8 Comments

I hope everyone had a wonderful Thanksgiving last week. My household celebrated by welcoming a 4th member to the family. My daughter was born on Wednesday morning, November 25th. And thus explains what I did last week instead of writing the normal Hackaday column. Never fear, we shall catch up today, and cover the news that’s fit to be noticed.

iOS Zero-click Wifi Attack

[Ian Beer] of Google’s Project Zero brings us the fruit of his lockdown-induced labors, a spectacular iOS attack. The target of this attack is the kernel code that handles AWDL, an Apple WiFi protocol for adhoc mesh networks between devices. The most notable feature that makes use of AWDL is AirDrop, Apple’s device-to-device file sharing system. Because AWDL is a proprietary protocol, the WiFi hardware can’t do any accelerated processing of packets. A few years back, there was an attack against Broadcom firmware that required a second vulnerability to jump from the WiFi chip to the device CPU. Here, because the protocol is all implemented in Apple’s code, no such pivot is necessary.

And as you’ve likely deduced, there was a vulnerability found. AWDL uses Type-Length-Value (TLV) messages for sending management data. For a security researcher, TLVs are particularly interesting because each data type represents a different code path to attack. One of those data types is a list of MAC addresses, with a maximum of 10. The code that handles it allocates a 60 byte buffer, based on that maximum. The problem is that there isn’t a code path to drop incoming TLVs of that type when they exceed 60 bytes. The remainder is written right past the end of the allocated buffer.

There is more fun to be had, getting to a full exploit, but the details are a bit too much to fully dive in to here. It interesting to note that [Ian] ran into a particular problem: His poking at the target code was triggering unexpected kernel panics. He discovered two separate vulnerabilities, both distinct from the vuln he was trying to exploit.

Finally, this exploit requires the target device to have AWDL enabled, and many won’t. But you can use Bluetooth Low Energy advertisements to trick the target device into believing an Airdrop is coming in from a trusted contact. Once the device enables AWDL to verify the request, the attack can proceed. [Ian] reported his findings to Apple way back in 2019, and this vulnerability was patched in March of 2020.

Via Ars Technica.
Continue reading “This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex” →