There’s been yet another technique discovered to fingerprint users, and this one can even work in the Tor browser. Scheme flooding works by making calls to application URLs, something like steam://browsemedia. If your machine supports the requested custom URL, a pop-up is displayed, asking permission to launch the external application. That pop-up can be detected by JavaScript in the browser. Detect enough apps, and you can build a reasonable fingerprint of the system the test is run on. Unlike some previous fingerprinting techniques, this one isn’t browser dependent — it will theoretically give the same results for any browser. This means even the Tor browser, or any browser being used over the Tor network, can give your potentially unique set of installed programs away.

Now for the good news. The Chrome devs are already working on this issue, and in fact, Chrome on my Linux desktop didn’t respond to the probes in a useful way. Feel free to check out the demo, and see if the results are accurate. And as for Tor, you really should be running that on a dedicated system or in a VM if you really need to stay anonymous. And disable JavaScript if you don’t want the Internet to run code on your computer.

Samba Security Lost in Translation

Windows system security and Linux system security are quite different. OK, that’s probably both something of an understatement, and pretty obvious. In a project like Samba, which re-implements the Server Message Block protocol, those differences are a constant challenge. Sometimes, like in the case of CVE-2021-20254, the results are unusual.

This story really begins at Linköping University, where [Peter Eriksson] discovered that someone was able to delete a file on a Samba share, when that should not have been possible. He apparently tracked down the problem, which is in the Samba code that maps Windows SIDs to Unix Group IDs. Samba caches these lookups, and a possible cached result is that a match cannot be found. The bug is triggered when that cached response is fetched again, reading past the end of the buffer. There isn’t a known technique for triggering this bug intentionally, but that’s likely a failure of imagination, so make sure you get this one patched.

21st Century Finnish Wardialing

There are odd machines still connected to the Plain Old Telephone System (POTS). This thought was apparently keeping [Valtteri Lehtinen] up at night, because he built a system to call 56,874 different phone numbers, and then documented what he found. His testing rig is a bit odd, using WarVOX as the dialer. That program only supports IAX2, a VoIP protocol introduced by the Asterisk project that has been mostly forgotten in favor of SIP. His interface to the outside world was a SIP-to-GSM gateway and a cheap prepaid SIM card. To make WarVOX talk to the SIP gateway, he stood up an Asterisk instance to do the translation. His target was the “freephone” numbers, similar to a 1-800 number in the States — mostly businesses rather than individuals.

He spent 60 seconds per call, and recorded the results, running the experiment for 40 days. His results? About 2% of the numbers were interesting. He categorized those, and came up with 74 unique systems he had reached. For an example of what that means, seven of his calls reached dedicated fax lines. These were indistinguishable from each other, so only accounts for a single unique system. Eleven calls just played music, but several of those seemed to be playing the exact same music, making for seven unique systems.

There are a few really oddball recordings that [Valtteri] found. Two numbers contain a prompt about the zombie apocalypse, asking the caller if he wants to be rescued. These remind me very much of the various joke phone numbers, like the rejection hotline. He also found a couple numbers that sound very much like old mechanical phone switching hardware. Wouldn’t it be interesting to know exactly what hardware is on the other end of those calls? We can’t recommend taking up wardialing as a hobby, but there are certainly still some interesting endpoints out there. Want to look into the recordings for yourself? Check out his blog post, where many of the recordings are available to listen to.

Don’t Connect To That Wifi Network!

There’s a very odd problem with the iPhone that’s attracted a lot of attention this week. Connecting to a WiFi network with a name like %p%s%s%s%s%n made the phone’s WiFi subsystem crash, and prevented connection to any other networks. That string looks interesting, doesn’t it? Almost like a format string. For those not following, most programming languages have string formatting functions that take a series of inputs, combined with a format string like this one, and plug the inputs into the string. C’s printf() is one of the more familiar to many of us. The catch here is that when the inputs don’t match what the string calls for, you enter the realm of undefined behavior, AKA crashes and vulnerabilities.

After joining my personal WiFi with the SSID “%p%s%s%s%s%n”, my iPhone permanently disabled it’s WiFi functionality. Neither rebooting nor changing SSID fixes it :~) pic.twitter.com/2eue90JFu3

— Carl Schou (@vm_call) June 18, 2021

[CodeColorist] took a deeper look at the problem, and confirmed that it is indeed a format string issue. When the device attempts to connect to a new WiFi network, a message is written to the system log: “Attempting Apple80211AssociateAsync to ” and then the network name, using a format string method. The process of writing the string to the log invokes another such method, but this time the SSID is now part of the format string. The inputs no longer match, leading to a crash of the WiFi process. While it’s certainly an annoying bug, it doesn’t appear to be one that can lead to RCE.

Rate Limiting Bypass and Bounty Dispute

Password reset systems have always been something of a weak point of security schemes. Of particular note are the schemes that use a four- or six-digit reset code to protect the account. Have you ever wondered what stops an attacker from triggering a reset, and then simply trying all one million possible codes, assuming a six-digit number? The usual answer is a combination of expiring codes and rate limiting on guesses. This story is about Apple accounts, but the background is that [Laxman Muthiyah] first found a way to exploit the password reset function of Instagram.

