Lapsus$

For every very clever security protocol that keeps people safe, there’s a stupid hack that defeats it in an unexpected way. Take OAuth for instance. It’s the technology that sites are using when they offer to “log in with Facebook”. It’s a great protocol, because it lets you prove your identity using a trusted third party. You don’t have to use a password at whatever site you’re trying to use, you just to be logged in to your Google/Facebook/Apple account, and click the button to allow access. If you’re not logged in, the pop-up window prompts for your username and password, which of course is one way phishing attacks try to steal passwords. So we tell people to look at the URL, and make sure they are actually signing in to the proper site.

The stupid hack that isn’t stupid, because it works: Recreating the browser window in HTML/CSS. Yep, it’s pretty straightforward to add a div to your site, and decorate it to look just like a browser window, just like an OAuth pop-up. In the appropriate place goes an iframe pointing to the actual phishing form. It looks convincing, but once you’re aware of the game, there’s a dead giveaway — try to move the OAuth window outside the browser window that spawned it. Websites can’t draw outside the browser window or over its window decorations, so this limitation makes it easy to confirm whether this hack is in play. The other saving grace is that a password manager isn’t fooled by this trick at all.

Via: Ars Technica

Typo-squatting At Scale

There’s a typo-squatting campaign going on at NPM, primarily targeted at Azure users. NPM has a packaging feature called “scoped packages”. A scope starts with the at sign, and indicates packages intentionally grouped together. In this case the scope is @azure, including packages like @azure/core-tracing, with over 1.5 million weekly downloads. The typo? Just drop the scope. NPM considers it completely acceptable to have both the @azure/core-tracing and core-tracing packages — in fact, it’s a feature of the scoping system. But forget to include the scope, and you may get a malicious package instead. Over 200 packages were targeted in this way, but have since been pulled by NPM.

The payload was strictly reconnaissance, grabbing directory listings, IP addresses, and the like. It’s likely that the information would be used to craft more malicious future updates, though no such behavior has been observed. This is likely due to how rapidly these packages were caught and removed — after only about two days. The domain used for data collection is 425a2.rt11.ml, so that string showing up in a DNS log somewhere is an indicator that one of these packages were installed.

Lapsus$ Strikes Again, Again

The loose collection of hackers knows as Lapsus$ have potentially scored breaches at both Microsoft and Okta. KrebsonSecurity has a bit more information about the group and the Microsoft case. The group seems to be doing some of their coordination over a Telegram channel, which is open for anyone to join. The group boasted of their exploits on this channel, and Microsoft respondents found and cut their access during the data exfiltration. A 10 GB file has been released containing partial source to Bing search, Bing Maps, and Cortana.

The Okta situation is even murkier, as the released screenshots indicate access back in late January. The access seems to have been limited to a administrative portal, via a Support Engineer’s account. Okta has gone out of their way to assure everyone that there was no actual breach, and the rogue access was quickly dealt with. This seems to be a bit disingenuous, as Lapsus$ was after companies making use of Okta services, and didn’t need to compromise their systems any further. Okta provides access management for other companies, like Cloudflare. There’s likely been some quiet infiltration happening in the months since this happened.

Linux Gets More Random

[Jason Donenfeld], kernel hacker and main developer of Wireguard, has worked recently on the Linux random number generator. A few changes landed in release 5.17, and more are coming in 5.18. He was kind enough to write up some of the interesting changes for our education. He considers his most important contribution to be documentation. I can confirm, among the most frustrating problems a programmer can face is when the documentation has bit-rotted to uselessness.

One of the biggest user-facing changes was the attempt to unify /dev/random and /dev/urandom. We say attempt, because this change caused multiple failures to boot on the kernel’s test setup. Apparently some architectures, specifically when being virtualized, have no method of generating high quality randomness during boot. There next killer feature is the new add_vmfork_randomness() call, that allows a newly cloned virtual machine to request a regeneration of its randomness pool. Without a call like this, the first few random numbers generated by the kernel after a VM fork would be identical — obviously a problem.

Internally, the randomness code retires the venerable SHA-1 algorithm, replacing it with the more modern BLAKE2 hash function. An interesting advantage is that BLAKE2 is intentionally a very fast algorithm, so the kernel gains a bit of performance when generating random numbers. The rest of the changes delve into more complicated cryptography considerations. Definitely worth reading if you’re interested.

