Author: Jonathan Bennett

526 Articles

This Week In Security: Browser In The Browser, Mass Typo-squatting, And /dev/random Upgrades

March 25, 2022 by 19 Comments

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.

An OAuth pop-up window

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.

Reliving Second-Hand Nostalgia With The PDP-11

March 19, 2022 by 31 Comments

Levy’s Hackers: Heroes of the Computer Revolution is something like required reading for the hacker subculture, and Hackaday by extension. The first section of that book is all about early hackers and their adventures with the PDP-1 at MIT. The PDP-11 has earned a special place in hacker history for being the minicomputer used to write the first Unix. We’re always amazed to find how many of our readers have stories about programming PDP microcomputers, usually the PDP-11. Those of us young enough to have missed out on the PDP experience often have something of a second-hand nostalgia for the old machines. An exceptionally detailed article over at Ars Technica promises to get us started reliving the glory days, even if it is for the first time.

It turns out that there’s an emulator for the old minicomputers, the History Simulator, abbreviated SimH. The article gives step-by-step instructions to get the emulator running, booting Unix 2.11 on a virtual PDP-11. The fun doesn’t stop there. The write-up includes an intro the the PDP-11 hardware, and a crash-course to assembly programming for the beast. It’s a great look at how the stack, branching, and subroutines work under the hood. Most of it still applies to computing today, so it really is worth the read.

Looking for more PDP-11 lore? Check out our coverage of DEC’s history.

The image above is “PDP-11” by ToastyKen, and is licensed under CC BY 2.0

This Week In Security: More Protestware, Another Linux Vuln, And TLStorm

March 18, 2022 by 13 Comments

It seems I have made my tiny, indelible mark on internet security history, with the term “protestware“. As far as I can tell, I first coined this particular flavor of malware while covering the Faker.js/Colors.js vandalism in January.

Yet another developer, [RIAEvangelist] has inserted some malicious code (Mirror, since the complaint has been deleted) in an existing project, in protest of something, in this case the war in Ukraine. The behavior here is to write a nice note on the desktop, preaching “peace not war”. However, a few versions of this sample have a nasty surprise — it does a GeoIP lookup, and attempts to wipe the entire drive if it detects a Russian location. Yes, node-ipc versions 10.1.1 and 10.1.2 contain straight-up malware. It’s not clear how many users ran the potentially malicious code, as it was quickly reverted and released 10.1.3. Up-to-date versions of node-ipc still create the desktop file, and Unity Hub has already confirmed they shipped the library in this state, and have since issued a hotfix.
Continue reading “This Week In Security: More Protestware, Another Linux Vuln, And TLStorm” →

This Week In Security: DDoS Techniques, Dirty Pipe, And Lapsus$ Continued

March 11, 2022 by 26 Comments

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

This Week In Security: Ukraine, Nvidia, And Conti

March 4, 2022 by 11 Comments

The geopolitics surrounding the invasion of Ukraine are outside the scope of this column, but the cybersecurity ramifications are certainly fitting fodder. The challenge here is that almost everything of note that has happened in the last week has been initially linked to the conflict, but in several cases, the reported link hasn’t withstood scrutiny. We do know that the Vice Prime Minister of Ukraine put out a call on Twitter for “cyber specialists” to go after a list of Russian businesses and state agencies. Many of the sites on the list did go down for some time, the digital equivalent of tearing down a poster. In response, the largest Russian ISP stopped announcing BGP routes to some of the targeted sites, effectively ending any attacks against them from the outside.

A smattering of similar events have unfolded over the last week, like electric car charging stations in Russia refusing to charge, and displaying a political message, “GLORY TO UKRAINE”. Not all the attacks have been so trivial. Researchers at Eset have identified HermeticWiper, a bit of malware with no other purpose but to destroy data. It has been found on hundreds of high-value targets, likely causing much damage. It is likely the same malware that Microsoft has dubbed FoxBlade, and published details about their response. Continue reading “This Week In Security: Ukraine, Nvidia, And Conti” →

This Week In Security: Updraft, Termux, And Magento

February 25, 2022 by 7 Comments

One of the most popular WordPress backup plugins, UpdraftPlus, has released a set of updates, x.22.3, that contain a potentially important fix for CVE-2022-23303. This vulnerability exposes existing backups to any logged-in WordPress user. This bug was found by the guys at Jetpack, who have a nice write-up on it. It’s a combination of instances of a common problem — endpoints that lacked proper authentication. The heartbeat function allows any user to access it, and it returns the latest backup nonce.

A cryptographic nonce is a value that’s not exactly a cryptographic secret, but is only used once. In some cases, this is to mitigate replay attacks, or is used as an initialization vector. In the case of UpdraftPlus, the nonce works as a unique identifiers for individual backups. The data leak can be combined with another weak validation in the maybe_download_backup_from_email() function, to allow downloading of a backup. As WordPress backups will contain sensitive information, this is quite the problem. There are no known in-the-wild instances of this attack being used, but as always, update now to stay ahead of the game.

Continue reading “This Week In Security: Updraft, Termux, And Magento” →

This Week In Security: Chrome 0-day,Cassandra, And A Cisco PoC

February 18, 2022 by 7 Comments

Running Chrome or a Chromium-based browser? Check for version 98.0.4758.102, and update if you’re not running that release or better. Quick tip, use chrome://restart to trigger an immediate restart of Chrome, just like the one that comes after an update. This is super useful especially after installing an update on Linux, using apt, dnf, or the like.

CVE-2022-0609 is the big vulnerability just patched, and Google has acknowledged that it’s being exploited in the wild. It’s a use-after-free bug, meaning that the application marks a section of memory as returned to the OS, but then accesses that now-invalid memory address. The time gap between freeing and erroneously re-using the memory allows malicious code to claim that memory as its own, and write something unexpected.

Google has learned their lesson about making too many details public too early, and this CVE and associated bug aren’t easily found in in the Chromium project’s source, and there doesn’t seem to be an exploit published in the Chromium code testing suite. Continue reading “This Week In Security: Chrome 0-day,Cassandra, And A Cisco PoC” →