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 1.2.3.4 and dst host 5.4.3.2"
-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!

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: http://www.counterhack.net/permission_memo.html)

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.