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

September 2, 2022 by Jonathan Bennett 4 Comments

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” →

Genshin Security Impact

August 29, 2022 by Jonathan Bennett 29 Comments

An MMORPG with cute anime-style characters and maybe a bit too much inspiration taken from another classic Nintento franchise, Genshin Impact is a relatively popular game across the PlayStation, iOS, Android, and PC platforms. That last one has already generated a bit of controversy, since the PC version game includes an anti-cheat kernel driver that runs in the Windows kernel context, and on initial release that module kept running even after the game was closed.

That anti-cheat driver is back in the news, with Trend Micro discovering a ransomware campaign that includes mhyprot2.sys, the anti-cheat driver, as a component of the infection. The module is known to have vulnerabilities, and is still a signed kernel driver, so the malware campaign loads the driver and uses its functions to disable anti-malware protections.

The rest of the campaign is straightforward. Starting with access to a single domain-connected machine, an attacker uses that foothold to gain access to the domain controller. The malicious script is hosted on shared storage, and PsExec is used to run it on all the domain member machines. The real novelty here is the use of the vulnerable anti-cheat kernel driver as the anti-malware bypass. As far as we can tell, this driver is *still* signed and considered trustworthy by Windows. We join the call to Microsoft, to revoke this vulnerable driver, as it’s now actively being used in ongoing malware campaigns. For more on security, check out our weekly column on the topic,

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

August 26, 2022 by Jonathan Bennett 19 Comments

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 archive.org, 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” →

Everything You Didn’t Know You Need To Know About Glitching Attacks

August 25, 2022 by Dan Maloney 1 Comment

If you’ve always been intrigued by the idea of performing hardware attacks but never knew where to start, then we’ve got the article for you: an in-depth look at the hows and whys of hardware glitching.

Attentive readers will recall that we’ve featured [Matthew Alt]’s reverse engineering exploits before, like the time he got root on a Linux-based arcade cabinet. For something a bit more challenging, he chose a Trezor One crypto wallet this time. We briefly covered a high-stakes hack (third item) on one of these wallets by [Joe Grand] a while back, but [Matthew] offers much, much more detail.

After introducing the theory of glitching attacks, which seek to force a processor into an undefined state using various methods, [Matthew] discusses the specifics of the Trezor wallet and how the attack was planned.

His target — the internal voltage regulator of the wallet’s STM32 microcontroller — required desoldering a few caps before the attack could begin, which was performed with a ChipWhisperer. After resolving a few initial timing issues, he was able to glitch the chip into dropping to the lowest level of readout protection, which gave access to the dongle’s SRAM through an ST-Link debugger.

While this summary may make the whole thing sound trivial, it’s obvious that the attack was anything but, nor was the effort that went into writing it all up. The whole thing reads a little like a techno-thriller, and there’s plenty of detail there if you’re looking for a tutorial on chip glitching. We’re looking forward to part 2, which will concentrate on electromagnetic fault-injection using a PicoEMP and what looks like a modified 3D printer.

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

August 19, 2022 by Jonathan Bennett 9 Comments

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

August 12, 2022 by Jonathan Bennett 9 Comments

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” →

Photo of the MCH2022 badge's screen, showing the "Hack me if you can" app's start splashscreen, saying "Service is accessible on IP ADDRESS : 1337"

MCH2022 Badge CTF Solved, With Plenty To Learn From

August 7, 2022 by Arya Voronova 3 Comments

Among all the things you could find at MCH2022, there were a few CTFs (Capture The Flag exercises) – in particular, every badge contained an application that you could try and break into – only two teams have cracked this one! [dojoe] was part of one of them, and he has composed an extensive reverse-engineering story for us – complete with Ghidra disassembly of Xtensa code, remote code execution attempts, ROP gadget creation, and no detail left aside.

There was a catch: badges handed out to the participants didn’t contain the actual flag. You had to develop an exploit using your personal badge that only contained a placeholder flag, then go to the badge tent and apply your exploit over the network to one of the few badges with the real flag on them. The app in question turned out to be an echo server – sending back everything it received; notably, certain messages made it crash. One man’s crashes are another man’s exploit possibilities, and after a few hacking sessions, [dojoe]’s team got their well-deserved place on the scoreboard.

If you always thought that firmware reverse-engineering sounds cool, and you also happen to own a MCH2022 badge, you should try and follow the intricately documented steps of [dojoe]’s writeup. Even for people with little low-level programming experience, repeating this hack is realistic thanks to his extensive explanations, and you will leave with way more reverse-engineering experience than you had before.

The MCH2022 badge is a featureful creation of intricate engineering, with the ESP32 portion only being part of the badge – we’re eager to hear about what you’ve accomplished or are about to accomplish given everything it has to offer!