A particularly nasty 0-day was discovered in the wild, CVE-2021-40444, a flaw in how Microsoft’s MSHTML engine handled Office documents. Not all of the details are clear yet, but the result is that opening a office document can trigger a remote code execution. It gets worse, though, because the exploit can work when simply previewing a file in Explorer, making this a potential 0-click exploit. So far the attack has been used against specific targets, but a POC has been published.
It appears that there are multiple tricks that should be discrete CVEs behind the exploit. First, a simple invocation of mshtml:http in an Office document triggers the download and processing of that URL via the Trident engine, AKA our old friend IE. The real juicy problem is that in Trident, an iframe can be constructed with a .cpl URI pointing at an inf or dll file, and that gets executed without any prompt. This is demonstrated here by [Will Dormann]. A patch was included with this month’s roundup of fixes for Patch Tuesday, so make sure to update. Continue reading “This Week In Security: Office 0-day, ForcedEntry, ProtonMail, And OMIGOD”→
A PoC was just published for a potentially serious flaw in the Ghostscript interpreter. Ghostscript can load Postscript, PDF, and SVG, and it has a feature from Postscript that has been a continual security issue: the %pipe% command. This command requests the interpreter to spawn a new process — It’s RCE as part of the spec. This is obviously a problem for untrusted images and documents, and Ghostscript has fixed security vulnerabilities around this mis-feature several times over the years.
This particular vulnerability was discovered by [Emil Lerner], and described at ZeroNights X. That talk is available, but in Russian. The issue seems to be a bypass of sorts, where the pipe command appears to be working in the /tmp/ directory, but a simple semicolon allows for an arbitrary command to be executed. Now why is this a big deal? Because ImageMagick uses Ghostscript to open SVG images by default on some distributions, and ImageMagick is often used for automatically resizing and converting images for web sites. In [Emil]’s presentation, he uses this flaw as part of an attack chain against three different companies.
I was unable to reproduce the flaw on my Fedora install, but I haven’t found any notice of it being fixed in the Ghostscript or Imagemagick changelogs either. It’s unclear if this problem has already been fixed, or if this is a true 0-day for some platforms. Either way, expect attackers to start trying to make use of it.
We’ve covered a lot of ransomware here, but we haven’t spent a lot of time looking at the decryptor tools available to victims. When ransomware gangs give up, or change names, some of them release a decryption tool for victims who haven’t paid. It’s not really a good idea to run one of those decryptors, though. The publishers don’t have a great track record for taking care of your data, after all. When a decryptor does get released, and is verified to work, security researchers will reverse engineer the tool, and release a known-good decryption program.
The good folks at No More Ransom are leading the charge, building such tools, and hosting a collection of them. They also offer Crypto Sheriff, a tool to identify which ransomware strain got your files. Upload a couple encrypted files, and it will inform you exactly what you’re dealing with, and whether there is a decryptor available. The site is a cooperation between the Dutch police, Interpol, Kaspersky, and McAfee. It may surprise you to know that they recommend reporting every ransomware case to the authorities. I can confirm that at the very least, the FBI in the US are very interested in keeping track of the various ransomware attacks — I’ve fielded a surprise call from an agent following up on an infection.
Windows security problems due to insecure drivers is nothing new, but this one is kinda special. Plug in a Razer mouse, tell the install dialog you want to install to a non-standard location, and then shift+right click the Explorer window. Choose a powershell, and boom, you now have a SYSTEM shell. It’s not as impressive as an RCE, and it requires hands-on the machine, but it’s beautiful due to the simplicity of it.
The problem is a compound one. First, Windows 10 and 11 automatically downloads and starts the install of Razer Synapse when a Razer device is plugged in. Note it’s not just Razer, any branded app that auto installs like this is possibly vulnerable in the same way. The installation process runs as system, and because it was started automatically, there is no admin account required. The second half of the issue is that the installer itself doesn’t take any precautions to prevent a user from spawning additional processes. There isn’t an obvious way to prevent the launch of Powershell from within the FolderPicker class, so an installer running as SYSTEM would have to go out of its way to drop privileges, to make this a safe process. The real solution is for Microsoft to say no to GUI installers bundled with WHQL signed drivers. Continue reading “This Week In Security: Through The Mouse Hole, Zoom RCE, And Defeating Defender”→
Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.
We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.
Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.
During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.
The folks at Pen Test Partners decided to take a look at electric vehicle chargers. Many of these chargers are WiFi-connected, and let you check your vehicle’s charge state via the cloud. How well are they secured? Predictably, not as well as they could be.
The worst of the devices tested, Project EV, didn’t actually have any user authentication on the server side API. Knowing the serial number was enough to access the account and control the device. The serial numbers are predictable, so taking over every Project EV charger connected to the internet would have been trivial. On top of that, arbitrary firmware could be loaded remotely onto the hardware was possible, representing a real potential problem.
The EVBox platform had a different problem, where an authenticated user could simply specify a security role. The tenantadmin role was of particular interest here, working as a superadmin that could see and manage multiple accounts. This flaw was patched within an impressive 24 hours. The EVBox charger, as well as several other devices they checked had fundamental security weaknesses due to their use of Raspberry Pi hardware in the product. Edit: The EVBox was *not* one of the devices using the Pi in the end product.