Sunday, November 2, 2008

Focused IDS Sensor for DNS

Many enterprises have what is known as a split domain name system (DNS) configuration. Split DNS is where you serve your internal network with one (or perhaps a pair) of DNS servers, but forward all unresolved requests to another DNS server(s) that lives within your DMZ. Using split DNS provides some security protection for your internal DNS servers, and performance benefit in that the internal servers do not have to cache external network information.

Additional security protection can be provided by carefully controlling your network perimeter (anti-spoofing and bogon filtering for example), and carefully configuring your external DNS servers to only respond to DNS requests that are within your network domain.

In recent times, DNS cache poisoning has risen as a significant challenge yet again. It has been noted that DNS is fundamentally flawed due to it's weak reliance on a matching DNS identification and packet source information in query responses. Though widespread deployment of DNSSEC (secure) is the correct solution, it has not gained in popularity enough at this time.

Beyond ensuring that you have correct vendor patches, which are written to ensure significant entropy in the randomly chosen DNS identification field, and UDP source ports, there needs to be another method to indicate that your DNS cache may be poisoned.

The two methods I find effective are to use the CAIDA project's DNS statistics collector (DSC), and to also deploy a focused Intrusion Detection Sensor (IDS) with Snort running directly on my DNS servers.

First of all, I would recommend becoming a registered snort user at in order to stay within about one month's release of the up to date snort signatures. Then, assuming you are running a UNIX based system for your DNS server(s), download the latest snort source code which as of this writing is snort-

  1. Compile and install snort.
  2. After installation, you should have a /etc/snort directory which contains a basic snort configuration file and the base set of rules.
  3. Download the latest registered user rule set from and extact it inside the /etc/snort directory.
  4. Now, start editing the /etc/snort/snort.conf file with your favorite text editor. In some installations, this file might be located in /etc/snort/rules.

Key variables you must set in order to get snort functioning are as follows with examples:
  • HOME_NET = $eth0_ADDRESS
  • DNS_SERVERS = [,]
Since this is a focused sensor, I would suggest that the home network (HOME_NET) be set to the address of the DNS server itself. The external network variable can simply be anything that is not the home network.

With regard to snort's preprocessors, you will need to keep frag3 and stream5 for both framentation and stream reassembly. Most importantly, the only remaining preprocessor you must have configured is the DNS preprocessor.

To keep the sensor memory usage low, I would disable (by commenting out) all other preprocessors, such as ftp_telnet, http, dcerpc etc. You are deploying a sensor focused on DNS so lets keep it optimized and looking at DNS traffic!

Next, go down to where the include statements reside, and comment out ALL of the includes listed except the one that reads: include $RULE_PATH/dns.rules

Now, test your configuration:

snort -p -c /etc/snort/snort.conf -A cmg -u_snort -g_snort -t/var/snort -l/var/snort/log

You should watch the output and make sure that there are no errors. Also, please note that the above command line uses the -p flag to disable promiscuous mode on your DNS server interface card. Again, let's remember that this is a focused sensor that is looking at the traffic going to/from this specific DNS system so your network card does NOT need to see other system traffic.

Also, to be as secure as possible, always run as a non-root user, hence the use of the -u_snort and -g_snort to change the effective running user and group id respectively.

Once you have checked that your configuration is operating as expected, then setup snort to run at boot time, and start the process as follows:

snort -pD -c/etc/snort/snort.conf -u_snort -g_snort -t/var/snort -l/var/snort/log

I would additionally suggest adding output alert_syslog into your configuration. If things are setup properly, the false positive (noise) level should be very low, so I personally syslog ALL alerts to the console of the UNIX system itself as well as the root user to make sure that if any IDS alerts show up, I will see them.

Following all these steps now gives you the equivalent of the canary in the coal mine. Your snort sensor is optimally configured to start sqawking if there are events such as a large number of DNS NXDOMAIN replies indicating potential cache posioning.

The additional bonus is that you will quickly find applications on your network that are misbehaving and incorrectly beating on your DNS infrastructure when they should not be!

Happy hunting.

Saturday, October 25, 2008

TShark - High performance packet capture

Wireshark users may not realize that there is a command line version of Wireshark, namely TShark, which provides superior packet capture performance. The challenge with Wireshark is that it has to update all of the window elements while at the same time capturing data, and it's defaults do not favor performance.

When you are in a situation of very high traffic flow (like a DoS attack perhaps), you really need to capture as much of the data as possible to a file for later "post analysis". I always use a combination of setting up the TShark capture with Berkeley Packet Filter (BPF), and then plugging the RJ-45 Ethernet cable in after the capture is set to run.

To run TShark within MS-Windows, you need to start a command window first.

