According to researchers at GTSC, there’s an unpatched 0-day being used in-the-wild to exploit fully patched Microsoft Exchange servers. When they found one compromised server, they made the report to Microsoft through ZDI, but upon finding multiple Exchange servers compromised, they’re sounding the alarm for everyone. It looks like it’s an attack similar to ProxyShell, in that it uses the auto-discover endpoint as a starting point. They suspect it’s a Chinese group that’s using the exploit, based on some of the indicators found in the webshell that gets installed.
There is a temporary mitigation, adding a URL-based request block on the string .*autodiscover\.json.*\@.*Powershell.. The exact details are available in the post. If you’re running Exchange with IIS, this should probably get added to your system right now. Next, use either the automated tool, or run the PowerShell one-liner to detect compromise: Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200. This one has the potential to be another really nasty problem, and may be wormable. As of the time of writing, this is an outstanding, unpatched problem in Microsoft Exchange. Come back and finish the rest of this article after you’ve safed up your systems.
Digital Dopplegangers
[Connor Tumbleson] got a weird surprise a couple weeks ago, via an email from another developer, [Andrew], who had been hired to pretend to be [Connor] for a job interview. Say what? This scam is a new one on us, and seems to go like this: Scammer picks a GitHub account with a professional picture and impressive activity, and then goes and creates an Upwork account in that senior developer’s name. This includes a deep dive into the publicly available data on the target developer. Next, our scammer contacts another GitHub account holder, with less impressive credentials — a junior developer, and makes a job offer: work with a development team that doesn’t speak English, doing some development work and working as a face of the team when working with North American clients. The only iffy part of the job is that the new hire will conduct interviews using the name of teammates.
This brings us to [Andrew], who was the “junior dev” in this scenario. It all seemed legitimate, until he realized that the team member he was supposed to be representing wasn’t actually part of the team, and reached out to the real [Connor], who started digging.
It boils down to an employment scam, trying to use the name and reputation of a skilled developer to land a contract. Keep an eye out for fake profiles on Upwork or similar employment sites. And if you get an offer that sounds similar to the one that bit [Andrew], be wary. And finally, if you hired a developer through Upwork, maybe consider whether you really confirmed that your new dev is who they claimed to be.
Changing Times Byte Python in the TAR
For this bug, what we’re gonna do right here is go back, way back, back in time. CVE-2001-1267 was the original tar directory traversal vulnerability. You could include ../ as part of the file path in tarballs, and tar would happily follow the directory path wherever it pointed. Want to overwrite /etc/passwd? No problem. Well, the developers at GNU realized that was a vulnerability, and fixed GNU with version 1.13.20. Fast forward to 2007, and [Jan Matejek] noticed that Python’s tar unpacker had the same problem. After some debate, the issue was decided to be notabug, and closed with documentation updates. The issue was raised *again* in 2017, and never acted upon.
And now, we come to the recent findings by Trellix. Researchers there first thought they had discovered a 0-day in Python, only to realize it was good old CVE-2007-4559, still lurking. Even though the danger was documented, had some Python developers mistakenly introduced vulnerable code into their projects by using the Python tarfile module insecurely? On GitHub, searching for "Import tarfile" language:Python returns 300,000 hits. Checking a subset of those projects returned a 61% vulnerability rate. Yikes!
Chrome Root
Google Chrome is doing something new, that’s potentially controversial, that just might break things — so just another Friday. This one is a bit special, though. Google Chrome is going to begin shipping its own root store. That’s essentially the master list of what HTTPS certificates are considered valid by the browser. The big advantage here is this means that Chrome will behave the same across all platforms, no longer depending on the list of certificates provided by the OS. Of course, this also means that Google controls who gets to use HTTPS. If there is a certificate that has been manually added on the OS side, Chrome will pick it up and also honor it. We’ll see.
Intermittent Encryption, and Other Byte-Sized Stories
Ransomware campaigns have a new trick up their collective sleeves — intermittent encryption. It’s the observation that not every byte in a target file needs to be encrypted, in order to make it unusable for the owner. Encrypting every other 16 bytes makes for faster encryption and slower detection. There are other trends Sentinel One have discovered, like ransomware written in Rust and Go, and even more variations in Ransomware as a Service.
WhatsApp just published an update for iOS and Android that fixes a pair of remote code execution vulnerabilities, both relating to the handling of video. In one case it was an integer overflow reachable through a live video call, and the other was an integer underflow in handling a video file.
Twitter had a really nasty issue, where a password reset didn’t actually invalidate app tokens. So if someone took over an account and logged in on the mobile app, changing the password didn’t terminate access. The problem has been fixed, and anyone affected has been notified.
HP has issued firmware updates for many of their printers, fixing a pair of vulnerabilities that can enable RCE on many of their network printers. There’s not a lot of information about the problem available, but an attacker with persistent network access in an oft-overlooked device is scary enough. Just wait for the inevitable wave of driver vulnerabilities where a malicious printer can trigger arbitrary code execution on a machine trying to print to it.
This Week in Security: Exchange 0-day, Doppelgangers, And Python Gets Bit in the TAR
Source: Manila Flash Report
0 Comments