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.

That token had access to create and edit tags in reviewdog/action-setup, a GitHub Action that runs as a dependency for multiple other actions. The attacker created a fork of this repository, added malicious code, and then overwrote the v1 git tag to point to this malicious code. The tj-actions/changed-files ran a CI flow that made use of the malicious reviewdog/action-setup fork, leaking a GitHub token with write permission to tj-actions/changed-files.

The tag override trick does a lot of heavy lifting in this story, and that’s what was used on tj-actions/changed-files too. Another malicious fork, and a specific tag was overridden to point there. The tag chosen was one used in a Coinbase repository. Specifically coinbase/agentkit used the newly malicious tag in one of its workflows. A Coinbase maintainer discovered this, and deleted the targeted workflow, putting an end to the Coinbase-specific attack. At this point, the attacker opted to burn the pilfered access, and pushed malicious code to every tj-actions/changed-files tag. The idea apparently being that there would likely be some interesting secrets that were leaked. It’s also possible this was intended to hide Coinbase as the primary target. Regardless, that’s the widespread attack we’ve already covered, and now you know the rest of the story.

ZendTo: No CVE, No Problem?

ZendTo is a nifty Open Source, web-based file sharing platform. It’s been around for a while, and the release notes from a 2021 release makes reference to a “security fix” with no additional details given. That caught the attention of [Jay] from Project Black. It sounds like a potential vulnerability, but it seems like no CVE was ever assigned, and no further details were given.

Here’s the issue: ZendTo has an anonymous file upload feature on by default. This has a security feature built in, in the form of scanning the uploaded file with ClamAV in a temporary location, before moving the file to its long term storage directory. Part of this process includes the ever lovely exec("/bin/chmod go+r " . $ccfilelist); line. PHP has some footguns to be aware of, and calling exec() with any user-provider input is one of them. And of course, the user-provided tmp_name value is used to construct the $ccfilelist string. Set tmp_name to 1;command, and you’ve got code execution.

There is another outstanding issue, where legacy md5 passwords that happen to begin with 0e will be interpreted as a number in scientific notation. PHP handles some type comparisons a bit weirdly. These scientific notation values all evaluate as 0. Using any password that also evaluates to one of these special “scientific” md5 hashes, and the comparison collapses to 0 == 0. So one out of every 256 users have a trivially bypassed password — if their account was still using a md5 password hash.

So here we have a pair of serious vulnerabilities, though one has limited exposure, with neither being fully disclosed nor given CVEs. What’s the result of this lack of transparency? Old, vulnerable installs of ZendTo are still on the Internet. Without a CVE, there’s much less pressure to update. No CVE doesn’t necessarily mean no vulnerabilities.

Leaking Call Records

Researcher [Evan Connelly] was looking into the Verizon Call Filter iOS app, and found it to be using an interesting web service. The callLogRetrieval endpoint allows a user to look up call logs for their own Verizon number. Authorization is done using JSON Web Tokens (JWT), which included a “sub” field, indicating the phone number the token was authorized to fetch. The request itself also has a field to indicate the number being queried. This particular endpoint uses a JWT for authorization, but returns the information requested in the query field — without comparing the two values. Yes, any customer that could obtain a valid JWT could query the call records of virtually any other Verizon number. While this is particularly bad, Verizon acknowledged it quickly, and rolled a fix out in less than a month.

When Parameterized Queries Aren’t

What’s the single most powerful tool to prevent SQL injection attacks? Easy: Parameterized queries. Write the SQL query ahead of time, the library converts it into native database code, and only then are the user-generated values plugged in. In theory that means those values can never be understood as part of the SQL logic. While there are ways this can still go wrong, the basic approach is sound. But what if a language, like Nim, had a parameterization option that didn’t actually do parameterized queries?

Yes, Nim’s db_postgres module provides the facility to run code like getRow(sql"SELECT username FROM users WHERE username=?;", "user"), which is intended to protect against SQL injection. But, under the hood, it really is just doing string replacement with character escaping, like replacing null characters with \\0. Now consider PostreSQL’s standard_conforming_strings setting, which among other things, removes the backslash as a special character. But if that setting is disabled, the backslash can be used to escape quotes. Nim doesn’t know anything about that behavior. This combination of not-actually-parameterized parameterization, and lack of awareness of the standard_conforming_strings behavior, means that ./poc '\' ' OR user_id=1; --' is once again a potential SQL injection. Whoops.

