This Week In Security:Camaro Dragon, RowPress, And RepoJacking

Malicious flash drives have come a long ways since the old days of autorun infections. It’s not an accident that Microsoft has tightened down the attack surface available of removable media. So how exactly did a malicious flash drive lead to the compromise of a European hospital? Some sophisticated firmware on the drive? A mysterious zero day? Nope, just hidden files, and an executable using the drive name and icon. Some attacker discovered that a user trying to access a flash drive, only to be presented with what looks like the same flash drive icon, will naturally try to access it again, running an .exe in the process.

That executable runs a signed Symantec binary, included on the drive, and sideloads an OCX that hijacks the process. From there, the computer is infected, as well as any other flash drives in the machine. Part of the obfuscation technique is an odd chain of executables, executed recursively for a hundred copies. Naturally once the infection has rooted itself in a given machine, it takes commands from a C&C server, and sends certain files out to its waiting overlords. Checkpoint Research has attributed this campaign to Camaro Dragon, a name straight from the 80s that refers to a Chinese actor with an emphasis on espionage. Continue reading “This Week In Security:Camaro Dragon, RowPress, And RepoJacking”

Meshtastic For The Greater Good

Last week, my city was hit by a tornado. That’s not surprising here in Oklahoma, and thankfully this event was an F0 or possibly even an EF0 — a really weak tornado. Only a couple roofs collapsed, though probably half the houses in town are going to need roof repairs, thanks to the combination of huge hail and high winds. While it wasn’t too bad, power did go down in a few places around town, and this led to an interesting series of events.

Chat messages were coming in like this: “That was a [power] flicker, yeah. Even took down my Internet.” Followed by “Whee, [fiber Internet] got knocked out and now Starlink has too many clouds in the way.” And after ten minutes of silence, we got a bit worried to see “Time to hide under a bed. … Is cell service back?” It is a bit spooky to think about trying to help neighbors and friends after a disaster, in the midst of the communication breakdown that often follows. If he had needed help, and had no working communications, how long would it have taken for us to go check on him?
Continue reading “Meshtastic For The Greater Good”

Et Tu, Red Hat?

Something odd happened to git.centos.org last week. That’s the repository where Red Hat has traditionally published the source code to everything that’s a part of Red Hat Enterprise Linux (RHEL) to fulfill the requirements of the GPL license. Last week, those packages just stopped flowing. Updates weren’t being published. And finally, Red Hat has published a clear answer to why:

Red Hat has decided to continue to use the Customer Portal to share source code with our partners and customers, while treating CentOS Stream as the venue for collaboration with the community.

Sounds innocuous, but what’s really going on here? Let’s have a look at the Red Hat family: RHEL, CentOS, and Fedora.

RHEL is the enterprise Linux distribution that is Red Hat’s bread and butter. Fedora is RHEL’s upstream distribution, where changes happen fast and things occasionally break. CentOS started off as a community repackaging of RHEL, as allowed under the GPL and other Open Source licenses, for people who liked the stability but didn’t need the software support that you’re paying for when you buy RHEL.

Red Hat took over the reigns of CentOS back in 2014, and then imposed the transition to CentOS Stream in 2020, to some consternation. This placed CentOS Stream between the upstream Fedora, and the downstream RHEL. Some people missed the stability of the old CentOS, and in response a handful of efforts spun up to fill the gap, like Alma Linux and Rocky Linux. These projects took the source from git.centos.org, and rebuilt them into usable community operating systems, staying closer to RHEL in the process.

Red Hat has published a longer statement elaborating on the growth of CentOS Stream, but it ends with an interesting statement: “Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement.” What exactly is in that subscription agreement? Well according to Alma Linux, “the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.” Continue reading “Et Tu, Red Hat?”

This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride

There’s a fun logic flaw in how multiple online services handle OAuth logins, that abuses Microsoft’s Azure Active Directory service to allow account takeovers. The problem is how a site handles the “Sign In With Microsoft” option, when there’s an existing account under the same email address. This is an irritating problem for an end-user, when a site offers multiple sign-in options. Trying to remember which option was used to set up an account is a struggle, so many services automatically merge accounts.

The problem is that the Microsoft Azure authentication information includes an email address, but Microsoft hasn’t done any verification that the account in question actually controls that address. And in fact, it’s trivial for the Azure admin to change that address at whim. So if the service accepts that email address as authoritative, and auto-merges the accounts, it’s a trivial account takeover. And it’s more than just a theoretical problem, as researchers at descope were able to demonstrate the attack, and have found multiple medium and large services that were vulnerable, as well as at least two authentication providers that themselves were vulnerable to this attack.

Microsoft has pushed updates to the Azure AD service to make the issue easier to avoid, though it seems that the unverified “email” field is still being sent on authentication transactions. There is a new flag, “RemoveUnverifiedEmailClaim” that eliminates the issue, and is enabled by default for new applications. Unfortunately this means that existing vulnerable applications will continue to be vulnerable until fixed on the application side. Continue reading “This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride”

This Week In Security: ACME.sh, Leaking LEDs, And Android Apps

Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service. Continue reading “This Week In Security: ACME.sh, Leaking LEDs, And Android Apps”

Do Not Attempt Disassembly: Analog Wizardry In A 1960s Counter

[CuriousMarc] is back with more vintage HP hardware repair. This time it’s the HP 5245L, a digital nixie-display frequency counter from 1963. This unit is old enough to be entirely made of discrete components, but has a real trick up its sleeve, with add-on components pushing the frequency range all the way up to 18 GHz. But this poor machine was in rough shape. There were previous repair attempts, some of which had to be re-fixed with proper components. When it hit [Marc]’s shop, the oscillator was working, as well as the frequency divider, but the device wasn’t counting, and the reference frequencies weren’t testing good at the front of the machine. There were some of the usual suspects, like blown transistors. But things got really interesting when one of the boards had a couple of tarnished transistors, and a handful of nice shiny new ones — but maybe not all the right transistors. Continue reading “Do Not Attempt Disassembly: Analog Wizardry In A 1960s Counter”

This Week In Security: Minecraft Fractureiser, MOVEit, And Triangulation

Modded Minecraft is having a security moment, to match what we’ve seen in the Python and JavaScript repositories over the last few months. It looks like things started when a handful of burner accounts uploaded malicious mods to Curseforge and Bukkit. Those mods looked interesting enough, that a developer for Luna Pixel Studios (LPS) downloaded one of them to test-run. After the test didn’t pan out, he removed the mod, but the malicious code had already run.

Where this gets ugly is in how much damage that one infection caused. The virus, now named fractureiser, installs itself into every other Minecraft-related .jar on the compromised system. It also grabs credentials, cookies, cryptocurrency addresses, and the clipboard contents. Once that information was exfiltrated from the LPS developer, the attacker seems to have taken manual actions, using the purloined permissions to upload similarly infected mod files, and then marking them archived. This managed to hide the trapped files from view on the web interface, while still leaving them exposed when grabbed by the API. Once the malware hit a popular developer, it began to really take off.

It looks like the first of the malicious .jar files actually goes all the way back to mid-April, so it may take a while to discover all the places this malware has spread. It was first noticed on June 1, and investigation was started, but the story didn’t become public until the 7th. Things have developed rapidly, and the malware fingerprints has been added to Windows Defender among other scanners. This helps tremendously, but the safe move is to avoid downloading anything Minecraft related for a couple days, while the whole toolchain is inspected. If it’s too late and you’ve recently scratched that voxel itch, it might be worth it to take a quick look for Indicators of Compromise (IoCs).

Continue reading “This Week In Security: Minecraft Fractureiser, MOVEit, And Triangulation”