Project Rubicon: The NSA Secretly Sold Flawed Encryption For Decades

There have been a few moments in the past few years, when a conspiracy theory is suddenly demonstrated to be based in fact. Once upon a time, it was an absurd suggestion that the NSA had data taps in AT&T buildings across the country. Just like Snowden’s revelations confirmed those conspiracy theories, a news in February confirmed some theories about Crypto AG, a Swiss cryptography vendor.

The whole story reads like a cold-war era spy thriller, and like many of those novels, it all starts with World War II. As a result of a family investment, Boris Hagelin found himself at the helm of Aktiebolaget Cryptograph, later renamed to Crypto AG (1952), a Swedish company that built and sold cipher machines that competed with the famous Enigma machine. At the start of the war, Hagelin decided that Sweden was not the place to be, and moved to the United States. This was a fortuitous move, as it allowed Hagelin to market his company’s C-38 cipher machine to the US military. That device was designated the M-209 by the army, and became the standard in-the-field encryption machine.

Continue reading “Project Rubicon: The NSA Secretly Sold Flawed Encryption For Decades”

This Week In Security: Chrome Bugs And Non-bugs, Kr00k, And Letsencrypt

Google Chrome minted a new release to fix a trio of bugs on Monday, with exploit code already in the wild for one of them. The first two bugs don’t have much information published yet. They are an integer-overflow problem in Unicode internationalization, and a memory access issue in streams. The third issue, type confusion in V8, was also fixed quietly, but a team at Exodus Intel took the time to look at the patches and figure out what the problem was.

The actual vulnerability dives into some exotic Javascript techniques, but to put it simply, it’s possible to change a data-type without V8 noticing. This allows malicious code to write into the header area of the attacked variable. The stack, now corrupted, can be manipulated to the point of arbitrary code execution. The researchers make the point that even with Google’s fast-paced release schedule, a determined attacker could have several days of virtual zero-day exploitation of a bug mined from code changes. Story via The Register.

The Chrome Problem that Wasn’t

A second Chrome story came across my desk this week: Chrome 80 introduces a new feature, ScrollToTextFragment. This useful new feature allows you to embed a string of text in a URL, and when loading that address, Chrome will scroll the page to make that text visible. For certain use cases, this is an invaluable feature. Need to highlight a specific bit of text in a big document online?

The following bookmarklet code by [Paul Kinlan] is the easy way to start using this feature. Paste this code into the URL of a bookmark, put it on the bookmark bar, highlight some text in a webpage, and then run the bookmarklet. It should open a new tab with the new URL, ready to use or send to someone.

javascript:(function()%7Bconst%20selectedText%20%3D%20getSelection().toString()%3Bconst%20newUrl%20%3D%20new%20URL(location)%3BnewUrl.hash%20%3D%20%60%3A~%3Atext%3D%24%7BencodeURIComponent(selectedText)%7D%60%3Bwindow.open(newUrl)%7D)()

Since we’re talking about it in the security column, there must be more to the story. A privacy guru at Brave, [Peter Snyder], raised concerns about privacy implications of the feature. His argument has been repeated and misrepresented in a few places. What argument was he making? Simply put, that it’s not normal user behavior to immediately scroll to an exact position on the page. Because modern web pages and browsers do things like deferred loading of images, it could be possible to infer where in the page the link was pointing. He gives the example of a corporate network where DNS is monitored. This isn’t suggesting that the entire URL is leaked over DNS, but rather that DNS can indicate when individual components of a page are loaded, particularly when they are embedded images from other sites.

While this concern isn’t nonsensical, it seems to me to be a very weak argument that is being over-hyped in the press.

Whatsapp Groups Searchable on Google

It’s not new for search engines to index things that weren’t intended to be public. There is a bit of mystery surrounding how Google finds URLs to index, and StackExchange is full of plenty of examples of webadmins scratching their heads at their non-public folders showing up in a Google search.

That said, a story made the rounds in the last few days, that WhatsApp and Telegram group invites are being indexed by Google. So far, the official word is that all the indexed links must have been shared publicly, and Google simply picked them up from where they were publicly posted.

It appears that WhatsApp has begun marking chat invitation links as “noindex”, which is a polite way to ask search engines to ignore the link.