Oracle: Oh, That Oracle Cloud!

We finally have a bit more insight into what’s going on at Oracle. You probably remember that the company has continually denied a breach into Oracle Cloud. It seems this is a bit of verbal sleight-of-hand, as Oracle has renamed part of their cloud offering to Oracle Cloud Classic. The remaining, current generation service is the Oracle Cloud. Oracle Cloud Classic has suffered the breach, not technically Oracle Cloud.

It’s not clear that this is really all there is to the story, though, as more data is getting released by the attacker, including video of a web meeting from 2019. Oracle has started reaching out to customers and confirmed the breach, though apparently strictly avoiding putting anything in writing.

Microsoft Joins the Hotpatch Game

Enterprise Linux distros have long had support for various forms of live-patching. We even interviewed TuxCare about this feature for FLOSS Weekly a few weeks ago. It seems that Microsoft finally wants in on the fun. Windows 11 Enterprise has in-memory security patching starting with the 24H2 update. This support is strictly for machines with an Enterprise or certain Education Microsoft subscriptions. The Hotpatches will be available for 8 of the 12 monthly security patches, with an enforced quarterly update via traditional updates and a reboot.

Bits and Bytes

Researchers at GreyNoise have noted an uptick in IPs scanning for Palo Alto device login pages for several days in March. The scanning had as many as 20,000 unique IPs hunting for these login interfaces, which suggests a botnet has been tasked with finding these devices. It’s very possible that a threat actor has found a new vulnerability in Palo Alto devices, and is preparing to launch an attack.

And finally, a pair of posts from ZDI caught our attention this week. The first is a dive into how Binary Ninja’s static code analysis can find potential use-after-free vulnerabilities. The second is all about building an electric car simulator, that can actually plug into real electric vehicle charging stations, and actually fool the charger into believing a car is attached. How is this problem approached safely, given the high voltages and amperages involved? Very carefully.

Bears! Are they scared of massive arcs that rip through the air, making a lot of noise in the process? [Jay] from the Plasma Channel sure hopes so, because that’s how his bear deterrent works!

[Jay] calls it the Bear Blaster 5000. Right from the drop, this thing looks like some crazy weapon out of Halo. That’s because it throws huge arcs at 280,000 volts. The basic concept behind it is simple enough—a battery drives a circuit which generates (kinda) low voltage AC. This is fed to the two voltage multipliers which are set up with opposite polarity to create the greatest possible potential difference between the two electrodes they feed. The meaty combination is able to arc across electrodes spaced over four inches apart. It’s all wrapped up in a super-cool 3D printed housing that really shows off the voltage multiplier banks.

Given its resemblance to a stun gun, you might think the idea is to jab an attacking bear with it. But the reality is, if the bear is close enough that you could press this device against it, you’re already lunch. [Jay] explains that it’s more about scaring the animal off with the noise and light it produces. We’d certainly take a few steps back if we heard this thing fire off in the woods.

[Jay] does a great job of explaining how the whole setup works, as well as showing off its raw ability to spark. We’ve seen some great builds from [Jay] before, too, like this beefy custom flyback transformer.

You don’t see them as often as you used to, but it used to be common to see “electronics trainers” which were usually a collection of components and simple equipment combined with a breadboard, often in a little suitcase. We think [Pro Maker_101’s] portable electronics workstation is in the same kind of spirit, and it looks pretty nice.

The device uses a 3D printed case and a custom PC board. There are a number of components, although no breadboard. There is a breakout board for Raspberry Pi GPIO, though. So you could use the screw terminals to connect to an external breadboard. We were thinking you could almost mount one as a sort of lid so it would open up like a book with the breadboard on one side and the electronics on the other. Maybe version two?

One thing we never saw on the old units? An HDMI flat-screen display! We doubt you’d make one exactly like this, of course, but that’s part of the charm. You can mix and match exactly what you want and make the prototyping station of your dreams. Throw in a small portable soldering iron, a handheld scopemeter, and you can hack anywhere.

We’d love to see something like this that was modular. Beats what you could build in 1974.

Odd hardware designs crop up in art and renders far more frequently than in the flesh, but console modder [GingerOfOz] felt the need to bring [Anh Dang]’s image of the inevitable carcinization of our gaming consoles to life.

