There’s a bit of a panic about Chromium, Google Chrome, the system clipboard, and most importantly, Google Doodles on the New Tab page. This is Chromium issue 1334203, “NewTabPageDoodleShareDialogFocusTest.All test fails when user gesture is applied”. You see, Chromium has a pretty big suite of regression tests, and Google engineers want to make sure Google Doodles still work. A security feature added to the clipboard management API broke a Doodles test, so to fix the Doodle, the security feature was partially rolled back. The now missing feature? Requires user interaction before a page can read or write to the clipboard.
Now you understand why there was a bit of a panic – yes, that sounds really bad. Pages read arbitrarily from your clipboard are downright malicious and dangerous. And if no interaction is required, any page can do that, right? No, not quite. So, Chrome has a set of protections, according to which there are certain things that a page cannot do if the user has not interacted with the page. You can see it in play in Discord when you try to refresh a page that has a video call. “Click anywhere on this page to activate the video.” It is intended to prevent the autoplay of annoying videos and other irritating page behavior. Importantly, it’s *not* the only protection against a page reading from your clipboard. See for yourself. Reading the clipboard is a site permission, as is accessing your camera or mic.
Now, it’s true that a site could potentially *write* to the clipboard and use it to try to be malicious. For example, write
rm -rf / on a site that claims to show Linux command line tricks. But that has always been the case. This is why you should always paste into a simple text editor, not directly into the console from a site. So really, no panic is necessary. The Chromium devs tried to deploy a slightly more aggressive security measure and found it broke something unrelated, so partially rolled it back. The sky does not fall.
The sky is falling
If you’re running a Gitlab instance, haven’t checked out the update released on the 22nd, and imports from Github are enabled, you may have a problem. CVE-2022-2884 allows execution of arbitrary code when importing a malicious Github repository. The saving grace is that only registered users can perform this action, but there is always the double danger of a compromised account and a user unwittingly uploading a malicious repository. If you can’t update immediately, 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 since the 21st, you may have an issue. Several endpoints in these Atlassian products have a command injection vulnerability, and if your server contains public repositories, this is a pre-authorization attack. CVE-2022-36804 gets a stunning CVSS scale of 9.9.
Snakes on a field
sysmon.lnk appears in your startup folder. This, uh, probably isn’t good, is it? It’s a link to an executable in a suspicious folder,
update.py as an argument. This is the situation the Huntress researchers were investigating, and the story is definitely going down the rabbit hole – snake hole?
ctfmon.exe is actually the IronPython Interpreter, a nifty runtime that allows Python code to talk to
.net libraries. That just leaves the Python script. Malicious? Yes. We’ll call it step 1. Step 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 obfuscated variables, Huntress researchers turned to CyberChef, a nifty open-source project for this kind of de-obfuscation. And guess what, it loads a few libraries and then deobfuscates another huge string. This time it’s a .net executable, step 3. What does it do? There is a tool for this, dnSpy.
Step 3 decodes yet another obfuscated string, then throws a non-malicious
msbuild.exe treat. It then performs 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 step 4, but the fun isn’t over. This code is not .Net, but is an open source runtime assembly, essentially reverse-engineered code from Cobalt Strike. And yes, it’s also a loader, which launches another .net binary, step 5.
And yes, I too hear echoes of Samuel L Jackson getting tired of snakes on the plane. Step 5 runs a script that fixes AMSI, the Anti-Malware Scanning Interface, removing yet another obstacle to a full compromise. And finally, it contained another obfuscated string, although this obfuscation is more than just a base64 routine. By writing a decryption program in Python, they finally had a level 6 binary, the real Remote Access Trojan (RAT). This does what you’d expect, making sure persistence is up, downloading updates, and contacting a command and control server for instructions.
What a journey. Someone really wanted their malware hidden. There are a few indicators of compromise in the post, though it looks like this persistence chain was written to avoid leaving static IoCs – just change the final encryption key, and the nesting dolls set is different.
Binary Golf 3
Binary Golf Grand Prix 3 is now over, a fun contest to find the smallest file that will crash a program of your choice. This is great practice for vulnerability hunting, as the goal is a simple crash, not a complex vulnerability chain like we normally cover. The minimum file size challenge usually means the competitor determines exactly what is causing the crash. There are bonus points for doing a write-up, manipulating the program counter, achieving arbitrary code execution, and the biggest bonus for getting a merged fix for the discovered crash. Everyone wins!
Now that the contest is over, some of the entries are posted and more will follow. To wrap up this week, we have two such entries that are especially fun, because they’re retro!
Two bytes only
[Pierre Kim] and [Alexandre Torres] can stretch the rules a bit, as they send their file over a network connection to a telnetd service. At two bytes, that’s an impressive feat.
0xff0xf7 is the payload, and it crashes every telnetd client based on the old 1991 BSD telnetd.
0xff is IAC, interpreted as a command, and
0xf7 means the Erase Character command. The problem is that the telnetd binary is still in the connection negotiation and authentication phase, and not all initialization steps have been completed. Because the input processing code is shared between these states, a pointer is dereferenced that has not yet been initialized, and kablam.
This one wasn’t a formal entry in BGGP3, but it’s still a great story. Nintendo has a habit of designing add-ons for its 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 GB Mobile Adapter, which connected a GameBoy Color/Advance to a cell phone for online connectivity. Pokemon Crystal had support for this gadget, and trading worked by sending HTTP requests to the Nintendo endpoint, then later checking the responses using the POP protocol. This response was a base64 encoded data structure. Twiddling values in this structure led to a crash, but it wasn’t good enough for [Harvey Phillips]who absolutely wanted the execution of arbitrary code on his GBC emulator.
Fear not, Pokemon Crystal has also supported Battle Colliseum, where you can call a friend with the same game and play together over the mobile network. Again, in 2001! Pokemon Crystal has 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 when trying to display this character. It’s unclear what the original use of these control characters was, but they’re likely a workaround to get the game to work on the very limited GBC hardware. The
0x3F The control character makes a similar jump, but just happens to jump to a slot just a few bytes before the mobile adapter buffer.
And that’s how an exploit was finally found. Start a battle, replace the save to transfer with your code, then use
0x3F 0x00 0x00 as the name of the trainer. The remote device tries to display the text “wants to fight”, but the control code triggers a jump in this “mobile script”. Even if it didn’t make the contest, [Harvey] uses the 43 bytes of shellcode to write a “3” to the screen. Beautiful.