This Week In Security: .zip Domains, Zip Scanning

The world may not be ready, but the .zip Top Level Domain (TLD) is here. It’s a part of the generic TLD category, which was expanded to allow applications for custom TLDs. Google has led the charge, applying for 101 such new TLDs, with .zip being one of the interesting ones. Public registration for .zip domains has been open for a couple weeks, and some interesting domains have been registered, like update.zip, installer.zip, and officeupdate.zip.

The obvious question to ask is whether this new TLD can be abused for scamming and phishing purposes. And the answer is yes, sure it can. One of the trickiest ways is to use the AT symbol @ in a URL, which denotes user info at the beginning of the URL. It usually is used to include a username and password, like http://username:password@192.168.1.1/. That is pretty obvious, but what about https://google.com@bing.com? Still looks weird. The catch that really prevents this technique being abused is that slashes are disallowed in user data, so a abusive URL like https://google.com∕gmail∕inbox@bing.com is right out.

Except, take a look at that last link. Looks like it has slashes in it, so it should take you to google, and ignore the AT symbol. But it doesn’t, it goes to Bing. You may have guessed, it’s Unicode shenanigans again. Those aren’t slashes, they’re U2215, the division slash. And that means that a .zip TLD could be really sneaky, if the apparent domain is one you trust.

Troy Hunt has some thoughts on the matter. The Godfather of compromised passwords points out that URLs are already ridiculously hard to parse at times, and once Unicode tricks are part of the problem, it’s basically impossible to tell a good URL by eye. His final gift: attachment.zip

Scanning Inside Zips

[Andrew Brandt] discovered something odd, as a part of his security research. He uses Microsoft Sharepoint to share live samples of malware, always password protected with “infected”. Just recently those files got flagged as containing malware in Sharepoint.

For normal users, finding malware in zip files is great. For a security researcher, it’s a huge hassle. But how is the Sharepoint service looking inside encrypted zip files? It’s simple, Microsoft is automatically trying the most common passwords, as well as scraping user emails for obvious patterns like the password is “$password”. The default zip encryption in Windows, however, is notoriously insecure. Even so, it’s a bit unnerving for a cloud vendor to be automatically decrypting files in this manner.

Vulnerable Addons

There are a couple of high-priority vulnerabilities in web plugins this week. Up first is Essential Addons for Elementor, which has a flaw allowing an unauthenticated user to take over any user’s account. It’s a byproduct of the new password reset functionality, which fails to actually verify the password reset key. Considering that this WordPress plugin is installed on over a million sites, that’s a big problem. The flaw only exists between 5.4.0 and 5.7.2, with that release containing the fix. Make sure to patch right away, as this is a trivial problem, and now fully disclosed in the public.

And over on PrestaShop, there’s a really nasty problem in a module called possearchproducts. In that one, an HTTP request can trigger an SQL injection attack, leading to full admin access to the site. The worst part is this vulnerability is accessible even if the module is installed but not active on the site. It’s being actively used to steal credit card information. The author of this plugin seems to have abandoned development, and is not responding to attempts to contact, so this looks like one to uninstall right away.

BlackLotus Fallout

Secure Boot on Windows has been broken by BlackLotus. This technique was found in the wild, and announced just a couple weeks ago. Since then there’s been a patch and workaround found, allowing BlackLotus to continue to bypass Secure Boot, and start running malware very early in the boot chain.

The latest bypass takes advantage of existing secure boot binaries, that themselves have bugs, to get a toe-hold into the boot process. The solution is to add those binaries to the list of disallowed EFI binaries. The only problem is that those binaries are key to booting the Windows Install disks, and a handful of other tools. So the solution is to roll the fix out very slowly.

You can get the update now, but it’s a hassle, and intentionally so. In July a second update will make the process simpler, but still not revoke the binary signatures by default. And finally in 2024, the revocation update will roll out for everyone. If you’re not using it, this doesn’t really apply, but any user of Secure Boot for system integrity should take a close look at this one.

Bits and Bytes

