This Week in Security: Default Passwords, Lock Slapping, and Mastodown

Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead in /home/u333346598/domains/thebulletin.tech/public_html/wp-content/plugins/insert-headers-and-footers/includes/class-wpcode-snippet-execute.php(411) : eval()'d code on line 18

Estimated reading time: 8 minutes

• Lock Vulnerabilities
• Fuzzing!
• Fuzzing the Kernel
• Water Hacking
• Windows Registry Continued
• Mastodown
• Bits and Bytes
• About The Author

The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.

I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.

What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.

So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.

Lock Vulnerabilities

Vulnerabilities and bypasses aren’t unique to software. They are, however, much harder to patch in hardware. Take for instance, the Mul-T-Lock SBNE12 padlock. This lock really looks like it was carefully made to be secure. If you’re not familiar with [LockPickingLawyer]’s videos, the two minutes it takes him to pick this lock is a ringing endorsement. However, the lock does have a weakness, and LPL challenges us to figure it out. I’ll give you a hint, that the problem can be seen during the lock teardown at 2:25. See below the video for the explanation.

The problem here is demonstrated by [Trevor], AKA @McNallyOfficial. It’s the springs. The retainer pin is also the lock pin, and that pin is held in place by a pair of springs. The lock is probably designed such that you can lock the shackle without the key, and that means that there is enough play in those springs to slip the pin over the locking lip. Just a good smack in the right place uses the inertia of the locking pin to compress the springs and slip the shackle. It’s a bit disconcerting how many locks can be opened this way.

Fuzzing!

First up we have a walk-through to setting up a function fuzzing run with American Fuzzy Loop (AFL). First let’s cover *why* you might want to do this. We’re looking for vulnerabilities, and the scenario [Craig Young] lays out is one where we have a binary listening for HTTP calls on port 8080, and using some internal code to parse the request bodies. We want to throw a bunch of weird data at that parser to see how it breaks, and using real HTTP requests is way too slow when compared to direct function calls.

AFL is quite clever about its approach, particularly when you run it with “instrumentation”, or injected code that tracks what target code is being run in response to the AFL input. This allows AFL to track what fuzzing input resulted in exercising new target code paths. (It did something new, make a note!) That only works when re-compiling a program from source. The approach to use with a pre-compiled binary is to run it under QEMU so AFL can spy on execution. And in this case, that executable into a shared library to get to the target function directly.

To make that bit of magic work, the Library to Instrument Executable Files (LIEF) is used. When given the function address, this spits out a cooked shared object .so file. The actual harness is a bit of trivial code to call into that function and capture the output. And with that, you can start throwing interesting fuzz data at compiled code.

Fuzzing the Kernel

The Linux kernel has support for NVMe-oF, or Non-Volatile Memory express over Fabric, a high speed data storage link that can run over fiber, Ethernet, or simple TCP. That TCP support is interesting, as it means the kernel itself is opening INET sockets directly, which is why [Alon Zahavi] found it a juicy target for finding vulnerabilities. Because we’re talking the kernel, we can’t just trivially connect AFL like above. Thankfully there’s a fuzzer that’s written specifically for kernel fuzzing: syzkaller.

This one is a bit more complicated, and code has to be added for each subsystem that is supported. But NVME-oF is a supported module. The kernel also has the KCOV subsystem, for collecting coverage data during a run. It took quite a bit of work to add all the necessary bits, but [Alon] but the time in, and came up with 5 nice bug finds in the targeted code. Nice!

Water Hacking

We’ve looked at reported hacks against water treatment plants in the past, and so far there has been lots of splash, and very little substance. That hasn’t kept government agencies from beating the proverbial wardrum about attacks. That said, there is a lot of room for improvement in how these critical systems are secured. Apparently there was one actual breach that caused a tank to overflow, and a second attempt, where 37,000 credential were stuffed into a public-facing firewall over a span of about four days. If our critical systems actually have Internet-facing login pages, then something has truly gone wrong in a fundamental way.

Windows Registry Continued

The ongoing dive into the Windows registry continues over at Google Project Zero. This time with a blast from the past: The registry as it was in Windows 3.1. Way back then it was strictly for file type handling and OLE and COM object handling. Then Windows NT came along with NT 3.1, and started stuffing more and more setting data into the registry. Today, we’re at a crazy 100,000 lines of registry code in the Windows kernel. It’s no wonder this struck Project Zero as a good place to look for Windows vulnerabilities.

Mastodown

We got a bit of a chuckle out of this one, as the folks at It’s FOSS are asking readers not to share links to itsfoss.com stories on Mastodon. Why? Because apparently posting a link to Mastodon triggers a micro-DDOS, as each of the federated Mastodon instances pull a copy of the linked site, to generate a preview. The Mastodon code currently uses a random delay of up to 60 seconds to mitigate the issue. But for some sites that’s just not enough, and the traffic spike from multiple servers pulling a preview copy can be enough to take the site temporarily offline.

A bit of research was done back in 2022, which found that a moderately well-connected Mastodon server would generate just shy of 400 page loads per minute, when a link was shared. It’s likely those numbers are higher now, but still unlikely to be the sort of volume that a post going viral on a link aggregator would generate. Put another way, this seems to be a smaller problem than the classic “Slashdot Effect”.

So on one hand, it would be nice if the Mastodon project could puzzle out a way to keep every federated server from having to pull an independent copy of the site just to generate a preview. But on the other hand, a site that is actively trying to attract attention and visitors needs to be big enough to handle this level of traffic. But for now, at least for “It’s FOSS”, if you want to post a link to Mastodon, please Mastodon’t.

[Editor’s note: Hackaday has a pretty robust CDN. Toot away!]

Bits and Bytes

Hopefully you’re aware that there are malicious images on Docker Hub. Some images mine cryptocurrency in the background, while others try to steal credentials. Researchers at Jfrog have found a class of repositories that plant malicious links in their descriptions. From phishing, to malware, to straight up spam, these repositories are a real pain, and make up nearly 20% of the Docker Hub library. That apparently doesn’t even include the cryptocurrency miners. Oof. It’s probably a good idea to stick to the “Trusted Content” section of Docker Hub.

Nettitude Labs got their hands on a Cisco C195 email security appliance, and went through the steps to make it fully their own. That includes BIOS modification to run arbitrary code, finding a command injection attack in the Cisco firmware, building a full exploit, and finally running Doom on the box. It’s an epic hack and a great write-up.

And finally, HPE Aruba has published fixes for four critical vulnerabilities that allow unauthorized attackers to execute arbitrary code on affected devices. In a refreshing turn of events, these aren’t being used in-the-wild, and there hasn’t been any public Proof-of-concept code published yet. The HPE advisory has a few more details. As always, expect these to eventually get exploited in the wild.

About The Author