This Week in Security

238 Articles

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

June 30, 2023 by 4 Comments

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” →

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

June 23, 2023 by 4 Comments

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

June 16, 2023 by 3 Comments

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” →

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

June 9, 2023 by 2 Comments

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” →

This Week In Security: Barracuda, Zyxel, And The Backdoor

June 2, 2023 by 12 Comments

Barracuda’s Email Security Gateway (ESG) has had a vulnerability in it for years. Tracked as CVE-2023-2868, this one was introduced back in version 5.1.3.001, and only got patched during the 9.2 development cycle. Specific build information on patched firmware has not been made available, but a firmware build containing the patch was deployed on May 20.

The flaw was a command injection bug triggered by .tar files attached to incoming emails. The appliance scans attachments automatically, and the file names could trigger the qx operator in a Perl script. It’s a nasty one, ranking a 9.4 on the CVSS scale. But the really bad news is that Barracuda found the vulnerability in the wild, and they have found evidence of exploitation as far back as October 2022.

There have been three malware modules identified on the compromised appliances. SALTWATER is a backdoor trojan, with the ability to transfer files, execute commands, and host network tunnels. SEASPY is a stealthier module, that looks like a legitimate service, and uses PCAP to monitor traffic and receive commands. And SEASIDE is a Lua module for the Barracuda SMTP monitor, and it exists to host a reverse shell on command. Indicators of Compromise (IOCs) have been published, and Barracuda recommends the unplug-and-remove approach to cleaning up an infection. The saving grace is that this campaign seems to have been targeted, and wasn’t launched against every ESG on the Internet, so maybe you’re OK.

Moxa, Too

And speaking of security software that has problems, the Moxa MXsecurity appliance has a pair of problems that could be leveraged together to lead to a complete device takeover. The most serious problem is a hard coded credential, that allows authentication bypass for the web-API. Then the second issue is a command-line escape, where an attacker with access to the device’s Command Line Interface (CLI) can break out and run arbitrary commands. Continue reading “This Week In Security: Barracuda, Zyxel, And The Backdoor” →

This Week In Security: Gitlab, KeyPassMini, And Horse

May 26, 2023 by 6 Comments

There’s a really nasty CVSS 10.0 severity vulnerability in Gitlab 16.0.0. The good news is that this is the only vulnerable version, and the fix came a mere two days after the vulnerable release. If you happened to be very quick to go to 16.0.0, then be very quick to get the fix, because CVE-2023-2825 looks like a bad one.

An unauthenticated malicious user can use a path traversal vulnerability to read arbitrary files on the server when an attachment exists in a public project nested within at least five groups.

That’s a very specific set of requirements for vulnerability, so it seems like hardly any installs would be vulnerable. The rest of the story is that regular users can create groups, and many installs allow for open user registration. So if you’re running Gitlab 16.0.0, update now!

KeyPassMini

A Redditor got a surprising notice that someone attempted to access a bank account, but failed two-factor authentication. That seemed odd, and led the Redditor down the rabbithole of auditing applications. And one iOS app in particular stood out as maybe problematic — KeyPassMini.

The app was a mobile client for KeyPass, the password manager. The problem was some analytics. It looks like KeyPassMini was bundling up some system information and uploading it to a server controlled by the creator. Analytics are often unpopular, but this app was including the system clipboard contents in the uploaded data. Yikes! And it gets worse: The app does password fills by using that same clipboard, so some of the protected passwords may have been scooped up into that analytics data. And sent unencrypted. Oof.

Now, the app author has pulled the plug on the app altogether, and responded on the old Github project page. It’s a bit odd, but it’s perfectly believable that there were no ill intentions here. Regardless, code to send the clipboard is a big problem, and definitely undoes a lot of trust in a project.

And KeyPass itself has a problem, though much less worrying. KeyPass attempts to keep sensitive data out of its own memory when possible. This approach aims to protect even in the event of a compromised machine. [vdohney] on Sourceforge discovered that there is a channel to recover the master password, by being just a bit clever. When a user types in the master password, by default, KeyPass will show the last letter typed, and replace the previous letters with bullets. But each iteration of that string ends up in program memory, so a privileged attacker can get a memory dump, look for the bullet characters, and find a set of leftover strings like •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. It’s an easy password grab. Now remember, this essentially implies an attacker has memory access on your system, so it’s not a gaping weakness in KeyPass.

As you can see from the POC on GitHub, the problem is that a .NET text box keeps the strings in memory, so it probably hits both Windows and Linux users under Mono. The proposed solution that the KeyPass team is taking is to poison the well with enough random characters that retrieving the correct password is a lot harder. It’s still getting fixed in the next release.

