Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: SANS Internet Storm Center SANS Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Crashing explorer.exe with(out) a click

Published: 2020-03-30
Last Updated: 2020-03-30 06:12:15 UTC
by Jan Kopriva (Version: 1)
0 comment(s)

In a couple of my recent diaries, we discussed two small unpatched vulnerabilities/weaknesses in Windows. One, which allowed us to brute-force contents of folders without any permissions[1], and another, which enabled us to change names of files and folders without actually renaming them[2]. Today, we’ll add another vulnerability/weakness to the collection – this one will allow us to cause a temporary DoS condition for the Explorer process (i.e. we will crash it) and/or for other processes. It is interesting since all that is required for it to work is that a user opens a link or visits a folder with a specially crafted file.

The vulnerability lies in the way in which URL links (.URL files) and Shell Links (.LNK files) are handled by Windows when they are self-referential (i.e. they “link to themselves”). The principle behind the vulnerability is not new – a similar issue was supposedly present in the early versions of Windows 7 with self-referential symlinks – but since I didn’t find any write-up for the issue with URLs and LNKs, I thought I’d share this version of the vulnerability here. I should mention that I informed Microsoft of the issue and they decided not to patch it due to its limited impact.

With URL links, crafting a self-referential one is quite simple. URL shortcuts are basically just INI files and you may create one in the same way you would create a LNK shortcut (i.e. right click in a folder -> New -> Shortcut), you just have to input URL as the target. If we were to create a shortcut this way, which points to https://isc.sans.edu/, we would end up with following contents inside the resulting URL file.

The structure is quite simple, but we may simplify it further still, since for our purposes, we only need to specify the [InternetShortcut] section and a target for the link. A file with the following contents will work the same way as the previous one.

In order to create a self-referential URL file, we simply need to point the URL property to the path where our file is located.

If we try to open this file, the Explorer process will crash and after a while, it will be started again.

This is intriguing behavior and since the mechanism works for remote file shares as well (and since we may change the icon which is displayed for the URL file), a specially crafted URL link might be used quite easily to pull a prank on someone. Besides it being a potential tool for use during the April Fools’ day, however, there don’t seem to be many uses for a self-referential URL.

Self-referential Shell Links, on the other hand, could be quite handy in certain red teaming situations. This is because in case of LNK files, one doesn’t need to interact with them directly in any way in order to cause Explorer to crash, it is enough to open the folder in which they are located.

This is due to the interesting way in which Windows handles Shell Links. To demonstrate the behavior of Windows when a user opens a folder in which a LNK file is located, I created a shortcut, which points to calc.exe, and placed in in the folder C:\PoC. As you may see from the output from Process Monitor bellow, which shows what happened when I opened the PoC folder, the Explorer process automatically found the target file (C:\system32.calc.exe) and accessed it.

Although this behavior is quite interesting by itself, the fact that Explorer tries to access target of a LNK file when a folder, inside which it is placed, is opened is sufficient for our purposes.

At this point, we may try to create a self-referential LNK. However, if we simply try to point existing Shell Link file back on itself (or point it to any other LNK), Windows will stop us, because creating a shortcut to another shortcut is not allowed.

Since Shell Links have a binary format, making them point to themselves “manually” isn’t as straightforward as in the case of URL files. With a hex editor and with a little help from the official documentation[3], it still isn’t too difficult though.

The only potential snag is that Shell Link files really aren’t meant to point to other LNKs and to enable this behavior, we need to set a special flag in the header of the Shell Link called “AllowLinkToLink“ (i.e. add 0x80 to byte at offset 0x16)[4].

If we try to access a folder, inside which the LNK is placed, Explorer will indeed crash and then start up again.

If you’d like to try this out on your own system, I prepared a sample Shell Link file to make it easier. You may download it from https://untrustednetwork.net/files/ISC/2020/infinilink.zip (password is “infected”) and unzip the “infinilink” directory to your C drive. It works from certain other locations as well, but I would caution against putting the downloaded LNK directly on a Desktop.

Although it should be harmless (besides causing the Explorer process to crash, that is), I would also recommend that you only try it in a backed up virtual environment.

For completeness sake, I should mention that explorer.exe isn’t the only process we may crash this way. Any application, which uses one of the standard Windows file dialogs (i.e. Open File dialog, Save File dialog, etc.) is susceptible and will crash if the dialog window is used to open a folder containing a self-referential LNK.

[1] https://isc.sans.edu/diary/25816
[2] https://isc.sans.edu/diary/25912
[3] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943
[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/ae350202-3ba9-4790-9e9e-98935f4ee5af

-----------
Jan Kopriva
@jk0pr
Alef Nula

0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Obfuscated Excel 4 Macros
Mar 29th 2020
20 hours ago by DidierStevens (0 comments)

Covid19 Domain Classifier
Mar 28th 2020
1 day ago by DidierStevens (0 comments)

Malicious JavaScript Dropping Payload in the Registry
Mar 27th 2020
3 days ago by Xme (0 comments)

Very Large Sample as Evasion Technique?
Mar 26th 2020
4 days ago by Xme (0 comments)

Recent Dridex activity
Mar 25th 2020
5 days ago by Brad (0 comments)

Another Critical COVID-19 Shortage: Digital Security
Mar 24th 2020
6 days ago by Russ McRee (0 comments)

Windows Zeroday Actively Exploited: Type 1 Font Parsing Remote Code Execution Vulnerability
Mar 24th 2020
6 days ago by DidierStevens (0 comments)

KPOT Deployed via AutoIt Script
Mar 23rd 2020
6 days ago by DidierStevens (0 comments)

View All Diaries →

Latest Discussions

testgvbgjbhjb.com
created Mar 10th 2020
2 weeks ago by Bill (9 replies)

DShield analysis
created Mar 1st 2020
4 weeks ago by Anonymous (0 replies)

Setting up a security champions network.
created Feb 24th 2020
1 month ago by Anonymous (0 replies)

Wireshark - To analyze "TCP sequence numbers" or not to analyze.
created Feb 15th 2020
1 month ago by Anonymous (0 replies)

TikTok app possibly using DNS over HTTPS directly
created Feb 15th 2020
1 month ago by jauntysankey (0 replies)

View All Forums →

Latest News

Top Diaries

An infection from Rig exploit kit
Jun 17th 2019
9 months ago by Brad (0 comments)

Malspam with password-protected Word docs pushing Dridex
Jun 18th 2019
9 months ago by Brad (0 comments)

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
2 years ago by Brad (0 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
2 years ago by Johannes (0 comments)

Verifying Running Processes against VirusTotal - Domain-Wide
Jun 28th 2019
9 months ago by Rob VandenBrink (0 comments)