Date: Tue, 26 Oct 2010 03:16:54 -0400
From: Tyler Borland <tborland1@...il.com>
To: "Thor (Hammer of God)" <thor@...merofgod.com>
Cc: Full-Disclosure mailing list <full-disclosure@...ts.grok.org.uk>
Subject: Re: Windows Vista/7 lpksetup dll hijack

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)
<thor@...merofgod.com>wrote:

> 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?
> >
> >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.
> >>
>

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