Date: Tue, 26 Oct 2010 15:45:14 -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>,
	Jann Horn <jannhorn@...glemail.com>
Subject: Re: Windows Vista/7 lpksetup dll hijack

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

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

> >Am Montag, den 25.10.2010, 22:56 +0000 schrieb 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
>
>

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