Windows Vista/7 lpksetup dll hijack

[Tyler Borland]

/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Vulnerability
Extension: .mlc
Author: Tyler Borland (***@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and
Windows 7 Enterprise should be vulnerable as well)
Effect: Remote Code Execution

lpksetup is the language pack installer that is included by default with
Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc file
through something like an open SMB or WebDav share, the oci.dll file will be
grabbed and ran in the context of the vulnerable application.

This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist, so if
a full path is not supplied when calling the dll or the search path has not
been cleared before the call, we will hit our fifth search path and load the
library from the remote filesystem.

Interestingly enough, while lpksetup is blocked for execution by UAC under a
normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows
complete anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors:
http://www.binaryplanting.com/attackVectors.htm
*/

#include <windows.h>

int main()
{
WinExec("calc", SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
main();
return 0;
}

/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */

[Thor (Hammer of God)]

I've tested loading a library from an application that requires admin privileges from a normal user and it will prompt for UAC if needed or fail. I understand where the jacking takes place, but you are making it seem like you can bypass user permissions when you can't. At least that's what I got from your OP. IOW, even if the original app you run doesn't require UAC, if the jacked .dll requires escalated permissions, which would be just about anything interesting you could do, then it will fail (or prompt depending on how you write it).

The main point is that you've got to get people to not only connect up to your remote share, but you've got to get them to execute the file, etc. So I'm just wondering what makes this anything more than any other "put a malicious link here to make the user execute it" or email attachment business, particularly when you say "Remote Code Execution."

t

Have you tested out the actual exploit method in a lab environment yet to see just what can be done as I have?

If you are considering this "Remote Code Execution" then why not just have the victim run an .exe from the "complete anonymous share" you've managed to get
people connected to and save all the trouble?   This would still run as the user context, and if the hijacked DLL tried to do something a normal user couldn't do then it too would be blocked or fail anyway. 

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

[Tyler Borland]

While the circumstance of the type of exploit may change, the actual exploit
type does not to me.

It does not escalate privileges, it will run under the context of the user
who opened the mcl as this is the same user level lpksetup will run under as
well. However, from my experience under Windows 7 Ultimate in VirtualBox,
even if lpksetup.exe is blocked by UAC in more paranoid settings, the
payload will still run as the lpksetup halts for execution somewhere after
the import. In Windows 7 you have a verbosity meter, I set it higher so
that it would treat executables signed by Microsoft just like the rest. In
Windows vista, this setting is either on or off. The Windows 7 test box
should have higher restrictions because of this change than Vista will
have. Anyway, I opened the mcl file over a test public share and UAC popped
up requesting permissions. I thought this would've killed the exploit as it
killed the process, but when I sadly hit cancel, I was presented with the
payload's result (calc in the PoC). I just thought this piece was
interesting so I included it. Sorry for any confusion.

Anyway, with your typical stack overflow, you modify the PC (ie - eip in
x86, rip in x64, etc.) to point to your new instructions (likely not
directly) you'd like ran. This, I believe, is your default type of remote
code execution.

With this exploit, loadlibrary is pointing to a dll on a remote system (our
instructions we'd like to export to the process and continue executing) due
to how the application works and how the default windows search path is
setup.

The slimmed down execution flow of the application is:
....
The loadlibrary function looks for oci.dll and will search in the following
pattern:
1. The directory from which the application loaded - NO --
C:\Windows\system32\oci.dll
2. 32-bit System directory (Windows\System32) - NO --
C:\Windows\system32\oci.dll (it indeed does look twice even if the location
is the same as the application location)
3. 16-bit System directory (Windows\System) - NO --
C:\Windows\system\oci.dll
4. Windows directory (Windows)
- NO -- C:\Windows\oci.dll
5. Current working directory - YES --
\\140.130.120.110\Share\oci.dll
The function will continue on this remote dll
It gets imported and WinExec (our happy PoC) pops calc

While I agree the exploit is not as sexy as a stack/heap overflow that does
not require user intervention in most cases, this does execute code from the
injected library that's given by a remote user. This is all inside the
context of the process, which means an exploit in the process and the way
it's written to look for this library (ie - how they looked for oci.dll
instead of a full path so that this vulnerable default search path is used).
The uses of this would vary, but I would think it'd effect local attacks
more than anything. Local as in LAN, not physically at box obviously.
What's the best, however, is that .mlc can be completely legitimate and have
appropriate uses, the oci.dll just needs to be in that same location. If
you'd like an actual remote kind of example, this is only one file format.
There are many many file formats and lots of businesses use shares to
well...share things. Think of a large compiled list of known file formats
and associated dll's that allow injection could help further an attack to
other hosts. For example, we'll use malware as it's probably the easiest
way to explain widespread attack uses. Malware hits one host, scans for
open shares, lists contents of open shares, searches extensions, find
possible vulnerable extensions, place injectable dll on share, next time
someone accesses the file (remember, file does not have to be changed at
all. A dll just has to be on the same location. So if a folder on a share
is full of language packs, or full of text files, or full of any vulnerable
extension, it can be exploited to run this code.
I would love to test a more interesting payload that doesn't just pop a
useless process and how it'd interact with application whitelists and how
being signed by Microsoft really helps a binary do things.

Anyway, not to get off track of the things I'd like to do. It's not really
the how, but the what of the exploit that I'm really basing this description
off of.

Keep the questions coming if you have them.
*I keep forgetting about reply-all, don't use mailing lists much*

On Mon, Oct 25, 2010 at 6:56 PM, Thor (Hammer of God)

Post by Thor (Hammer of God)
I've tested loading a library from an application that requires admin
privileges from a normal user and it will prompt for UAC if needed or fail.
I understand where the jacking takes place, but you are making it seem like
you can bypass user permissions when you can't. At least that's what I got
from your OP. IOW, even if the original app you run doesn't require UAC, if
the jacked .dll requires escalated permissions, which would be just about
anything interesting you could do, then it will fail (or prompt depending on
how you write it).
The main point is that you've got to get people to not only connect up to
your remote share, but you've got to get them to execute the file, etc. So
I'm just wondering what makes this anything more than any other "put a
malicious link here to make the user execute it" or email attachment
business, particularly when you say "Remote Code Execution."
t

Have you tested out the actual exploit method in a lab environment yet to

see just what can be done as I have?

If you are considering this "Remote Code Execution" then why not just

have the victim run an .exe from the "complete anonymous share" you've
managed to get

people connected to and save all the trouble? This would still run as

the user context, and if the hijacked DLL tried to do something a normal
user couldn't do then it too would be blocked or fail anyway.

[Thor (Hammer of God)]

I thought this would've killed the exploit as it killed the process, but when I sadly hit cancel, I was presented with the payload's result (calc in the PoC). 
I just thought this piece was interesting so I included it.  Sorry for any confusion.

Yes, I understand that part... My point is that the payload result of "calc" would run like that, but if the payload did something else that required admin privileges, it would fail. But I understand your point, and I do find it interesting that the cancel proceeds with the .dll load. That might be something worth looking at in more detail.

t

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

[Jann Horn]

Post by Thor (Hammer of God)
The main point is that you've got to get people to not only connect up
to your remote share, but you've got to get them to execute the file,
etc. So I'm just wondering what makes this anything more than any
other "put a malicious link here to make the user execute it" or email
attachment business, particularly when you say "Remote Code
Execution."

Err... as far as I know, the interesting part is having the current path
be set to something you can control (to make windows load evil dlls),
and if you just link to the file, that's not the case.

Jann

[Thor (Hammer of God)]

Post by Thor (Hammer of God)
The main point is that you've got to get people to not only connect up
to your remote share, but you've got to get them to execute the file,
etc. So I'm just wondering what makes this anything more than any
other "put a malicious link here to make the user execute it" or email
attachment business, particularly when you say "Remote Code
Execution."

Err... as far as I know, the interesting part is having the current path be set to
something you can control (to make windows load evil dlls), and if you just link
to the file, that's not the case.

But your *aren't* controlling it. The loadlibrary seek priority is a set path. The user must first connect to the share, and launch the file from the share. THAT makes it part of the working directory. These are not the droids you are looking for.

This particular execution mechanism still makes lpksetup run and it still launches UAC. Now what IS interesting is that, as I've previously stated, when one cancels UAC, the oci.dll is still executed - however it can only run code that the user can.

Thus, if you are going to get a user to connect to a share and launch a file from that share, why make it go through all that crap (and launch UAC) when you can just have them run an EXE that does whatever you want in user mode without worrying about UAC at all. That's my main point.

t

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

[Tyler Borland]

Post by Thor (Hammer of God)
But your *aren't* controlling it. The loadlibrary seek priority is a set

path. The user must first connect to the share, and launch the file from
the share. THAT makes it part of the working directory. These are not the
droids you are looking for.

I don't understand why you don't believe we are in control of what the
process decides to continue execution on on a remote machine. If oci.dll
never existed on that directory, which there's no reason it should, nothing
will obviously happen. The attacker is doing something to make the remote
process resume execution on the attacker supplied instructions. We can't
say it's normal behavior because then every application would obviously have
the same library loading problem. It's a vulnerability in how the process
uses loadlibrary() and relies on the vulnerable search path. If oci.dll was
on a remote share and the process used a full path, this problem would not
exist and we would not have control anymore. I'm sorry I'm not explaining
this part well.

Post by Thor (Hammer of God)
Thus, if you are going to get a user to connect to a share and launch a

file from that share, why make it go through all that crap (and launch UAC)
when you can just have them run an EXE that does whatever you want in user
mode without worrying about UAC at all. That's my main point.

Now, as you're forcing me to debate the merits of this exploit and why we'd
want this over simply saying 'here, download this exe', I'll give close to
the same example as before:
First, of all, I envision this attack to be most useful on a local network
where regular business uses SMB for shared projects, accounts, and etc.
Yes, this happens often in businesses. Now, this is one of many many file
formats and applications that are vulnerable to this. Say, for example,
you're looking \\192.168.20.10\work\oct2010 and it's full of .docx files for
this month. Well, there's a dll hijack in Microsoft Windows under*
**rpawinet.dll
for .docx files.** *Drop your payload dll in the SMB and whomever accesses
a normal .docx in that directory will have this payload execute. Now, I
believe UAC was only achieved through more paranoid settings in 7. Which
means no prompt in Vista nor with default UAC in 7. I could be wrong on
this and am not able to test at the moment.

Stealth points to the exploit over other vectors:
1.) No modification needs to be done to any file. All the victim has to do
is open the file to work on like they may do every day. No specific file
access by the user is required (.exe), no trickery to get them to open the
file is required, and etc. Just everyday business practices leading to
exploitation of the user.
2.) This happens everytime the application starts regardless of there
actually being a .dll on the remote share. Which means this is normal
network traffic and not unusual activity for the application to request
this.
3.) No alerts to the end user.

