This Week In Security: Default Passwords, Lock Slapping, And Mastodown

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.


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.


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 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.

8 thoughts on “This Week In Security: Default Passwords, Lock Slapping, And Mastodown

  1. > Just a good smack in the right place uses the inertia of the locking pin to compress the springs and slip the shackle.

    “just” put another mechanism in the lock where when the shackle is lowered into the lock body it presses on a plunger which in turn frees a ratcheting(?) secondary locking pin which locks the primary locking pin in place.
    -> no more inertia shenanigans (or at least sequential “inertia” application required in two orthogonal directions).

    I’m sure there are locks with such a mechanism or something functionally similar.

  2. I don’t think the new UK law will help at all for the following reasons:
    1. The support lifetime for these devices is only 2-3 years however a lot of them (such as thermostats) are designed as fit and forget, I know people with (non smart) thermostats over 20 years old and i’m sure there’re people who know of older ones – what happens when the current generation reach this age?
    2. Feature regression leaving old products that you still need incompatible with new ones, the result being you need to keep the old one running.
    3. Non-UK imports that don’t comply with the law, In my experience the UK struggles to ensure complience with even basic electrical saftey laws of goods purchesed online.

  3. Password passing/failing cracklib rather than a policy, I’ve had experience with a system that did that. The users get tired quickly when there is no password policy other than it can’t be broken in x seconds. Maybe not a problem on a set once it password, but never you it on something a user has to regularly change.

      1. While this is the general consensus & policy, I would point out that it’s not all sunshine and roses either way. If you tell people that if they pick a good enough password they won’t need to change it, they will still probably pick something at the lowest complexity that passes the policy. But if it’s got decent complexity, they’ll put it on sticky notes under their screen or on unprotected documents saved to their devices because they are worried they’ll forget it. (Providing a company password manager on company devices with biometrics or hardware tokens and such can help a lot.) And no matter what, they’ll put the same password into every sign-up box on the internet for years until it’s been involved in a dozen data breaches and been phished multiple times.

        A brand new terrible password that hasn’t been associated with the person on any other system yet is at least able to hold off a handful of attempts. Say you have email, vpn, and probably some other company-specific services exposed to the internet. Also say that because of at least one user or one service, you have to support less secure auth methods or non-company devices. Maybe one of the services syncs passwords and has MFA, but doesn’t do a great job of alerting or logging what’s going on. Maybe it’s the kind where only a correct password will receive a MFA prompt, but disconnecting at that point mistakenly counts as a dropped connection instead of a failed auth attempt. Now any of the other services with poor MFA are the next weak point. Basically, changing passwords occasionally is a way to blindly approximate the situation where your detection works and you realize a change is needed, while also gradually ruling out the reuse of very old passwords that are already compromised in their entirety. It still sucks though.

  4. Regarding default passwords. Some devices are expected to work out of the box. I can live with a random password, that is part of the serial number sticker, when I buy a new 4 port switch.

  5. It turns out the “It’s FOSS” site – sitting behind cloudflare – had a cache timeout set to zero. So – the CDN wasn’t ever caching anything, per their setup. No idea if they’ve since corrected this, but a caching front-end works better if you turn it on. Just sayin.

  6. Obligatory passwords… hmmm….

    In the Cold War the US instituted another safety to the missile launch procedure called “Permissible Action Links” or PALs which depended on a password in order to authorize a missile launch. Well the password was left in ZEROS for 15 years by SAC partly for fear of losing the password and not finding it and part laziness.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.