To the left, a breadboard with the ATMega328P being attacked. To the right, the project's display showing multiple ;) smiley faces, indicating that the attack has completed successfully.

Glitching An ATMega328P Has Never Been Simpler

Did you know just how easily you can glitch microcontrollers? It’s so easy, you really have no excuse for not having tried it out yet. Look, [lord feistel] is doing glitching attacks on an ATMega328P! All you need is an Arduino board with its few SMD capacitors removed or a bare 328P chip, a FET, and some sort of MCU to drive it. All of these are extremely generic components, and you can quickly breadboard them, following [lord feistel]’s guide on GitHub.

In the proof-of-concept, you can connect a HD44780 display to the chip, and have the victim MCU output digits onto the display in an infinite loop. Inside of the loop is a command to output a smiley face – but the command is never reachable, because the counter is reset in an if right before it. By glitching the ATMega’s power input, you can skip the if and witness the ;) on your display; it is that simple.

What are you waiting for? Breadboard it up and see for yourself, this might be the method that you hack your next device and make it do your bidding. If the FET-and-MCU glitching starts to fail you at some point, there’s fancier tools you can use, like the ChipWhisperer. As for practical examples, [scanlime]’s elegant glitching-powered firmware hack is hard to forget.

This Week In Security: Operation Endgame, Appliance Carnage, And Router Genocide

This week saw an impressive pair of takedowns pulled off by law enforcement agencies around the world. The first was the 911 S5 botnet, Which the FBI is calling “likely the world’s largest botnet ever”. Spreading via fake free VPN services, 911 was actually a massive proxy service for crooks. Most lately, this service was operating under the name “Cloud Router”. As of this week, the service is down, the web domain has been seized, and the alleged mastermind, YunHe Wang, is in custody.

The other takedown is interesting in its own right. Operation Endgame seems to be psychological warfare as well as actual arrests and seizures. The website features animated shorts, a big red countdown clock, and a promise that more is coming. The actual target was the ring that manage malware droppers — sort of middlemen between initial shellcode, and doing something useful with a compromised machine. This initial volley includes four arrests, 100+ servers disrupted, and 2,000+ domains seized.

The arrests happened in Armenia and Ukraine. The messaging around this really seems to be aimed at the rest of the gang that’s out of reach of law enforcement for now. Those criminals may still be anonymous, or operating in places like Russia and China. The unmistakable message is that this operation is coming for the rest of them sooner or later. Continue reading “This Week In Security: Operation Endgame, Appliance Carnage, And Router Genocide”

This Week In Security: Drama At The C-Level, Escape Injection, And Audits

There was something of a mystery this week, with the c.root-servers.net root DNS server falling out of sync with it’s 12 siblings. That’s odd in itself, as these are the 13 servers that keep DNS working for the whole Internet. And yes, that’s a bit of a simplification, it’s not a single server for any of the 13 entities — the C “server” is actually 12 different machines. The intent is for all those hundreds of servers around the world to serve the same DNS information, but over several days this week, the “C” servers just stopped pulling updates.

The most amusing/worrying part of this story is how long it took for the problem to be discovered and addressed. One researcher cracked a ha-ha-only-serious sort of joke, that he had reported the problem to Cogent, the owners of the “C” servers, but they didn’t “seem to understand that they manage a root server”. The problem first started on Saturday, and wasn’t noticed til Tuesday, when the servers were behind by three days. Updates started trickling late Tuesday or early Wednesday, and by the end of Wednesday, the servers were back in sync.

Cogent gave a statement that an “unrelated routing policy change” both affected the zone updates, and the system that should have alerted them to the problem. It seems there might room for an independent organization, monitoring some of this critical Internet Infrastructure.

Continue reading “This Week In Security: Drama At The C-Level, Escape Injection, And Audits”

FLOSS Weekly Episode 784: I’ll Buy You A Poutine

This week Jonathan Bennett and Dan Lynch talk with François Proulx about Poutine, the Open Source security scanner for build pipeline vulnerabilities. This class of vulnerability isn’t as well known as it should be, and threatens to steal secrets, or even allow for supply chain attacks in FLOSS software.

Poutine does a scan over an organization or individual repository, looking specifically for pipeline issues. It runs on both GitHub and GitLab, with more to come!

Continue reading “FLOSS Weekly Episode 784: I’ll Buy You A Poutine”

This Week In Security: The Time Kernel.org Was Backdoored And Other Stories

Researchers at Eset have published a huge report on the Ebury malware/botnet (pdf), and one of the high profile targets of this campaign was part of the kernel.org infrastructure. So on one hand, this isn’t new news, as the initial infection happened back in 2011, and was reported then. On the other hand, according to the new Eset report, four kernel.org servers were infected, with two of them possibly compromised for as long as two years. That compromise apparently included credential stealing or password cracking.

The Ebury attackers seem to gain initial access through credential stuffing — a huge list of previously captured credentials are tried one at a time. However, once the malware has a foothold in the network, a combination of automated and manual steps are taken to move laterally. The most obvious is to grab any private SSH keys from that system, and try using them to access other machines on the local network. Ebury also replaces a system library that gets called as a part of sshd, libkeyutils.so. This puts it in a position to quietly capture credentials.

For a targeted attack against a more important target, the people behind Ebury seem to go hands-on-keyboard, using techniques like Man-in-the-Middle attacks against SSH logins on the local network using ARP spoofing. In this case, someone was doing something nasty.

And that doesn’t even start to cover the actual payload. That’s nasty too, hooking into Apache to sniff for usernames and passwords in HTTP/S traffic, redirecting links to malicious sites, and more. And of course, the boring things you might expect, like sending spam, mining for Bitcoin, etc. Ebury isn’t exactly easy to notice, either, since it includes a rootkit module that hooks into system functions to hide itself. Thankfully there are a couple of ways to get a clean shell to look for the malware, like using systemd-run or launching a local shell on the system console.

And the multi-million dollar question: Who was behind this? Sadly we don’t know. A single arrest was made in 2014, and recovered files implicated another Russian citizen, but the latest work indicates this was yet another stolen identity. The rest of the actors behind Ebury have gone to great lengths to remain behind the curtain.

Continue reading “This Week In Security: The Time Kernel.org Was Backdoored And Other Stories”

This Week In Security: TunnelVision, Scarecrows, And Poutine

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine”

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.

Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown”