This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians

September 18, 2020 by Jonathan Bennett 19 Comments

The big news this week is the huge flaw in Microsoft’s Active Directory, CVE-2020-1472 (whitepaper). Netlogon is a part of the Windows domain scheme, and is used to authenticate users without actually sending passwords over the network. Modern versions of Windows use AES-CFB8 as the cryptographic engine that powers Netlogon authentication. This peculiar mode of AES takes an initialization vector (IV) along with the key and plaintext. The weakness here is that the Microsoft implementation sets the IV to all zeros.

It’s worth taking a moment to cover why IVs exist, and why they are important. The basic AES encryption process has two inputs: a 128 bit (16 byte) plaintext, and a 128, 192, or 256 bit key. The same plaintext and key will result in the same ciphertext output every time. Encrypting more that 128 bits of data with this naive approach will quickly reveal a problem — It’s possible to find patterns in the output. Even worse, a clever examination of the patterns could build a decoding book. Those 16 byte patterns that occur most often would be guessed first. It would be like a giant crossword puzzle, trying to fill in the gaps.

This problem predates AES by many years, and thankfully a good solution has been around for a long time, too. Cipher Block Chaining (CBC) takes the ciphertext output of each block and mixes it (XOR) with the plaintext input of the next block before encrypting. This technique ensures the output blocks don’t correlate even when the plaintext is the same. The downside is that if one block is lost, ~~the entire rest of the data cannot be decrypted~~ Update: [dondarioyucatade] pointed out in the comments that it’s just the next block that is lost, not the entire stream. You may ask, what is mixed with the plaintext for the first block? There is no previous block to pull from, so what data is used to initialize the process? Yes, the name gives it away. This is an initialization vector: data used to build the initial state of a crypto scheme. Generally speaking, an IV is not secret, but it should be randomized. In the case of CBC, a non-random IV value like all zeros doesn’t entirely break the encryption scheme, but could lead to weaknesses. Continue reading “This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians” →

GitHub’s Move Away From Passwords: A Sign Of Things To Come?

September 15, 2020 by Maya Posch 69 Comments

Later this month, people who use GitHub may find themselves suddenly getting an error message while trying to authenticate against the GitHub API or perform actions on a GitHub repository with a username and password. The reason for this is the removal of this authentication option by GitHub, with a few ‘brown-out’ periods involving the rejection of passwords to give people warning of this fact.

This change was originally announced by GitHub in November of 2019, had a deprecation timeline assigned in February of 2020 and another blog update in July repeating the information. As noted there, only GitHub Enterprise Server remains unaffected for now. For everyone else, as of November 13th, 2020, in order to use GitHub services, the use of an OAuth token, personal token or SSH key is required.

While this is likely to affect a fair number of people who are using GitHub’s REST API and repositories, perhaps the more interesting question here is whether this is merely the beginning of a larger transformation away from username and password logins in services.

Continue reading “GitHub’s Move Away From Passwords: A Sign Of Things To Come?” →

Security This Week: Racoons In My TLS, Bypassing Frontends, And Obscurity

September 11, 2020 by Jonathan Bennett 7 Comments

Raccoon is the next flashy security flaw with a name, cute logo, and a website (and a PDF). Raccoon is a flaw in TLS version prior to 1.3, and seems to be a clever bit of work, albeit one with limited real-world application. The central problem is that these older versions of TLS, when using Diffie Hellman (DH), drop leading all-zero bytes in the resulting pre-master key. As that key is part of the input for calculating the master session key, a shortened pre-master key results in a slightly faster calculation of the master key. If an attacker can make fine-grained timing measurements, he can determine when the pre-master key is trimmed.

Let’s review Diffie Hellman, briefly. The client and server agree on two numeric values, a base g and modulus p, and each party generates a secret key, a and b. Each party calculates a public key by raising the shared base to their own private key, mod the shared modulus: A = g^a mod p. These public keys are exchanged, and each party raises the received key to their own secret key: A^b. Exponents have a non-obvious quirk, the power rule. A value raised to a power raised to a power is the same as the value raised to the power of the exponents multiplied together. g^a^b is equal to g^(a*b). By going through this mathematical dance, the server and client have arrived at a shared value that only they know, while preserving the secrecy of their private keys. Continue reading “Security This Week: Racoons In My TLS, Bypassing Frontends, And Obscurity” →

ESP32 Hash Monster Fills Pockets With Packets

September 8, 2020 by Tom Nardi 4 Comments

Unless you’re reading this from the middle of the ocean or deep in the forest, it’s a pretty safe bet there’s WiFi packets zipping all around you right now. Capturing them is just a matter of having the right hardware and software, and from there, you can get to work on cracking the key used to encrypt them. While such things can obviously have nefarious connotations, there are certainly legitimate reasons for auditing the strength of the wireless networks in the area.

It might not have the computational horsepower to crack any encryption itself, but the ESP32 M5Stack is more than up to the task of capturing WiFi packets if you install the Hash Monster firmware developed by [G4lile0]. Even if you don’t intend on taking things farther, this project makes finding WiFi access points and grabbing their packets a fascinating diversion with the addition of a few graphs and an animated character (the eponymous monster itself) that feeds on all those invisible 1s and 0s in the air.

