Supercon 2023: Alex Lynd Explores MCUs In Infosec

The average Hackaday reader hardly needs to be reminded of the incredible potential of the modern microcontroller. While the Arduino was certainly transformative when it hit the scene, those early 8-bit MCUs were nothing compared to what’s on the market now. Multiple cores with clock speeds measured in the hundreds of megahertz, several MB of flash storage, and of course integrated WiFi capability mean today’s chips are much closer to being fully-fledged computers than their predecessors.

It’s not hard to see the impact this has had on the electronics hobby. In the early 2000s, getting your hardware project connected to the Internet was a major accomplishment that probably involved bringing some hacked home router along for the ride. But today, most would consider something like an Internet-connected remote environmental monitor to be a good starter project. Just plug in a couple I2C sensors, write a few lines of Python, and you’ve got live data pouring into a web interface that you can view on your mobile device — all for just a few bucks worth of hardware.

But just because we’re keenly aware of the benefits and capabilities of microcontrollers like the ESP32 or the Pi Pico, doesn’t mean they’ve made the same impact in other tech circles. In his talk Wireless Hacking on a $5 Budget, Alex Lynd goes over some examples of how he’s personally put these devices to work as part of his information security (infosec) research.

Continue reading “Supercon 2023: Alex Lynd Explores MCUs In Infosec”

This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto”

This Week In Security: BatBadBut, DLink, And Your TV Too

So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.

When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.

And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.

Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”

USB HID And Run Exposes Yet Another BadUSB Surface

You might think you understand the concept of BadUSB attacks and know how to defend it, because all you’ve seen is opening a terminal window. Turns out there’s still more attack surface to cover, as [piraija] tells us in their USB-HID-and-run publication. If your system doesn’t do scrupulous HID device filtering, you might just be vulnerable to a kind of BadUSB attack you haven’t seen yet, rumoured to have been the pathway a few ATMs got hacked – simply closing the usual BadUSB routes won’t do.

The culprit is the Consumer Control specification – an obscure part of HID standard that defines media buttons, specifically, the “launch browser” and “open calculator” kinds of buttons you see on some keyboards, that operating systems, surprisingly, tend to support. If the underlying OS you’re using for kiosk purposes isn’t configured to ignore these buttons, they provide any attacker with unexpected pathways to bypass your kiosk environment, and it works astonishingly well.

[piraija] tells us that this attack provides us with plenty of opportunities, having tested it on a number of devices in the wild. For your own tests, the writeup has Arduino example code you can upload onto any USB-enabled microcontroller, and for better equipped hackers out there, we’re even getting a Flipper Zero application you can employ instead. While we’ve seen some doubts that USB devices can be a proper attack vector, modern operating systems are more complex and bloated than even meets the eye, often for hardly any reason – for example, if you’re on Windows 10 or 11, press Ctrl+Shift+Alt+Win+L and behold. And, of course, you can make a hostile USB implant small enough that you can build them into a charger or a USB-C dock.

USB image: Inductiveload, Public domain.

The printer's display with the exploit-loaded animation playing, saying "hacked by blasty" and a bunch more stuff

A Fun Exploit For Canon Printers Brings GDB Gifts

Modern printers make it all that much more tempting to try and hack them — the hardware generally tends to be decent, but the firmware appears to be designed to squeeze as much money out of you as possible while keeping your annoyance level consistently high. That’s why it’s nice to see this exploit of the Canon imageCLASS MF74XCdw series (MF742Cdw/MF743Cdw) by [blasty], triggerable over a network connection, with a story for our amusement.

In this post, we get a tale of how this hack came out of a Pwn2Own Toronto challenge, notes on the hardware involved, and we’re shown the journey to a successful hack. The Canon printer OS is built without many of the protections, which makes playing with it easier than with more modernized targets, but it’s nevertheless not straightforward. Still, exploiting a couple things like the SOAP XML implementation and the UTF8 encoder nets you an ability to play nice animations on the display, and most certainly, control over the entirety of the hardware if you wanted it.

One of the most fun things about this hack is the GDB stub recently included in the repo. If you wanted to debug Canon printers for fun or profit, [blasty] brings you a GDB stub to do that comfortably, with a respectable README that even has porting notes for other Canon ImageCLASS printer models, should you lay your hands on a different machine of despair. WiFi connectivity appears to be enough for this hack, so you better make sure you don’t have your network-connected printers exposed on the Internet — not that you needed more reasons to avoid that.

Three ZigBee radios in ESD bags, marked "Zigbee Sniffer", "Router" and "Coordinator".

Crash IoT Devices Through Protocol Fuzzing

IoT protocols are a relatively unexplored field compared to most PC-exposed protocols – it’s bothersome to need a whole radio setup before you can tinker on something, and often, for low-level experiments, just any radio won’t do. This means there’s quite a bit of security ground to cover. Now, the U-Fuzz toolkit from [asset-group] helps us make up for it.

Unlike fuzzers you might imagine, U-Fuzz doesn’t go in blindly. This toolkit has provisions to parse protocols and fuzz fields meaningfully, which helps because many of devices will discard packets they deem too malformed. With U-Fuzz, you feed it a couple packet captures, help it make some conclusions about packet and protocol structure, and get suggestions on how to crash your devices in ways not yet foreseen.

This allows for basically arbitrary protocol fuzzing, and to demonstrate, we get examples on 5G, CoAP and ZigBee probing alike, with a list of found CVEs to wrap the README up. As Wikipedia often states, this list is incomplete, and you can help by expanding it. Fuzzing is an underestimated tool – it will help you hack ubiquitous wireless protocols, proprietary standards, and smart home hubs alike.

Flipper Zero Panic Spreads To Oz: Cars Unaffected

A feature of coming to adulthood for any young person in the last quarter of the twentieth century would have been the yearly warnings about the danger of adulterated Halloween treats. Stories were breathlessly repeated of apples with razor blades in them, or of chocolate bars laced with rat poison, and though such tales often carried examples of kids who’d died horrible deaths in other far-away places, the whole panic was (as far as we know) a baseless urban legend.

It’s difficult not to be reminded of those times today then, as we read news from Australia warning about the threat from the Flipper Zero wireless hacking tool. It has the same ingredients, of an imaginary threat earnestly repeated by law enforcement officers, and lapped up by a credulous media with little appetite for verifying what they print.

This is a story which first appeared in mid-February in Canada, when a government minister singled out the Flipper Zero as a car theft tool and promised to ban it. This prompted a storm of derision from tech-savvy Canadians and others who immediately pointed out that vehicle security has long ago eclipsed the capabilities of the Flipper, and that there are far more pertinent threats such as those from CAN bus attacks or even RF boosters. Despite this debunking, it seems to have spread. Where will Flipper Mania pop up next?

Canada and Australia are both countries with a free press; that press should be doing their job on these stories by fact-checking and asking pertinent questions when the facts don’t fit the story. When it comes to technology stories it seems not doing this has become the norm.

Thanks [Peter Caldwell] for the tip.