This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching

April 4, 2025 by Jonathan Bennett 2 Comments

We know a bit more about the GitHub Actions supply chain attack from last month. Palo Alto’s Unit 42 has been leading the charge on untangling this attack, and they’ve just released an update to their coverage. The conclusion is that Coinbase was the initial target of the attack, with the open source agentkit package first (unsuccessfully) attacked. This attack chain started with pull_request_target in the spotbugs/sonar-findbugs repository.

The pull_request_target hook is exceptionally useful in dealing with pull requests for a GitHub repository. The workflow here is that the project defines a set of Continuous Integration (CI) tests in the repository, and when someone opens a new Pull Request (PR), those CI tests run automatically. Now there’s an obvious potential problem, and Github thought of it and fixed it a long time ago. The GitHub Actions are defined right in the repository, and letting any pull request run arbitrary actions is a recipe for disaster. So GitHub always uses actions as they are defined in the repository itself, ignoring any incoming changes in the PR. So pull_request_target is safe now, right? Yes, with some really big caveats.

The simplest security problem is that many projects have build scripts in the repository, and those are not considered part of GitHub Actions by GitHub. So include malicious code in such a build script, make it a PR that runs automatically, and you have access to internal elements like organization and repository secrets and access tokens. The most effective mitigation against this is to require approval before running workflows on incoming PRs.

So back to the story. The spotbugs/sonar-findbugs repository had this vulnerability, and an attacker used it to export secrets from a GitHub Actions run. One of those secrets happened to be a Personal Access Token (PAT) belonging to a spotbugs maintainer. That PAT was used to invite a throwaway account, [jurkaofavak], into the main spotbugs repository. Two minutes after being added, the [jurkaofavak] account created a new branch in spotbugs/spotbugs, and deleted it about a second later. This branch triggered yet another malicious CI run, now with arbitrary Github Actions access rather than just access through a build script. This run leaked yet another Personal Access Token, belonging to a maintainer that worked on both the spotbugs and reviewdog projects. Continue reading “This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching” →

MIT Wants You To Secure Your Hardware Designs

April 3, 2025 by Al Williams 9 Comments

When you think of attacking or defending computer systems, you probably think of software viruses and the corresponding anti-virus software. But MIT’s 6.5950 class teaches secure hardware design — how to attack and defend CPUs from bad actors. Interested? The course is open source, so you can follow along as long as you don’t mind not getting a grade.

Browsing some of the lecture slides shows that the material isn’t as stuffy as you might imagine. A slide about side channel attacks, for example, features an article called “And Bomb the Anchovies,” which says that Washington DC pizza places know when big news is about to break because pizza delivery to places like the White House or the Pentagon trend upward (something spies call pizza-int, by the way).

Even if you don’t have a burning desire to design more secure hardware, some of the lecture slides make for an interesting flip through on a rainy weekend day. For example, the charts about RowHammer (“RowHammer in One Sentence”) is a great explanation about how software can cause DRAM failures to attack a computer. We only wished they’d identified companies A, B, and C in their study. There are also labs and they politely clarify what setup you need to do each lab (typically, just a Linux server, although some you can do with just a browser).

One of the great things about the Internet is that you can virtually audit classes from anywhere in the world, often for free. MIT is always up to something interesting.

Automatically Crack Safes With This Autodialer

March 30, 2025 by Bryan Cockfield 13 Comments

When attempting to secure something, whether it’s a computer, sensitive data, or valuables, there’s always going to be a way to break that security. It might be impossibly hard, like taking centuries to brute-force an encryption algorithm, but it’s weakness is still there. And, like the future might make certain encryption obsolete, modern electronics has made security of the past somewhat obsolete as well. [Startup Chuck] has been using tools the creators of safes from the late 1800s could probably not have imagined.

The tool that [Startup Chuck] has come up with is known as an autodialer in the safe-cracking world, and as its name suggests it automates the process of opening the safe by trying as many combinations as possible. The autodialer attaches to the safe with three magnetic feet and couples to the dial through a chuck attached to a magnetic clutch, which allows the autodialer to disengage as soon as the correct combination is found. It’s driven with a stepper motor which can test out combinations so fast that [Startup Chuck] needed to take 240 fps video and slow it down to make sure that the mechanism was behaving properly.

The autodialer itself can’t actually open the safe, though. The last step of the process is taken care of by a bungie cord, attached to the safe handle to pre-tension it enough so that when the correct combination is finally entered the safe pops open automatically. For anyone looking to duplicate the project, [Startup Chuck] has added the program code to a GitHub page. If you’re looking at a more modern safe, though, there are of course ways to crack their security systems as well.

Continue reading “Automatically Crack Safes With This Autodialer” →

This Week In Security: IngressNightmare, NextJS, And Leaking DNA

March 28, 2025 by Jonathan Bennett 9 Comments

This week, researchers from Wiz Research released a series of vulnerabilities in the Kubernetes Ingress NGINX Controller that, when chained together, allow an unauthorized attacker to completely take over the cluster. This attack chain is known as IngressNightmare, and it affected over 6500+ Kubernetes installs on the public Internet.

