mailing list archives
Re: Windows Vista/7 lpksetup dll hijack
From: TBorland1 () gmail com
Date: Mon, 25 Oct 2010 22:39:10 +0000
The language file installer can be completely legitimate. The actual
exploit is the process running the library from the remote location. This
will execute the library/code in the context of the running application
under the current user and will not present a warning dialog box depending
on your chosen method if attack. I have made sure that this does also not
care if UAC allows the application to run or not.
I have provided a link to ACROS's look into the different attack vectors to
give you more clues as to how this can be exploited without any hassling
alerts to the victim/end user. IE6 and Outlook seem to be the most
prevalent ways of doing this. However, there are certainly other more
interesting vectors out there.
Have you tested out the actual exploit method in a lab environment yet to
see just what can be done as I have?
On Oct 25, 2010 5:34pm, "Thor (Hammer of God)" <thor () hammerofgod com> wrote:
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.
From: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure-bounces () lists grok org uk]
On Behalf Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: bugtraq () securityfocus com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Author: Tyler Borland (tborland1 () gmail com)
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:
WinExec("calc", SW_NORMAL); // the typical non-lethal PoC
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/