Excerpt from Network Forensics Chapter
A crucial component of using trusted tools and techniques is ensuring that the network evidence collected by a sensor can be read and analyzed in another environment. This may seem like an obvious point, but consider my recent dismay when I tried to analyze the following trace supposedly captured in Libpcap format. I started by using the Capinfos command packaged with Ethereal. On a regular trace, Capinfos lists output like the following.
On the trace in question, Capinfos produced this odd output.
That’s disturbing. Something is wrong with this trace. Tcpdump can’t read anything beyond one packet.
Something is wrong with the bad2.tcpdump.052705 trace. Perhaps I could use the Editcap program, also bundled with Ethereal, to convert it from its present form to something recognizable by Tcpdump?
That looks promising. The bad2.tcpdump.052705 file may be a trace captured from a Nokia version of Libpcap. Editcap reports it understands the following five variations on the Libcap format:
The four options after the first represent various vendor tweaks to the Libpcap library. They are nothing but a source of headaches for network investigators and security vendors. However, perhaps we can use Editcap to convert from the reported Nokia variant to a standard Libpcap format.
Unfortunately, that process fails. For a last ditch try at reading this data, we move the trace to a Windows system equipped with Tethereal and the WinPcap library.
Again, we are unable to read this trace. This is an extreme example of collecting traffic on one system and not being able to read it elsewhere. All is not completely lost, however. The raw file itself is still available. Using a hex viewer like hd, we can see the raw file contents.
Although Tcpdump and related Libpcap tools cannot read the trace due to the presence of corruption or a non-standard format, the ASCII content can still be read.
It would have helped to have known more about the system and tools used to capture the bad2.tcpdump.052705 trace when trying to decode it. Therefore, I recommend saving data like the following and bundling it with traces when shared with investigators: On a Unix system, record Uname, Tcpdump, and Tethereal versions.
On Windows, use the Sysinternals program Psinfo to record system information, and then obtain version numbers from any installed packet capture programs like Tethereal.
Saving this information to a text file in the directory where network packets are recorded may save another investigator time and frustration when analyzing traces. This information also provides more solid footing when defending the nature of the collection process to a legal body or human resources panel.
bourque:/home/analyst$ capinfos goodtrace
File name: goodtrace
File type: libpcap (tcpdump, Ethereal, etc.)
Number of packets: 1194
File size: 93506 bytes
Data size: 213308 bytes
Capture duration: 342.141581 seconds
Start time: Thu Jun 23 14:55:18 2005
End time: Thu Jun 23 15:01:01 2005
Data rate: 623.45 bytes/s
Data rate: 4987.60 bits/s
Average packet size: 178.65 bytes
On the trace in question, Capinfos produced this odd output.
bourque:/home/analyst$ capinfos bad2.tcpdump.052705
capinfos: An error occurred after reading 1 packets from
"bad2.tcpdump.052705": File contains a record that's not valid.
(pcap: File has 1701147252-byte packet, bigger than
maximum of 65535)
That’s disturbing. Something is wrong with this trace. Tcpdump can’t read anything beyond one packet.
bourque:/home/analyst$ tcpdump -n -r bad2.tcpdump.052705
reading from file bad2.tcpdump.052705, link-type EN10MB
(Ethernet)
16:57:20.259256 IP 192.160.62.68.45626 > 5.9.153.222.25:
P 2134566659:2134567683(1024) ack 3376746668 win 24840
tcpdump: pcap_loop: bogus savefile header
Something is wrong with the bad2.tcpdump.052705 trace. Perhaps I could use the Editcap program, also bundled with Ethereal, to convert it from its present form to something recognizable by Tcpdump?
bourque:/home/analyst$ editcap -v bad2.tcpdump.052705
File bad2.tcpdump.052705 is a Nokia libpcap (tcpdump) capture file.
That looks promising. The bad2.tcpdump.052705 file may be a trace captured from a Nokia version of Libpcap. Editcap reports it understands the following five variations on the Libcap format:
- libpcap - libpcap (tcpdump, Ethereal, etc.)
- rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump)
- suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump)
- modlibpcap - modified libpcap (tcpdump)
- nokialibpcap - Nokia libpcap (tcpdump)
The four options after the first represent various vendor tweaks to the Libpcap library. They are nothing but a source of headaches for network investigators and security vendors. However, perhaps we can use Editcap to convert from the reported Nokia variant to a standard Libpcap format.
bourque:/home/analyst$ editcap bad2.tcpdump.052705
bad2.tcpdump.052705.lpc
editcap: An error occurred while reading "bad2.tcpdump.052705":
File contains a record that's not valid.
(pcap: File has 1701147252-byte packet, bigger than maximum
of 65535)
Unfortunately, that process fails. For a last ditch try at reading this data, we move the trace to a Windows system equipped with Tethereal and the WinPcap library.
D:\>Tethereal -n -r bad2.tcpdump.052705
1 0.000000 e0:a6:08:00:45:00 -> 50:c8:00:0d:65:18 LLC I,
N(R)=0, N(S)=32; DSAP b2 Group, SSAP SNA Command
tethereal: "bad2.tcpdump.052705" appears to be damaged or corrupt.
(pcap: File has 1701147252-byte packet, bigger than maximum
of 65535)
Again, we are unable to read this trace. This is an extreme example of collecting traffic on one system and not being able to read it elsewhere. All is not completely lost, however. The raw file itself is still available. Using a hex viewer like hd, we can see the raw file contents.
bourque:/home/analyst$ hd bad2.tcpdump.052705 > bad2.tcpdump.052705.hd
bourque:/home/analyst$ less bad2.tcpdump.052705.hd
...edited...
4d 49 4d 45 2d 76 65 72 73 69 6f 6e 3a 20 31 2e MIME-version: 1.
30 0d 0d 0a 58 2d 4d 49 4d 45 4f 4c 45 3a 20 50 0...X-MIMEOLE: P
72 6f 64 75 63 65 64 20 42 79 20 4d 69 63 72 6f roduced By Micro
73 6f 66 74 20 4d 69 6d 65 4f 4c 45 20 56 36 2e soft MimeOLE V6.
30 30 2e 32 39 30 30 2e 32 31 38 30 0d 0d 0a 58 00.2900.2180...X
2d 4d 61 69 6c 65 72 3a 20 4d 69 63 72 6f 73 6f -Mailer: Microso
66 74 20 4f 75 74 6c 6f 6f 6b 2c 20 42 75 69 6c ft Outlook, Buil
64 20 31 30 2e 30 2e 36 36 32 36 0d 0d 0a 43 6f d 10.0.6626...Co
6e 74 65 6e 74 2d 74 79 70 65 3a 20 6d 75 6c 74 ntent-type: mult
69 70 61 72 74 2f 72 65 70 6f 72 74 3b 0d 0d 0a ipart/report;...
20 62 6f 75 6e 64 61 72 79 3d 22 2d 2d 2d 2d 3d boundary="----=
5f 4e 65 78 74 50 61 72 74 5f 30 30 30 5f 30 30 _NextPart_000_00
...truncated...
Although Tcpdump and related Libpcap tools cannot read the trace due to the presence of corruption or a non-standard format, the ASCII content can still be read.
It would have helped to have known more about the system and tools used to capture the bad2.tcpdump.052705 trace when trying to decode it. Therefore, I recommend saving data like the following and bundling it with traces when shared with investigators: On a Unix system, record Uname, Tcpdump, and Tethereal versions.
bourque:/home/analyst$ uname -a
FreeBSD bourque.taosecurity.com 5.4-RELEASE FreeBSD
5.4-RELEASE #0: Thu Jun 23 14:29:51 EDT 2005
root@bourque.taosecurity.com:/usr/obj/usr/src/sys/BOURQUE i386
bourque:/home/analyst$ tcpdump -V
tcpdump version 3.8.3
libpcap version 0.8.3
bourque:/home/analyst$ tethereal -v
tethereal 0.10.11
Compiled with GLib 1.2.10, with libpcap 0.8.3, with libz 1.2.2,
without libpcre, without UCD-SNMP or Net-SNMP, without ADNS.
NOTE: this build doesn't support the "matches" operator for
Ethereal filter syntax.
Running with libpcap version 0.8.3 on FreeBSD 5.4-RELEASE.
On Windows, use the Sysinternals program Psinfo to record system information, and then obtain version numbers from any installed packet capture programs like Tethereal.
D:\>c:\progra~1\pstools\psinfo
PsInfo v1.63 - Local and remote system information viewer
Copyright (C) 2001-2004 Mark Russinovich
Sysinternals - www.sysinternals.com
System information for \\ORR:
Uptime: 0 days 0 hours 45 minutes 49 seconds
Kernel version: Microsoft Windows 2000, Uniprocessor
Product type: Professional
Product version: 5.0
Service pack: 4
Kernel build number: 2195
Registered organization: TaoSecurity
Registered owner: Richard Bejtlich
Install date: 5/15/2005, 3:08:21 PM
Activation status: Not applicable
IE version: 6.0000
System root: C:\WINNT
Processors: 1
Processor speed: 750 MHz
Processor type: Intel Pentium III
Physical memory: 384 MB
Video driver: ATI Mobility M3
D:\>"c:\Program Files\Ethereal\Tethereal" -v
tethereal 0.10.11
Compiled with GLib 2.4.7, with WinPcap (version unknown), with
libz 1.2.2,with libpcre 4.4, with Net-SNMP 5.1.2, with ADNS.
Running with WinPcap (3.0) on Windows 2000 Service Pack 4,
build 2195.
Saving this information to a text file in the directory where network packets are recorded may save another investigator time and frustration when analyzing traces. This information also provides more solid footing when defending the nature of the collection process to a legal body or human resources panel.
Comments
I had come across the same problem at one point when I used a Nokia box as a packet collector for a Shadow IDS. I agree that it is frustrating when a vendor puts their little "tweaks" on things and makes them incompatible with the rest of the world.
However, the solution I found was to use the following:
$ tethereal -r infile.log -F libpcap -w outfile.log
where infile.log is the Nokia libpcap format and outfile.log is the file you wish to read with tcpdump/Snort/ethereal/whatever. If I remember correctly, it doesn't work 100% of the time but its better than nothing.
I am doing this from memory so I'm curious to know if that works.
tyler at hudakville dot com
IE:
tcpdump -g -r bad.tcpdump -w good.tcpdump
BTW, the tethereal trick worked for me. And since I often find myself on Nokia boxes, I'll be sure to keep '-g' in mind for the future.
thanks guys.
Dave