The background here is that web applications running on Kubernetes need some way for outside traffic to actually get routed into the cluster. One of the popular solutions for this is the Ingress NGINX Controller. When running properly, it takes incoming web requests and routes them to the correct place in the Kubernetes pod.

When a new configuration is requested by the Kubernetes API server, the Ingress Controller takes the Kubernetes Ingress objects, which is a standard way to define Kubernetes endpoints, and converts it to an NGINX config. Part of this process is the admission controller, which runs nginx -t on that NGINX config, to test it before actually deploying.

As you might have gathered, there are problems. The first is that the admission controller is just a web endpoint without authentication. It’s usually available from anywhere inside the Kubernetes cluster, and in the worst case scenario, is accessible directly from the open Internet. That’s already not great, but the Ingress Controller also had multiple vulnerabilities allowing raw NGINX config statements to be passed through into the config to be tested. Continue reading “This Week In Security: IngressNightmare, NextJS, And Leaking DNA” →

This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon

March 21, 2025 by Jonathan Bennett 4 Comments

Last Friday Github saw a supply chain attack hidden in a popular Github Action. To understand this, we have to quickly cover Continuous Integration (CI) and Github Actions. CI essentially means automatic builds of a project. Time to make a release? CI run. A commit was pushed? CI run. For some projects, even pull requests trigger a CI run. It’s particularly handy when the project has a test suite that can be run inside the CI process.

Doing automated builds may sound straightforward, but the process includes checking out code, installing build dependencies, doing a build, determining if the build succeeded, and then uploading the results somewhere useful. Sometimes this even includes making commits to the repo itself, to increment a version number for instance. For each step there are different approaches and interesting quirks for every project. Github handles this by maintaining a marketplace of “actions”, many of which are community maintained. Those are reusable code snippets that handle many CI processes with just a few options.

One other element to understand is “secrets”. If a project release process ends with uploading to an AWS store, the process needs an access key. Github stores those secrets securely, and makes them available in Github Actions. Between the ability to make changes to the project itself, and the potential for leaking secrets, it suddenly becomes clear why it’s very important not to let untrusted code run inside the context of a Github Action.

And this brings us to what happened last Friday. One of those community maintained actions, tj-actions/changed-files, was modified to pull an obfuscated Python script and run it. That code dumps the memory of the Github runner process, looks for anything there tagged with isSecret, and writes those values out to the log. The log, that coincidentally, is world readable for public repositories, so printing secrets to the log exposes them for anyone that knows where to look.

Researchers at StepSecurity have been covering this, and have a simple search string to use: org:changeme tj-actions/changed-files Action. That just looks for any mention of the compromised action. It’s unclear whether the compromised action was embedded in any other popular actions. The recommendation is to search recent Github Action logs for any mention of changed-files, and start rotating secrets if present. Continue reading “This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon” →

Spy Tech: Build Your Own Laser Eavesdropper

March 18, 2025 by Heidi Ulrich 33 Comments

Laser microphones have been around since the Cold War. Back in those days, they were a favorite tool of the KGB – allowing spies to listen in on what was being said in a room from a safe distance. This project by [SomethingAbtScience] resurrects that concept with a DIY build that any hacker worth their soldering iron can whip up on a modest budget. And let’s face it, few things are cooler than turning a distant window into a microphone.

At its core this hack shines a laser on a window, detects the reflected light, and picks up subtle vibrations caused by conversations inside the room. [SomethingAbtScience] uses an ordinary red laser (visible, because YouTube rules) and repurposes an amplifier circuit ripped from an old mic, swapping the capsule for a photodiode. The build is elegant in its simplicity, but what really makes it shine is the attention to detail: adding a polarizing filter to cut ambient noise and 3D printing a stabilized sensor mount. The output is still a bit noisy, but with some fine tuning – and perhaps a second sensor for differential analysis – there’s potential for crystal-clear audio reconstruction. Just don’t expect it to pass MI6 quality control.

While you probably won’t be spying on diplomats anytime soon, this project is a fascinating glimpse into a bygone era of physical surveillance. It’s also a reminder of how much can be accomplished with a laser pointer, some ingenuity, and the curiosity to see how far a signal can travel.

Continue reading “Spy Tech: Build Your Own Laser Eavesdropper” →

Add WebUSB Support To Firefox With A Special USB Device

March 15, 2025 by Maya Posch 7 Comments

RP2040-based Pico board acting as U2F dongle with Firefox. (Credit: ArcaneNibble, GitHub)

The WebUSB standard is certainly controversial. Many consider it a security risk, and, to date, only Chromium-based browsers support it. But there is a workaround that is, ironically, supposed to increase security. The adjacent Universal 2nd Factor (U2F) standard also adds (limited) USB support to browsers. Sure, this is meant solely to support U2F USB dongles for two-factor authentication purposes, but as [ArcaneNibble] demonstrates using U2F-compatible firmware on a Raspberry Pi RP2040, by hijacking the U2F payload, this API can be used to provide WebUSB-like functionality.

Continue reading “Add WebUSB Support To Firefox With A Special USB Device” →