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.

Zoom RCE

Researchers from Sector 7, part of Computest, pulled off an impressive hack at Pwn2Own, achieving an RCE via the Zoom client. The caveat is that the attacker has to be accepted as a contact, either manually, or through being in the same organization. The central vulnerability is CVE-2021-30480, a heap buffer overflow, a result of a static buffer being allocated for a string generated by a connecting remote client. While the overflow is a very powerful vulnerability, turning it into a full exploit took quite some effort.

To pull it off, the researchers discovered a data leak vulnerability, based on URI confusion in image links. A malformed contact request could be sent with an odd member image link. In normal usage, the pic_relative_url field would start with a leading “/”, and specify a picture at the marketplacecontent.zoom.us domain. In the strange contact request they crafted, they used a relative URL that didn’t start with that leading slash, but instead started with a partial domain name, like example.org. When the Zoom client attempted to download the remote image, it ended up making the request from marketplacecontent.zoom.usexample.org/..., a domain an attacker could control. This URL confusion bug could be combined with the overflow mentioned above to leak data about the current memory state of the victim machine.

The last vulnerability used was a seemingly insignificant one, the maximum size limit of messages could be sidestepped by sending a GIF from GIPHY. Additionally, sending multiple copies didn’t trigger multiple downloads, but did cause multiple copies to be made in memory. Pushing these copies into memory allowed the researchers to set up their exploit chain, with the full attack hitting about a 50% success rate when confined to the 5 minute limitations of the contest.

Update 8/27/21: A company spokesperson reached out to Hackaday with the following statement on this issue:

We take security very seriously and thank Computest for their work to help us enhance the security of our platform through this responsible disclosure. We also want to thank the Zero Day Initiative for allowing Zoom to sponsor and participate in the Pwn2Own Vancouver 2021 competition that led to the discovery of these issues. The issues have been addressed with a server-side fix as well as a client-side fix in Zoom version 5.6.3, released on April 19, 2021.

2nd Opinion on Pegasus

Citizen Lab has released an outside review of Amnesty International’s work on the NSO Group’s Pegasus Spyware program. Their investigation has found that the technical aspects of Amnesty’s findings were correct — the infection analysis, IOCs, and identified infrastructure all seem to be correct. The biggest question raised by Amnesty International’s report is entirely unaddressed: the list of targets. The source and veracity of that document is still entirely uncorroborated.

Long-term Windows Defender Bypass

The research group, APTortellini has published their guide to defeating Windows Defender. A few commenters on this particular write-up scoffed at the first step, elevating to SYSTEM. You might even wonder, what’s the point if you’ve already compromised a machine to the point of being root? Getting SYSTEM access is only the beginning for an actual malicious campaign. This research is all about how to nullify Windows Defender without actually disabling it.

The first thing to know is that modern Windows systems have adopted quite a few elements from Unix, with the Windows legacy stuff bolted on top. To make that point clear, note that a Windows 10 C: drive is actually located at \Device\HarddiskVolumeX, with a series of symbolic links to make the C: notation work. One of those links is \SystemRoot, which by default points to \Device\BootDevice\Windows. Even for SYSTEM, that link can’t be modified, but it can be deleted and recreated. That particular path happens to be part of where Windows Defender looks to load its back-end driver, WdFilter.sys.

The technique essentially consists of remapping \SystemRoot to a fake Windows directory, and then restarting the Windows Defender service, causing it to reload the driver from the spoofed location. The replacement driver still must be signed, but that still leaves a great amount of leeway. In the write-up, they used the RWEverything driver. Recreate the original symlink, and you have a placebo Defender that looks like it’s working properly, and a arbitrary-but-signed driver running instead.

$610 Million Recovered

Poly Network is a Decentralized Finance protocol. I’m not going to get into the weeds describing what exactly that means, as this is a security column, not This Week in Blockchain. Just know that it’s a blockchain platform that uses smart contracts to accomplish something similar to a bank or investment firm. Poly Network had a problem earlier this month, where just over $600 million was moved out of their control. This feat seems to have been the result of a vulnerability in the smart contracts themselves. See SlowMist for more technical details.

The new news is that [Mr. White Hat] has actually returned control of all of the stolen funds back to the Poly Network. The whole story is bizarre, and reminiscent of the attack on The DAO, many years ago.

More Suspicious Activity in Iran

On the heels of one hacktivist group targeting Iranian infrastructure, we have the story of another group breaking into the security camera systems at the Evin Prison in Tehran, and releasing the video evidence detailing prisoner treatment. Part of the dump is a security camera showing the displays in the main security room. It really is a case of real life imitating art.

This clip of a security control room at Iran's most notorious prison being shut down by hackers is straight out of a movie.

Hackers are now leaking stolen CCTV from across the Evin prison to highlight the abuse of inmates, per @AP.pic.twitter.com/Ts2jbKmoqL

— Ed Clowes (@EdClowes) August 24, 2021

This attack has been claimed by a group calling themselves “The Justice of Ali.” At some point, the question must be asked whether these attacks are really grassroots efforts from independent hackers. It’s easy to imagine that these are simply fronts all run by western intelligence agencies.

T-Mobile Update

Remember the T-Mobile breach? [John Binns] has claimed credit for it, and apparently provided sufficient evidence to convince the Wall Street Journal of that claim. He claims that he found an unsecured router by scanning the internet, and used that foothold to access an internal data center network. This likely means he was scanning for one of the trivial RCEs that we’ve covered in the last few months, and found a gateway that hadn’t yet been updated. His past history reads like a bad spy novel, with about half of it being believable. It’s still unclear if he actually sold the data to anyone.