I got a rude awakening Wednesday morning this week. HaD writers don’t necessarily keep normal hours — don’t judge. A local client called, complaining that Google Maps was blocking on one of their computers, and the browser stated that it was a malicious site. Well that got my attention. Standard incident response: “Turn off the affected computers, I’m on my way.” Turns out, it was Malwarebytes that was complaining and blocking Google Maps, as well as multiple other Google domains. That particular machine happened to have a fresh install of the program, and was still in the trial period of Malwarebytes premium, which includes the malicious IP and domain blocking feature.
Oof, this could be bad. The first possibility that came to mind was a DNS hijack. The desktop’s DNS was set to the router, and the router’s DNS was set to the ISP’s. Maybe the ISP had their DNS servers compromised? Out came the cell phone, disconnected from the WiFi, for DNS lookups on some Google domains. Because Google operates at such a massive scale, they have multiple IPs serving each domain, but since the two different results were coming from the same subnet, the suspicious DNS server was likely OK. A
whois on the blocked IP also confirmed that it was a Google-owned address. We were running out of explanations, and as a certain fictional detective was known for saying, “whatever remains, however improbable, must be the truth.” And, yes, Malwarebytes did indeed accidentally add Google to its bad list. The upside was that my customer wasn’t compromised. The downside? I had to answer a phone call before my first cup of coffee. Blegh.
In p0wnage news this week, Uber got compromised through an employee’s VPN account. Uber uses two factor authentication for those accounts, and the attacker used a “MFA fatigue” attack to defeat it. Essentially, send repeated 2FA requests, and hope the user gets tired of it and confirms. Or alternatively, contact them after a few attempts, claim to be from corporate IT, and ask them to approve the prompt, or read back the number. That attacker is [Tea Pot], somehow affiliated with Lapsus$.
The VPN access got TP in to the corporate intranet, and some sniffing found an accessible share with Powershell scripts on it. And in those scripts were some hard-coded admin credentials to Uber’s Thycotic account — the service that manages all of their authentication. In short it was the keys to the kingdom. “Using this I was able to extract secrets for all services, DA, DUO, Onelogin, AWS, Gsuite.”
Uber has released a statement that essentially states that there is no evidence of code tampering or user-data access. As deep as TP was able to penetrate into Uber’s systems, this seems somewhat surprising, though welcome news. Of course, it may eventually be revealed that more serious tampering did occur.
Top Of Rack Vulnerabilities
I’m not sure if a Power Distribution Unit (PDU) counts as IoT, but the S apparently still stands for security. The iBoot PDU had some serious problems. The first one was a page on the web interface, seemingly abandoned by the manufacturer, that didn’t include the authentication code. It’s pretty standard, when writing a web interface in PHP, to have the authentication code in a single file, and just include that from each page that should be protected. The code for the
git-update.php endpoint was missing that include. Shouldn’t be a problem, it was hard-coded to download updates from the manufacturers GitHub repositories, and used an access token, which is no longer supported by GitHub. Dead code, nothing to worry about.
Yeah, it was vulnerable. This endpoint takes two arguments as HTTP POST parameters,
token. Neither of those get sanitized at all, so the branch parameter can use path traversal to point at a completely different GitHub account, and the token parameter can be set to
&, which essentially means that it is blanked out in the request to GitHub. Single pre-auth request, and the device politely downloads a webshell for you.
Ah, but we’re no fools. Never expose this sort of thing to the unfiltered Internet. They have a cloud access function for that. To connect, you authenticate, and then send a deviceID parameter in a URL request. But those deviceIDs are sequential, and any valid authentication cookie works to connect to any device. So if you can connect to one PDU, you can connect to them all. And because the cloud access is a simple reverse proxy, the update page can be abused as shown above. Ouch! The problems have been fixed, and if you happen to have a Dataprobe PDU, go check for updated firmware! And maybe disconnect it from the internet entirely, and make it VPN accessible only. Huge thanks to Team82 at Claroty for finding this one and reporting it privately.
Seagate Privilege Escalation
In a beautiful write-up, [x86matthew] shares a very simple exploit using Seagate Media Sync, to add an arbitrary service to a Windows machine. Media Sync uses the UI and Service paradigm, where a service runs as SYSTEM to do the heavy lifting, and a user-interface application runs as the logged-in user. A bit of sleuthing and debugging finds the format used for Inter Process Communication (IPC) is a simple named pipe. That pipe supports a handful of commands, but the most interesting one calls a function in the service,
As one might expect, it sets a registry key to a value, creating the key if it’s absent. In this particular case, there are no checks on where that key is created, so anyone that can talk to the pipe could create a key in
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices. And if you can create an arbitrary service on a Windows machine, you own the machine.
OpenRazer Escalation — Almost
And because Linux exploitation deserves our love, too, the OpenRazer project had a similar exploitation issue recently fixed. For those not in the know, we Linux geeks like our clacky, LED lit, keyboards just as much as Windows users, but Razer sadly only publishes Windows drivers and tools. To fill the void, projects like OpenRazer re-implement the Razer LED control and other functions for Linux. Part of the OpenRazer project is an out-of-tree Linux kernel module, that allows some of the tricky USB communication bits used to talk to the on-device controllers. It’s a bit of a hack, and the code quality isn’t quite up to the par of the mainline kernel,as evidenced by the classic buffer overflow discovered by Cyberark. It should have been a straightforward path to exploitation, but starting with kernel 5.18, the Fortify Source feature is enabled to prevent
memcpy() functions from overflowing fields in a struct. So in a new enough kernel, with this protection turned on, you just get a crash instead of an exploit. Neat!
One of the tasks in doing a red-team test is to look for user accounts. The trouble you can run into is that brute-forcing possible user names leaves log entries, and that can get you caught. [Lars Karlslund] caught wind of LDAP Ping Requests, and immediately made the connection to user enumeration. The purpose of this was originally to easily test domain controllers for reachability, and also for certain capabilities or configurations. One of the test specifications you choose is username. [Lars]’s new tool,
ldapnomnom, uses this facility to query 10,000 usernames a second. Find all the users!