Jump to content

New Windows .LNK vulnerability


Guest wsxedcrfv

Recommended Posts


Guest wsxedcrfv

Even though the Microsoft link I posted earlier says that Windows 98 requires that the shortcut file have the target encoded in ANSI, my win-98 system can execute .lnk files where the target is encoded in unicode as well as ANSI.

I have written a DLL that generates a text message as part of it's DLLMain routine, and I can confirm that this .lnk vulnerability DOES NOT WORK on win-98 systems where the target filespec is encoded using unicode. I have not been able to generate a malicious .lnk file yet that has a target coded in ANSI (I expect to do that tomorrow).

But the bottom line is that unless I have a special win-98 system, then windows 98 will execute both types of .lnk files (unicode and ansi). To test this, if you have a win-2k or XP system, then generate a shortcut for any file (say, calc.exe) under that OS and copy the shortcut to a win-98 system and try it (naturally, calc.exe should be in the same place on both systems).

Link to comment
Share on other sites

The Shell Item ID structure is only part of the LNK file spec; if, for the master LNK flags, the first bit is set (01), then the LNK file contains a Shell Item ID structure, which is necessary for code execution. I've never gotten a unicode path within a Shell Item ID structure to work on 98SE.

So, more info:

- You have to literally see an exploit shortcut for it to execute a DLL; if the LNK file is hidden and you don't have hidden files shown, or if the exploit shortcut is one file among many and if you need to scroll down in Explorer before you see it, it won't execute automatically (unless you show hidden files, or scroll down until you can see the file). This limits the capability of using 20+ LNK files, one for each drive letter, as in most cases many would be down far enough where you'd have to scroll down to see them.

- Vista (and presumably 7) doesn't allow a shortcut to point to another shortcut. This isn't very important, just interesting. It will simply ignore and consider invalid such shortcuts.

- The \\?\ path to a given flash drive is formatted very differently between XP and Vista/7, so to use such an approach requires a different shortcut file per version of Windows. This still means ~2 instead of 20+. I suspect malware that's out there uses such a method.

I think I have a solution that works on all versions of Windows, that fixes this exploitable flaw, but I have more testing to do before I say any more. The gist of it is replacing the LNK file shell handler with one that filters out illegitimate control panel shortcut icon calls. At the very least I aim for it to be a solid fix for 9x and 2k; I expect Microsoft to fix things for XP, Vista and 7.

Queue

Edited by Queue
Link to comment
Share on other sites

Guest wsxedcrfv

What I've determined so far:

a) If you take a shortcut file created on an XP system and copy it to a win-98 system, nothing happens (initially). If you run the shortcut, win-98 will modify the shortcut internally (it will re-code the target from unicode to ansi text). If you run the shortcut from a write-protected floppy, win-98 can't modify the shortcut, but the shortcut will still work (ie - the target will still be executed). This is assuming you have a target file with the same name in the same location on both the XP and the 98 system.

B) I've taken the example exploit shortcut file and re-coded the target from unicode to ansi (and set the IsUnicode flag to 0). This modified shortcut file still DOES NOT trigger the vulnerability on a win-98 system, but it does trigger the vulnerability on an XP system.

I can make available the following:

- alternate dll.dll that displays a text message on both win-9x and XP when it's DLLMain function is called