Here’s the setup. When you start the password reset process on Instagram, a six-digit code is emailed to the email address on file. If you have access to that email, you type in the code within ten minutes, proving that you’re the account owner. After ten minutes, the code expires. If you’re an attacker, you can start the password reset process, and then guess that six-digit code — again, one million possible values. Try to brute force the code, and about 200 attempts go through before the rate-limiting kicks in. That gives you a 1-in-5,000 chance in breaking into the account.

What if there was a way to get around the rate-limiting? Hint: There was. You see, trying to send more than 200 guesses from a single IP was easily detected and rate-limited. But what if you had two different IPs? Send 200 guesses from each, at the same time, and they all get processed with no rate limiting. So to take over an Instagram account, all it takes is 5,000 IPs that you can send traffic from for a few seconds. Now how would you get 5,000 IPs to use? Three options come to mind. The cloud, a botnet, or IPv6 addresses. He used a cloud to demonstrate the attack, covering 20% of the possible key space in a single go. He netted a cool $30,000 from turning in the findings to Facebook.

Would other providers have the same weakness? [Muthiyah] took a look at Apple’s account recovery process, and found a way to pull off the same attack, but with some major limitations. Rather than 200 guesses from each IP, he could send six. That isn’t enough for a viable attack — but the target URL endpoint exists on six different IPs. That gives an attacker 36 guesses from each IP he controls. That’s on the edge of being exploitable, with only 28,000 IPs needed. That’s a *small* botnet. Apple agreed, asking him to keep the attack under his hat until they could push out fixes.

The story gets weird from here. First, what should have been a relatively simple fix took about ten months to roll out. [Laxman] asked for an update, and was told that his attack only worked against accounts not tied to a hardware device. Accounts tied to a device use a bit different password reset method, where a hashing function is used to prove that the user knows the reset code. That URL endpoint is now very well protected against his parallel brute-force attack, but he was only able to test it after the flaw was fixed.

For his trouble, Apple offered him $18,000. Sounds great, right? Hold up. A vulnerability that leads to an Apple account takeover should be worth $100,000; and if that leads to data extraction from a device, it goes up to $250,000. [Laxman] openly speculates that his attack probably worked on all accounts before it was patched, and suspects Apple of pulling a fast one. He walked away from the offered bounty, and posted the entire story for everyone to see. This isn’t the first time we’ve covered disputes over bug bounties, and I’m sure it won’t be the last.

Dell Bios Vulnerabilities

Eclypsium found a handful of problems with Dell’s firmware update process. BIOSConnect is a firmware update process that runs entirely from the system BIOS. From what I can tell, this means that a Dell machine could be vulnerable even if it isn’t running Dell’s SupportAssist, or even Windows at all. The BIOS makes an HTTPS request to downloads.dell.com, but fails to properly validate the TLS certificate. It seems that any wildcard certificate for any domain will be accepted. You could fool it as easily as using a Let’s Encrypt certificate for *.myuniquedomain.com, and telling an HTTPS server to use that cert for dell.com.

The saving grace here is that an attacker needs to be on the same network as the victim machine, in order to MItM the connection to the update server. Either way, if you have Dell hardware, go check for this issue and update if it’s there, or at least turn off BIOSConnect.

Unplug Your MyBooks

There’s been a rash of ransomware attacks against consumer NAS devices, and it looks like Western Digital’s My Book Live might be the next device to be hit. Multiple users discovered their drives wiped on the 23rd, and a log note that a factory restore had been triggered. WD has released a statement, acknowledging the issue, and recommending that anyone with a My Book Live unplug it from the network right away, and leave it offline until they can get to the bottom of the issue. The latest official news is a reference to a 2018 CVE, a pre-auth network RCE. What immediately comes to mind is that a particularly obnoxious ransomware program could include this attack as part of an effort to destroy backups. The odd part is that none of the affected users have reported a ransomware note.

Windows 11

Microsoft announced Windows 11, and while there was the normal marketing hype and keynotes, there were a couple interesting security-related tidbits, mostly in the updated system requirements. First up is the Trusted Platform Module 2.0 requirement. Most modern motherboards ship with a firmware TPM, but often disabled by default. If you try running the upgrade check, and were told that your nearly-new system can’t run Windows 11, that’s probably why. But why would Microsoft require a TPM for everyone? Credit to Robert Graham for this one: TPM is a requirement for BitLocker, the high quality whole disk encryption software built into Windows. This would indicate that BitLocker is going to be on for everyone, rather than a feature you have to manually enable.

The other somewhat surprising change is that Microsoft is doing away with support for 32-bit processors, and going to 64-bit Windows only. There are sure to be some issues for people still running 16-bit code, which won’t execute at all under 64-bit Windows. There are, however, quite a few security features that only run on 64-bit windows, like ASLR, signed drivers, the NX bit for Data Execution Protection, and PatchGuard. While the reduced engineering burden of dropping 32-bit Windows was likely the major driver in this decision, the Windows platform will be significantly more secure as a result.