Same thing applies to a remote share. I currently work as a Security
Analyst and must say I see normal external SMB share access quiet often.
Now, remotely .docx would be a good choice. However, .mp3 is the better one
for your typical home user (new pirate site that has a lot of music for free
by accessing x share . However, we're talking more targeted than drive-by
capable. From this point, it depends on your method of attack to keep the
alerts away from the user. But, remember, these are legitimate files
they're getting here, not backdoored or trojaned files.

Better explained or now more confusing? I understand your point on why you
believe that if a user is going to load a vulnerable file, why not just give
them a link to a trojan'ed executable, however this method is much more
indirect and stealthy than that.

Keep the questions coming if you've got them.

On Tue, Oct 26, 2010 at 1:54 PM, Thor (Hammer of God)

Post by Thor (Hammer of God)

Post by Jann Horn

Post by Thor (Hammer of God)
The main point is that you've got to get people to not only connect up
to your remote share, but you've got to get them to execute the file,
etc. So I'm just wondering what makes this anything more than any
other "put a malicious link here to make the user execute it" or email
attachment business, particularly when you say "Remote Code
Execution."

Err... as far as I know, the interesting part is having the current path

be set to

Post by Jann Horn
something you can control (to make windows load evil dlls), and if you

just link

Post by Jann Horn
to the file, that's not the case.

But your *aren't* controlling it. The loadlibrary seek priority is a set
path. The user must first connect to the share, and launch the file from
the share. THAT makes it part of the working directory. These are not the
droids you are looking for.
This particular execution mechanism still makes lpksetup run and it still
launches UAC. Now what IS interesting is that, as I've previously stated,
when one cancels UAC, the oci.dll is still executed - however it can only
run code that the user can.
Thus, if you are going to get a user to connect to a share and launch a
file from that share, why make it go through all that crap (and launch UAC)
when you can just have them run an EXE that does whatever you want in user
mode without worrying about UAC at all. That's my main point.
t

[Thor (Hammer of God)]

If you are considering this "Remote Code Execution" then why not just have the victim run an .exe from the "complete anonymous share" you've managed to get people connected to and save all the trouble? This would still run as the user context, and if the hijacked DLL tried to do something a normal user couldn't do then it too would be blocked or fail anyway.

t

From: full-disclosure-***@lists.grok.org.uk [mailto:full-disclosure-***@lists.grok.org.uk] On Behalf Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: ***@securityfocus.com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack

/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking Vulnerability
Extension: .mlc
Author: Tyler Borland (***@gmail.com<mailto:***@gmail.com>)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and Windows 7 Enterprise should be vulnerable as well)
Effect: Remote Code Execution