- a small executable that can call the DLLMain function of this alternate dll.dll (just to verify it's working)

- my ansi-modified lnk file that *should* (but doesn't) trigger the vulnerability on a win-98 system

I can make those files available on a download link for others to study or experiment with if requested.

I am curious as to how Queue created a shortcut file that (as he says) triggers the behavior on a win-98 system.

Link to comment
Share on other sites

Guest wsxedcrfv

Even though I really don't think win-9x/me is vulnerable to this exploit, I think we have a solution here:

http://code.google.com/p/linkiconshim/

Source code:

http://linkiconshim.googlecode.com/svn/trunk/

------------------

LinkIconShim

A simple shell extension that inserts itself in front of the original buggy lnk file handler and checks the incoming files. If a link to control panel item is found (the exploitable one), default 'blocked' icon is returned instead of trying to extract one by running arbitrary dll.

------------------

Edited by wsxedcrfv
Link to comment
Share on other sites

That's essentially the solution I have in the works, however, instead of discarding all control panel shortcuts, I'm simply validating them and only discarding ones that aren't literally pointing to a control panel applet in a proper location. I don't intend to make a 64-bit version however (but Microsoft should be covering all 64-bit versions of Windows anyhow). Pointing exploit shortcuts at some sort of warning icon is a good idea (and caches an icon for that shortcut leading to less icon retrieval attempts).

I haven't found any vulnerabilities in PIF processing, but that doesn't mean there aren't any. I'd be curious if they're simply axing them too just to be on the safe side.

wsxedcrfv, I can assure you 98SE is vulnerable, and I didn't have to convert a unicode shortcut to ansi, so you may be mucking something up during said conversion. When I made the initial control panel shortcut on XP, it was ansi-only when Windows created it (now I'm curious as to why); I didn't have to make ANY modifications other than changing the target of the shortcut. Luckily, actually abusing the flaw on 98SE is much more difficult since you can't use \\?\ paths to refer to a specific device (nor can you use relative paths).

A control panel shortcut generated by 98SE doesn't automatically trigger the flaw without modification. Most control panel shortcuts generated by Vista don't contain a path whatsoever (they seem to refer to default control panel applets by index number or something).

You can also simply mark a shortcut as read-only and 98SE won't modify it (instead of using read-only media to protect the file).

Queue

Link to comment
Share on other sites

Windows 9x [95, 98 + ME] OSes cannot be vulnerable to this kind of code "injection":

1. All newer lnk files [from WinXP on] have different code than all older Win9x OSes, because new features have been introduced back in 2001 [beginning with XP Gold RTM]: native Unicode support, complex/long text strings [i.e. long local or UNC paths / combined with long filenames] can be used as local/URL shortcuts.

2. SHELL32.DLL APIs code [specific only to NTx OSes] was "revamped" accordingly to accommodate new lnk features.

3. In case the back-door "infection" mechanism is via rootkit delivery, that's a no-no, 9x OSes cannot be affected. ;)

... And actually the only way [i know of] to run something like this on 9x OSes is thru a modded PIF file [MS-DOS ANSI link = simple shortcut to an executable], with a properly attached BAT file [CMD files don't work on 9x OSes either].

Also, please notice that all MS Windows OSes [starting with Win95] have another vulnerability: the list of file extensions that can be added as executables is a plain REG_SZ value [registry ANSI string], and any1 can add more extensions to it at will.

Example:

- Win9x version:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment]
"PATHEXT"=".COM;.EXE;.BAT;.SCR;.PIF;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;"

Theoretically [i have not tested this] this would allow CMD files [for example] to be run as executables on 9x OSes.

- WinNTx version [current user + global]:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment]
"PATHEXT"=".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"PATHEXT"=".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH"

Also [beginning with Win2000 SP2 I believe], there is another way to run "protected" files by extension, by modifying the GPO [Group Policy Editor] value in the registry from "medium-risk" [XP/2003 default] to "low-risk" [custom], thus disabling the security warning. This works only on NTx OSes.

Example:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations]
"LowRiskFileTypes"=".js;.zip;.rar;.nfo;.txt;.ini;.inf;.exe;.bat;.com;.cmd;.reg;.msi;.msu;.msc;.hta;.htc;.htm;.html;.gif;.bmp;.jpg;.jpeg;.avi;.mpg;.mpeg;.mov;.mp3;.m3u;.mkv;.wav;.7z;.cab;.php;.pif;.png;.hlp;.cnt;.chm;.vbs;.vb;.sc;.scr;.rtf;.wri;.doc;.cdf;.url;.lnk;.pif;"