Horse Shell for MIPS Routers

Checkpoint Research brings us news of the Horse Shell, a bit of malware specifically for MIPS architecture routers running Linux. It’s been found in TP-Link firmware images so far, but as so many of those routers are essentially based on the same Linux SDK, the malware appears to be applicable to many models. The exact firmware images being examined were found in a collection of tools used by Camaro Dragon, a rather catchy name for a Chinese APT group.

The firmware images have some of the normal bits you would expect, like data collection, remote shell, and remote proxy support. They have some really sneaky tricks, too, like storing part of the data on the partition reserved for WiFi calibration data. One has to wonder if hijacking that partition negatively affects the router’s wireless performance. In the firmware images examined, the quickest tell is to go to the firmware upgrade page. If it’s blank, without a form to upload new firmware, you may have the malicious image.

WordPress

WordPress 6.2.1 has a security fix, that is then improved upon in 6.2.2, where block themes could parse user-generated shortcodes. A shortcode is tags inside [brackets], that gets replaced by more complicated data. We use a code shortcode all the time here on Hackaday, to try to get source code to render nicely, angle brackets and all.

It turns out, the fix in 6.2.1 went a little overboard, breaking quite a few sites by disabling shortcodes in block themes altogether. The situation in 6.2.2 is a bit better, with most of the problems being dealt with. Sometimes it’s hard to tell the bugs and the features apart.

And a WordPress plugin, Beautiful Cookie Consent Banner, is under active attack for a Cross-Site Scripting vulnerability. The attack is odd, as WordPress.org shows just 40,000 active installs, and almost 1.5 million sites have been sent the malicious payload to try to exploit the plugin. And the kicker? It looks like the payload on this attack is a dud, and fails to actually infect a vulnerable site. It can still goober a vulnerable site, so make sure to check your plugins.

Bits and Bytes

Speaking of plugins, be careful what VScode plugins you use. They’re not all friendly. Microsoft has been working to keep malicious plugins off the official marketplace, but that arms race never seems to have an end. And as such, there were a couple known malicious plugins with nearly 50,000 installs.

For some in-depth fun, check out this PDF paper on Android Fingerprint Reader attacks. It seems simple, right? Take a screenshot of a finger, compare it to a known data set, and lock the phone if the test fails too many times. It is, of course, not quite that simple. Researchers formulated two loopholes, Cancel-After-Match-Fail and Match-After-Lock, both of which abuse user-friendly features to manage way more attempts at a fingerprint read. Read the paper for the juicy details.

And finally, Troy Hunt had some fun at the expense of a scammer. Troy’s wife was selling a fridge on Gumtree, and they decided to play along with a suspicious “buyer”. Turns out, it’s the old agent fee scam. I’ll give you the money you asked for, plus $800 to cover the fee. Can you forward that extra money on? But of course, the Paypal confirmation message was faked, and there was no money paid. Troy managed to get an impressive bit of information, including that the scam is actually being run out of, you guessed it, Nigeria. Shipping would be a pain. ><

This Week In Security: .zip Domains, Zip Scanning

May 19, 2023 by 17 Comments

The world may not be ready, but the .zip Top Level Domain (TLD) is here. It’s a part of the generic TLD category, which was expanded to allow applications for custom TLDs. Google has led the charge, applying for 101 such new TLDs, with .zip being one of the interesting ones. Public registration for .zip domains has been open for a couple weeks, and some interesting domains have been registered, like update.zip, installer.zip, and officeupdate.zip.

The obvious question to ask is whether this new TLD can be abused for scamming and phishing purposes. And the answer is yes, sure it can. One of the trickiest ways is to use the AT symbol @ in a URL, which denotes user info at the beginning of the URL. It usually is used to include a username and password, like http://username:password@192.168.1.1/. That is pretty obvious, but what about https://google.com@bing.com? Still looks weird. The catch that really prevents this technique being abused is that slashes are disallowed in user data, so a abusive URL like https://google.com∕gmail∕inbox@bing.com is right out.

Except, take a look at that last link. Looks like it has slashes in it, so it should take you to google, and ignore the AT symbol. But it doesn’t, it goes to Bing. You may have guessed, it’s Unicode shenanigans again. Those aren’t slashes, they’re U2215, the division slash. And that means that a .zip TLD could be really sneaky, if the apparent domain is one you trust. Continue reading “This Week In Security: .zip Domains, Zip Scanning” →