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.

The Sky Is Falling

If you’re running a Gitlab instance, haven’t grabbed the update released on the 22nd, and have imports from Github enabled, you may have a problem. CVE-2022-2884 allows arbitrary code execution when importing a malicious Github repository. The saving grace is that only registered users can perform this action, but there are still the twin dangers of a compromised account, and a user unintentionally importing a malicious repo. If you can’t get to updating right away, you can disable Github imports, to mitigate the issue.

If you’re running a Bitbucket Server or Bitbucket Data Center instance, and haven’t installed the update from the 21st, you may have a problem. Multiple endpoints in these Atlassian products have an command injection vulnerability, and if your server contains public repositories, it’s a pre-auth attack. CVE-2022-36804 scores an eye-watering 9.9 CVSS scale.

And if you use Foxit PDF Editor or PhantomPDF, those two programs have just released substantial security updates, fixing multiple RCE vulnerabilities. The most notable element of the update is bringing the V8 javascript engine up to current, as the old bundled version had known vulnerabilities in it. I’ve had to deploy Foxit for a client, humorously, because Adobe PDF reader would crash when trying to view a particular PDF generated with Adobe Photoshop. Regardless of why any of us run Foxit, get it up to date!

Snakes on a Domain

sysmon.lnk shows up in your startup folder. That, uhh, probably isn’t good, right? It’s a link to an executable in a suspicious folder, c:\users\\appdata\roaming\PpvcbBQh\ctfmon.exe, and passes update.py as an argument. This is the situation researchers at Huntress were investigating, and the story definitely goes down the rabbit hole — snake hole? ctfmon.exe is actually the IronPython interpreter, a nifty runtime that enables Python code that can talk to .net libraries. That just leaves the Python script. Malicious? Yes. We’ll call it stage 1. Stage 2 is a very large base64 encoded string, given a random variable name, decoded and then exec()‘d. Typical obfuscation stuff.

So what does the payload do? To safely examine the contents of this and other obscured variables, Huntress researchers turned to CyberChef, a nifty Open Source project for just this sort of deobfuscation. And guess what, it loads a few libraries, then deobfuscates another huge string. This time it’s a .net executable, stage 3. What does it do? There’s a tool for that, dnSpy.

Stage 3 decodes yet another obfuscated string, then launches a non-malicious msbuild.exe process. It then pulls off a “Process Hollowing” maneuver, launching a victim process and injecting foreign code for that process to run. Since MSBuild is a trusted program, most antimalware tools won’t bother it. This injection is stage 4, but the fun isn’t over. This code isn’t .Net, but is an open source execute-assembly, essentially code reverse engineered from Cobalt Strike. And yes, it’s also a loader, kicking off another .net binary, stage 5.

And yes, I too am hearing echoes of Samuel L Jackson getting tired of snakes on the plane. Stage 5 runs a script that patches AMSI, the Anti-Malware Scan Interface, clearing yet another barrier to full compromise. And finally it contained another obfuscated string, though this obfuscation was more than a simple base64 routine. Writing a decryption program in Python, they finally had a stage 6 binary, the actual Remote Access Trojan (RAT). This does the things you would expect, ensuring the persistence is in place, downloading updates, and contacting a command and control server for instructions.

What a ride. Someone really wanted their malware to be hidden. There are some indicators of compromise in the post, though it seems like this persistence chain was written to avoid leaving static IoCs — just change the final encryption key, and the whole set of nesting dolls are different.

Binary Golf 3

The Binary Golf Grand Prix 3 is now over, a fun contest to find the smallest file that will crash a program of your choice. It’s great practice for vulnerability hunting, since the goal is a simple crash, not a complex vulnerability chain like we normally cover. The minimal file size challenge generally means that the contestant figures out exactly what causes the crash. There are bonus points for doing a write-up, manipulating the program counter, reaching arbitrary code execution, and the biggest bonus for getting a fix merged for the crash discovered. Everybody wins!

Now that the contest is over, some of the entries are getting published with more to follow. To end out this week, we have two such entries that are particularly fun, because they’re retro!

Two Bytes Only

[Pierre Kim] and [Alexandre Torres] may be stretching the rules just a bit, as they’re sending their file over a network connection to a telnetd service. At two bytes, it’s an impressive feat. 0xff0xf7 is the payload, and it crashes every telnetd client based on the old BSD telnetd from 1991. 0xff is IAC, interpret as command, and 0xf7 is understood as the Erase Character command. The problem is that the telnetd binary is still in the negotiation and authentication phase of the connection, and not all of the initialization steps have been completed. Because the input processing code is shared between these states, a pointer is dereferenced that has yet to be initialized, and kablam.

Pokemon RCE

This one wasn’t a formal entry in BGGP3, but is still a great story. Nintendo has a legacy of designing add-ons for their consoles that sell briefly in Japan, and never see the light of day in the rest of the world. (Looking at you, 64DD.)

One such device was the Mobile Adapter GB, which tethered a GameBoy Color/Advance to a mobile phone for online connectivity. Pokemon Crystal had support for this gadget, and trading worked by sending HTTP requests to the Nintendo endpoint, and then checking later for responses using the POP protocol. That response was a base64 encoded data structure. Twiddling values in that struct led to a crash, but that wasn’t good enough for [Harvey Phillips], who definitely wanted arbitrary code execution on his GBC emulator.

Well never fear, Pokemon Crystal also supported Battle Colliseum, where you could dial a friend with the same game, and play together over the mobile network. Again, in 2001! Pokemon Crystal does have another quirk, and it’s already being used for crazy speedruns. 0x15 is used as a control character in the Japanese version of the game, and the game’s text engine will perform a code jump upon trying to display this character. It’s not clear exactly what the original use of these control characters were, but they’re likely a workaround to make the game run on the very limited hardware of the GBC. The 0x3F control character does a similar jump, but just happens to jump into a location just a few bytes ahead of the Mobile Adapter buffer.

And thus an exploit was finally found. Initiate a battle, replace the save to transfer with your code, and then use 0x3F 0x00 0x00 as the trainer’s name. The remote device tries to show the “wants to battle” text, but the control code triggers a jump into this “mobile script”. Even though this didn’t make the contest, [Harvey] uses the 43 bytes of shellcode to write a “3” to the screen. Beautiful.