Start -> Run -> CMD.EXE

Find the directory that TShark is installed within. For a default Wireshark installation, it is probably as follows:

CD \Program Files\Wireshark

Then, find out the HELP syntax from TShark:

tshark -h

The first thing you must do is find out which network interface number you must use for the data capture.

tshark -D shows all of the interfaces with an integer number in front of them. Windows understands all network interfaces by the long hexadecimal object identifier but you really don't want to have to remember that!

example output:

1. \Device\NPF_{11A468B6-C065-45F6-AB32-D69695A6F601} (MS Tunnel Interface Driver)
2. \Device\NPF_{A16900A3-020C-4B05-B430-4CD67527C189} (Realtek RTL8168B/8111B PCI-E Gigabit Ethernet NIC)

Now, select the right interface, capture some data and write it directly to a file. For example:

tshark-i 2 -s 200 -w example.pcap -f "tcp[13] = 0x14"

The particular example shown above captures data with the 13th offset of the TCP header equal to hexadecimal of 0x14. This happens to be packets that have the TCP flags of RST and ACK set. The -i flag is used to select the capture interface.

TShark will count the packets captured, and then you simply use the CTRL-C keyboard sequence to stop the capture when finished. After that, open your example.pcap file within Wireshark for full analysis. The (.pcap) file extension ensures you could simply double click the file itself.

With regard to the -s (snap length) flag, be aware that TShark will default to a packet capture length of 65,535 bytes, which given a standard 1514 MTU Ethernet frame size, will always capture the entire packet. Using a snaplen of 68 bytes makes the behavior of TShark identical to tcpdump default behavior.

Early versions of TShark did not allow a snaplen that is less than 68 bytes, however I believe there is a source patch that has fixed this now for those who like capturing headers only! Some quick calculations:

  • Ethernet header = 14 bytes
  • IPv4 header (without options) = 20 bytes
  • TCP header (without options) = 20 bytes
  • Typical TCP header options for Windows Vista = 12 bytes
  • UDP header = 8 bytes

If we examine a TCP SYN packet of a modern operating system, there are almost always TCP options attached. Windows Vista by default will use Max Segment Size (0x02), Window Scaling (0x03), and Selective Acknowledgement (0x04), as well as three No Operation (NOP = 0x01) options, giving a total of 12 bytes on a TCP SYN packet. The NOP option is used to pad the options data to even byte boundaries so that 32-bit processor code is happy!

To capture a Windows Vista TCP SYN packet header under IPv4 with all options, we would need a minimal snap length as follows:

14 (Ethernet header) + 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 66 bytes.

If you want to throw in some payload data, then add more to the snap length from there. I find that a snap length of about 200 gives good performance and captures a reasonable amount of data.

Keep your goals in mind! If you were capturing traffic that is a Samba CIFS file read for example, you can be pretty sure that the server to client TCP packets will have 1514 bytes of data, so use the default snaplen!

With regard to the Berkeley Packet Filters (libpcap / BPF), the standard language syntax applies. So, if ever in need of help, you can always get on a UN*X host somewhere and do 'man tcpdump' and learn all about the BPF syntax used within libpcap.

Some ideas as follows:

-f "src host and dst host"
-f "dst port 22"
-f "dst port 80"

This last example shows some interesting ways to use the BPF syntax in combination with binary masking for very specific filter matches. In the below example, we are taking the 13th byte of the TCP header, shifting it left by a nibble (4 bits), then masking it with 0x40 which is binary 0010 0000, and finally testing it not equal to zero. In short, this will show any packet with the TCP RST flag set, but not exclusively that flag. (ie: would could see purely the RST flag, or perhaps even packets with RST+ACK, or some other illegal combination)

-f "(tcp[13] << 4 & 0x40) != 0"

BPF syntax allows us to either use macros for matching (like: src port), or header field matches with integer offsets for the more sophisticated.

Next time you need to capture traffic that is saturating some network link, give TShark some consideration for ensure a high degree of performance and better accuracy.

Finally, for maximum network and security analyst safety, please always ensure you have the latest version of Wireshark and WinPCAP. There have been published exploits against these open source products and you don't want to be a victim!

Friday, October 24, 2008

Selling security via ethical hacking

I had the pleasure recently in my organization to receive a directive similar to this. "Please develop a presentation that shows people why they need to be a participant in our new higher security network service".

Ok, calling to all you creative geeks out there - wow... did I just get an order to "ethically hack"? My thinking was "yes" and this turned out to be one of the most fun assignments I had come across in a while.

