The funniest thing happened to REvil this week. Their online presence seems to have disappeared.
Their Tor sites as well as conventional sites all went down about the same time Tuesday morning, leading to speculation that they may have been hit by a law enforcement operation. This comes on the heels of a renewed push by the US for other countries, notably Russia, to crack down on ransomware groups operating within their borders. If it is a coordinated takedown, it’s likely a response to the extremely widespread 4th of July campaign launched via the Kaseya platform. Seriously, if you’re going to do something that risks ticking off Americans, don’t do it on the day we’re celebrating national pride by blowing stuff up.

All REvil sites are down, including the payment sites and data leak site. 🤔

The public ransomware gang represenative, Unknown, is strangely quiet.

— Lawrence Abrams (@LawrenceAbrams) July 13, 2021

Speaking of Kaseya, they have finished their analysis, and published a guide for safely powering on their VSA on-premise hardware. Now that the fixes are available, more information about the attack itself is being released. Truesec researchers have been following this story in real time, and even provided information about the attack back to Kaseya, based on their observations. Their analysis shows that 4 separate vulnerabilities were involved in the attack. First up is an authentication bypass. It takes advantage of code that looks something like this:

if password == hash(row[nextAgentPassword] + row[agentGuidStr]) 
    login ok 
elseif password == hash(row[curAgentPassword] + row[agentGuidStr])
    login ok
elseif password == hash(row[nextAgentPassword] + row[displayName])
    login ok
elseif password == hash(row[curAgentPassword] + row[displayName])
    login ok
elseif password == row[password]
    login failed 
else 
    login ok

Yeah, their code fails open, rather than failing closed. I have spent some time trying to understand how that code could have ever worked, or what the engineer was thinking that wrote it, and I’ve got nothing. I have to hope the original version makes more sense. One thing to note, in order to get this far in the login process, an attacker would need a valid agentGuid.

Next in the attack flow, an unexpected request to the done.asp endpoint triggered an unrestricted upload vulnerability. This would theoretically be thwarted by a Cross Site Request Forgery protection token, but that token wasn’t being properly vetted, allowing for another easy bypass. Two files were uploaded by the attacker, a payload to send to the victim machines, as well as an ASP script to execute on the appliance itself. The final step from the attacker was to trigger the execution of this script through another faulty endpoint. From there the attack would be carried out automatically and the logs of the appliance wiped to cover the trail.

Android Wifi Scan RCE

There is always something fun hidden in the monthly Android security updates, and this month is no exception. CVE-2021-1965 is a flaw in Qualcomm driver code, a buffer overflow in how BSSID beacons are handled when scanning for networks. Part of those beacons is the “Information Element”, which additional information about the network. The code in question didn’t properly handle long IE fields, resulting in a potential buffer overflow.

This is an interesting bug, because unless you put it in airplane mode, a modern phone is always running scans for WiFi networks, and simply being in range of a malicious network is enough to trigger the vulnerability.

PrintNightmare Is Over?

Microsoft pushed a pair of fixes, both aimed at the PrintNightmare flaw, one of which being an Out Of Band (OOB) patch, AKA not put out on Patch Tuesday. Several researchers stepped forward to point out that the vulnerability was still present, if you had a certain system configuration. Microsoft has responded to those claims:

Our investigation has shown that the OOB security update is working as designed and is effective against the known printer spooling exploits and other public reports collectively being referred to as PrintNightmare. All reports we have investigated have relied on the changing of default registry setting related to Point and Print to an insecure configuration.

It seems like the ride isn’t quite over, though this time maybe it really is limited to local users:

#printnightmare – Episode 3

You know that even patched, with default config (or security enforced with #Microsoft settings), a standard user can load drivers as SYSTEM?

– Local Privilege Escalation – #feature pic.twitter.com/Zdge0okzKi

— 🥝 Benjamin Delpy (@gentilkiwi) July 15, 2021

You Don’t Need to See My Credentials

Sage X3 is an Enterprise Resource Planning system. Think Quickbooks, but for enterprise scale. Researchers at Rapid7 found a few problems with the program, but the big one is CVE-2020-7388. The server and client elements of Sage X3 communicate over a TCP connection, and use a proprietary authentication mechanism to protect that connection. So long as the authentication is successful, commands can be sent back over the connection to execute on the server as the authenticated user. That proprietary authentication mechanism has a little bug in it. If you change one of the bytes in the auth initialization, the server never actually asks for the hashed username and password, and instead runs commands as its own user, SYSTEM. That’s one to hurry up and update.

Insecure Cameras, or, Why Use A VLAN

Researchers at Randorisec seem to have a hobby of finding security vulnerabilities in UDP Technology cameras. Continuing in their favorite pasttime, they grabbed the latest firmware for their cameras, and set about looking for vulnerabilities. The problem? Those firmware files were encrypted. Not deterred, they simply looked for an undiscovered RCE on the firmware version they still had access to, and then used that to pop the up-to-date cameras and grab the filesystems. They found twelve more CVEs. The writeup is great, walking through the process of turning a vulnerability into a working exploit — go read it.

There’s a lesson to be learned here. Code that a vendor assumes to be unimportant and never to be seen is almost guaranteed to be garbage in one way or another. How many devices do you have on your networks that are probably in this category? We’re not even talking about hardware that might have intentional backdoors. IP Cameras are useful tools for physical security, but they can be a terrible problem for network security. Is there a solution? Separate networks, most easily done via VLANs. Keep your untrusted devices away from your important network, and even better, keep your cameras off the internet.