This Week in Security: Exchange 0-day, Doppelgangers, And Python Gets Bit in the TAR

-

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.



from Blog – Hackaday https://ift.tt/ibLwI0f

Comments

Post a Comment

Popular posts from this blog

Modern Radio Receiver Architecture: From Regenerative to Direct Conversion

-
Image
Modern radio receivers have a distinct advantage over the common early designs which I covered in my previous article . Most of the receivers you will have worked with over the past couple decades are designs by Edwin Armstrong ; regenerative, superregenerative, or most commonly superheterodyne. These are distinguished by a few fascinating key traits that bring both benefits and drawbacks. Today let’s dive into Mr. Armstrong’s receivers. I’ll also talk about DC receivers which, despite the name, are not made to listen to batteries. These are receivers you are much more likely to encounter in modern equipment. Regenerative and Superregenerative The regenerative receiver is all about doing more with less. You still see some of these in simple applications like RF remote controls. The idea derives from how an oscillator works. In a simple way of thinking, an oscillator is an amplifier with enough positive feedback that any tiny signal at the right frequency will amplify and then, throu...
Get this one»

Hackaday Links: May 31, 2020

-
We begin with sad news indeed as we mark the passing of Marcel van Kervinck on Monday. The name might not ring a bell, but his project, the Gigatron TTL computer , certainly will. We did a deep dive on the microprocessor-less computer a while back, and Marcel was a regular at conferences and on the Gigatron forums, supporting users and extending what the computer can do. He was pretty candid about his health issues, and I’ll add that when I approached him a few weeks ago out of the blue about perhaps doing a Hack Chat about Gigatron, he was brutally honest about how little time he had left and that he wouldn’t make it that long. I was blown away by the grace and courage he displayed. His co-conspirator Walter Belger will carry on the Gigatron mission, including joining us for a Hack Chat on June 24. In the meantime, this might be a great time to pick up a Gigatron kit before they’re all sold out and get busy soldering all those delicious through-hole TTL chips. May of 2020 is the mo...
Get this one»

Homebrew 68K Micro-ATX Computer Runs Its Own OS

-
Image
We’re no stranger to home built Motorola 68000 computers here at Hackaday, but more often than not, they tend to be an experiment in retro minimalism. The venerable processor is usually joined by only a handful of components, and there’s an excellent chance they’ll have taken up residence on a piece of perfboard. Then [NotArtyom] sent in his Blitz , and launched the bar into the stratosphere. Make no mistake, the Blitz isn’t just some simple demo of classic chips. The open hardware motherboard has onboard floppy, IDE, and PS/2 interfaces, with a trio of 8-bit ISA expansion slots for good measure. The  Motorola 68030 CPU is humming along at 50 MHz, with 4 MB of RAM and 512 KB of ROM along for the ride. Designed to fit the Micro-ATX motherboard standard, you can even mount the Blitz in a contemporary PC case and run it on a standard ATX power supply. An earlier prototype of the Blitz motherboard. As if the hardware wasn’t impressive enough, [NotArtyom] went ahead and created hi...
Get this one»