There’s a problem in the unrar utility, and as a result, the Zimbra mail server was vulnerable to Remote Code Execution by simply sending an email. So first, unrar is a source-available command-line application made by RarLab, the same folks behind WinRAR. CVE-2022-30333 is the vulnerability there, and it’s a classic path traversal on archive extraction. One of the ways this attack is normally pulled off is by extracting a symlink to the intended destination, which then points to a location that should be restricted. unrar has code hardening against this attack, but is sabotaged by its cross-platform support. On a Unix machine, the archive is checked for any symbolic links containing the ../ pattern. After this check is completed, a function runs to convert any Windows paths to Unix notation. As such, the simply bypass is to include symlinks using ..\ traversal, which don’t get caught by the check, and then are converted to working directories.

That was bad enough, but Zimbra made it worse by automatically extracting .rar attachments on incoming emails, in order to run a virus and spam check. That extraction isn’t sandboxed, so an attacker’s files are written anywhere on the filesystem the zimbra user can write. It’s not hard to imagine how this turns into a full RCE very quickly. If you have an unrar binary based on RarLab code, check for version 6.1.7 or 6.12 of their binary release. While Zimbra was the application specifically called out, there are likely to be other cases where this could be used for exploitation.

Router Malware

A widespread malware campaign has been discovered in a bit of an odd place: running on the firmware of Small Office/Home Office (SOHO) network devices. The surprising element is how many different devices are supported by the campaign, including Cisco, Netgear, ASUS, etc. The key is that the malware is a little binary compiled for the MIPS architecture, which is used by many routers and access points.

Once in place, the malware then launches Man-in-the-Middle attacks against DNS and HTTP connections, all with the goal of compromising the Windows machines that run their connection through the compromised device. There have been mass exploit campaigns in the past, where the DNS resolver was modified on vulnerable routers, but this seems to be quite a bit more sophisticated, leading the researchers to suspect that this may be a state-sponsored campaign. There’s an odd note in the source report, that the initial exploit script makes a call to /cgi-bin/luci, which is the web interface for OpenWRT routers. We’ve reached out for more information from Lumen, so stay tuned for the details. It may very well be that this malware campaign is specifically targeting the hoard of very old, vulnerable OpenWRT-based routers out there. There may be a downside to multiple companies using old versions of the Open Source project as their SDK.

WebAssembly and Old Tricks

One of the most interesting concepts to happen recently in the browser space is WebAssembly. You have a library written in C, and want to use it with JavaScript in a browser? Compile it to WebAssembly, and you have a solution that’s faster than JavaScript, and easier to use than a traditionally compiled binary. It’s a very clever solution, and allows for some crazy feats, like Google Earth in the browser. Could there be any down side to running C in the browser? The good folks at Grav have an example of the sort of thing that could go wrong: good old buffer overflows.

Now it’s a bit different from how a standard overflow exploit works. One reason, Wasm doesn’t have address layout randomization or Data Execution Prevention. On the other hand, web assembly functions don’t reside at a memory address, but simply a function index. The RET instruction equivalent can’t jump to arbitrary locations, but just to function indexes. However, it’s still a stack, and overflowing a buffer can result in overwriting important data, like the return pointer. Time will tell whether WebAssembly exploits are going to be a big deal, or will forever be a novelty.

Intune Remote Management

In our new, brave future, remote work seems to be the new standard, and this brings some new security considerations. Example: Microsoft’s Intune remote management suite. It’s supposed to be an easy way to deploy, manage, and monitor laptops and desktops remotely. In theory, a robust remote admin suite combined with Bitlocker should make for an effective protection against tampering. Why Bitlocker? While it prevents an attacker from reading data from the disk, it also prevents tampering. For instance, there’s a really old trick, where you copy the cmd.exe binary over the top of the sticky keys, or accessibility binary. These can be launched from the login page, and results in a super-easy root shell. Bitlocker prevents this.

It sounds great, but there’s a problem. Intune can be deployed in two ways. The “user-driven” flow results in a system with more administrative capabilities entrusted to the end user, including access to the BitLocker recovery key. The only way around this is to do the setup, and then remove the Primary User and rotate the Bitlocker keys. Then there’s the troubleshooting mode, holding Shift+F10 during initial setup grants SYSTEM access to the end user. Yikes. And finally, that last gotcha to note is that a remote wipe removes user data, and deletes extra binaries from some important places, but doesn’t do any sort of file verification, so our simple sticky-keys hack would survive. Oof.

Bits and Bytes

[Jack Dates] participated in 2021 Pwn2Own, and put together an Apple Safari exploit that uses the Intel graphics kernel extensions for the escape. It’s a *very* deep dive into OSX exploitation. The foothold is an off-by-one error in a length check, which in total allows writing four bytes of arbitrary data. The key to turn this into something useful was to strew some corpses around memory — forked, dead processes. Corrupt the size of the corpse, and you can use it to free other memory that’s still in use. Use after free for the win!

The OpenSSL bug we talked about last week is still being looked into, with [Guido Vranken] leading the charge. He found a separate bug that specifically isn’t a security problem back in May, and it’s the fix for that bug that introduced the AVX512 problem we’re interested in. There still looks to be a potential for RCE here, but at least it’s proving to be non-trivial to put such an attack together.

There’s a new malware campaign, ytstealer, that is explicitly targeting YouTube account credentials. The malware is distributed as fake installers for popular tools, like OBS Studio, Auto-Tune, and even cheats and cracks for other software. When run, YTStealer looks for an authentication cookie, logs into YouTube Studio, and grabs all the data available there from the attached account. This information and cookie are encrypted and sent on to a C&C server. It’s unclear why YouTube accounts are so interesting to an attacker, but maybe we can all look forward to spammy videos getting uploaded to our favorite channels.

And finally, because there’s more to security than just computers, a delightful puzzle solve from LockPickingLawyer. Loki is a puzzle lock made from a a real padlock, and it caught the attention of our favorite lock-picker, who makes an attempt to open it. We won’t spoil any of the results, but if puzzles or locks are your jam, it’s worth a watch.