DLL hijacking POC (failed, see for yourself)

[Christian Sciberras]

and failed to use it right!

Well, I suppose I could have used neat tricks such as specifically and
directly loading the "bad" dll.
But as much as security goes, those are cheap tricks.

Besides, I did ask for suggestions why my tests "failed".

The "application directory" is ALWAYS the first one where both implicit
(referenced in the binary) as well as explicit (via LoadLibrary())

I believe the correct term is "static" vs "dynamic".

Next time, do your homework first!

I did. And it worked out right. I proved my point that the issue relates to:
- loading nonexistent dlls - is a very bad practice
- loading from the wrong directory (CWD instead of base) - is wrong

Furthermore, it proves my original point of why one needs
differentiation between filesystem zones:
a network should be an untrusted zone; executables should only run
when (eg) a user accepts
via a proper dialog, just like any web browser asks the user whether
he wants to "open" the download or not.

The fix doesn't concern the affected applications (though using the
correct code would be very nice of them),
it should go into how LoadLibrary(Ex) handle remote/insecure files.

Chris.


On Tue, Sep 14, 2010 at 11:15 PM, Stefan Kanthak

I wrote my own example POC.

and failed to use it right!
[...]

DHPOC\example\the-install-folder\
DHPOC\example\the-install-folder\dhpocApp.exe
DHPOC\example\the-install-folder\dhpocDll.dll
DHPOC\example\the-remote-folder
DHPOC\example\the-remote-folder\example.dhpoc
DHPOC\example\the-remote-folder\dhpocDll.dll
While testing this, I noticed that the dll hijack exploit completely
failed my tests (on Windows 7 64bit).

No, you failed the test!
The "application directory" is ALWAYS the first one where both implicit
(referenced in the binary) as well as explicit (via LoadLibrary())
loading will search.
Next time, do your homework first!
Stefan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Stefan Kanthak]

I wrote my own example POC.

and failed to use it right!

[...]

DHPOC\example\the-install-folder\
DHPOC\example\the-install-folder\dhpocApp.exe
DHPOC\example\the-install-folder\dhpocDll.dll
DHPOC\example\the-remote-folder
DHPOC\example\the-remote-folder\example.dhpoc
DHPOC\example\the-remote-folder\dhpocDll.dll
While testing this, I noticed that the dll hijack exploit completely
failed my tests (on Windows 7 64bit).

No, you failed the test!
The "application directory" is ALWAYS the first one where both implicit
(referenced in the binary) as well as explicit (via LoadLibrary())
loading will search.

Next time, do your homework first!

Stefan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Christian Sciberras]

No. Guess where the D in DLL comes from!
Static linking occurs when the linker builds a binary (this might be a
DLL.-) using *.OBJ and *.LIB.
Dynamic linking occurs when the loader loads a binary (again: this might
be a DLL) into memory and resolves its dependencies.

Oh really?

http://www.codeproject.com/KB/DLL/dynamicdllloading.aspx

Note that I never mentioned "linking" above. Also note that the first
sample code does not mention the need of any object files.

Another misconception: nonexistent DLLs can and will NEVER be loaded.

How can you say something might but will never do something?
It is either "might" or "won't".

DLLs but can and are used to extend the functions of an application.
Just think of a "modular" application where the modules are built as
DLLs and loaded on demand. Its the responsibility of the application
to load the right module/DLL from the right path and give appropriate
feedback to its user on failure.

Any reasonable framework out there, provides the developer an "exists"
functionality.
Surely I don't have to run an exeuctable to know that the file exists?
Likewise, such functionality should exist to tell me which dll would
be loaded beforehand.

What is a "wrong" directory?
Windows' DLL load order (as well as the EXE load order) are both
well-known and documented and contain CWD from the very beginning.
The latter is sad but true.

Didn't you say loading from CWD comes after loading from the
application directory?
I did say what such a wrong directory would be: loading from the
current working directory vs loading from the base directory.
If you don't know the difference or implications, just search for the
phrase, not attempt to ask abstract questions.

SAFER a.k.a. Software Restriction Policies (available with EVERY
supported version of Windows) allow the Administrator to control
which executables (including DLLs) may be run: you can deny or allow
execution to specified (UNC) paths as well as "internet zones".
See <http://technet.microsoft.com/en-us/library/bb457006.aspx> and
<http://technet.microsoft.com/en-us/windows/cc507878.aspx>

What are we doing again here? Oh right. Because as far as SAFER goes,
it DOES NOT WORK. At least not by default.

Stefan, may I ask how much experience do you have with dlls? I don't
consider being an expert in this area, but I wrote such libraries for
both windows, osx and linux.
In the case of windows dlls, I can assure you that I've noticed some
of the neatest tricks around, which as far as FD goes, have never even
been discussed (as far as I know), for some reason.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/