Maximising Windows XP security with LUA and SRP

Technically, that link says to allow LNK executions from anywhere...


So...are people sure now that spoofed extension files cannot get through SRP?

 

But only the executables in the Windows and Program Files folders these LNKs are pointing to are allowed to execute.

 

This issue was raised before in the thread, cant LNK files be malicious executables by themselves; as opposed to simply pointing to malicious files?

 

A .lnk that is an executable must be executed by an engine, the same as a .script file must be executed by an engine (ie. test.vbs executed by wscript.exe).

Any executable will call the method CreateProcess. Every time CreateProcess is called, it examines the SAFER registry area to find any SRP values. This is why XP and Vista HOME editions can use SRP, because you only need those registry values. Regardless of whether SRP is in the Group Policy, those registry settings are what counts.

So here is the question then. What does windows do with a .lnk? Is it defined as an executable binary? As a script? It is defined as a link, a pointer to something else. If a file has the extention .lnk, it will only ever point to another object/container. When you double click this, windows does only what it is told, and that is to find the target, and then execute whatever it needs to. It might be to open notepad, or open a directory in explorer, or actually load and execute binary code. It all depends on what the extention of the target is.

In order for a true .lnk file to be executed "itself", the file association for .lnk needs to by default open rundll32.exe or wscript.exe or something.

But, when either of those two are called into action, they will use the CreateProcess method, which will check with SRP values. So, even if the .lnk association was changed for it be execute the .lnk itself rather than the intended target, SRP can deny it. Why? Because if you follow Mechbogons guide, only items in windows and program files are allowed by default. Unless the account is an Administrator, how is the .lnk file going to get into either of those two directories, and further, how is the file association going to get changed?

Pretty muddy waters, but as far as I am concerned, a file like this
trojan.exe.lnk
is going to be a link, to basically nowhere. You might trick some people who don't show file extentions by doing this though
trojan.lnk (.exe is hidden)

As always, someone with more infos than I might prove me wrong, but this has been my experience.

Sul.

 

Just a +1 for Win 7 on that one because I don't believe it can even when running as Admin if one has UAC set properly.

 

Evidently it is:

Abusing Shortcut files
http://www.thesecurityblog.com/2009/01/abusing-shortcut-files/

I test things like this by attempting to load the file into a text editor:

​

-rich

 

Interesting, I have question about the .lnk extension and SRP. Would it be wise to keep the .lnk extension in the SRP list of extensions in Local Security/Registry and create an allow rule for each shortcut.lnk or better yet the folder they are kept in?

 

Thanks Sully. A couple more questions. Suppose trojan.exe is renamed to trojan.lnk. Suppose SRP allows LNK, but not .exe files. In this case, will trojan.lnk be allowed to execute.

From your post, I am conjecturing that for each file extension in the SRP menu, is it the case that each file extension requires a different engine; so what is really happening is that the restrictions are on the different execution engines, rather than on the file extensions? Hence, it does not matter if a .vbs file is renamed to .shazam (and .shazam is not present in the SRP file extension list); as they must both be handled by the vbs engine?

 

It appears though that the .lnk itself is not executable in the classic sense. Examine a .lnk with a hex editor, and you can see its pointers to the object it is for. As in those examples you posted, the only one that can run by itself is still needing cmd.exe. It is true that the "parameters" which the .lnk are passing look to be scriptable, but without the engine, it cannot work. The apparent trojan attack modifies the .lnk to point somewhere else or to include a parameter to pass to the new target such as cmd.exe. I am very curious, but it still seems that .lnk files are not executables themselves.

One interesting note, the SID is included in some of the shortcuts I examined. I wonder if an Admin creates a shortcut if the SID is included in this .lnk. As well, can a .lnk be reversed so that it includes the SID of an Admin account and gain rights by creative use of this.

Apparently Rmus, you have just created some studying for me... time to dig into .lnks a bit more. There might be a rough gem in there that I can use to my advantage in automation that was never intended. Who knows what one may find. Reminds me a lot of .scf files, a lot of hidden documentation for something that could be robust be we will never know.

Sul.

 

"Executable" has different meanings to different people.

Technically, there are "binary" and "script" executables, "script" meaning ASCII text carries out the commands.

Since LNK files are binary -- see some the analyses of the current LNK exploit --, they fall into the executable category in that way.

Squibbling aside, the vulnerability allows the LNK file to "execute" its commands by just viewing the file in the appropriate viewer.

Any executable file requires something to initiate it, whether an engine or VBS code, as in the old MDAC exploit:

Code:

