[framework] NBNS/WINS Name Spoofing

Tue Mar 11 11:04:51 CDT 2008

If any metasploit admins object to this discussion, tell us to take it
offlist and we will.  Otherwise I'll continue to keep it here (if
there's more discussion to be had).

I'm glad to hear you got it working.

That's an interesting idea.  I had written off MITM/XSS/etc because to
spoof an already-existing resource with NBNS, the following conditions
have to be met:

- The resource has to normally be resolved via WINS/NBNS.  If they use
DNS to resolve it, it's a no go.
- You have to be able to guess the transaction ID faster than the
legitimate resource can respond.  This one was the deal breaker.

Phishing would be interesting.  (Linking to http://Comp-Security/ or
http://Password-Change/ for example.)

As far as guessing the TID, I was spoofing it by looping from 0x8000
to 0x9fff repeatedly until the timing hit the correct one.  Perhaps
you can get aggressive with the applet and speed this up, I don't
know.  But using the looping method, the target usually got off 2
rounds of requests before it accepted my reply.  In my environment,
the legitimate service usually replies well ahead of that.

natron

On Tue, Mar 11, 2008 at 5:12 AM, Parity <pty.err at gmail.com> wrote:
> I just did some quick experimentation to see if this works.  Which it does.
> Nice.
>
> Some quibbles:
>
> #1: No java, no exploit, of course.  If only Sun hadn't sued Microsoft all
> those years ago, Windows clients might have been vulnerable by default.
>
> #2: Strictly speaking, this rebinding technique enables name spoofing, which
> in turn enables the interesting NTLM behavior.  And my own opinion is that
> this is *way* more interesting when viewed as a name spoofing technique,
> since name spoofing leads to a much wider variety of fun stuff such as:
>
> - man in the middle attacks
> - easy phishing
> - universal XSS
> - universal session fixation
> - etc etc etc
>
> #3 & finally: Just in case anybody is already thinking to themselves "whose
> bug is this?", I feel like voicing my $0.02, which is that this is not so
> much a NTLM / Microsoft / SSO problem as it is a Sun / Java problem.  It's
> the Java runtime which fails to pin the IP address and thereby enables name
> spoofing.  All of the other issues are secondary consequences which follow
> directly from the name spoofing condition.
>
> Apologies to anyone who feels we've strayed pretty far from the intended
> topic of this mailing list.  Cheers,
>
> - pty
>
>
> 2008/3/10 natronicus <natronicus at gmail.com>:
>
>
>
> > DNS rebinding allows you to rebind the name attacker.com to the IP address
> of the local host.  This works like so:
> >
> > 1. Victor loads malicious java applet from http://www.alice.is.evil.com
> > 2. The applet code looks up the local ip address with a .getlocalhost() or
> similar method and returns it to Alice
> > 3. Alice rebinds the domain name Alice.is.evil.com from its internet
> address (e.g. 64.233.167.99) to to Victor's internal IP address (e.g.
> 10.10.10.10)
> > 4. Victor (through Alice's applet) opens an iframe to http://ALICE
> > 5. The applet starts spamming NBNS answers for the hostname "ALICE" with
> IP address 64.233.167.99.
> >
> > Note: This is possible because Windows tries DNS first, which fails, then
> tries NBNS/WINS.  NBNS does not randomize transaction IDs under Windows,
> starting at 0x8000 on boot, and windows doesn't care that it received the
> answer from its own IP address.
> > 6. Victor maps ALICE to Alice's internet IP 64.233.167.99, but thinks
> ALICE is local because it received the answer through NBNS and because there
> is no TLD.
> > 7. Since Victor thinks ALICE is local, it will auto authenticate via IWA
> > ... and the attack proceeds as outlined in the previous email.
> >
> > Variations: You don't have to use NBNS.  You can use dynamic SOA updates
> to DNS if the client's network is allowing Active Directory to manage DNS.
> Often times, if the name ends in the same domain name it will place it in a
> higher trust zone.
> >
> > Also, all the trickery above does is place alice's IP address in a higher
> zone of trust.  This often allows you to do things like auto-load unsafe
> activex controls.
> >
> > natron
> >
> >
> >
> >
> >
> > On Mon, Mar 10, 2008 at 10:49 AM, Kurt Grutzmacher <grutz at jingojango.net>
> wrote:
> >
> > > Your memory is correct. The classical SMB Relay attack assumes that the
> user is a local administrator of the workstation they're coming from. Since
> I have been in more environments lately where this is no longer the case
> I've shifted the attack to some of the foundational services that use NTLM
> authentication: IMAP, POP3, HTTP, etc.
> > >
> > > - Bob talks HTTP to Alice
> > > - Alice returns HTTP NTLM Authorization header, closes HTTP connection
> > > - Bob talks HTTP to Alice and sends Type 1 header
> > > - Alice initiates POP3/IMAP/SMTP/etc to Victor, passing Type 1 message
> > > - Victor responds with Type 2 message, including challenge
> > > - Alice sends Bob Type 2 message in HTTP header
> > > - Bob receives and processes request, sends credentials to Alice in Type
> 3 message
> > > - Alice ends Type 3 message to Victor, checks for authorization
> > > - Alice closes HTTP session with Bob
> > > - Alice sends commands as Bob to Victor, wash, rinse, repeat
> > >
> > > http://grutz.jingojango.net/exploits/psyduck-pop3.rb
> > >
> > > When you and I last talked about the DNS Pinning issue I was on-board
> and did some research and talked with another researcher doing NTLM/HTTP
> work. We've come to the same conclusion that DNS pinning probably will not
> work for this attack. Pinning changes the IP address of an already-known DNS
> name and by the IE has already put it in its specific trust zone. If you've
> got some code or something that shows this changing because of pinning, I'd
> love to see it.
> > >
> > > Right now this attack, like SMB Relay, only affects an Enterprise.
> > >
> > > Enterprise may be 50,000+ users of course. :)
> > >
> > > Kurt
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Mar 10, 2008 at 7:56 AM, natronicus <natronicus at gmail.com>
> wrote:
> > >
> > > > An NTLM-over-HTTP implementation would allow more than server attacks
> that require authorization (although this is handy for that, too).  You can
> perform the regular SMB_RELAY attack, but you're substituting the attacker's
> SMB server for an HTTP server, thus getting around the port restriction
> problems.
> > > >
> > > > It's been a few months since I've looked at the protocol and how this
> attack works, but if my memory is correct, it is functionally:
> > > >
> > > > 1. (HTTP) Victor clicks link / previews email / etc and issues a GET
> to http://alice, which requests Integrated Windows Authentication (IWA) with
> NTLMv1.
> > > > 2. (SMB) Alice begins an NTLMv1 SMB connection to Victor
> > > > 3. (SMB) Victor replies to Alice with the challenge hash
> > > > 4. (HTTP) Alice replies to the IWA request with the challenge hash
> just received
> > > > 5. (HTTP) Victor supplies the answer to the challenge request
> > > > 6. (SMB) Alice copies the answer from the HTTP stream to the SMB
> stream and authentication occurs
> > > > 7. (SMB) Alice uploads the payload and executes
> > > >
> > > > From a functional perspective, the attack is exactly the same, but
> uses port 80 on the attacker's box instead of the problematic 137-139 or
> 445.
> > > >
> > > > Additionally, with some java applets and DNS rebinding chicanery, you
> can extend this attack over the internet.
> > > >
> > > > Natron
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Mar 9, 2008 at 3:08 AM, Kurt Grutzmacher
> <grutz at jingojango.net> wrote:
> > > >
> > > > > I've done the work to get NTLM Type-message processing into MSF. At
> this tim there aren't any exploits within MSF that use the library, I just
> referenced it from some external ruby code I wrote but we should be able to
> integrate client-side NTLM-over-HTTP fairly easily for server attacks that
> may require authorization. I just haven't put it on the top of my list yet.
> > > > >
> > > > > http://grutz.jingojango.net/exploits/pokehashball.html has some of
> the information along with two exploits (hash grabber and HTTP-to-POP3 proxy
> exploit).
> > > > >
> > > > > If anyone wants to work on implementing any exploits, let me know
> and I'll work with you.
> > > > >
> > > > >
> > > > >
> > > > > 2008/3/7 natronicus <natronicus at gmail.com>:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Is there a particular reason you're trying to use Windows for this
> one?  I tried to mess with implementing NTLM-over-HTTP / Windows Integrated
> Auth a few months back, but got frustrated learning Ruby and it hit the
> projects-to-finish-later pile.  I recently saw HD mentioned in another
> thread someone was working on this problem, but it sounded like they may be
> focused on other items first (NTLMv2, for example).
> > > > > >
> > > > > > In any event, until the HTTP version is implemented, you're always
> going to have problems getting it to work on Windows, because Windows is
> incredibly greedy about those particular ports.  Why not use a Linux image
> in VMWare instead?  If your network will allow 2 IPs for 1 MAC address,
> there's no reason why you can't use it under (e.g.) Backtrack and still have
> access to whatever you need Windows for.
> > > > > >
> > > > > > Just a though,
> > > > > > N
> > > > > >
> > > > > >
> > > > > > 2008/3/7 Karlsson Anders <Anders.Karlsson at atea.com>:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > And it is realy hard to use port 445. I needed to disable almost
> every service and binding in my XP machine. After that I can not use the
> machine to connect to the server with old plain "net use", so I do not think
> using port 445 is the right way....
> > > > > > >
> > > > > > > /A
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > http://spool.metasploit.com/mailman/listinfo/framework
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > http://spool.metasploit.com/mailman/listinfo/framework
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > _______________________________________________
> > http://spool.metasploit.com/mailman/listinfo/framework
> >
> >
>
>