This Week In Security: UTorrent Vulnerable, Crowd-Sourcing Your Fail2Ban, And Cryptographers At Casinos

September 25, 2020 by Jonathan Bennett 22 Comments

The uTorrent client was recently updated to fix a null pointer dereference (CVE-2020-8437), discovered by [whtaguy]. Triggering the dereference simply crashes the client — so far an actual RCE hasn’t been found. Given the nature of the null pointer dereference, it’s possible this bug is limited to denial of service. That’s extremely good, because the flaw is extremely easy to target.

BitTorrent is a clever protocol. It’s still used to distribute large files, like Linux ISOs. The concept is simple: Split a large file into small chunks. Send the chunks to a client one at a time. As each chunk is received, the client sends a copy of that chunk to the next client. As a result of this peer-to-peer (p2p) arrangement, the bandwidth available to the server is greatly multiplied. As with all other p2p arrangements, the sticking point is how to make those connections between peers, particularly when most of the world’s desktops are behind NAT routers. In practice, for two peers to share data, at least one of them has to have a port opened or forwarded to the client. This is often accomplished through Universal Plug-n-Play (UPnP) or the NAT Port Mapping Protocol (NAT-PMP). The idea of both protocols are the same; a client on an internal device can request a temporary port forward without manual intervention. Whether it’s a good idea to allow automatic port forwards is another issue for another day. Continue reading “This Week In Security: UTorrent Vulnerable, Crowd-Sourcing Your Fail2Ban, And Cryptographers At Casinos” →

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” →

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” →

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” →

This Week In Security: DEF CON, Intel Leaks, Snapdragon, And A Robot Possessed

August 14, 2020 by Jonathan Bennett 6 Comments

Last weekend, DEF CON held their “SAFE MODE” conference: instead of meeting at a physical venue, the entire conference was held online. All the presentations are available on the official DEF CON YouTube channel. We’ll cover a few of the presentations here, and watch out for other articles on HaD with details on the other talks that we found interesting.
Continue reading “This Week In Security: DEF CON, Intel Leaks, Snapdragon, And A Robot Possessed” →

This Week In Security: Garmin Ransomware, KeePass , And Twitter Warnings

August 7, 2020 by Jonathan Bennett 9 Comments

On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices. Continue reading “This Week In Security: Garmin Ransomware, KeePass , And Twitter Warnings” →

This Week In Security: Twilio, PongoTV, And BootHole

July 31, 2020 by Jonathan Bennett 5 Comments

Twilio, the cloud provider for all things telecom, had an embarrassing security fail a couple weeks ago. The problem was the Amazon S3 bucket that Twilio was using to host part of their public facing content. The bucket was configured for public read-write access. Anyone could use the Amazon S3 API to make changes to the files stored there.

The files in question were protected behind Cloudflare’s CDN, but there’s a catch to Cloudflare’s service. If you know the details of the service behind Cloudflare, it can often be interacted with directly. In many cases, knowing the IP address of the server being protected is enough to totally bypass Cloudflare altogether. In this case, the service behind the CDN is Amazon’s S3. Any changes made to the files there are picked up by the CDN.

Someone discovered the insecure bucket, and modified a Javascript file that is distributed as part of the Twilio JS SDK. That modification was initially described as “non-malicious”, but in the official incident report, Twilio states that the injected code is part of an ongoing magecart campaign carried out against misconfigured S3 buckets.
Continue reading “This Week In Security: Twilio, PongoTV, And BootHole” →