On a related note, there is a way to run remote executables, just add this to the environment in the registry:

SEE_MASK_NOZONECHECKS=1

either under HKLM or HKCU or HKU\.Default .

More info @ MSKB.

And how to disable the warning for running remote apps:

Open Control Panel.

Open Internet Options.

Click the Security Tab.

Click on Local Intranet.

Click on Sites.

Click Advanced.

Type respective drive letter of server address where your apps are located in the "Add this website to this zone" box.

Click Add.

Click Close.

Click OK/Apply.

Ok, I'm gonna stop this rambling now. :wacko:

HTH

Link to comment
Share on other sites

Guest wsxedcrfv

Windows 9x [95, 98 + ME] OSes cannot be vulnerable to this kind of code "injection":

1. All newer lnk files [from WinXP on] have different code than all older Win9x OSes (...)

A user-created shortcut in XP is practically identical to a shortcut created in win-98 (biggest difference is ANSI vs Unicode in specifying the target). Win-98 understands how to execute shortcut files created by XP (perhaps only shortcuts with simple paths, and perhaps only if unicode support has been installed). Perhaps there are enhanced or advanced features of "XP-style" lnk files that a win-98 system would fall-over if exposed to, but I wonder how common or useful those features really are.

2. In case the back-door "infection" mechanism is via rootkit delivery, that's a no-no, 9x OSes cannot be affected. ;)

The fact that some implimentations of this exploit might try to plant a rootkit on a system doesn't mean that a rootkit is part of the exploit. Any system that already has a rootkit installed and functioning on it doesn't need to be exposed to this exploit in order to gain control of the system. I don't know why or how some people are linking vulnerability to this exploit with vulnerability to rootkits. The two are totally different things.

Also, please notice that all MS Windows OSes [starting with Win95] have another vulnerability: the list of file extensions that can be added as executables is a plain REG_SZ value [registry ANSI string], and any1 can add more extensions to it at will.

And just how would someone implement those registry settings on a win-98 system in order to then exploit the system?

If I could remotely modify the registry on a win-98 system according to your example, then presumably I'd have enough control of the system to do other things (like install botnet software) and I wouldn't bother making those registry changes.

Link to comment
Share on other sites

Windows 9x [95, 98 + ME] OSes cannot be vulnerable to this kind of code "injection":

1. All newer lnk files [from WinXP on] have different code than all older Win9x OSes (...)

A user-created shortcut in XP is practically identical to a shortcut created in win-98 (biggest difference is ANSI vs Unicode in specifying the target). Win-98 understands how to execute shortcut files created by XP (perhaps only shortcuts with simple paths, and perhaps only if unicode support has been installed). Perhaps there are enhanced or advanced features of "XP-style" lnk files that a win-98 system would fall-over if exposed to, but I wonder how common or useful those features really are.
You've actually made my point...

