7-Zip 0-day was exploited in Russia’s ongoing invasion of Ukraine

Status
You're currently viewing only GFKBill's posts. Click here to go back to viewing the entire thread.

GFKBill

Ars Tribunus Militum
2,447
Subscriptor
Just curious how this works. If certain files are to be recognised as executable (eg for double clicking) they need to be associated by a correct file extension to them that executes the linked action (opening a file in a program or executing it).

While changing the extension with different but similarly looking characters, would that not break the link to the associated program or the fact that Windows recognises it as executable in the first place (for double clicking)?
I've just read the blog post, and I'm still not clear on that aspect.

I think it relies on the user renaming the file correctly before opening it, so this is as much a social hack as a zero day. And the contents of the .doc are a target URL to download another zip with the actual malware payload, so... just send them the url in the original email? 🤷

If your protection systems are so bad they allow a user to click a link in a word file and download a .zip containing malware, you've got other problems than 7z missing a flag from the contents of a zip 🤨
 
Upvote
-13 (0 / -13)

GFKBill

Ars Tribunus Militum
2,447
Subscriptor
2. {List}.doc (with the c being a Cyrillic character) is an inner 7z archive to which the MoTW flag does not propagate. It in turn holds:
3. {Payment Order and Attachments}.url, which gets auto-opened thanks to the lack of MoTW (other files that can be auto-opened are .js (JavaScript) and .wsf (Windows Script File)).
Thanks.

Why does the URL get opened if it's in a file with a malformed extension, and by what?
 
Upvote
14 (14 / 0)

GFKBill

Ars Tribunus Militum
2,447
Subscriptor
Hi all! I'm the threat hunter who found this vulnerability. There is some confusion as to the file extension and execution. The second archive file starts with a Cyrillic "Es" character, in-the-wild the file extension is .do[es]/.doc. Where [es] is the placeholder for the Cyrillic character which looks like a Latin "c" character. In many cases commonly used extensions are tied to applications which will open these files by default. Since .do[es] is not tied to any program Windows doesn't know how to handle it. Now the interesting thing is 7-ZIP will not only look at the file extension BUT the files magic bytes "\x37\x7A\xBC\xAF \x27 \x1C" in the header. Recognizing the 7-Zip magic bytes, 7-Zip will then proceed to process this file as an archive, the contents of which will not receive mark-of-the-web protections due to CVE-2025-0411.
Ahh, thank you! That makes sense now.
 
Upvote
21 (21 / 0)

GFKBill

Ars Tribunus Militum
2,447
Subscriptor
The dirty secret of file operations is that extensions really don’t matter much - as @gothburz says, 7-zip is scanning the first few bytes of the file to match on the magic numbers of the 7-zip header, and so 7-zip will extract that archive happily despite its extension being malformed.

I’m not sure who decided to open the contained files immediately after extracting an archive, but it seems like Windows has had problems with .wsf files in archives as a malware vector for a while now - so my guess is that this behavior is a Windows “feature” that comes from supporting the .wsf ecosystem (which can include raw .js files as well).
That's not quite what's happening, and isn't accurate either re file extensions.

Windows (unlike osx) absolutely does relies on file extension for file operations. There's a reason the attacker "broke" the extension.

In this instance the file is a zip file, named as a .doc/.do(Es) to throw the user off. 7zip doesn't recognise the file extension so looks at the headers, sees an archive, and decompresses it. The user is then presented with the .url file contained in the archive, and gets no warning that it's suspect as it has no MoTW bit set.
 
Upvote
12 (12 / 0)
Status
You're currently viewing only GFKBill's posts. Click here to go back to viewing the entire thread.