As I’ve used Software Restriction Policies (SRP) on several occasions in my blogposts, and several people have suggested using SRP to protect against .LNK exploitation as an alternative to Ariad, I’ll describe how to configure SRP for the first time on a workstation that is not a member of a domain. For domain members, you have to configure SRP in the GPO on the domain controller.
Start the Local Security Policy manager from Control Panel / Administrative Tools:
Software Restriction Policies need to be defined the first time:
We exclude our system drive (C:) from being restricted (add other drives if you have more):
To protect against .LNK exploitation, we need to restrict DLLs too, not only EXEs:
And finally, switch from blacklisting to whitelisting:
After configuring SRP, execute a logoff/logon to apply them immediately.
From now on, only executables on your C: drive will be allowed to run.
.LNK exploitation from removable media is blocked:
Didier Stevens 
[…] This post was Twitted by jcanto […]
Pingback by Twitted by jcanto — Tuesday 20 July 2010 @ 7:39
[…] Die aktuelle Windows-Schwachstelle, bei der sich über .LNK-Dateien Schadcode aus DLL-Dateien beim Laden der Icons nachladen lässt, kann u. A. mit Hilfe einer Softwareeinschränkungsrichtlinie eingedämmt werden. Eine Anleitung dazu gibt es hier. […]
Pingback by TC Blog » Blog Archive » M 4.286 Verwendung der Softwareeinschränkungsrichtlinie unter Windows Server 2003 — Tuesday 20 July 2010 @ 8:20
[…] nouvelle méthode de protection est expliquée par Didier Stevens sur son blog. Elle consiste à créer une règle locale restreignant le démarrage d’applications […]
Pingback by Faille de sécurité des raccourcis sous Windows (suite) « Criminalités numériques — Tuesday 20 July 2010 @ 10:15
[…] suggested to use SRP to restrict the execution of binaries (EXE and […]
Pingback by Mitigating the LNK 0-day wth AppLocker | Computer Security Articles — Tuesday 20 July 2010 @ 14:27
[…] suggested to use SRP to restrict the execution of binaries (EXE and […]
Pingback by Mitigating the LNK 0-day with AppLocker | Computer Security Articles — Tuesday 20 July 2010 @ 15:28
Many thanks for all your work in helping us mitigate this zero-day!
Comment by jeng02 — Tuesday 20 July 2010 @ 18:58
My first instinct is that this wouldn’t defend against merely opening a drive-by .ZIP file. Normally, assuming no vulnerabilities in the ZIP libraries, opening a ZIP file and just looking at (not opening) the contents should be safe. I suspect that this is not so if you are using the built-in ZIP support in Windows and there is a malicious .LNK file in it. Furthermore, I suspect SRP wouldn’t defend against this vector because the temporary files would be on the C:\ drive.
Comment by TROE — Tuesday 20 July 2010 @ 20:56
[…] of time before we start seeing other, new malware using this vector to spread. It seems like using a Group Policy Object to prevent executables launching from drives other than C might be the best way to protect your networks for the time […]
Pingback by siemens to scada users – don’t change that default password – yikes! — Tuesday 20 July 2010 @ 21:05
If one has several drives say d: and e: how is that handled in the
“new path rule”? Can it be a list and if so what is the deliminator? thanks!
Comment by chert — Tuesday 20 July 2010 @ 21:47
OUCH!
0. SRP does NOT help against this type of exploit at all, since there is no
code “executed” via ShellExec(), WinExec() etc.
1. SRP would not help against the original exploit, which uses a *.TMP file.
*.TMP is not in the list of executables for SRP, to be found here:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
“ExecutableTypes”=multi:…
2. With SRPs standard level set to DENY no shortcut within the start menue
will function!
Comment by Anonymous — Tuesday 20 July 2010 @ 21:51
[…] 8 […]
Pingback by Emmanuel Computer Consulting, L.L.C. – New Zero Day problem with all versions of windows(High Potential for Mass Infections..Stay Alert) — Tuesday 20 July 2010 @ 22:06
@chert No, you just add a new rule for each drive you want to exclude
Comment by Didier Stevens — Tuesday 20 July 2010 @ 22:30
@Anonymous You’ll have to redo your homework, you’re wrong on all 3 accounts.
0. Yes it does also work for LoadLibrary, I did configure SRP to INCLUDE libraries. Pay close attention to the screenshots and test it yourself.
1. Yes it does, SRP blocks LoadLibrary when it sees the file is on the D drive. I tested this with dll.tmp.
2. No it won’t. Shortcuts in the start menu are in the users directories (like all users). On a non-domain member machine, these are also on the C drive which I excluded. Test it yourself.
Comment by Didier Stevens — Tuesday 20 July 2010 @ 22:34
[…] https://blog.didierstevens.com/2010/07/20/mitigating-lnk-exploitation-with-srp/ […]
Pingback by 윈도우 쉘 바로가기 취약점 « Snort rules — Wednesday 21 July 2010 @ 1:06
Will this prevent signed malwares too?
Comment by msm — Wednesday 21 July 2010 @ 1:31
A security researcher has now found a way to turn the .LNK exploit into a drive by attack. You visit a site and you get infected. This SRP is not going to protect against that.
Comment by Romeo29 — Wednesday 21 July 2010 @ 1:35
@Anonymous As already stated, your comments are completely wrong. Also, simply remove the LNK shortcut file type from the SRP list to allow your normal shortcuts to work. Have a read here:
http://www.mechbgon.com/srp/
SRP doesn’t specifically block the POC lnk file from executing anyway, even if the LNK file type is included.
Comment by ssj100 — Wednesday 21 July 2010 @ 2:55
@msm Yes, if it’s on another drive than C:\. AuthentiCode signing only makes a difference when you create a specific Certificate Rule.
Comment by Didier Stevens — Wednesday 21 July 2010 @ 6:39
Correct, this is for removable drives (in my example, all drives other than C:\).
But you could create an extra Path rule to disallow all programs from temporary internet files. This might help, but needs to be tested.
Comment by Didier Stevens — Wednesday 21 July 2010 @ 6:41
How is this LNK vulnerability different from the one discoverd back in 2005 and patched in
Microsoft Security Bulletin MS05-049 – Vulnerabilities in Windows Shell Could Allow Remote Code Execution (900725)
http://www.microsoft.com/technet/security/Bulletin/MS05-049.mspx
Comment by MKZ — Wednesday 21 July 2010 @ 7:56
[…] Esta entrada detalla cómo aplicar una directiva de restricción de software para evitar la última vulnerabilidad crítica de Windows en todas sus versiones y para la que aún no hay parche. Es una libre adaptación y traducción de la entrada de Didier […]
Pingback by Solución a la vulnerabilidad “LNK” de Windows - Windows Técnico - WindowsTecnico.com — Wednesday 21 July 2010 @ 8:05
So using this method, wouldn’t it get messy on which drive letters to exclude this restriction using a GPO for a entire domain? I mean I have many users that use mapped network drives? I could exclude them all from the restriction, but then what stops the LNK exploit from working from a USB drive on drive letter E: for instance? Great posting! thanks….
Comment by hellcat — Wednesday 21 July 2010 @ 13:19
[…] la mise en place de règles locales de sécurité qui empêchent l’exécution de fichiers extérieurs au disque système C:; […]
Pingback by Stuxnet / CPLink la situation ne s’arrange pas « Criminalités numériques — Wednesday 21 July 2010 @ 14:58
Didier,
what about your homework first?
SAFER does NOT help against these types of exploits. The shell does NOT LoadLibrary() an executable which hosts an icon when enumerating a drive, directory or folder!
1. Turn on SAFER logging (grant users/authenticated users write access to the file) and see yourself, whether and when the DLL.DLL gets logged.
Hint: open the folder: no; right-click the shortcut: no; show properties of the shortcut: yes.
2. When SAFER blocks execution, a dialog box is displayed to the user, or an error message shown in the console window, as well as an event logged.
Where are they?
@ssj100: completely wrong are Didier and you.
BTW: Whitelisting the whole C:\ drive is ridiculous.
See http://home.arcor.de/skanthak/download/XP_SAFER.INF when you want to do it right!
Comment by Anonymous — Wednesday 21 July 2010 @ 15:08
[…] […]
Pingback by Anonymous — Wednesday 21 July 2010 @ 15:13
[…] exploitation' bill …Game be not politics! The producer cancels intelligent zone …Mitigating .LNK Exploitation With SRP Didier StevensMartin Rapaport: Fair Trade An End to Exploitation : […]
Pingback by Articles » Blog Archive » Why I Swore off Acne Medications — Wednesday 21 July 2010 @ 15:39
@Anonymous Except for Quickposts, I thoroughly test before I post:
explorer.exe (PID = 448) identified \??\C:\WINDOWS\system32\psapi.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
explorer.exe (PID = 448) identified \??\C:\WINDOWS\system32\psapi.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
explorer.exe (PID = 448) identified \??\D:\dll.tmp as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 448) identified \??\D:\dll.tmp as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 448) identified \??\D:\dll.tmp as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 448) identified \??\C:\WINDOWS\system32\shgina.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
Do you see that explorer.exe tries to load the DLL d:\dll.tmp 3 times when I mount the drive? And do you see that it is Disallowed?
Comment by Didier Stevens — Wednesday 21 July 2010 @ 19:31
@hellcat Oh yes, on a large domain, this is not easy at all. That’s why I kept my SRP configuration example for non-domain machines.
But I’ve observed that on many corporate networks, network drives are defined with letters found at the end of the alphabet. If this is the case on your network too, you could exclude C: and then M: through Z:
USB sticks will usually use letters at the beginning of the alphabet, for example E:
But it’s not precise.
Comment by Didier Stevens — Wednesday 21 July 2010 @ 22:05
@Anonymous Again, you are mistaken. But I must thank Didier Stevens for providing the evidence that SRP does block this exploit (in all forms discovered so far).
Also, it appears you do not understand LUA + SRP, as described here:
http://www.mechbgon.com/srp/
…since you write: “Whitelisting the whole C:\ drive is ridiculous.”
Who said anyone was whitelisting the whole C:\ drive?
Comment by ssj100 — Wednesday 21 July 2010 @ 22:31
@Didier What do you use for logging the SRP allows and disallows? Thanks.
Comment by ssj100 — Wednesday 21 July 2010 @ 22:35
You should test on my system(s) too; I use a fully patched XP SP3 here:
Step 1: open “My computer” and then drive C:\
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\browselc.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\drprov.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\ntlanman.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\NETUI0.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\NETUI1.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\NETRAP.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\davclnt.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\fxsst.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\FXSAPI.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
No C:\DLL.DLL here!
Step 2: right-click on C:\SUCKME.LNK
EXPLORER.EXE (PID = 1880) identified \??\c:\Programme\Microsoft Security Essentials\shellext.dll as Unrestricted using path rule, Guid = {d2c34ab2-529a-46b2-b293-fc853fce72ea}
Still no C:\DLL.DLL here!
Step 3: left-click on “Properties”
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\SlayerXP.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\sfc.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\sfc_os.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\System32\cryptext.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\MSISIP.DLL as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\wshext.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\Programme\Microsoft\Office\OFFICE11\MCPS.DLL as Unrestricted using path rule, Guid = {d2c34ab2-529a-46b2-b293-fc853fce72ea}
EXPLORER.EXE (PID = 1880) identified \??\c:\Programme\Microsoft Silverlight\xapauthenticodesip.dll as Unrestricted using path rule, Guid = {d2c34ab2-529a-46b2-b293-fc853fce72ea}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\SYSTEM32\SHELLEXT\HASHTAB.DLL as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\rshx32.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\AUTHZ.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\aclui.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\docprop.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\docprop2.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\WINDOWS.XP\system32\twext.dll as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
EXPLORER.EXE (PID = 1880) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
Do you see that your claim doesn’t hold here?
Do I need to show you almost identical logs from some more installations?
A mitigation that doesn’t work on all systems is no solution you should rely on!
Comment by Anonymous — Thursday 22 July 2010 @ 0:11
@Anonymous Sorry, but you are mistaken again. And Didier, don’t worry about answering my previous question – I worked it out myself after reading this page:
http://technet.microsoft.com/en-us/library/bb457006.aspx#EDAA
***Create the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers
String Value: LogFileName,
***
I repeated the test with the POC file via the 2 methods as described here:
http://ssj100.fullsubject.com/security-f7/vulnerability-in-windows-shell-could-allow-remote-code-execution-t187.htm#1308
As you can see, I refer to them as test A and test B – all other methods of testing are unreliable at executing the POC properly. This is why Anonymous is finding inconsistent results with SRP – if SRP is not logging C:\dll.dll, it simply means C:\dll.dll wasn’t executed in the first place. Anonymous would have realised this by simply looking at the Debugger output – nothing is displayed.
I have tested both methods and here are my results:
Test A:
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
Test B:
rundll32.exe (PID = 1072) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
As you can see, SRP clearly blocks C:\dll.dll from loading (either via “explorer.exe” or via “rundll32.exe”).
To summarise:
1. SRP does successfully block this exploit in all known forms, period.
2. Anonymous did not test the POC correctly.
3. Anonymous mis-interpreted the results of the SRP log file, and subsequently concluded wrongly that SRP did not block the exploit.
4. I am fairly sure Didier Stevens will agree with me. And he should join my forum haha.
Comment by ssj100 — Thursday 22 July 2010 @ 9:06
Anonymous, What is your problem? You fail to test properly and then you say Didier’s method does not work? I agree with ssj100, your wrong.
Didier wrote that all executables on drive C are unrestricted but that .LNK exploitation from removable media is blocked.
So why do you insist to test on C:? Didier tests on D:, with an infected removable drive!
And the reason why DLL.DLL from the PoC is not loaded when you open drive C: on your machine, is that the data is already in IconCache.db. You clearly ran this PoC many times on your machine.
This PoC works only once: it will load the DLL 3 times in a row. Afterwards, the PoC will not work anymore.
To properly retest, you need to restart from a clean machine or clear the cache. Otherwise the .LNK exploit will not work for a second time.
To clear the cache, delete file IconCache.db in c:\Documents and Settings\User\Local Settings\Application Data and then logoff immediately.
Logon, and check that the file IconCache.db is deleted (was not restored automatically).
When it is deleted, you can run the PoC again by opening the drive.
Another way to deal with the cache is to rename the .LNK file to something new you have never used before.
And finally, after you interacted with the DLL, I see a Disallowed for C:\dll.dll! It is clear you are not using the same SAFER configuration than Didier.
Comment by Patrick — Thursday 22 July 2010 @ 11:48
Hi Didier,
To add on this, Do we have a tool that will detect a file that executes 2 process? (without looking the hex value)
For example, if clicking a pdf file, as expected a pdf will execute to open a file with pdf format, but in the background another execution is happening without our knowledge (unless we use process explorer to check every file we open).
Maybe, process explorer tool should upgrade and use this idea to make the tool more pro-active (with pop-up alert).
It will alert the user if a file executes 2 program which means something is not right.
I believe if we have a good tool to detect this type then it could be like a customized HIDS and could somehow prevent many malwares.
my 2 cents
Comment by yaggi — Thursday 22 July 2010 @ 12:12
@yaggi I’ve some software to do this, not all is published yet:
Comment by Didier Stevens — Thursday 22 July 2010 @ 19:05
Microsoft updated their advisory with new information about possible attack vectors.
Other workaround details and the video:
http://ptresearch.blogspot.com/2010/07/stuxnet-attacks-one-more-zero-day-for.html
Comment by Alex — Thursday 22 July 2010 @ 19:30
I am going to ask a silly question, but is it possible in the SRP just to have lnk in the designated file types and just allow lnk files to run on C:\ and block them on other drives to stop this exploit instead of having every executable file type blocked? That way exe files on other drive letters are not effected?
Comment by James — Friday 23 July 2010 @ 1:01
Why my post was deleted? I dont say anything wrong, I just ask a question about this vulnerability…
Comment by Mike Br. — Friday 23 July 2010 @ 10:12
I mean that an attacker can use lnk file to use embedded system tools and api calls, there is no necessary to use some other executable files (for example to steal information). Are srp can prevent this?
Comment by Mike Br. — Friday 23 July 2010 @ 10:16
@James The problem lies not in the opening .LNK files. Just having these .LNK files (with corresponding dll) displayed in a window is enough to trigger it.
The SRP blocks the DLL from being loaded from removable drives (actually all drives other than C:) into the Windows Explorer process.
Comment by Didier Stevens — Friday 23 July 2010 @ 10:36
@Mike Br. You’re talking about shellcode? I haven’t actually seen shellcode in the .LNK PoC, just some
malformeddata and a unicode string with the DLL path.But if it would be possible to include shellcode, and this shellcode loads no PE files, then no, SRP will not prevent it.
And your comment was not deleted, all comments are moderated and filtered for SPAM.
Comment by Didier Stevens — Friday 23 July 2010 @ 10:41
@Didier Stevens Are you talking about a Buffer Overflow exploit? If so, then SRP won’t block that, particularly if it’s a kernel-mode exploit. In fact, I don’t think anything can stop it except for a Microsoft patch haha.
Comment by ssj100 — Friday 23 July 2010 @ 12:09
Perhaps off topic, but Hardware DEP would be able to stop some Buffer Overflow exploits, as long as they don’t employ the “Ret2Libc” method (and probably others):
http://ssj100.fullsubject.com/security-f7/buffer-overflow-bo-tests-t47.htm#216
Comment by ssj100 — Friday 23 July 2010 @ 12:13
Sorry for the triple post, but I did some testing a while back against a real-world buffer overflow exploit POC (which used the “Ret2Libc” method). The exploited application executes shellcode. SRP/AppLocker would do nothing against this, and Hardware DEP failed too:
http://ssj100.fullsubject.com/security-f7/buffer-overflow-exploit-writing-tutorial-t97.htm#590
Comment by ssj100 — Friday 23 July 2010 @ 12:22
@Didier
That’s no malformed data, that’s valid data for the handler (referenced via its GUID/CLSID) to look for the icon in that DLL. It is the handler that does the LoadLibrary.
@all forensic analysts
Can’t you see forest for the trees?
Comment by prk — Friday 23 July 2010 @ 13:09
@Didier Stevens You write:
***
“…and this shellcode loads PE files, then no, SRP will not prevent it.”
***
If the shellcode loads PE files, wouldn’t SRP block the PE files from executing? I just re-tested the Buffer Overflow exploit (after adding calc.exe to SRP’s deny list) and SRP predictably blocks calc.exe from being loaded (which was called by shellcode via the buffer overflow exploit).
If shellcode was used to load PE files (not in SRP’s white-list), the PE files would be unable to execute right? Thanks for clarifying.
Comment by ssj100 — Friday 23 July 2010 @ 13:15
@ssj100 It’s a typo, in meant “this shellcode load *no* PE files”, I’ll edit it.
Comment by Didier Stevens — Friday 23 July 2010 @ 13:30
@prk Doesn’t your browser render the strike-out? I edited my comment shortly after writing it, striking-out the word malformed.
Comment by Didier Stevens — Friday 23 July 2010 @ 13:31
[…] versiones y para la que aún no hay parche. Es una libre adaptación y traducción de la entrada de Didier Para aplicar la directiva hay que acceder desde el panel de control, herramientas administrativas: […]
Pingback by Marcosof Informatica y Telecomunicaciones » Blog Archive » Solución a la vulnerabilidad “LNK” de Windows mediante Directivas de Restricción de Software — Friday 23 July 2010 @ 14:41
I tried this on Windows Server 2003 (except that I marked the policy to apply to users only, and not administrators, just to not lock myself out). I found out that implementation of Software Restriction Policies is not usable. Ariad works way better.
I have three drives, C:\ (system), D:\ (my home directory is in D:\Users\user ) and E:\.
First, I tried the following path rules: Unrestricted on C:\ and unrestricted on D:\Users\user. This should let me run executables on the system drive and those in my home directory.
Log out from admin, logging in as user. The user logs in, but Explorer shell never shows up. From the task manager, I can start cmd.exe. I also tried to start eventvwr.exe or mmc.exe, and all I got was “mmc.exe – Application Error : The application failed to initialize properly (0xc0000142).”. When I went to the Event log in the admin account, it did not show that SRP stopped anything from loading.
Then I tried the following path rules: Unrestricted on C:\ and unrestricted on D:\.
This time the user can log in and the Explorer shell starts. However, many applications cannot load their DLLs, some of them fail silently, without any log entry in Event log.
I opened Total Commander, changed to E:\foo directory, then pressed Shift+F4 to create a text file and open it in a text editor. The editor should open and create the file. Instead, I got “Cannot load C:\Program Files\FooEditor\foo.dll” (but C:\ path was allowed in the path rule!)
I have 7zip at D:\Users\user\bin\7z.exe and D:\Users\user\bin\7z.dll. I open a cmd.exe window, cd to E:\foo , then try “7z x file.tar.gz” to extract the archive. Got this error: “7-Zip cannot find the code that works with archives”. Event log does not show that it stopped the loading of the DLL file.
Also, I noticed that when I view properties of a file or a folder on E:\ as user, there is no Security tab. I get the Security tab on C:\ and D:\ normally.
All in all, Software Restriction Policies is very buggy, at least on my setup.
Comment by Name — Saturday 24 July 2010 @ 0:08
[…] Adieu AppLocker, bonjour les SRP (restrictions logicielles liées à une politique de sécurité), ainsi que le prêche Didier Stevens. Reste que les « policies » restrictives ne sont pas non plus d’une absolue fiabilité, et des […]
Pingback by « rootkit .lnk », déchaînement de réactions en chaînes - CNIS mag — Saturday 24 July 2010 @ 14:25
[…] Mitigating .LNK Exploitation With SRP – didierstevens.com […]
Pingback by Week 29 in Review – 2010 | Infosec Events — Monday 26 July 2010 @ 4:34
[…] Mitigating .LNK Exploitation With SRP – didierstevens.com […]
Pingback by Week 29 in Review – 2010 | Portable Digital Video Recorder — Monday 26 July 2010 @ 5:46
@Didier
Hey Didier! Yes, it does. I wasn’t too sure what the stroke meant as I hadn’t seen the original post.
*hint* Have you tried parsing these LNKs with any current publicly available LNK parser? 🙂
Comment by prk — Monday 26 July 2010 @ 7:06
@prk No, but I’ve written my own 010 Editor template for the .LNK binary format. Do you have a link to a publicly available LNK parser?
Comment by Didier Stevens — Monday 26 July 2010 @ 7:15
There are a few… I.e
http://jafat.sourceforge.net/files.html
http://www.javafaq.nu/java-example-code-468.html
Plus the good reference at http://msdn.microsoft.com/en-us/library/dd871305%28PROT.10%29.aspx (which lately has received some well needed updates)
I phrased it wrong though, I really meant any common LNK Parser (the public ones, EnCase’s, etc). Do you get any useful information out of your template on these specific LNKs?
Comment by prk — Monday 26 July 2010 @ 7:34
@prk No, nothing special.
Comment by Didier Stevens — Monday 26 July 2010 @ 16:26
after looking over the ms kb, and googling, it looks like it’s easiest for everyday win users to set webclient to “stopped” and “disabled” in services.msc
webclient is probably already off, i assume (uh oh 😉 ) that disabling it will prevent a .lnk file (in explorer.exe) from starting up webclient?
Comment by - — Tuesday 27 July 2010 @ 10:48
[…] is still a disgrace Details. http://technet.microsoft.com/en-us/l…/bb457006.aspx Mitigating .LNK Exploitation with SRP | Didier Stevens Sujay, that's one of the best OS defensive pillbox. But it wont appeal to […]
Pingback by Free_Sophos_tool_blocks_Windows_shortcut_attacks — Wednesday 28 July 2010 @ 5:07
[…] writing this quickpost just in case you hadn’t figured this out for yourself: the techniques I described to protect machines from the .LNK vulnerability also help you mitigate the DLL preloading […]
Pingback by Quickpost: Ariad & DLL Preloading « Didier Stevens — Thursday 26 August 2010 @ 12:11
[…] la mise en place de règles locales de sécurité qui empêchent l’exécution de fichiers extérieurs au disque système C:; […]
Pingback by Stuxnet / CPLink la situation ne s’arrange pas | Linux-backtrack.com — Thursday 10 February 2011 @ 21:32
Thank you for your posts, Didier!
I tested your Ariad program too – it’s great.
I have another working SRP solution for preventing *.LNK payload execution – with Unrestricted Enforcement I set two Path rules in Additional rules:
Allow – C:\*.LNK and Disallow for ?:\*.LNK.
It works as expected for all drives.
Comment by Norbert X — Saturday 28 June 2014 @ 18:36