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_MACHINE\SYSTEM\CurrentControlSet\Services. 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!
12 thoughts on “This Week In Security: Malwarebytes Goes Nuts, Uber”
Great choice of name ldap-nom-nom
10,000 usernames a second, if you’re going to get caught, best to use a BIG battering ram to get in fast so you can do whatever then be gone.
I assume there’s a setting to limit the allowed time between login attempts?
He says you can go even faster with multiple servers to ping. I think it’s a server resource limitation more than anything. For actual logins, yes, those are much closer monitored and rate-limited.
We bought a LOT of iBoot products at my last job and they were hot garbage. They were relatively inexpensive compared to similar products, but you got what you paid for. If the MCU goes out to lunch, and it will, you must power cycle mains feeding the PDU to get it talking over the network again. That means you have to schedule downtime for all of the devices plugged into it.
My previous employer had them hidden behind the corporate firewall, but I wouldn’t be surprised if someone made some bad choices since I left.
And you think that you are judge, jury and executioner? Don’t get me wrong, I don’t condone blackhat hacking, but advocating murder with no due process is absolute insanity. I could already see how such a system could be horribly abused to step up swatting to a whole new level.
Internet Tough Guychecking in.
or a frustrated script-kiddie who couldn’t even made the baby toys work :)
It’s pretty sad when a user interface device needs another user interface to configure it. Keyboards have keys and lights, should be able to host its own configuration interface. I certainly don’t trust a keyboard company to write bulletproof software for every supported platform and my employer doesn’t either. If people are willing to pay hundreds of dollars on a keyboard they can add a tiny LCD display that would only add a few cents to the BOM.
I swore off Razor products after they required creating an account to download a driver.
The Keypro FK9000 had 12 programmable function keys that were programmable using only the keyboard. A NiCd battery charged from the 5V supply to the keyboard to keep the macros when the computer was off. The numpad also doubled as a calculator with LCD. The feature it lacked was the ability to send the calculator display contents to the computer.
malwarebytes. yuck. this software has caused me so many headaches from preventing my pc booting. avoid it.
To be fair, Google is a big, spammy company that hosts tons of spammers, scammers and shady businesses. Plus, they completely ignore abuse reports.
It’s a shame they can’t be directly punished because they mix the bad in with the good.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)