Windows Transparent Authentication updates

[grutz at jingojango.net (Kurt Grutzmacher)]

On Mon, Nov 19, 2007 at 09:46:16AM -0600, natronicus wrote:
> The RSnake posting you referred to was an email from me.  Just wanted
> to address your three circumstances:

Great! I was giving some brain dump on what I'd learned from doing
NTLMSSP Type Message work. Didn't want to get into too much detail
before.

> > 1. URL must be an internal IP address or hostname (no FQDN)
>
> Yep, that's why I used NBNS spoofing to create an arbitrary computer
> name and point it to an external IP.

However you can get the browser into that Intranet Zone then it's all
good. There are a number of ActiveX controls that can be instantiated
within that zone with a host of issues and in some cases an org will
lower the restrictions further to get their own ActiveX code to work.
 
> > 2. Server must send the correct domain workstation is a member of
>
> I'm not sure what you mean by Server.  If you're referring to the
> applet doing the spoofing, it doesn't need to know your domain, as
> it's using NBNS/WINS.  NBNS doesn't care about your domain.  You need
> to know both the domain name and the AD server's address if you're
> doing dynamic SOA updates to cache a fake DNS entry.

Server = attacker. I'm focusing on the NTLMSSP here and not the spoofing.

When the attacker sends the Type 2 message in response to the client's
Type 1, it has to contain the Windows domain name the client belongs to.
If the client's workstation is in "WINDOM" and you send it "INETDOM"
then transparent authentication will not work as the user will be
presented a pop-up asking for user/password.

> > 3. Server must not be accessed via the proxy
>
> Again not sure what you mean by Server, but if here you mean the
> attacker's machine, that's not true.  All communication between the
> attacker and the browser occurs through HTTP (well, DNS for the actual
> DNS rebinding, but that's outside the scope of this part of the
> attack).  All other communication occurs between the applet in the
> browser and the localhost.

Again, server = attacker and attack is NTLMSSP as the method to capture
or broker the authentication.

If you give the URL as http://attacker/ then the browser needs to be
able to make a HTTP request. If the machine has a proxy configuration
then they're mostly likely going to designate any non-FQDN as being
behind the proxy server. The internal WINS may return an Internet IP
address but if the browser can't reach it without going through a proxy
server then the attack will fail.

Not EVERY organization uses this method. I'm just stating that in some
cases this scenario may be problematic.

> Regarding the proxy to use once you've begun the
> auto-auth/pass-the-hash, this is what I'm working on now.  (This
> theoretical proxy should be able to extend many metasploit exploits
> through the browser via DNS rebinding.  There are port/protocol
> restrictions keeping it from allowing all exploits, and it would never
> work for anything that requires the victim to initiate the
> connection.)  If anyone has code they'd be willing to release, please
> let the list know, as it would be appreciated.

I'd love to work with you on this as I've got some code that does this to
some extent. I've been focusing on controlling the browser to initiate 
NTLMSSP requests to allow browsing as a controlled user, authenticating
to IMAP/POP3, etc.

AFAIK this attack was first shown a few years back at SyScan by Jesse Burns. 
He used jCIFS but ... Java... yeech.

-- 
                 ..:[ grutz at jingojango dot net ]:..
     GPG fingerprint: 5FD6 A27D 63DB 3319 140F  B3FB EC95 2A03 8CB3 ECB4
        "There's just no amusing way to say, 'I have a CISSP'."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20071119/7c1ff62b/attachment.pgp>