This Week In Security: Malwarebytes Goes Nuts, Uber

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.

Continue reading “This Week In Security: Malwarebytes Goes Nuts, Uber”

This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds

Automated Tank Gauges (ATGs) are nifty bits of tech, sitting unseen in just about every gas station. They keep track of fuel levels, temperature, and other bits of information, and sometimes get tied into the automated systems at the station. The problem, is that a bunch of these devices are listening to port 10001 on the Internet, and some of them appear to be misconfigured. How many? Let’s start with the easier question, how many IPs have port 10001 open? Masscan is one of the best tools for this, and [RoseSecurity] found over 85,000 listening devices. An open port is just the start. How many of those respond to connections with the string In-Tank Inventory Reports? Shodan reports 11,113 IPs as of August of this year. [RoseSecurity] wrote a simple Python script that checked each of those listening IPs came up with a matching number of devices. The scary bit is that this check was done by sending a Get In-Tank Inventory Report command, and checking for a good response. It seems like that’s 11K systems, connected to the internet, with no authentication. What could possibly go wrong? Continue reading “This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds”

This Week In Security: One-click, UPnP, Mainframes, And Exploring The Fog

A couple weeks ago we talked about in-app browsers, and the potential privacy issues when opening content in them. This week Microsoft reveals the other side of that security coin — JavaScript on a visited website may be able to interact with the JS embedded in the app browser. The vulnerability chain starts with a link handler published to Android, where any https://m.tiktok[.]com/redirect links automatically open in the TikTok app. The problem here is that this does trigger a redirect, and app-internal deeplinks aren’t filtered out. One of these internal schemes has the effect of loading an arbitrary page in the app webview, and while there is a filter that should prevent loading untrusted hosts, it can be bypassed with a pair of arguments included in the URI call.

Once an arbitrary page is loaded, the biggest problem shows up. The JavaScript that runs in the app browser exposes 70+ methods to JS running on the page. If this is untrusted code, it gives away the figurative keys to the kingdom, as an auth token can be accessed for the current user. Account modification, private video access, and video upload are all accessible. Thankfully the problem was fixed back in March, less than a month after private disclosure. Still, a one-click account hijack is nothing to sneeze at. Thankfully this one didn’t escape from the lab before it was fixed.

UPnP Strikes Again

It’s not an exaggeration to say that Universal Plug and Play (UPnP) may have been the most dangerous feature to be included in routers with the possible exception of open-by-default WiFi. QNAP has issued yet another advisory of ransomware targeting their devices, and once again UPnP is the culprit. Photo Station is the vulnerable app, and it has to be exposed to the internet to get pwned. And what does UPnP do? Exposes apps to the internet without user interaction. And QNAP, in their efforts to make their NAS products more usable, included UPnP support, maybe by default on some models. If you have a QNAP device (or even if you don’t), make sure UPnP is disabled on your router, turn off all port forwarding unless you’re absolutely sure you know what you’re doing, and use Wireguard for remote access. Continue reading “This Week In Security: One-click, UPnP, Mainframes, And Exploring The Fog”

This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf

There’s a bit of a panic regarding Chromium, Google Chrome, the system clipboard, and of all things, Google Doodles on the New Tab Page. It’s all about Chromium issue 1334203, “NewTabPageDoodleShareDialogFocusTest.All test fails when user gesture is enforced”. You see, Chromium has quite a large regression test suite, and Google engineers want to ensure that the Google Doodles always work. A security feature added to the clipboard handling API happened to break a Doodles test, so to fix the Doodle, the security feature was partially reverted. The now-missing feature? Requiring user interaction before a page can read or write to the clipboard.

Now you understand why there’s been a bit of a panic — yes, that sounds really bad. Pages arbitrarily reading from your clipboard is downright malicious and dangerous. And if no interaction is required, then any page can do so, right? No, not quite. So, Chrome has a set of protections, that there are certain things that a page cannot do if the user has not interacted with the page. You might see this at play in Discord when trying to refresh a page containing a video call. “Click anywhere on this page to enable video.” It’s intended to prevent annoying auto-play videos and other irritating page behavior. And most importantly, it’s *not* the only protection against a page reading your clipboard contents. See for yourself. Reading the clipboard is a site permission, just like accessing your camera or mic.

