Close

HAVE QUESTIONS?

Contact us today.

Subscribe me to your mailing list

NetBIOS spoofing for attacks on browser

Some time ago during a pentest, the NetBIOS protocol got my attention, in particular NetBIOS naming and its co-work with DNS. In spite of having a long-time distribution, NetBIOS is a protocol which doesn’t have many security mechanisms. I think that many interesting things are born in different technologies’ intersection, so I started a little research and I would like to show some results of it.

NetBIOS Intro

On the Internet there is a lot of information about NetBIOS. Wiki says: “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 excepting NetBIOS names by IP-address. Name Service operates on UDP port 137 being an analogue to DNS. NetBIOS Name can include any alphanumeric characters except:

\ / : * ? ” ; | + space

Maximum Name length is 15 characters.

Name resolution can be done either with the use of a special WINS server (NetBIOS Name Server) or by a broadcast request, the second method is more spread. A NetBIOS request has «Transaction ID» field with a unique identifier. When somebody tries to resolve a NetBIOS name, Windows sends a broadcast request and we can catch it and send a reply from 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 had an idea to create a Metasploit module to perform NBNS-spoofing, but Tim Medin passed ahead of me. Almost a year ago he had already created that module (auxiliary/spoof/nbns/nbns_response). In addition, he had written a great post about the use of NBNS-spoofing for NTLM-relay attack. A bit later I’ll add his trick to SMBRelay Biblein case of receiving of the permission.

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”. It is used both as an address bar and as a search bar. 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 for 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.\only after that “ERPScan” is gone to default search engine.

Therefore, we can use a NBNS-spoofing attack and send a reply with our IP address to a user’s browser, when it tries to resolve “ERPScan” by NBNS. Then the user’s browser connects to our web-server.

New Tricks

Let’s go forward. If Windows can’t perform IP resolution via DNS, it tries NBNS. What if we try to connect to aaa.google.com?

There is an analogue situation. DNS is the first, NBNS is the second. We can spoof Internet addresses, it means that there that NBNS-spoofing is analogue to DNS-spoofing.

Is an NBNS-spoofing attack better than DNS-spoofing?

No, it is not because an 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. Though we can bypass this limitation, if we can perform a DoS attack on DNS server.

By the way, NBNS-spoofing attack can be useful in some situations. The main benefit of this attack is that it doesn’t send any illegal traffic. DNS-spoofing or ARP Poisoning are “aggressive” attacks and make much “worse” traffic. So it’s harder to detect NBNS-spoofing attack by IPS/IDS systems. In addition, it can be helpful 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 which is enough for us.

There is a list of things that we can do, if we can spoof subdomain of attacking domain and “redirect” a user to our web-server.

  • Steeling of the session cookie. Cookies can be set to all subdomains of a domain (domain=.foo.com;). If we spoof a subdomain of a domain, the browser sends us a victim’s session cookies. Therefore, if a cookie is set without a domain-field (such situation is common), 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, it is possible to 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 the 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 which comes in handy. If a web application of a server has a session fixation vulnerability, we can spoof the subdomain of this server and set cookie to it. There is some weird thing. During test I tried to set cookie to “localhost” from subdomain of the local host, but it failed.
  • 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 a subdomain (aaa.adobe.com) and get the full session riding via Flash.
  • Phishing. Classic phishing attacks… Catch a user. In all these attack vectors, we have the same problem. How to a enforce user to come to our fake subdomain? For resolving it we can use a NBNS-spoofing attack. An 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 with a simple HTML page with hidden iframe (“src=aaa.example.com”).
    • When user inserts into a browser any inexistent domain name, our NBNS-spoofing attack will work and their 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.

Conclusion

NBNS-spoofing is an interesting type of an attack and it’s not that hard to perform such attacks in real life.

I’ll be glad if my research will be useful for anyone.

I also would like to thank @D0znpp for his help.

And thank you for your attention.

Do you want more?

Subscribe me to your mailing list