Hacking technique – DLL hijacking

May 21, 2014 10 CommentsWritten by Oddvar Moe

Hi everybody, sorry that it has been a long time since my last post. In this post I will try to go over one privilege escalation technique that I know of that I think is really cool. Privilege escalation is when you are able to gain more privileges on a system than you are supposed to. You typically start out as a standard windows user with no special permissions and you want to get SYSTEM or Administrator privileges on the box you are hacking. So how do we go from standard user to Administrator or the SYSTEM account? That is what I will try to describe in this post. Remember that penetration testing is not an accurate science. Some techniques work in some scenarios and sometimes not.

DLL hijacking is often mixed up with DLL Injection, but this post is about hijacking and not injection. Remember when reading this that I am not a programmer at all (just a wannabe). Where do we begin when we look for a possible DLL hijacking vulnerability? We need some tools for the job. I like to use process monitor from Mark Russinovich, which is probably one of the best tools out there in terms of finding out what processes are up to. In my example that is illustrated here, the setup is that the machines in the domain have BGInfo deployed to c:bginfo and a logon script is present that executes BGInfo when someone logs on. Why am I interested in this application in particular you may ask, why not an application inside “c:program files”?. Well, the answer is that every “custom” made folder on root of the C-drive inherits the Creator Owner permission by default. That means that every authenticated user has the ability to create new files inside the folder and that’s pretty convenient for us.

To find out if the application is DLL hijacking vulnerable we need to see what happens in process monitor when we launch BGInfo.

I like to add the filter of the application I want to look at by using “Process Name” – IS – Bginfo.exe.

 

As we can see on this next screenshot there is a lot of action going on when it starts:

 

Let’s add another filter to look at only the juicy stuff:

I added “RESULT – Contains – NOT FOUND” and “PATH – Ends with – .dll”. When the filter is applied the results looks a little better.

In my example I will be exploiting the fact that BGInfo looks for version.dll. So what’s the deal with that the process is looking for a bunch of dll’s inside the same folder you may ask? The answer here is that this is default behavior for applications if the path to a specific dll is not hard-coded. BGInfo will find version.dll inside of c:windowssystem32 eventually. The order that an application looks for DLLs is documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx .

What the documentation basically says is that it looks in the current directory where the binary (bginfo.exe) is executed first, unless it is hardcoded.

In order to exploit this we need to create our own version of the Version.dll file that redirects all normal code calls to a valid copy of version.dll (or else the application will crash). In our custom version.dll file we will insert an extra call to adduser.dll that we will create using metasploit.
The flow is like this (sorry for my bad mspaint skillz):

 

Doing stuff

Now that we know what needs to be done we are going to create our own version.dll file. In order to do that, we need to find out all calls and stuff from the version.dll file, so that we can redirect valid calls to the original version.dll file (hack.dll). To do this I use this tool: http://www.nirsoft.net/utils/dll_export_viewer.html .

Start up the tool and follow the screenshots:

 

Now you got all the functions that we need to redirect from our custom dll to the original copy of the dll. You can either export them to a HTML file or copy paste them to excel or what you prefer. Your end result should be like this for each function:

#pragma
comment(linker, “/export:GetFileVersionInfoA=hack.GetFileVersionInfoA,@1”)

Hack is our copy of version.dll, this could be version1.dll or whatever.

Now that you have converted all the functions into a format we can use in Visual studio, you can now start Visual studio and follow my instructions:

Start a new project and choose Win32 project as template. Name the project Version.
Make sure you choose DLL as the application type.

 

After the project is created you have to edit the properties on the project:

 

It is important that you set the options as this screenshot:

Now you can paste the code generated earlier in this post into the Visual studio project as illustrated below:
Right now, we have all in place to build our copy of version.dll, make bginfo.exe use it and redirect all calls to our original copy of version.dll (hack.dll). But that is not enough for us, we want bginfo to create an administrator user also. In order to do just that I choose to create a DLL file as payload from metasploit. I know that it is possible to just do this in visual studio directly, but I guess I’m too lazy to code it. Here is a quick walkthrough on how to make a DLL file payload in metasploit. I use the Kali distribution for this:

Start metasploit framework from the start menu.

Then type the following :
msfpayload windows/exec CMD=”cmd /c net user localhero P@ssw0rd /add && net localgroup administrators localhero /add” D > AddUser.dll
You now have a DLL file that when triggered will create a user named localhero and add it to the local administrators group. Our next step is to add a call to AddUser.dll in our version.dll file, so back to Visual Studio.

Add the following line: HINSTANCE hDll = LoadLibraryA(“AddUser.dll”);

Everything is now ready for us to build our DLL file. Go to Debug on the menu and choose build solution:
Visual studio should now have created a version.dll file that is within your project folder that you defined when setting up the visual studio project. Copy the compiled DLL file to the bginfo folder along with the generated payload from metasploit. Also remember to have a copy of the original version.dll named as hack.dll within the folder. You should now have a directory looking like this on the computer:

In my lab I have created a logon script that I have placed inside the same folder (bginfo.bat). In a normal network setup this would be placed on the domain controller.

Whenever someone logs on to the computer the bginfo.bat script launches. This will launch bginfo.exe with server.bgi. bginfo.exe will find version.dll (our cool custom made one) and this will execute AddUser.dll and redirect all normal calls to hack.dll (the original version.dll). All you need now is someone that is administrator to logon to the machine and the local user will be created. You can of course change the commands and do other interesting stuff, like adding yourself to domain admins, creating a domain user or whatever. If bginfo was running as a machine startup script, this would be executed as system. It is not common to add bginfo at machine startup, but there are plenty of other applications that are DLL hijacking vulnerable that runs at computer startup with system privileges.

 

Preventing DLL hijacking
There are several methods for preventing DLL hijacking, the easiest is probably to ask the author of the software to hard-code calls to the different dll files. Microsoft has also created a knowledge base article on the subject where they explain how to prevent this by adding a single registry key. http://support.microsoft.com/kb/2264107 .

This can however break other applications so be careful. It is possible to change behavior individually for each application as well. It’s all explained in the kb. The registry key name is CWDlllegallnDllSearch .

By changing the values in that key you will be able to disable DLL loading from the folder where the application is executed.

Hope you enjoyed this post and sorry @markrussinovich for making bginfo look bad, I love bginfo and so does the rest of the IT-pro world.