fname1= F.BuildPath("C:\","svchost.exe")
script language="VBScript" >

S.open
S.write x.responseBody
S.savetofile fname1,2
set Q = eeeeeeeeeeeennnnnnnnnnn.createobject("Shell.App"&"licat"&"ion","")
Q.ShellExecute fname1,"","","o"&"pe"&"n",0

No matter how you classify LNK, its code has the potential to be exploited in some bad way!

----
rich

 

Every computer is stupid. It does not understand that your custom file type, .sul, is actually a text file. You know it because you named it that and know it is only text.

So, what they decided to do was to have a list of registered file types. You associate the extensions .mp3, .wav and .avi all with Media Player, because it can play them. Third party programs register themselves for know filetypes. For instance WinRar will make itself become the default "open with" action for .zip, .rar, .iso, .cab, etc etc.

In the case of SRP, the list of file extensions is part of when and why SRP filters on a specific file or filetype. If you have a program named test.exe, and you rename it to supertest.exe, it is still a .exe, and when you double click it, the internals of the OS will lauch the compiled binary and it will be whatever it is supposed to be - text editor, music player, video game, etc.

If you are not monitoring the file type .exe, then when the CreateProcess method is called, it (somehow) compares the extension .exe to the list of file types. If .exe is not in the list, it might do some other check, but it might ignore it, happy that it can execute the file because it is not a monitored filetype.

But, if we look at a script or .lnk file, it is not as clear cut. If you have a file name test.vbs, how does it work? In SRP, it is designed to be used with the CreateProcess method, and a .vbs file invokes no such method because it is only a text file. But, if you open test.vbs with wscript.exe, now it will most likely (wscript will) call the CreateProcess method. Now SRP will apply to wscript.exe, not test.vbs.

The same applies to the .lnk files, although .lnk is treated as an executable binary although I don't understand why as it cannot stand alone, it always needs a parent program. Anyway, if you click a shortcut to program.exe, CreateProcess is called, which examines the SRP and might deny program.exe from running. Even though you clicked a .lnk file, the CreateProcess method came from program.exe, not the shortcut to program.exe.

The inclusion of .lnk into SRP file list is now a great question for me personally. But in any case, if you are monitoring .lnk files with SRP, and you attempt to execute it from a denied directory, it should be denied, regardless of what has been modified within it. Mechbogon suggested removing these .lnks from the list so that you are free to use them without being denied. But, he also had you make sure windows and program files directories were open so that you could only use a .lnk to those areas. You could choose to deny user space (blacklist) with SRP and then no executable could run from user space, .lnk or not. In this manner .lnk files would only be usable if they pointed to an item in an approved location.

But going further with this, if wscript.exe or cmd.exe were left open so that SRP did not deny them, you have the potential for a malicious script run in user space to modify a .lnk, that would pass a parameter to cmd.exe, which could then execute. Still, if you are a User, what can happen should be limited unless the malicious program somehow gets root.

There is another potential vulnerability in SRP and that is (if memory serves correctly) that environment variables could be used against you. So suppose you are a User, and use SRP for a default deny for anything but c:\windows and c:\program files. Suppose you removed the .lnk file type as suggested. Suppose as well that you have not denied cmd.exe with SRP not taken the steps to reduce the environment variable exploit.

Now suppose that you surfed to some-bad-site-DOT-com. While there, a script exploits the browswer or tricks you into clicking on the "You've won" pop-up. Now suppose that the script on the website modifies the shortcut to MyComputer on your desktop as well as creates an environment variable - lets pretent it is %screwyou%=del c:\windows /q or rmdir c:\windows\system32 /q.

Now the next time you double click the MyComputer icon, the modified .lnk executes cmd.exe, which is allowed to execute, and it attempts to pass as %1 parameter the environment varible %screwyou%. While this example would fail, you can still see that cmd.exe "should" attempt the command.

Many have suggested using SRP to deny execution of wscript.exe and cmd.exe. AppGuard was also toying with this at one time as well I believe. But, if you did not, could such an exploit escape the User account you should be using?

So many questions, so many scenarios. Man, I love this place.

Sul.

 

Hmm. LNK files must be defaulted then to open with inbuilt function such as rundll32 ? They don't appear to be a typical binary in the sense that I am used to. I definately think they deserve some further research on my end anyway.. I am extremely curious as to just what they are exactly and what method in the OS is being used by them.

Sul.

 

It is for me now and questioned it above somewhere. I added it back in and am in the process of creating individual allow rules for each .lnk. I figured that adding the entire directory could be semi unsafe in my thinking.

Not the case for me. Program Files and System Root are unrestricted and the shortcuts that point to them, after adding LNK extesnion back in, are dead. They either need the directory added as unrestricted or each individual shortcut.lnk

With SRP I don't know, with AppGuard it's dead in it's tracks but so is alot of legit uses of script and cmd. My thoughts on this SRP are this, If it's done right, especially in Win 7 and even running an Admin account with UAC set to max, extra securtiy apps such as AppGuard and Malware Defender etc.. are not needed for anti-executable.

 

I don't get this.. yet.

I appears that to create a .lnk file in C, it is pretty typical as you would expect, as seen with any gui. There are certain properites of the class, such as the paths and parameters. Nothing special really.

To execute a .lnk file, you can use the START command from batch/prompt (which I can't yet find what that calls). Most of the languages use some form of ShellExecute because this will find the filetype of the target and using the file associations start the correct application and pass the target and the parameter if needed.

Some others state that you should query the properties and get the target/parameters, then query the filetype associations and start the correct application yourself and the parameters.

I don't see an API anywhere or any reference in the creation of an .lnk file that makes it an executable. Perhaps I will have to make that class and create some from scratch to see how they work.

I have such a nerd mentat....

Sul.

 

I think it's about the interpreter, and whether or not these respect (look for) the SRP. For every binary executable file, the CreateProcess function is ultimately called, and Windows can intercept and apply SRP rules regardless of extension. Similarly, wscript and cscript are both written by MS (of course), and they wrote it to respect SRP - extension doesn't matter in this case either. Same goes for batch files i think.

It's when some other interpreter is involved, say Python, that possibly doesn't care about SRP (i don't know). Then, extension matters, and it only applies to when you execute it from explorer.exe - like double clicking the file. It is explorer that checks the extension list and applies the policies. If you would launch it from the command line, with python malware.shazam, SRP is ignored - assuming Python doesn't check SRP because, as i said, i don't know if that's the case. It's up to Python to execute it or not, according to its own rules.

http://technet.microsoft.com/en-us/library/cc786941(WS.10).aspx

Hope this helps.

 

This sound correct though. If you monitor .lnk, you have to allow them to 'execute' from desktop for example, so desktop must not be default-denied. As windows and program files are not denied, the .lnk would have to reside within those directories for them to both be monitored and allowed.

Are you by chance denying desktop execution except specific links (default deny)? If so, add desktop to be default allow *.lnk and then see how the hierarchy works. In other words, if windows is allowed all execution, and c:\test is default denied, have a .lnk on desktop for c:\windows\notepad.exe and c:\test\some-program.exe. It "should" work out that all .lnks on the desktop will function, but that SRP blocks any executable in c:\test because the SRP states to, and that the .lnks to windows should be allowed, again because SRP says to.

I am curious to hear how the hierarchy works for you.

Sul.

 

I was under the assumption that any thread that is created, regardless of whom the interpreter is, will face the CreateProcess method to become a valid process and be assigned a handle. I would be interested to know if there is a manifest or something that proper code should follow to utilize the CreateProcess method correctly.

Sul.

 

Yes, it's default deny and you are correct. I was just stating that with default deny and LNK included/monitored, even though Program Files is unrestricted, a shortcut to a file within Program Files is still blocked no matter where the shortcut.lnk is located unless it is in Program Files. Sorry, I must have mis-understood what you were saying in an earlier reply. I added each individual path/shortcut.lnk as allowed. Am I correct in assuming that allowing individual path/shortcut.lnk is sort of safer than allowing desktop or quick launch directorires as a whole, unrestricted?

 

I have no idea Sully, and it just may be possible you're confusing me with someone who really understands all his
Isn't there a CreateThread function independent from CreateProcess?

 

I'm still confused by the connection between SRP and file extension blacklists.

Can someone check by deleting .lnk from the SRP list, then renaming an .exe to .lnk, and then trying to execute this renamed .lnk what happens?

 

It's blocked. But you should test it yourself.

 

To answer my own question, it may be semi safer but it's not practical unless there's a way to generate a directory listing which would include the paths. Doing it individually is too labor intense especially with the Start Menu Programs. Depending on how something got installed, the path could be in one of three different locations just for a single user.

 

That may be a good educated guess!

Here are the registry entries for .lnk and lnkfile in Win2K

I'll leave it for you to investigate the various CLSIDs!

​

 

RegEditX is hard to beat in XP, great addon!

 

That rundll32 appwiz stuff is just how you create a shortcut, using the appwiz.cpl applet to do the creating. It is what really happens when you use the context menu to create a shortcut.

You can do the same thing by passing that structure to the command prompt. It is what is within the appwiz.cpl that I want to know. But no bother really, a gentle excurion into MSDN land and some delphi forums shows that to create an .lnk is fairly typical, you pass certain parameters and it is parsed by, don't know, the shell basically. Could not find a link anywhere about a specific tool such as rundll32 etc. They are all calls to shellexecutes of some kind. I suspect it is the shell that creates the entrypoint and the process/handle, so what we have is (I think) just another file type that is treated as an executable for internal purposes, but does not have the means itself to actually be an executable.

The properties that a .lnk have can be manipulated, it is easy to see that now. But it will still rely soley on a) whether the objects of the .lnks affection is known to the OS and b) whether or not your system has any sort of blocking in place for either the target or the .lnk itself.

It is interesting to note that a parameter labeled SLDF_RUNAS_USER exists within .lnk files from Vista on, and this allows you to, on a PER SHORTCUT BASIS, if the shorcut should start the associated application as Admin or not (all part of UAC). It might be interesting to develop a little tool that does nothing but create shorcuts with this flag set, similar to what Norton UAC tool does.

It is also interesting to note that there is a registry key that will supposedly also set this for either a shortcut or the .exe itself. Don't remember what Norton UAC tool did, as I used it only very little, but perhaps there is another gem in there as well that could be exploited for the greater good of the geeks.

Ah well, sleep beckons. Till the next time.

Sul.