Western Digital NAS RCE

We’ve covered plenty of vulnerabilties and attacks in NAS boxes from QNAP and Synology, but this week it’s Western Digital getting in on the action. Thankfully it’s research from NCC Group, demonstrated at Pwn2Own 2021, and fixed in a January update. This Remote Code Execution (RCE) vulnerability is in how the NAS handles the Apple Filing Protocol (AFP), and was actually a problem in the Netatalk project. AFP supports storing file metadata as a separate file, for the sake of compatibility. These files are in the AppleDouble format, are take the name of their parent file, prepended with a ._. The kicker is that these files can also be accessed using the Windows SMB protocol, allowing direct manipulation of the metadata file. The function that parses the metadata file does indeed detect a malformed data structure, and logs an error to that effect, but fails to fail — it goes ahead and processes the bad data.

This continue-on-error is the central flaw, but actually building an exploit required a data leak to defeat the address layout randomization in place on the device. A simpler first step was to write memory locations into the AppleDouble file, and use SMB access to read it. With the leaked address in hand, the full exploit was easy. This would be bad enough, but these devices ship with a “Public” share world-accessible over SMB and AFP. This configuration makes it a pre-auth RCE. And this demonstrates the purpose of Pwn2Own — it was discovered, made the researchers a bit of money, and was fixed before the details were made public.

Denial-of-Service (DoS) amplification. Relatively early in the history of the Internet — it was only 14 years old at the time — the first DoS amplification attack was discovered. [TFreak] put together smurf.c, likely in 1997, though it’s difficult to nail the date down precisely.

The first real DoS attack had only happened a year before, in 1996. Smurf worked by crafting ICMP packets with spoofed source addresses, and sending those packets to a network’s broadcast address. A host that received the request would send the packet to the target, and if multiple hosts responded, you got a bigger DoS attack for free. Fast forward to 1999, and the first botnet pulled off a Distributed DoS, DDoS, attack. Ever since then, there’s been an ongoing escalation of DDoS traffic size and the capability of mitigations.

DNS and NTP quickly became the popular choice for amplification, with NTP requests managing an amplification factor of 556, meaning that for every byte an attacker sent, the amplifying intermediary would send 556 bytes on to the victim. You may notice that so far, none of the vulnerable services use TCP. The three-way handshake of TCP generally prevents the sort of misdirection needed for an amplified attack. Put simply, you can’t effectively spoof your source address with TCP.

There are a pair of new games in town, with the first being a clever use of “middleboxes”, devices like firewalls, Intrusion Prevention Systems, and content filters. These devices watch traffic and filter content or potential attacks. The key here is that many such devices aren’t actually tracking TCP handshakes, it would be prohibitively memory and CPU intensive. Instead, most such devices just inspect as many packets as they can. This has the unexpected effect of defeating the built-in anti-spoofing of TCP.

An attacker can send a spoofed TCP packet, no handshake required, and a vulnerable middlebox will miss the fact that it’s spoofed. While that’s interesting in itself, what’s really notable is what happens when the packet appears to be a request for a vulnerable or blocked resource. The appliance tries to interrupt the stream, and inject an error message back to the requester. Since the requestor can be spoofed, this allows using these devices as DDoS amplifiers. As some of these services respond to a single packet with what is essentially an entire web page to convey the error, the amplification factor is literally off the charts. This research was published August 2021, and late February of this year, researchers at Akamai have seen DDoS attacks actually using this technique in the wild.

The second new technique is even more alien. Certain Mitel PBXs have a stress-test capability, essentially a speed test on steroids. It’s intended to only be used on an internal network, not an external target, but until a recent firmware update that wasn’t enforced. For nearly 3,000 of these devices, an attacker could send a single packet, and trigger the test against an arbitrary host. This attack, too, has recently been seen in the wild, though in what appears to be test runs. The stress test can last up to 14 hours at worst, leading to a maximum amplification factor if over four billion, measured in packets. The biggest problem is that phone systems like these a generally never touched unless there’s a problem, and there’s a decent chance that no one on site has the login credentials. That is to say, expect these to be vulnerable for a long time to come. Continue reading “This Week In Security: DDoS Techniques, Dirty Pipe, And Lapsus$ Continued” →