lpksetup is the language pack installer that is included by default with Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc file through something like an open SMB or WebDav share, the oci.dll file will be grabbed and ran in the context of the vulnerable application.

This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist, so if a full path is not supplied when calling the dll or the search path has not been cleared before the call, we will hit our fifth search path and load the library from the remote filesystem.

Interestingly enough, while lpksetup is blocked for execution by UAC under a normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows complete anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors: http://www.binaryplanting.com/attackVectors.htm
*/

#include <windows.h>

int main()
{
WinExec("calc", SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
main();
return 0;
}

/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */

[ACROS Security Lists]

Hi Thor,

Thanks to Microsoft's "defense in depth," double-clicking an .exe from a remote share
pops up a security warning. In contrast, double-clicking a data file that opens a
vulnerable application (which downloads and executes a .dll from the same share)
doesn't trigger such security warning. You might argue that users don't care about
such warnings and you might be right.

On the upside (or downside, depending on one's role in this game), our researchers
have already found an attack vector for binary planting (a superset of dll hijacking)
that works entirely through a web browser and only requires two single clicks
anywhere on the page - which is what we all do when we browse web pages. So if luring
a user to a remote share and hoping he would double-click a file seems unrealistic,
this might change your mind. And it's important that security leaders - like yourself
- understand this so that the followers won't be lured into a false sense of security
by considering remote attacks merely hypothetical. I'm afraid every single instance
of this bug we've seen so far is remotely exploitable in a practical enough way that
even the highly-aware and cautious people like the members of this list can easily be
hacked.

Cheers,
Mitja

Mitja Kolsek
CEO&CTO

ACROS, d.o.o.
Makedonska ulica 113
SI - 2000 Maribor, Slovenia
tel: [phone]
fax: [phone]
web: http://www.acrossecurity.com

ACROS Security: Finding Your Digital Vulnerabilities Before Others Do

If you are considering this "Remote Code Execution" then why
not just have the victim run an .exe from the "complete
anonymous share" you've managed to get people connected to
and save all the trouble? This would still run as the user
context, and if the hijacked DLL tried to do something a
normal user couldn't do then it too would be blocked or fail anyway.
t
Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL
Hijacking Vulnerability
Extension: .mlc
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista
Ultimate/Enterpries and Windows 7 Enterprise should be
vulnerable as well)
Effect: Remote Code Execution
lpksetup is the language pack installer that is included by
default with Windows Vista/7 Ultimate or Enterprise editions.
By opening a .mlc file through something like an open SMB or
WebDav share, the oci.dll file will be grabbed and ran in the
context of the vulnerable application.
This is a LoadLibrary() load path bug. The load library
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable As
OracleOciLib is not used on target system, oci.dll does not
exist, so if a full path is not supplied when calling the dll
or the search path has not been cleared before the call, we
will hit our fifth search path and load the library from the
remote filesystem.
Interestingly enough, while lpksetup is blocked for execution
by UAC under a normal user, the injected library (payload)
will still execute.
Exploiters make sure your system's security policy,
secpol.msc, allows complete anonymous share access for
connecting users.
Outlook links seem to be the current exploit toyland, other
vectors: http://www.binaryplanting.com/attackVectors.htm
<http://www.binaryplanting.com/attackVectors.htm>
*/
#include <windows.h>
int main()
{
WinExec("calc", SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,
LPVOID lpvReserved) {
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */

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