Starting with the image as inspiration, [GingerOfOz] got to work in CAD, creating an entirely new shell for the battered PSOne he adopted for the project. The final product is slightly less curvy than the picture, but some artistic license was necessary to go from the page to the real world.

The enclosure itself looks straightforward, if a bit tedious, but the articulating crab controller is a work of art itself. He could’ve made the arms static or non-functional, but they’re a fully-functional PlayStation controller that can move around just like on your favorite crustacean at the beach, minus the pinching. We love this whimsical take on the console mod which is a breath of salty air to the continuous race to get increasingly complex consoles into handheld form, although there’s certainly nothing wrong with that!

If you’re looking for some other console mods, how about this Apple M1 inside a Wii or getting your old Ouya up-and-running again?

The console wars of the early 1990s had several players, but the battle that mattered was between Nintendo’s SNES and Sega’s Genesis, or Megadrive if you are European. They are both famous for their games, but in terms of software they can only run what’s on a cartridge. The Genesis has a Motorola 68000 on board though, which is capable of far more than just Sonic the Hedgehog. [EythorE] evidently thinks so, because here’s a port of Fusix, a UNIX-like OS, for the Sega platform.

As it stands, the OS is running on the BlastEm emulator, but given a Sega Saturn keyboard or a modified PC keyboard for the Sega, it could be run on real hardware. What you get is a basic UNIX-like OS with a working shell and the usual UNIX utilities. With 64k of memory to play with this will never be a powerhouse, but on the other hand we’d be curious to see it in a working cartridge.

Meanwhile, if the console interests you further, someone has been into its workings in great detail.

Header: Evan-Amos, CC BY-SA 3.0.

We’re used to there being an array of high-end microprocessor architectures, and it’s likely that many of us will have sat in front of machines running x86, ARM, or even PowerPC processors. There are other players past and present you may be familiar with, for example SPARC, RISC-V, or MIPS. Back in the 1990s there was another, now long gone but at the time the most powerful of them all, of course we’re speaking of DEC’s Alpha architecture. [JP] has a mid-90s AlphaStation that doesn’t work, and as part of debugging it we’re treated to a description of its unusual boot procedure.

Conventionally, an x86 PC has a ROM at a particular place in its address range, and when it starts, it executes from the start of that range. The Alpha is a little different, on start-up it needs some code from a ROM which configures it and sets up its address space. This is applied as a 1-bit serial stream, and like many things DEC, it’s a little unusual. This code lives in a conventional ROM chip with 8 data lines, and each of those lines contains a separate program selectable by a jumper. It’s a handy way of providing a set of diagnostics at the lowest level, but even with that discovery the weirdness isn’t quite over. We’re treated to a run-down of DEC Alpha code encoding, and should you have one of these machines, there’s all the code you need.

The Alpha was so special in the 1990s because with 64-bit and retargetable microcode in its architecture it was significantly faster than its competitors. From memory it could be had with DEC Tru64 UNIX, Microsoft Windows NT, or VMS, and with the last of which it was the upgrade path for VAX minicomputers. It faded away in the takeover by Compaq and subsequently HP, and we are probably the poorer for it. We look forward to seeing more about this particular workstation, should it come back to life.

Everyone knows that ultrasonic cleaners are great, but not every device that’s marketed as an ultrasonic cleaner is necessarily such a device. In a recent video on the Cheap & Cheerful YouTube channel the difference is explored, starting with a teardown of a fake one. The first hint comes with the use of the description ‘Multifunction cleaner’ on the packaging, and the second in the form of it being powered by two AAA batteries.

Unsurprisingly, inside you find not the ultrasonic transducer that you’d expect to find in an actual ultrasonic cleaner, but rather a vibration motor. In the demonstration prior to the teardown you can see that although the device makes a similar annoying buzzing noise, it’s very different. Subsequently the video looks at a small ultrasonic cleaner and compares the two.

Among the obvious differences are that the ultrasonic cleaner is made out of metal and AC-powered, and does a much better job at cleaning things like rusty parts. The annoying thing is that although the cleaners with a vibration motor will also clean things, they rely on agitating the water in a far less aggressive way than the ultrasonic cleaner, so marketing them as something which they’re not is very unpleasant.

In the video the argument is also made that you do not want to clean PCBs with an ultrasonic cleaner, but we think that people here may have different views on that aspect.