There’s some excellent documentation floating around that shows you the start to finish process of popping open a WiFi network with the help of Hash Monster, but that’s only the beginning of what’s possible with this gadget. A quick search uncovers a number of software projects that make use of the specific advantages of the M5Stack compared to more traditional ESP32 boards, namely the built-in screen, buttons, and battery. We’ve even seen it used in a few builds here on Hackaday, such as this DIY thermal camera and custom shipboard computer system.

[Thanks to Manuel for the tip.]

This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More

September 4, 2020 by Jonathan Bennett 5 Comments

Honeypots are an entertaining way to learn about new attacks. A simulated vulnerable system is exposed to the internet, inviting anyone to try to break into it. Rather than actually compromising a deployed device, and attacker just gives away information about how they would attack the real thing. A honeypot run by 360Netlab found something interesting back in April: an RCE attack against QNAP NAS devices. The vulnerability is found in the logout endpoint, which takes external values without properly sanitizing them. These values are used as part of an snprintf statement, and then executed with a system() call. Because there isn’t any sanitization, special characters like semicolons can be injected into the final command to be run, resulting in a trivial RCE.

QNAP has released new firmware that fixes the issue by replacing the system() call with execv(). This change means that the shell isn’t part of the execution process, and the command injection loses its bite. Version 4.3.3 was the first firmware release to contain this fix, so if you run a QNAP device, be sure to go check the firmware version. While this vulnerability was being used in the wild, there doesn’t seem to have been a widespread campaign exploiting it.

Continue reading “This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More” →

COVID-tracing Framework Privacy Busted By Bluetooth

September 3, 2020 by Elliot Williams 60 Comments

[Serge Vaudenay] and [Martin Vuagnoux] released a video yesterday documenting a privacy-breaking flaw in the Apple/Google COVID-tracing framework, and they’re calling the attack “Little Thumb” after a French children’s story in which a child drops pebbles to be able to retrace his steps. But unlike Hänsel and Gretl with the breadcrumbs, the goal of a privacy preserving framework is to prevent periodic waypoints from allowing you to follow anyone’s phone around. (Video embedded below.)

The Apple/Google framework is, in theory, quite sound. For instance, the system broadcasts hashed, rolling IDs that prevent tracing an individual phone for more than fifteen minutes. And since Bluetooth LE has a unique numeric address for each phone, like a MAC address in other networks, they even thought of changing the Bluetooth address in lock-step to foil would-be trackers. And there’s no difference between theory and practice, in theory.

In practice, [Serge] and [Martin] found that a slight difference in timing between changing the Bluetooth BD_ADDR and changing the COVID-tracing framework’s rolling proximity IDs can create what they are calling “pebbles”: an overlap where the rolling ID has updated but the Bluetooth ID hasn’t yet. Logging these allows one to associate rolling IDs over time. A large network of Bluetooth listeners could then trace people’s movements and possibly attach identities to chains of rolling IDs, breaking one of the framework’s privacy guarantees.

This timing issue only affects some phones, about half of the set that they tested. And of course, it’s only creating a problem for privacy within Bluetooth LE range. But for a system that’s otherwise so well thought out in principle, it’s a flaw that needs fixing.

Why didn’t the researchers submit a patch? They can’t. The Apple/Google code is mostly closed-source, in contrast to the open-source nature of most of the apps that are running on it. This remains troubling, precisely because the difference between the solid theory and the real practice lies exactly in those lines of uninspectable code, and leaves all apps that build upon them vulnerable without any recourse other than “trust us”. We encourage Apple and Google to make the entirety of their COVID framework code open. Bugs would then get found and fixed, faster.

Continue reading “COVID-tracing Framework Privacy Busted By Bluetooth” →

This Week In Security: XCode Infections, Freepik, And Crypto Fails

August 28, 2020 by Jonathan Bennett 8 Comments

There is a scenario that keep security gurus up at night: Malware that can detect software compilation and insert itself into the resulting binary. A new Mac malware, XCSSET (PDF), does just that, running whenever Xcode is used to build an application. Not only is there the danger of compiled apps being malicious, the malware also collects data from the developer’s machine. It seems that the malware spreads through infected Xcode projects.

WordPress Plugins

WordPress has a complicated security track record. The core project has had very few serious vulnerabilities over the years. On the other hand, WordPress sites are routinely compromised. How? Generally through vulnerable plugins. Case in point? Advanced Access Manager. It’s a third party WordPress plugin with an estimate 100,000 installations. The problem is that this plugin requires user levels, a deprecated and removed WordPress feature. The missing feature had some unexpected results, like allowing any user to request administrator privileges.

The issue has been fixed in 6.6.2 of the plugin, so if you happen to run the Advanced Access Manager plugin, make sure to get it updated. Beyond that, maybe it’s time to do an audit on your WordPress site. Uninstall unused plugins, and make sure the rest are up to date, along with the WordPress installation itself. Continue reading “This Week In Security: XCode Infections, Freepik, And Crypto Fails” →