If it’s shown that links are getting indexed without being posted publicly online, then we have a much bigger story. Otherwise, everything is working as expected.

Letsencrypt Makes Attacks Harder

Letsencrypt has rolled out an invisible change to their validation process that makes a traffic redirection attack much harder. The new feature, Multi-Perspective Validation, means that when you verify your domain ownership, Letsencrypt will test that verification from multiple geographic regions. It might be possible to spoof ownership of a domain through a BGP attack, but that attack would be much harder to pull off against traffic originating from another country, or multiple countries simultaneously. Letsencrypt is currently using different regions of a single cloud, but plans to further diversify and use multiple cloud providers for even stronger validation.

Kr00k

Brought to us by the researchers at Eset, Krook (PDF) is a simple flaw in certain wireless chips. So far, the flaw seems to be limited to WPA2 traffic sent by Broadcom and Cypress chips. They discovered Kr00k while doing some followup research on KRACK.

Let’s talk about WPA2 for a moment. WPA2 has a 4-way handshake process that securely confirms that both parties have the shared key, and then establishes a shared Temporal Key, also known as a session key. This key is private between the two devices that performed the handshake, meaning that other devices on the same wireless network can’t sniff traffic sent by other devices.

When a device disconnects, or disassociates, that session key is reset to all 0s, and no packets should be sent until another handshake is performed. Here’s the bug: The packets already in the output buffer are still sent, but are encrypted with the zeroed key, making them trivially decrypted. As it’s simple to trigger deauthentication events, an attacker can get a sampling of in-the-clear packets. The ubiquity of TLS is a saving grace here, but any unencrypted traffic is vulnerable. Eset informed vendors about the flaw in 2019, and at least some devices have been patched.

Exchange

Microsoft Exchange got a security patch this past Tuesday that addressed a pair of bugs that together resulted in a remote code execution vulnerability. The first bug was an encryption key that is generated on Exchange server installation. That generation seemed to lack a good source of entropy, as apparently every Exchange install uses the the exact same key.

The second half of this bug is a de-serialization problem, where an encrypted payload can contain a command to run. Because the encryption key is known, any user can access the vulnerable endpoint. The process of exploitation is so trivial, be sure to patch your server right away.

TODO: Remove Vulnerabilities

This one is just humorous. An Intel virtualization feature appears to have been pushed into the Linux kernel before it was finished. Know what unfinished code tends to contain? Bugs and vulnerabilities. CVE-2020-2732, in this case. It’s unclear how exactly an exploit would work, but the essence is that a virtual guest is allowed to manipulate system state in unintended ways.

This Week In Security: DNSSEC Temporarily Lost Their Keys, FIDO, And One Weird Windows Trick

DNSSEC is the system that allows for cryptographically secure DNS. It’s all based on a root cryptographic key, maintained by the Internet Assigned Numbers Authority (IANA). Ever wondered where the root Key Signing Key is stored, and how it’s accessed? Four times a year, a ceremony is held where the root key is pulled out of a physical safe, and maintenance tasks are performed in front of a group of witnesses.

Such an event was scheduled for February 12th, but a teensy problem was discovered. One of the safes that holds the key media had a broken lock, and the root key signing key was inaccessible for a few days while repairs were effected. The open nature of IANA means that much of their operations are publicly reported, and you can even watch the key signing ceremony, which was finally held on February 16th.

Continue reading “This Week In Security: DNSSEC Temporarily Lost Their Keys, FIDO, And One Weird Windows Trick”

Password Keeper Uses Off-The-Shelf Formfactor

With every website these days demanding the creation of an account, it can become difficult to remember so many logins. Each password should ideally be unique, lest a leak from your fantasy football game cost you thousands in stolen bitcoins. To help, [vcch] developed a password vault, using an interesting off-the-shelf platform.

The platform in question is the M5stickC, which packs an ESP32, color LCD, and battery into an attractive orange enclosure. It’s even got USB-C, making it a tool with an eye on the future. It serves as a quick way to get a basic IOT project up and running, without having to fuss about designing your own enclosure or basic power supply hardware.

On this platform, [vcch] created a tool to make keeping track of passwords easy. The PassStrong, as it’s called, can store a huge number of passwords, and communicates with the host PC over Bluetooth. The interface makes good use of the LCD, displaying the current mode and function of each button on the device for the user. It’s capable of working in both QWERTY and AZERTY environments, which should appeal to European users.

