(It's the post from January 2012)
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.
Then I tried to improve his ideas…
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
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…
Old Tricks
Tim wrote two interesting details.
The first is a sequence of resolution IP-addresses in Windows OS:
1) local hosts file - C:\Windows\System32\drivers\etc\hosts
2) DNS
3) 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 “dsecrg” in address bar of my browser, it tries to get IP-address of “dsecrg” by DNS, then by NetBIOS Name Service and after all “dsecrg” is gone to default search engine.
The first is a sequence of resolution IP-addresses in Windows OS:
1) local hosts file - C:\Windows\System32\drivers\etc\hosts
2) DNS
3) 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 “dsecrg” in address bar of my browser, it tries to get IP-address of “dsecrg” by DNS, then by NetBIOS Name Service and after all “dsecrg” 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 “dsecrg” 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 will be if we try to connect to aaa.google.com?
And what will be 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:
1) It works only in local networks
2) It has hostname length limitation (15 characters)
3) 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.
No, it is not. Because NBNS-spoofing attack has some rough limitations:
1) It works only in local networks
2) It has hostname length limitation (15 characters)
3) 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.
1) Stole 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.
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.
1) Stole 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.
2) 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 strange moment. During test I was trying to set cookie to “localhost” from subdomain of localhost, but I couldn’t do it.
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 strange moment. During test I was trying to set cookie to “localhost” from subdomain of localhost, but I couldn’t do it.
3) 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.
4) Phishing
Classic phishing attacks…
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.
4) 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:
1) Run NBNS-spoofing against all domains
2) Run our web-server with a little script, which should:
- Collect incoming cookies (sorted by Host http-request field)
- Reply a simple html page with hidden iframe with “src=aaa.example.com”
3) 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.
Example of cookie stealing for example.com:
1) Run NBNS-spoofing against all domains
2) Run our web-server with a little script, which should:
- Collect incoming cookies (sorted by Host http-request field)
- Reply a simple html page with hidden iframe with “src=aaa.example.com”
3) 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.
Комментариев нет:
Отправить комментарий