Close

HAVE QUESTIONS?

A partner account manager can help. Contact us today.

 Subscribe me to your mailing list

NetBIOS spoofing for attacks on browser

Sometime ago during pentest NetBIOS protocol got my attention. Especially, NetBIOS naming and its co-work with DNS. NetBIOS is an old protocol, distributed world-wide, but it doesn't have many security mechanisms. And I think that many interesting things are born in different technologies' interception. So I started a little research and I want to show some results of it.

NetBIOS Intro

First of all, there is some common information about NetBIOS. From wiki: "NetBIOS is an acronym for Network Basic Input/Output System. It provides services related to the session layer of the OSI model allowing applications on separate computers to communicate over a local area network As strictly an API, NetBIOS is not a networking protocol."

NetBIOS protocol provides some services, including Name Service. It is responsible for resolving of NetBIOS names to IP-address. Name Service operates on UDP port 137. So it's analogue to DNS. NetBIOS Name can include any alphanumeric characters except:

\ / : * ? " ; | + space

Max Name length is 15 characters.

Name resolution can be done either by a special WINS server (NetBIOS Name Server) or a broadcast request. But the second method is often used. A NetBIOS request has «Transaction ID» field with a unique identifier. So, when somebody tries to resolve NetBIOS name, Windows sends a broadcast request and we can catch it and send a reply with any IP-address. It is a NetBIOS Name Service-spoofing (NBNS) attack – a classic Man-in-the-middle attack. In addition, NetBIOS is enabled by default in all Windows systems.

Old Tricks

When I got into the NetBIOS-protocol, I've got an idea to create a Metasploit module to perform NBNS-spoofing, but Tim Medin passes ahead of me :) Almost a year ago, he created that module (auxiliary/spoof/nbns/nbns_response). In addition, he wrote a great post about using of NBNS-spoofing for NTLM-relay attack. A bit later I'll add his trick to SMBRelay Bible, if he accepts it :)

Then I tried to improve his ideas…

Tim wrote two interesting details.

The first is a sequence of resolution IP-addresses in Windows OS:

  • local hosts file - C:\Windows\System32\drivers\etc\hosts
  • DNS
  • NetBIOS Name Service

Secondly, all modern browsers have "intelligent address bar". This bar is used as address bar and as a search bar at the same time. When a user enters a word in it, a browser tries to access a host with such name and only then it tries to search this word.For example, if I enter "erpscan" in address bar of my browser, it tries to get IP-address of "erpscan" by DNS, then by NetBIOS Name Service and after all "erpscan" is gone to default search engine.

Therefore, we can use a NBNS-spoofing attack and send reply with our IP-address to user's browser, when it tries to resolve "erpscan" by NBNS. Then user's browser connects to our web-server.

New Tricks

But let's go forward. As we can see, if Windows can't perform IP-resolution via DNS, it tries NBNS. And what if we try to connect to aaa.google.com?

There is analogue situation. DNS is the first, NBNS is the second… And we can spoof Internet addresses! So, there we have that NBNS-spoofing is analogue to DNS-spoofing.

Is NBNS-spoofing attack better than DNS-spoofing?

No, it is not. Because NBNS-spoofing attack has some rough limitations:

  • It works only in local networks
  • It has hostname length limitation (15 characters)
  • It can spoof only hostnames which DNS can't resolve. But we can bypass this limitation, if we can make DoS attack on DNS server.

By the way, NBNS-spoofing attack can be very useful in some situations. The main plus of this attack is that it doesn't send any illegal traffic. DNS-spoofing or arp-poisoning are "aggressive" attacks and perform much "bad" traffic. So, it's harder to detect NBNS-spoofing attack by IPS/IDS systems. In addition, it can be useful when DNSSEC is used in a network.

Ok, but what can we gain with NBNS-spoofing's limitations?

Yes, we can spoof only hostname which it can't find via DNS (without DoS of DNS server), but we can spoof subdomains! And it is enough for us.

There is a list, what we can do, if we can spoof subdomain of attacking domain and "redirect" user to our web-server.

  • Steeling of session cookie. Cookies can be set to all subdomains of a domain (domain=.foo.com;). So if we spoof a subdomain of a domain, browser sends us a victim's session cookies. Therefore, if a cookie is set without a domain-field (such situation is very often), Internet Explorer sets them to a domain and all its subdomains. But, by RFC, IE should set it only to current domain. (Researched by @D0znpp)As we can see, we can steal cookies very often.
  • Session Fixation. Same Origin Policies set an interesting exception to cross domain interaction rules. Subdomain can set (and rewrite) a cookie of domain. For example, aaa.google.com can set cookie to google.com, but couldn't set to bbb.google.com or zzz.aaa.google.com. We can use it. If a web-application of a server has session fixation vulnerability, we can spoof subdomain of this server and set cookie to it. *A weird thing. During test I was trying to set cookie to "localhost" from subdomain of localhost, but I couldn't do it.
  • Cross domain policies bypass. It is a frequent situation, when * is used for domain in crossdomain.xml. For example, adobe.com: <allow-access-from domain="*.adobe.com"> We can spoof subdomain (aaa.adobe.com) and get full session riding via Flash.
  • Phishing. Classic phishing attacks… Catch a user In all these attack vectors, we have a little problem. How to enforce user to come to our (fake) subdomain? For resolving the problem, we can use a NBNS-spoofing attack :) Example of cookie stealing for example.com:
    • Run NBNS-spoofing against all domains
    • Run our web-server with a little script, which should: Collect incoming cookies (sorted by Host http-request field) and reply a simple html page with hidden iframe with "src=aaa.example.com".
    • When user inserts into browser any inexistent domain name, our NBNS-spoofing attack will work and his browser will come to our web-server. Then the browser will try to open aaa.example.com, NBNS-spoofing attack will work again and we'll get cookies from example.com.

Outro

NBNS-spoofing attack is an interesting stuff and it's not looking too hard to realize such attacks in real life.

I'll be glad if my research will be interesting and useful for anyone :)

By the way, I would like to thank @D0znpp for his help!

And thank you, for your attention.

Alexey Tyurin