The M5StickC is a perfect choice in this regard, packing enough buttons and the required Bluetooth hardware to get the job done. No need to spend any time integrating modules – simply open the box and get to coding. We expect to see more developments in this space in future, and look forward to the efficiency gains this will bring to all kinds of projects!

Wearable Cone Of Silence Protects You From Prying Ears

Careful,  the walls have ears. Or more specifically, the smart speaker on the table has ears, as does the phone in your pocket, the fitness band on your wrist, possibly the TV, the fridge, the toaster, and maybe even the toilet. Oh, and your car is listening to you too. Probably.

How does one fight this profusion of listening devices? Perhaps this wearable smart device audio jammer will do the trick. The idea is that the MEMS microphones that surround us are all vulnerable to jamming by ultrasonic waves, due to the fact that they have a non-linear response to ultrasonic signals. The upshot of that is when a MEMS hears ultrasound, it creates a broadband signal in the audible part of the spectrum. That creates a staticky noise that effectively drowns out any other sounds the microphone might be picking up.

By why a wearable? Granted, [Yuxin Chin] and colleagues from the University of Chicago have perhaps stretched the definition of that term a tad with their prototype, but it turns out that moving the jammer around does a better job of blocking sounds than a static jammer does. The bracelet jammer is studded with ultrasonic transducers that emit overlapping fields and result in zones of constructive and destructive interference; the wearer’s movements vary the location of the dead spots that result, improving jamming efficacy. Their paper (PDF link) goes into deeper detail, and a GitHub repository has everything you need to roll your own.

We saw something a bit like this before, but that build used white noise for masking, and was affixed to the smart speaker. We’re intrigued by a wearable, especially since they’ve shown it to be effective under clothing. And the effect of ultrasound on MEMS microphones is really interesting.

Continue reading “Wearable Cone Of Silence Protects You From Prying Ears”

This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7

First off this week, a ransomware named Robinhood has a novel trick up its sleeve. The trick? Loading an old known-vulnerable signed driver, and then using a vulnerability in that driver to get a malicious kernel driver loaded.

A Gigabyte driver unintentionally exposed an interface that allows unfettered kernel level read and write access. Because it’s properly signed, Windows will happily load the driver. The ransomware code uses that interface to turn off the bit that enforces the loading of signed drivers only. From there, loading a malicious driver is trivial. Robinhood uses it’s kernel-level access to disable anti-virus applications before launching the data encryption.

This is a striking example of the weakness of binary signing without a mechanism to revoke those signatures. In an ideal world, once the vulnerability was found and an update released, the older, vulnerable driver would have its signature revoked.

The last Windows 7 Update For Real This Time, Maybe

More news in the ongoing saga of Windows 7/Server 2008 reaching end-of-life. KB4539602 was released this patch Tuesday, fixing the black background problem introduced in the last “final” round of updates. Surely that’s the last we’ll hear of this saga, right?

Not so fast. Apparently that patch has led to multiple Windows Server 2008 machines failing to boot after install. According to Microsoft, the problem is a missing previous patch that updates SHA-2 support. Continue reading “This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7”

USB Password Keeper Runs On Tiny Chip

The most important rule of password use, especially when used for online logins, is to avoid reusing passwords. From there, one’s method of keeping track of multiple passwords can vary considerably. While memorization is an option in theory, in practice a lot of people make use of a password manager like Lastpass or KeePass. For those with increased security concerns, though, you may want to implement a USB password keeper like this one based on an ATtiny.

This password keeper, called “snopf”, is a USB device with an ATtiny85 which adds a layer of separation to password keeping that increases security substantially. Passwords are created by the USB device itself using a 128-bit key to generate the passwords, which are physically detached from the computer. Password requests are made by the computer to the USB device, but the user must push a button on the snopf in order to send the password to the computer. It does this by emulating a keyboard, keeping the password information off of the computer’s clipboard.

Of course, snopf isn’t perfectly secure, and the project’s creator [Hajo] goes into detail on the project’s page about some of the potential vulnerabilities. For most use cases, though, none of these are of serious concern. Upgrading your password keeper to a physical device is likely to be a huge security improvement regardless, and one was actually developed on Hackaday a few years ago.