This Week In Security: Dating App, WooCommerce, And OpenSSH

Up first this week is a report from vpnMentor, covering the unsecured database backing a set of dating apps, including 419 Dating. The report is a bit light on the technical details, like what sort of database this was, or how exactly it was accessed. But the result is 2.3 million exposed records, containing email address, photos — sometimes explicit, and more. Apparently also exposed were server backups and logs.

The good news here is that once [Jeremiah Fowler] discovered the database door unlocked and hanging open, he made a disclosure, and the database was secured. We can only hope that it wasn’t discovered by any bad actors in the meantime. The app has now disappeared from the Google Play store, and had just a bit of a sketchy air about it.

WooCommerce Under Siege

Back in March, CVE-2023-28121 was fixed in the WooCommerce plugin for WordPress. The issue here is an authentication bypass that allows an unauthenticated user to commandeer other user accounts.

Within a few months, working exploits had been derived from the details of the patch plugging the hole. It wasn’t hard. A function for determining the current user was explicitly trusting the contents of the X-WCPAY-PLATFORM-CHECKOUT-USER request header. Set that value in a request sent to the server, and ding, you’re administrator.

And now the cows are coming home to roost. Active exploitation started in earnest on July 14, and the folks at Wordfence clocked a staggering 1.3 million exploitation attempts on the 16th. What’s particularly interesting is that the Wordfence data gathering system saw a huge increase in requests for the readme.txt file that indicates the presence of the WooCommerce plugin on a WordPress site. These requests were observed before the attacks got started, making for an interesting early warning system. Continue reading “This Week In Security: Dating App, WooCommerce, And OpenSSH”

This Week In Security: Apple’s 0-day, Microsoft’s Mess, And More

First up, Apple issued an emergency patch, then yanked, and re-issued it. The problem was a Remote Code Execution (RCE) vulnerability in WebKit — the basis of Apple’s cross-platform web browser. The downside of a shared code base,is that bugs too are write-once, exploit-anywhere. And with Apple’s walled garden insisting that every browser on iOS actually run WebKit under the hood, there’s not much relief without a patch like this one.

The vulnerability in question, CVE-2023-37450, is a bit light on further details except to say that it’s known to be exploited in the wild. The first fix also bumped the browser’s user-agent string, adding an (a) to denote the minor update. This was apparently enough to break some brittle user-agent detection code on popular websites, resulting in an unhelpful “This web browser is no longer supported” message. The second patch gets rid of the notification.

Microsoft Loses It

Microsoft has announced that on May 15th, an attack from Storm-0558 managed to breach the email accounts of roughly 25 customers. This was pulled off via “an acquired Microsoft account (MSA) consumer signing key.” The big outstanding question is how Microsoft lost control of that particular key. According to an anonymous source speaking to The Washington Post, some of the targeted accounts were government employees, including a member of cabinet. Apparently the FBI is asking Microsoft this very same question.

Speaking of Microsoft, there’s also CVE-2023-36884, a vulnerability in Microsoft Office. This one appears to be related to the handling of HTML content embedded in Office documents, and results in code execution upon opening the document. This along with another vulnerability (CVE-2023-36874) was being used by storm- another unknown threat actor, Storm-0978 in an ongoing attack.

There’s an interesting note that this vulnerability can be mitigated by an Attack Surface Reduction (ASR) rule, that blocks Office from launching child processes. This might be a worthwhile mitigation step for this and future vulnerabilities in office. Continue reading “This Week In Security: Apple’s 0-day, Microsoft’s Mess, And More”

This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach

It appears we have something of a problem. It’s not really a new problem, and shouldn’t be too surprising, but it did pop up again this week: bogus CVEs. Starting out in the security field? What’s the best way to jump-start a career? Getting a CVE find to your name certainly can’t hurt. And as a result, you get very junior security researchers looking for and reporting novel security vulnerabilities of sometimes dubious quality. Sometimes that process looks a lot like slinging reports against the wall to see what sticks. Things brings us to an odd bug report in the OBS Studio project.

A researcher put together a script to look for possible password exposure on Github projects, and it caught a configuration value named “password” in a .ini file, being distributed in the project source. Obvious credential leak in Git source, right? Except for the little detail that it was in the “locale” folder, and the files were named ca-es.ini, ja-jp.ini, and similar. You may be in on the joke by now, but if not, those are translation strings. It wasn’t leaked credentials, it was various translations of the word “password”. This sort of thing happens quite often, and from the viewpoint of a researcher looking at results from an automated tool, it can be challenging to spend enough time with each result to fully understand the code in question. It looks like this case includes a language barrier, making it even harder to clear up the confusion.

Things took a turn for the worse when a CVE was requested. The CVE Numbering Authority (CNA) that processed the request was MITRE, which issued CVE-2023-34585. It was a completely bogus CVE, and thankfully a more complete explanation from OBS was enough to convince the researcher of his error. That, however, brings us back to CVE-2023-36262, which was published this week. It’s yet another CVE, for the same non-issue, and even pointing at the same GitHub issue where the alleged bug is debunked. There’s multiple fails here, but the biggest disappointment is MITRE, for handing out CVEs twice for the same issue. Shout-out to [Netspooky] on Twitter for spotting this one. Continue reading “This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach”

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”

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”

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”