Now it’s true that a site could potentially *write* to the clipboard, and use this to try to be malicious. For example, writing rm -rf / on a site that claims to be showing off Linux command line tips. But that’s always been the case. It’s why you should always paste into a simple text editor, and not straight into the console from a site. So, really, no panic is necessary. The Chromium devs tried to roll out a slightly more aggressive security measure, and found it broke something unrelated, so partially rolled it back. The sky is not falling.
Continue reading “This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf”

This Week In Security: In Mudge We Trust, Don’t Trust That App Browser, And Firefox At Pwn2Own

There’s yet another brouhaha forming over Twitter, but this time around it’s a security researcher making noise instead of an eccentric billionaire. [Peiter Zatko] worked as Twitter’s security chief for just over a year, from November 2020 through January 2022. You may know Zatko better as [Mudge], a renowned security researcher, who literally wrote the book on buffer overflows. He was a member at L0pht Heavy Industries, worked at DARPA and Google, and was brought on at Twitter in response to the July 2020 hack that saw many brand accounts running Bitcoin scans.

Mudge was terminated at Twitter January 2022, and it seems he immediately started putting together a whistleblower complaint. You can access his complaint packet on, with whistleblower_disclosure.pdf (PDF, and mirror) being the primary document. There are some interesting tidbits in here, like the real answer to how many spam bots are on Twitter: “We don’t really know.” The very public claim that “…<5% of reported mDAU for the quarter are spam accounts” is a bit of a handwave, as the monetizable Daily Active Users count is essentially defined as active accounts that are not bots. Perhaps Mr. Musk has a more legitimate complaint than was previously thought.
Continue reading “This Week In Security: In Mudge We Trust, Don’t Trust That App Browser, And Firefox At Pwn2Own”

This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness

It’s debatable just how useful Secure Boot is for end users, but now there’s yet another issue with Secure Boot, or more specifically, a trio of signed bootloaders. Researchers at Eclypsium have identified problems in the Eurosoft, CryptoPro, and New Horizon bootloaders. In the first two cases, a way-too-flexible UEFI shell allows raw memory access. A startup script doesn’t have to be signed, and can easily manipulate the boot process at will. The last issue is in the New Horizon Datasys product, which disables any signature checking for the rest of the boot process — while still reporting that secure boot is enabled. It’s unclear if this requires a config option, or is just totally broken by default.

The real issue is that if malware or an attacker can get write access to the EFI partition, one of these signed bootloaders can be added to the boot chain, along with some nasty payload, and the OS that eventually gets booted still sees Secure Boot enabled. It’s the perfect vehicle for really stealthy infections, similar to CosmicStrand, the malicious firmware we covered a few weeks ago.
Continue reading “This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness”

This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols

So you may have gotten a Slack password reset prompt. Something like half a percent of Slack’s userbase had their password hash potentially exposed due to an odd bug. When sending shared invitation links, the password hash was sent to other members of the workspace. It’s a bit hard to work out how this exact problem happened, as password hashes shouldn’t ever be sent to users like this. My guess is that other users got a state update packet when the link was created, and a logic error in the code resulted in too much state information being sent.

The evidence suggests that the first person to catch the bug was a researcher who disclosed the problem mid-July. Slack seems to use a sane password policy, only storing hashed, salted passwords. That may sound like a breakfast recipe, but just means that when you type your password in to log in to slack, the password goes through a one-way cryptographic hash, and the results of the hash are stored. Salting is the addition of extra data, to make a precomputation attack impractical. Slack stated that even if this bug was used to capture these hashes, they cannot be used to directly authenticate as an affected user. The normal advice about turning on 2-factor authentication still applies, as an extra guard against misuse of leaked information. Continue reading “This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols”