This Week In Security: Footguns, Bing Worms, And Gogs

The world of security research is no stranger to the phenomenon of not-a-vulnerability. That’s where a security researcher finds something interesting, reports it to the project, and it turns out that it’s something other than a real security vulnerability. There are times that this just means a researcher got over-zealous on reporting, and didn’t really understand what was found. There is at least one other case, the footgun.

A footgun is a feature in a language, library, or tool that too easily leads to catastrophic mistake — shooting ones self in the foot. The main difference between a footgun and a vulnerability is that a footgun is intentional, and a vulnerability is not. That line is sometimes blurred, so an undocumented footgun could also be a vulnerability, and one possible solution is to properly document the quirk. But sometimes the footgun should really just be eliminated. And that’s what the article linked above is about. [Alex Leahu] takes a look at a handful of examples, which are not only educational, but also a good exercise in thinking through how to improve them.

Continue reading “This Week In Security: Footguns, Bing Worms, And Gogs”

This Week In Security: Hardware Attacks, IoT Security, And More

This week starts off with examinations of a couple hardware attacks that you might have considered impractical. Take a Ball Grid Array (BGA) NAND removal attack, for instance. The idea is that a NAND chip might contain useful information in the form of firmware or hard-coded secrets.

The question is whether a BGA desolder job puts this sort of approach out of the reach of most attackers. Now, this is Hackaday. We regularly cover how our readers do BGA solder jobs, so it should come as no surprise to us that less than two-hundred Euro worth of tools, and a little know-how and bravery, was all it took to extract this chip. Plop it onto a pogo-pin equipped reader, use some sketchy Windows software, and boom you’ve got firmware.

What exactly to do with that firmware access is a little less straightforward. If the firmware is unencrypted and there’s not a cryptographic signature, then you can just modify the firmware. Many devices include signature checking at boot, so that limits the attack to finding vulnerabilities and searching for embedded secrets. And then worst case, some platforms use entirely encrypted firmware. That means there’s another challenge, of either recovering the key, or finding a weakness in the encryption scheme. Continue reading “This Week In Security: Hardware Attacks, IoT Security, And More”

Nix + Automated Fuzz Testing Finds Bug In PDF Parser

[Michael Lynch]’s adventures in configuring Nix to automate fuzz testing is a lot of things all rolled into one. It’s not only a primer on fuzz testing (a method of finding bugs) but it’s also a how-to on automating the setup using Nix (which is a lot of things, including a kind of package manager) as well as useful info on effectively automating software processes.

[Michael] not only walks through how he got it all up and running in a simplified and usefully-portable way, but he actually found a buffer overflow in pdftotext in the process! (Turns out someone else had reported the same bug a few weeks before he found it, but it demonstrates everything regardless.)

[Michael] chose fuzz testing because using it to find security vulnerabilities is conceptually simple, actually doing it tends to require setting up a test environment with a complex workflow and a lot of dependencies. The result has a high degree of task specificity, and isn’t very portable or reusable. Nix allowed him to really simplify the process while also making it more adaptable. Be sure to check out part two, which goes into detail about how exactly one goes from discovering an input that crashes a program to tracking down (and patching) the reason it happened.

Making fuzz testing easier (and in a sense, cheaper) is something people have been interested in for a long time, even going so far as to see whether pressing a stack of single-board computers into service as dedicated fuzz testers made economic sense.

This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS

Steve Ballmer famously called Linux “viral”, with some not-entirely coherent complaints about the OS. In a hilarious instance of life imitating art, Windows machines are now getting attacked through malicious Linux VM images distributed through phishing emails.

This approach seems to be intended to fool any anti-malware software that may be running. The VM includes the chisel tool, described as “a fast TCP/UDP tunnel, transported over HTTP, secured via SSH”. Now that’s an interesting protocol stack. It’s an obvious advantage for an attacker to have a Linux VM right on a target network. As this sort of virtualization does require hardware virtualization, it might be worth disabling the virtualization extensions in BIOS if they aren’t needed on a particular machine.

AI Finds Real CVE

We’ve talked about some rather unfortunate use of AI, where aspiring security researchers asked an LLM to find vulnerabilities in a project like curl, and then completely wasted a maintainer’s time on those bogus reports. We happened to interview Daniel Stenberg on FLOSS Weekly this week, and after he recounted this story, we mused that there might be a real opportunity to use LLMs to find vulnerabilities, when used as a way to direct fuzzing, and when combined with a good test suite.

And now, we have Google Project Zero bringing news of their Big Sleep LLM project finding a real-world vulnerability in SQLite. This tool was previously called Project Naptime, and while it’s not strictly a fuzzer, it does share some similarities. The main one being that both tools take their educated guesses and run that data through the real program code, to positively verify that there is a problem. With this proof of concept demonstrated, it’s sure to be replicated. It seems inevitable that someone will next try to get an LLM to not only find the vulnerability, but also find an appropriate fix. Continue reading “This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS”

This Week In Security: Playing Tag, Hacking Cameras, And More