User created shortcuts are pretty much similar, *except* (and that's the keyword here) for the Unicode (mostly for special symbols, special chars for languages other than English and for registry complex strings/multi-strings values) and standard (backslash divider) UNC path part { http://en.wikipedia.org/wiki/Path_%28computing%29#Uniform_Naming_Convention } which are not understood by 9x OSes without additional 3rd party programs installed (and then, only partial support is provided, and only for specific apps).

And to my knowledge, 9x OSes do not have MUI (Multilingual User Interface) Unicode packs, like XP/2003/Vista/2008/7 do.

Example: open the "Run..." box in Win95/88/ME and type something using extended characters, you'll get an error message:

http://support.microsoft.com/?kbid=192109

Same, the "Run..." box in 9x/ME does not understand %windir% or similar environment variables: you'll get an error message.

Also, share names longer than 12 chars are not understood by 9x OSes:

http://support.microsoft.com/kb/160843

List of unicode specific REG values (NTx OSes only):

REG_EXPAND_SZ

REG_LINK

REG_MULTI_SZ

REG_RESOURCE_LIST

REG_FULL_RESOURCE_DESCRIPTOR

REG_RESOURCE_REQUIREMENTS_LIST

More details here:

http://www.mdgx.com/reg.htm#RTS

Another example: the rundll + rundll32 commands have different behaviour on 9x and NTx OSes:

http://support.microsoft.com/kb/164787

Also, when creating (default in XP/2003) shortcuts to "registered" apps that reside in the %systemroot% / %windir% / %programfiles% / %userprofile% / etc paths, the environment strings (opposite to hard-linked actual drive letters + directories) are added, something that 9x OSes do not understand either.

And besides, 9x OSes do not understand %systemroot%, %programfiles% or %userprofile% environment variables, those have been introduced beginning with NT4/2000, but not in 98/ME, unless you install a 3rd party networking app to "translate" such variables for 9x OSes (and that with limited availability):

http://www.wilsonmar.com/1envvars.htm

http://wsh2.uw.hu/ch07c.html

Another "glitch": "set <variable>" commands can't be added in 95/98 OSes while running, one must add them to autoexec.bat or config.sys, and then reboot. WinME has a way of doing this (regenv32.exe + msconfig.exe) while the GUI is running [and writes them into the registry, similar to NTx Windows], but a reboot is still needed for such changes to take effect.

http://www.chem.gla.ac.uk/~louis/software/faq/q1.html

In comparison, WinNTx accepts SET <VARIABLE> commands "on-the-fly" (written into the registry), no reboot needed, in some cases a logoff and a log back in is required.

Without 3rd party software installed there is no way to add captured variables into the environment in Win9x, which run MS-DOS 7 [Win95/98] or 8 [WinME]:

http://www.pement.org/sed/bat_env.htm

2. In case the back-door "infection" mechanism is via rootkit delivery, that's a no-no, 9x OSes cannot be affected. ;_)
The fact that some implimentations of this exploit might try to plant a rootkit on a system doesn't mean that a rootkit is part of the exploit. Any system that already has a rootkit installed and functioning on it doesn't need to be exposed to this exploit in order to gain control of the system. I don't know why or how some people are linking vulnerability to this exploit with vulnerability to rootkits. The two are totally different things.
My point exactly...

Some rogue code is delivered + loaded via disguised rootkit TSRs, some is not.

That's why I started the phrase with "In case (...)".

Of course, the underlying code has nothing to do with the delivery system. ;_)

Also, please notice that all MS Windows OSes [starting with Win95] have another vulnerability: the list of file extensions that can be added as executables is a plain REG_SZ value [registry ANSI string], and any1 can add more extensions to it at will.
And just how would someone implement those registry settings on a win-98 system in order to then exploit the system?

If I could remotely modify the registry on a win-98 system according to your example, then presumably I'd have enough control of the system to do other things (like install botnet software) and I wouldn't bother making those registry changes.

There are numerous methods one can use to write to the registry remotely. These come to mind on a short notice (most of these APIs/functions are already built into Windows):

N.B.:

Please keep in mind I'm not a hacker nor a security expert, and all this is a purely theoretical rambling on my part.

... and now I need to stop... this... rambling... ;_)

HTH

Best wishes.

Link to comment
Share on other sites

Guest wsxedcrfv

Can someone explain why Microsoft's patch is some sort of file-modifier (performing some sort of modification to the user's existing shell32.dll) instead of just a straight file-replacement? On XP systems, shell32.dll is about 8 mb in size, and it compresses to about 3 mb. Microsoft's solution is a 2.9 mb download - saving about 100 kb in bandwidth at the expense of a somewhat complex file manipulation process.

What other patches does Microsoft provide that modifies the existing file instead of just replacing it?

PS: Will Win-2K users be scratching and poking at XP patches and updates, seeing if they can make them work? (heh heh). If you ask me, Microsoft delayed the "discovery" of this vulnerability just long enough so that it happened soon after Win-2K went EOL.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...