IPv6 is the relatively new kid on the Internet Protocol block, and as such, there’s a bunch of code paths that haven’t been as well tested as their old, IPv4 cousins. It’s true in the Linux kernel as well, evidenced by the remote kernel panic that can be induced by a single IPv6 packet.

There’s another vm2 escape this week. This seems like an instance of one bug discovery leading to another, as we covered vm2 escapes about a month ago, too. This library is intended to allow running untrusted JavaScript code safely, and gets used by quite a few big vendors. This escape is pretty simple, and abuses error handling to get to real execution.

The Wemo Mini Smart Plug V2 has a FriendlyName problem. Namely, that the bounds checking when setting said name happens in the browser, and sending an un-Friendly Name causes a buffer overflow. The overflow can be leveraged for Remote Code Execution, and could possibly be triggered via the Wemo cloud service. The device is passed its end of life, so no fixes are coming. On the plus side, these devices run an ancient fork of OpenWRT, so it seems like a great opportunity to jailbreak and update to a modern release. Happy Hacking!

17 thoughts on “This Week In Security: .zip Domains, Zip Scanning

  1. for “SCANNING INSIDE ZIPS” perhaps Andrew could use a repeating large binary pattern, like an OTP but not “One time”, and XOR all the data with it. 1kB would do, it can be the same pattern, it’s just a cipher really.

    1. After both Sharepoint and email servers blocked encrypted zip files I tried to share, I tried several different ways to directly encrypt the files I needed to share.

      Even using my own implementation of AES – trying both block encryption and stream (XOR) encryption – the services detected use of encryption and blocked the encrypted files.

      I also tried using my own implementations of the Two Fish and Three Fish algorithms. While they weren’t detected as “encrypted”, they were still still flagged as being “unable to analyze”, so also blocked.

      I finally had to copy the encrypted files to an USB drive and ship that by over night express.

      Since then, my employer’s IT department has configured our PCs to only read/write registered encrypted USB drives. This means that to send/receive confidential files to/from customers, my coworkers and I have to request these approved USB drives and send them to customers (either with files we are sending or for files the customers need to send to us).

      This process will just get harder when our customers start implementing similar restrictions.

  2. Microsoft is pretty bad at the moment, it’s all about spying on people for advertising purposes.
    But.. there is piggy-backing on top of that for other purposes, don’t kid yourself.

    1. If Apple hadn’t started it, and Google jumped in after them, they wouldn’t feel like they could get away with it.

      Go into the settings on edge and search “shopping”. I disable everything that comes up, uninstall Bing and use Google search.

      But I cannot set new tab page, that defaults to bing search. So I settle for unstalling an adblocker for when windows inevitably and against my express settings launches edge. And run Chrome as my default browser.

  3. If he is storing his password protected files with easy passwords, well, just use better ones.

    As for the scanning, encrypted zips show the file names without needing to decrypt, so a scanner could just check for names and would find suspicious files easy enough. And if he things malware researches should be exempted of scanning, well, use some other system specialized in malware/virus storage, maybe ? Or some secure compression/encryption mechanism, instead of relying on simple zip ?

    1. Why not 7z with encrypted filenames and a stronger non-dictionary password. Also, I imagine AI is being trained on password lists, so it’s going to find them much more easily in future.

  4. there is no need to know any password: zip archives encrypt the data but not the metadata.
    file size and crc are always available and the antivirus can use them as a fingerprint:

    $ unzip -ll eicar.zip
    Archive: eicar.zip
    Length Method Size Cmpr Date Time CRC-32 Name
    ——– —— ——- —- ———- —– ——– —-
    68 Stored 68 0% 05-19-2023 17:43 6851cf3c eicar.com
    ——– ——- — ——-
    68 68 0% 1 file

  5. Security minded browsers should respond by intentionally misidentify the .zip TLD as a zip file and therefore not displaying properly. It would stop most people from buying those TLDs for anything but malicious purposes, thereby making the TLD worthless.

  6. Interestingly Firefox warns when going to a URL containing user data when the page doesn’t require authentication. That’s a good move, and should really reduce the success rate of that particular attack.

  7. Don’t forget that Microsoft’s fix for BlackLotus will render ALL existing windows boot/install media useless. I haven’t read any solutions for this yet.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.