Wired has a fascinating story this week, about the length Sophos has gone to for the last 5 years, to track down a group of malicious but clever security researchers that were continually discovering vulnerabilities and then using those findings to attack real-world targets. Sophos believes this adversary to be overlapping Chinese groups known as APT31, APT41, and Volt Typhoon.

The story is actually refreshing in its honesty, with Sophos freely admitting that their products, and security products from multiple other vendors have been caught in the crosshairs of these attacks. And indeed, we’ve covered stories about these vulnerabilities over the past weeks and months right here on this column. The sneaky truth is that many of these security products actually have pretty severe security problems.

The issues at Sophos started with an infection of an informational computer at a subsidiary office. They believe this was an information gathering exercise, that was a precursor to the widespread campaign. That campaign used multiple 0-days to crack “tens of thousands of firewalls around the world”. Sophos rolled out fixes for those 0-days, and included just a bit of extra logging as an undocumented feature. That logging paid off, as Sophos’ team of researchers soon identified an early signal among the telemetry. This wasn’t merely the first device to be attacked, but was actually a test device used to develop the attack. The game was on. Continue reading “This Week In Security: Playing Tag, Hacking Cameras, And More”

Use PicoGlitcher For Voltage Glitching Attacks

We see a fair few glitcher projects, especially the simpler voltage glitchers. Still, quite often due to their relative simplicity, they’re little more than a microcontroller board and a few components hanging off some wires. PicoGlitcher by Hackaday.IO user [Matthias Kesenheimer] is a simple voltage glitcher which aims to make the hardware setup a little more robust without getting caught up in the complexities of other techniques. Based on the Raspberry Pico (obviously!), the board has sufficient niceties to simplify glitching attacks in various situations, providing controllable host power if required.

A pair of 74LVC8T245 (according to the provided BoM) level shifters allow connecting to targets at voltages from 1.8 V to 5 V if powered by PicoGlitcher or anything in spec for the ‘245 if target power is being used. In addition to the expected RESET and TRIGGER signals, spare GPIOs are brought out to a header for whatever purpose is needed to control a particular attack. If a programmed reset doesn’t get the job done, the target power is provided via a TPS2041 load switch to enable cold starts. The final part of the interface is an analog input provided by an SMA connector.

The glitching signal is also brought out to an SMA connector via a pair of transistors; an IRLML2502 NMOS performs ‘low power’ glitching by momentarily connecting the glitch output to ground. This ‘crowbarring’ causes a rapid dip in supply voltage and upsets the target, hopefully in a helpful way. An IRF7807 ‘NMOS device provides a higher power option, which can handle pulse loads of up to 66A. Which transistor you select in the Findus glitching toolchain depends on the type of load connected, particularly the amount of decoupling capacitance that needs to be discharged. For boards with heavier decoupling, use the beefy IRF7807 and accept the glitch won’t be as sharp as you’d like. For other hardware, the faster, smaller device is sufficient.

The software to drive PicoGlitcher and the hardware design files for KiCAD are provided on the project GitHub page. There also appears to be an Eagle project in there. You can’t have too much hardware documentation! For the software, check out the documentation for a quick overview of how it all works and some nice examples against some targets known to be susceptible to this type of attack.

For a cheap way to glitch an STM8, you can just use a pile of wires. But for something a bit more complicated, such as a Starlink user terminal, you need something a bit more robust. Finally, voltage glitching doesn’t always work, so the next tool you can reach for is a picoEMP.

Continue reading “Use PicoGlitcher For Voltage Glitching Attacks”

The Pound ( Or Euro, Or Dollar ) Can Still Be In Your Pocket

A British journalistic trope involves the phrase “The pound in your pocket”, a derisory reference to the 1960s Prime Minister Harold Wilson’s use of it to try to persuade the public that a proposed currency devaluation wouldn’t affect them. Nearly six decades later not so many Brits carry physical pounds in their pockets as electronic transfers have become more prevalent, but the currency remains. So much so that the governor of the Bank of England has had to reassure the world that the pound won’t be replaced by a proposed “Britcoin” cryptocurrency should that be introduced.

Normally matters of monetary policy aren’t within Hackaday’s remit, but since the UK is not the only country to mull over the idea of a tightly regulated cryptocurrency tied to their existing one, there’s a privacy angle to be considered while still steering clear of the fog of cryptocurrency enthusiasts. The problem is that reading the justification for the new digital pound from the Bank of England, it’s very difficult to see much it offers which isn’t already offered by existing cashless payment systems. Meanwhile it offers to them a blank regulatory sheet upon which they can write any new rules they want, and since that inevitably means some of those rules will affect digital privacy in a negative manner, it should be a worry to anyone whose government has considered the idea. Being at pains to tell us that we’ll still be able to see a picture of the King (or a dead President, or a set of bridges) on a bit of paper thus feels like an irrelevance as increasingly few of us handle banknotes much anyway these days. Perhaps that act in itself will now become more of an act of protest. And just when we’d persuaded our hackerspaces to go cashless, too.

Header: Wikitropia, CC BY-SA 3.0.