My first response was to get my "get out of jail free" card signed. (kudos to our friend Ed Skoudis for this one:

I then went away for 2 weeks to develop a quick and scary hacking demo that I could present in 45 minutes as a pure sales job for higher security. The structure of the demo ended up being a combination of some powerpoint slides, and some real live Metasploit fun.

The powerpoint slides went as follows.
  • Describe the process of penetrating an enterprise network (scanning, recon, gaining access, keeping access, covering tracks). My colleague did a little google hacking show in the process.
  • Describe the C programming language and its flaws, paying special attention to how sub-routines in "C" are being exploited due to poor programming practices with respect to unbounded arrays.
  • Describe how sub-routines in "C" are embedded in just about all of the computing devices in use today
  • Show a Metasploit Demo!

So, without further ado, lets talk about the Metasploit demo. First of all, I have to admit upfront that this was a time limited (canned) demo and I decided in the interests of keeping my job, not to find targets on our live network. (Although I may have done so if I had obtained enough advance recon. time)

Here is what I did:
  1. Setup a laptop with two virtual machines on it. One of the two had an unpatched WinXP host with no service packs, the second of the two was WinXP with service pack 2.

  2. Using a second MacBook, I scripted two flavors of MetaSploit attacks. I called them "direct network attacks", and "indirect network attacks". The exploits used for either flavor were basically the same, it simply depended on whether I attacked the target directly over a local network (back to back cable) or had the target come to my local web service.

  3. Direct network attack exploits used were as follows:

    • MS03-026: RPC-DCOM buffer overflow
    • MS03-049: Workstation Service NetAPI buffer overflow
    • MS04-007: Abstract Syntax Notation Library (ASN.1) buffer overflow
    • MS04-011: LSASS buffer overflow

  4. InDirect (phishing style) exploits used were as follows:

    • MS07-?: Browser LoadAniIcon() in User32.dll
    • MS07/08-?: Browser generic activex overflow
    • MS06-001: GDI Library WMF SetAbortProc()

  5. Payloads used were either the VNC DLL injection, Shellcode, or Meterpreter

  6. Finally, both laptops were at the front of the room with two projectors showing each screen. Sort of a "bad guy" and "innocent victim" approach.
Starting with the unpatched WinXP machine, I did the most simple RPC DCOM buffer overflow, and pushed the reverse VNC DLL payload onto the target. On the MacBook, I then simply connected to the VNC server localhost addressed and displayed a mirror image of the screen.

I had a fake looking file called "WIDGET-SALES.TXT" on the desktop which I displayed on the screen to show that the goal was all about gaining access to data (not necessarily about gaining root/system).

I then moved onto the second virtual machine to show a typical phishing attempt. Between my colleague and I, we faked up a google mail page with a URL link in it as the browser home page. On the MacBook, I launched my MetaSploit web listener with the LoadAniIcon() sploit as the payload, and MeterPreter as the payload.

On the WinXP-SP2 virtual, I showed the user clicking on the "phishing URL" within the google email page (from IE). The buffer overflow transpired, and we launched Meterpreter.

Using a meterpreter script, I did the following:
  • created a hidden directory
  • uploaded netcat.exe
  • poked a hole in the Windows firewall on port 8888 with a service name of "msc".
  • tweaked the "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" registry key to start my backdoor netcat listener on port 8888.
While still using Meterpreter, I killed a few processes (like Symantec AV), executed notepad, calculator, solitaire to truly show the level of control I had over the victim.

I then simply booted the machine from Meterpreter. After the reboot, I showed how I could use netcat from the MacBook to reconnect to the target multiple times, gaining Windows shell access each time.

All of this was accomplished in 45 minutes and let me tell you, I scared the wits out of everyone in the room. The weirdest part for me was that remotely rebooting the victim machine from Meterpreter seemed to have the highest impact. (*sigh* - sometimes you just have to take what you can get....)

However, the bottom line was outrageous success. In one short session, we built demand for more institutional network security implementation than we ever had experienced before. It actually turned into a case of "be careful what you wish for".

Multicast as a recon. or attack vector?

Having been in the network architecture and security business for some time, I am quite surprised that more network recon. and attack tools have not given consideration to Multicast destinations. The backdrop is that more and more internal networks are video [multicast] enabled, academic Internet2 participants are often Multicast enabled in a Wide Area (WAN) sense.

Assuming minimally some internal network access, it would seem that a quick method of recon. would be to send traffic to a well known multicast app. address / port, and see what yields. At worst, you find a network that is not Multicast enabled and responses at layer 2 only.

More insideous would be the existance of backdoor command and control of botnets listening on Multicast addresses. One would only need access to a single internal network node in a large enterprise to send command and control to the remainder of the herd. Or worse still, if that botnet lived within the Internet2 wide area Multicast space, the command and control aspect could easily be just a trickle of Multicast and not noticed.