Jump to content

DLL Hijacking vulnerability


Guest wsxedcrfv

Recommended Posts

Guest wsxedcrfv

If I understand this correctly, this exploitation method works by getting a legit app to load a DLL from a remote network source (including the internet) instead of the local machine. How the usual path traversal order is manipulated, changed, or taken advantage of - I'm not sure.

So the way I understand this (correct me if I'm wrong) is this:

Say a web page has some PDF content. Your browser will launch Adobe Acrobat reader to render the content. Reader may need a particular DLL, and when it requests it from the file system, if the DLL is not in the same directory where Reader was launched from, then the next place it will look is the location where the file-to-be-rendered is located - which in this case is a web-server somewhere in the cloud. If a hacker has planted a malicious version of the DLL on the server, then that's where Reader will get it from. This means that the hacker must know ahead of time the file names of likely DLL's to be looked for - or configure the remote server to simply look for any sort of DLL request and serve up a malicious file with the same name instead. Now substitute "PDF content" with flash, torrent, doc, XLS, MP3, AVI, etc.

Is this how this exploit works?

Is the solution just a matter of taking an inventory of all the apps that in any way interact with the internet and make sure all their DLL's are located in their respective root directories?

Link to comment
Share on other sites


I imagine it is possible. I've always wondered how most of eBay works off a website DLL for years now, but I never looked into it.

Oh also, remember that file extension only has to do with file associations and what programs are needed to launch a file. You can make up anything for a file extension, but an app can call it specifically and doesn't care what the extension is, as long as the file headers are correct.

Link to comment
Share on other sites

I still can't figure out if simple web-browsing / surfing can expose a system to this exploit.

Its definately possible and there are numerous ways to do it. The only way I've gotten a "web page" to do something on a local system was using Flash. You can also do it with HTML/JavaScript presuming you can change some registry keys beforehand. I originally had tried to make programs with HTML but found Flash to be easier to use.

Link to comment
Share on other sites

Guest wsxedcrfv

I still can't figure out if simple web-browsing / surfing can expose a system to this exploit.

Its definately possible and there are numerous ways to do it. The only way I've gotten a "web page" to do something on a local system was using Flash. You can also do it with HTML/JavaScript presuming you can change some registry keys beforehand. I originally had tried to make programs with HTML but found Flash to be easier to use.

But serving content from a remote shared folder is different than serving content from a web-server, isin't it?

What does a URL pointing to a shared folder look like, vs an ordinary HTTP URL?

If I give you a URL pointing to an MP3 file on a remote system, and your default MP3 player is Media Player Classic (mplayerc.exe), then I don't think that me planting a DLL needed by MPC on the remote server is going to be loaded by MPC.

Link to comment
Share on other sites

This ''exploit'' (which arguably isn't one, unless I've been reading the wrong things) isn't exploitable in a ''drive-by'' fashion through web browsing. All this issue is is the order that Windows searches for DLLs when an executable wants to load one (aka DLLs that are dynamically linked and loaded when you execute an EXE). Generally, the working directory is where an EXE checks first for a DLL, then it goes through the folders listed in your path environment variable. Windows 9x is actually less vulnerable to this than the NT line; it tends to be more strict with ''known'' DLLs so that they're only loaded out of your system folders (DirectX DLL wrappers are far more finnicky on 9x than NT, for example). The ''exploit'' is to set the working directory for a given EXE to a folder that contains a malicious version of a DLL that EXE wants (you can do this with a shortcut with a modified ''Start in'' entry, for example), or to simply throw a malicious DLL in the folder with the EXE. This is expected Windows functionality, so to call it a vulnerability seems pretty asinine (and I'm guilty of doing this earlier in this paragraph).

Really, the gist of this is: anywhere that this can be exploited, you could just as easily have a malicious executable, so why go through the trouble of hiding the malicious code in a DLL? The people that are vulnerable are going to fall prey to either situation.

Speaking of vulnerabilities, no one seemed to act on that LNK vulnerability (which is actually a vulnerability), and XP+ has had plenty of time to get patched up, so I guess a 9x proof-of-concept is due now. wsxedcrfv, I'll probably just release an even more stripped down version of what I showed you (as in, with no empty space allocated that makes hex editing in a new target DLL easier). What are MSFN's rules about disclosing a proof-of-concept for the purpose of getting a fix hammered out?

Queue

Link to comment
Share on other sites

Speaking of vulnerabilities, no one seemed to act on that LNK vulnerability (which is actually a vulnerability), and XP+ has had plenty of time to get patched up...

It's done! Microsoft offers a patch for it (XP+) since late July as KB2286198 (MS10-046).

...so I guess a 9x proof-of-concept is due now. wsxedcrfv, I'll probably just release an even more stripped down version of what I showed you (as in, with no empty space allocated that makes hex editing in a new target DLL easier). What are MSFN's rules about disclosing a proof-of-concept for the purpose of getting a fix hammered out?

Please refer to cluberti's answer below, regarding this matter.

Link to comment
Share on other sites

If you host a POC elsewhere (and link to the page, and not the exploit) here, that'd be fine. Any exploit code hosted here, or direct links to it, would not be allowed.

Okie dokey.

Dencorso, I know the fix for XP+ has been out for like a month, that's what I meant: not that they've had time to make one, that it's been a month since the fix has been available.

The fix I made is similar to the one linked early-ish in the LNK exploit thread, but I wrote it in MASM assembly, and haven't tested it rigorously to make sure its solid. Seeing as it's code used by Explorer for every LNK file, I want it to be perfect, hence why I haven't even made it (the fix) available for testing yet. I kinda threw it on the back-burner anyway since 9x hasn't been nor will be targeted for attack using it, but this thread reminded me about it.

Queue

Link to comment
Share on other sites

Guest wsxedcrfv

All this issue is is the order that Windows searches for DLLs when an executable wants to load one (aka DLLs that are dynamically linked and loaded when you execute an EXE). Generally, the working directory is where an EXE checks first for a DLL, then it goes through the folders listed in your path environment variable.

The order that you are stating is different than what Microsoft claims:

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

The LoadLibrary function and the LoadLibraryEx function are used to dynamically load DLLs. The following is the DLL search order for these two functions:

1. The directory from which the application loaded

2. The system directory

3. The 16-bit system directory

4. The Windows directory

5. The current working directory (CWD)

6. The directories that are listed in the PATH environment variable

I'm not sure how or why the CWD (6) would be different than the directory from which the application was loaded (1).

Link to comment
Share on other sites

I'm not sure how or why the CWD (6) would be different than the directory from which the application was loaded (1).

When you execute from the commandline:

.\Exe\Program.exe

then the 'directory from which the application was loaded' is CWD\Exe, while CWD is CWD.

Link to comment
Share on other sites

The order that you are stating is different than what Microsoft claims:

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

Whoops, my mistake. I was totally wrong about the ''CWD'' and I was over-simplifying when I said the path environment variable. The folders in that list generally are in your path environment variable as well, so rather than name them out I was lazy.

Queue

Edit -

http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx

Edited by Queue
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...