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.
Netlogon, on the other hand, uses a Cipher FeedBack (CFB8) mode of AES. This mode takes a 16 byte IV, and prepends that value to the data to be encrypted. The basic AES operation is performed on the first 16 bytes of this message (just the IV). The first byte of the output is XOR’d with the 17th byte of the combined string, and then the 16 byte window slides one byte to the right. When the last byte of the plaintext message has been XOR’ed, the IV is dropped and the process is finished. The peculiar construction of AES-CFB8 means that a random IV is much more important to strong encryption.
Remember the actual flaw? Microsoft’s implementation sets that IV value as all zeros. The encryption key is generated from the password, but the plaintext to be encrypted can be specified by the attacker. It’s fairly simple to manipulate the situation such that the entire IV + Plaintext string consists of zeros. In this state, 1-in-256 keys will result in an all-zero ciphertext. Put another way, the 128-bit security of AES is reduced to 8-bit. Within just a handful of guesses, an attacker can use Netlogon to authenticate as any user.
Microsoft has patched the issue in their August security updates. While it’s true that exploiting this issue does require a toehold in a network, the exploitation is simple and proof of concept code is already available. This is definitely an issue to go patch right away.
When 2FA Makes You Less Secure
Few security truisms are as universal as “Enable two factor authentication.” There is a slight gotcha there. 2FA adds an extra attack surface. Palo Alto found this out the hard way with their PAN-OS systems. With 2FA or the captive portal enabled, it’s possible to exploit a buffer overflow and execute code as root. Because the interface to be exploited is often exposed to the public, this vulnerability scored a 9.8 critical rating.
CardBleed Virtual Card Skimmer
Magento is an e-commerce platform, owned by Adobe since 2018. To put that more simply, it’s a shopping cart system for websites. In the last few days, it seems that nearly 2,000 Magento v1 instances were compromised, with a digital skimmer installed on those sites. The rapid exploitation would suggest that someone had a database of Magento powered sites, and acquired a zero-day exploit that could be automated.
Hacking Politicians for Fun and Profit
It’s been the fodder of pundits and politicians for years now, to talk about hacking elections, particularly by a particularly large country in northern Asia. Be it bravery or foolishness, we’re actually going to take a brief look at some real stories of political hacking.
First up, A trio of Dutch hackers managed to break into Donald Trump’s twitter account back in 2016, just before the election. How? The same story we’re all familiar with: password re-use and a LinkedIn database dump. Fun fact, Donald Trump’s favorite password was “yourefired”.
A successful break-in is often accompanied by a moment of terror. “Did I do everything right, or am I going to jail for this?” It’s not an unfounded fear. Breaking into a corporation is one thing, but what happens to the guys that hacked the president of the US? The moment their long-shot attempts paid off, they went into defensive mode, and documented everything. Once they had their documentation safely secured, an email was sent off to USCERT (United States Computer Emergency Readiness Team) informing them of what was found. Our Dutch friends haven’t been arrested or “disappeared”, so it seems their responsible disclosure was well received.
In a similar story, a former Australian prime minister posted a picture online containing his boarding pass, and a resourceful researcher managed to use that information to recover his passport and telephone number. Did you know that a boarding pass is considered sensitive information? To authenticate with an airline, all that is needed is a last name and matching booking reference number. This gets you access to a very uninteresting page, but when you have access to 1337 hackor tools (like Google Chrome’s page inspector), the sky is the limit. Apparently the Qantas website backend was sending everything in the database about the given customer, and only a few bits of that information was being shown to the user. Far more information was just waiting to be sniffed out.
The whole story is a trip, and ends with a phone call with the politician in question. Go read it, you won’t regret it.
[Dr. Neal Krawetz] runs a TOR hidden service, and found himself the victim of a DDoS attack over the TOR network. He called up a friend who did network security professionally, and asked for help. After reading out half of the public IP address where the hosting server lived, his friend told him the rest of the address. Let’s think through that process. Hidden TOR service under attack, someone with access to a big enough Network Operations Center (NOC) can tell what the Public IP address of that service is. This is a fundamental break in TOR’s purpose.
In retrospect, it’s pretty obvious that if you can watch traffic on a large chunk of the internet, or enough of the TOR nodes, you can figure out what service is running where. The surprise is how small the percentage needs to be, and that there are already companies (and certainly three-letter agencies) that casually have the capability to make those connections. [Krawetz] calls these flaws 0-days, which is technically correct, because there are no real mitigations in place to protect against them. Really, it should serve as a reminder of the limitations of the TOR model.