This is the first of a short series of entries that demonstrate the creation of a simple security/penetration-testing application. The end-result will be a simple NetBIOS Name Service spoofer, written in Python. The introduction to this series, including the discussion of the issue we are exploiting, is available here.
If you’re enjoying the packet analysis aspects of this, you might be interested in the SANS IP Packet Analysis course I’ll be teaching soon
The first order of business is to see what we’re getting into. We already know that the NetBIOS Name Service (NBNS) requests are sent as broadcast UDP, so it’d be nice to take a look at these packets to get an idea of the format, and how the responses look under normal circumstances. We’ll be able to use this information to craft our own malicious responses later.
The best way to examine the NBNS packets and behavior is to capture the traffic coming from real Windows machines. Given that many of you may not have a network with a couple of Windows machines that you’re allowed to tinker and sniff on, we’ll do this through the magic of virtualization. You also may be like me, somewhat of a nomadic hacker, so your mobile lab is your laptop.
It doesn’t really matter what virtualization software you use, but I’m going to make a strong recommendation for VMWare Server, for the following reasons:
- It’s free. A lot of people I talk to know that VMWare Player is free, however they do not realize that Server is also a free product.
- It’s very easy to install in Ubuntu. There’s a how-to here.
- Nice interface. Similar to Workstation, however it’s separated into a client and server. That said, here’s nothing wrong with running both on the same machine. It’s very easy to create and manage VMs.
- Great network configuration. It’s very easy to set things up to be either bridged, NAT’d, or completely isolated. This is important when you’re doing stupid network tricks like this.
So, I have created two virtual Windows XP machines, that are sitting in VMWare on a NAT’d network (172.16.185.0/24), so the NetBIOS traffic is contained between the VMs and the host OS. I can use Wireshark to sniff on the interface the host OS is using for the NAT’d network, and capture this traffic. Once the testing environment is set up, I can run a couple of scenarios to see what the NBNS traffic actually looks like.
First, I test the scenario described in the previous blog entry, where a user typo’s a domain name and the OS resorts to NBNS to try and resolve “example.cpm”. So, in one of my VMs, I pull up IE, and try to go to “example.cpm”. This pcap file is a capture of the traffic:
You can see, if you open this file in Wireshark, that the Windows machine gave the DNS server (.2) a chance at resolving “example.cpm”. The DNS server responds that there is no such name, so Windows tries again for “example.cpm.localdomain”, which is also non-existent. The next three packets are of interest! Three times, in intervals of one second, the Windows machine sent out a broadcast UDP packet, containing an NBNS Name qeury for “EXAMPLE.CPM”.
Now that we’ve verified the behavior discussed yesterday, we can take a look at what a legitimate NBNS Name query response looks like. For this, I had one Windows VM (xpprotest) ping another Windows VM (xpprotest2) on the NAT’d network. The sniffed results are in this pcap file:
Taking a look at this dump, the same process as the other dump can be observed, winding up with an NBNS Name query for “XPPROTEST2″. This time, however, the host being qeuried is there, and it responds with a NBNS Name query response, stating that “XPPROTEST2″ is at 188.8.131.52. Let’s take a closer look at the request, in this screen shot:
It’s pretty straightforward. There’s a 16 bit transaction ID for pairing responses up with queries, and a set of flags which identifies this NetBIOS traffic as a name query. You’ll notice that the host name, “XPPROTEST2″, which is highlighted in both the dissection and hex panes, is encoded in a way you might not be familiar with. We’ll deal with this later when we write some code to capture and deal with these packets.
For now, let’s look at the response from “XPPROTEST2″:
If you compare the two, you’ll see they’re very similar. The flags reflect that it is a response, as does the number of “answers”. There is some additional information tacked on at the end, regarding how long the results are valid, and finally the interesting bit (highlighted): the IP address that corresponds with “XPPROTEST2″.
So, to wrap things up for this entry, you’ve seen how to do some simple analysis to get the information necessary to write this app. Next time I’m going to get into how to look at these packets in Scapy and we’ll get started deciding what our nbnspoof app will do, and start a bit on the code.