Copy And Paste Deemed Insecure

June 18, 2020 by Al Williams 23 Comments

Back when Windows NT was king, Microsoft was able to claim that it met the strict “Orange Book” C2 security certification. The catch? Don’t install networking and remove the floppy drives. Turns out most of the things you want to do with your computer are the very things that are a security risk. Even copy and paste.

[Michal Benkowki] has a good summary of his research which boils down to the following attack scenario:

Visit a malicious site.
Copy something to the clipboard which allows the site to put in a dangerous payload.
Visit another site with a browser-based visual editor (e.g., Gmail or WordPress)
Paste the clipboard into the editor.

Continue reading “Copy And Paste Deemed Insecure” →

Disable Intel’s Backdoor On Modern Hardware

June 16, 2020 by Bryan Cockfield 42 Comments

While the Intel Management Engine (and, to a similar extent, the AMD Platform Security Processor) continues to plague modern computer processors with security risks, some small progress continues to be made for users who value security of the hardware and software they own. The latest venture in disabling the ME is an ASRock motherboard for 8th and 9th generation Intel chips. (There is also a link to a related Reddit post about this project).

First, a brief refresher: The ME is completely removable on some computers built before 2008, and can be partially disabled or deactivated on some computers built before around 2013. This doesn’t allow for many options for those of us who want modern hardware, but thanks to a small “exploit” of sorts, some modern chipsets are capable of turning the ME off. This is due to the US Government’s requirement that the ME be disabled for computers in sensitive applications, so Intel allows a certain undocumented bit, called the HAP bit, to be set which disables the ME. Researchers have been able to locate and manipulate this bit on this specific motherboard to disable the ME.

While this doesn’t completely remove the firmware, it does halt all execution of code in a way that is acceptable for a large governmental organization, so if you require both security and modern hardware this is one of the few ways to achieve that goal. There are other very limited options as well, but if you want to completely remove the ME even on old hardware the process itself is not as straightforward as you might imagine.

Header image: Fritzchens Fritz from Berlin / CC0

OmniBallot, Another Flawed Attempt At Online Voting

June 14, 2020 by Maya Posch 49 Comments

Although online voting in elections has been a contentious topic for decades already, it is during the current pandemic that it has seen significant more attention. Along with mail-based voting, it can be a crucial tool in keeping the world’s democratic nations running smoothly. This is where the OmniBallot software, produced by Democracy Live, comes into play, and its unfortunate unsuitability for this goal.

Despite already being used by multiple US jurisdictions for online voting, a study by MIT’s [Michael Specter] and University of Michigan researchers points out the flaws in this web-based platform. Their recommendations are to either avoid using OmniBallot completely, or to only use it for printing out a blank ballot that one then marks by hands and sends in by mail.

One of the issues with the software is that it by default creates the marked ballot PDF on the Democracy Live servers, instead of just on the user’s device. Another is that as a web-based platform it is hosted on Amazon Web Services (AWS), with JavaScript sources pulled from both CloudFlare and Google servers. Considering that the concern with electronic voting machines was that of unauthorized access at a polling station, it shouldn’t require a lengthy explanation to see this lack of end-to-end security with OmniBallot offers many potential attack surfaces.

When Ars Technica contacted Democracy Live for commentary on these findings, Democracy Live CEO [Bryan Finney] responded that “The report did not find any technical vulnerabilities in OmniBallot”. Since the researchers did not examine the OmniBallot code itself that is technically true, but misses the larger point of the lack of guarantee of every single voter’s device being secured, as well as every AWS, CloudFlare and Google instance involved in the voting process.

As a result, the recommended use of OmniBallot is to use it for the aforementioned printing out of blank ballots, to save half of the trip time of the usual mail-in voting.

This Week In Security: Crosstalk, TLS Resumption, And Brave Shenanigans

June 12, 2020 by Jonathan Bennett 2 Comments

Intel announced CrossTalk, a new side-channel attack that can leak data from CPU buffers. It’s the same story we’ve heard before. Bits of internal CPU state can be inferred by other processes. This attack is a bit different, in that it can leak data across CPU cores. Only a few CPU instructions are vulnerable, like RDRAND, RDSEEED, and EGETKEY. Those particular instructions matter, because they’re used in Intel’s Secure Enclave and OpenSSL, to name a couple of important examples.
Continue reading “This Week In Security: Crosstalk, TLS Resumption, And Brave Shenanigans” →

Quantum Computing And The End Of Encryption

June 11, 2020 by Maya Posch 58 Comments

Quantum computers stand a good chance of changing the face computing, and that goes double for encryption. For encryption methods that rely on the fact that brute-forcing the key takes too long with classical computers, quantum computing seems like its logical nemesis.

For instance, the mathematical problem that lies at the heart of RSA and other public-key encryption schemes is factoring a product of two prime numbers. Searching for the right pair using classical methods takes approximately forever, but Shor’s algorithm can be used on a suitable quantum computer to do the required factorization of integers in almost no time.

When quantum computers become capable enough, the threat to a lot of our encrypted communication is a real one. If one can no longer rely on simply making the brute-forcing of a decryption computationally heavy, all of today’s public-key encryption algorithms are essentially useless. This is the doomsday scenario, but how close are we to this actually happening, and what can be done?

Continue reading “Quantum Computing And The End Of Encryption” →

STM32 Blue Pill Turned GPG Security Token

June 10, 2020 by Tom Nardi 30 Comments

Feeling the cost of commercial options like the YubiKey and Nitrokey were too high, [TheStaticTurtle] started researching DIY alternatives. He found an open source project allows the STM32F103 to act as a USB cryptographic token for GNU Privacy Guard, which was a start. All he had to do was build a suitable device to install it on.

The first step was to test the software out on the popular “Blue Pill” development board, which [TheStaticTurtle] documents in the write-up should anyone want to give it a try themselves. The ST-Link V2 was already a supported target, so it only took some relatively minor tweaks to get running and add support for a simple push button. The output of gpg --card-status showed the device was working as expected, so with the software sorted, it was time to take a closer look at the hardware.

To create his “TurtleAuth” dongle, [TheStaticTurtle] started with the basic layout of the Blue Pill and added in a TTP223E touch control IC. The original Micro USB port was also swapped for a male USB-A connector so the device could be plugged directly into a computer. An upper PCB, containing the status LEDs and touch pad, was then designed so it would fit over the main board as an enclosure of sorts. While the sides are still open, the device looks robust enough to handle life in a laptop bag at least.

While it’s not exactly a common project, this isn’t the first time we’ve seen somebody spin up their own hardware token. More evidence of what the dedicated individual can accomplish these days on a relatively limited budget.

This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets

June 5, 2020 by Jonathan Bennett 9 Comments

So first off, remember the Unc0ver vulnerability/jailbreak from last week? In the 13.5.1 iOS release, the underlying flaw was fixed, closing the jailbreak. If you intend to jailbreak your iOS device, make sure not to install this update. That said, the normal warning applies: Be very careful about running out-of-date software.

Apple Sign In

An exploit in Apple’s web authentication protocol was fixed in the past week . Sign In With Apple is similar to OAuth, and allows using an Apple account to sign in to other sites and services. Under the hood, a JSON Web Token (JWT) gets generated and passed around, in order to confirm the user’s identity. In theory, this scheme even allows authentication without disclosing the user’s email address.

So what could go wrong? Apparently a simple request for a JWT that’s signed with Apple’s public key will automatically be approved. Yeah, it was that bad. Any account linked to an Apple ID could be trivially compromised. It was fixed this past week, after being found and reported by [Bhavuk Jain]. Continue reading “This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets” →