Extracting Metadata from PcapNG files
In our blog post about the Chinese MITM of GitHub we revealed the identity of the anonymous capture file uploader by analyzing metadata available in the PCAP-NG file format. In this blog post we explain what type of meta-data that can be found in PcapNG files, and how to extract it.
The old libpcap format (a.k.a. PCAP) is designed to only store captured network frames. The new PCAP-NG format, however, additionally includes the ability to store meta-data in the capture files. In fact only about 20% of the PcapNG file specification concerns storage of captured frames, the remaining 80% is focused on various types of metadata.
So what types of metadata can a PcapNG file contain? Well, the spec allows features such as MAC address of capturing interface as well as interface speed (in bps) to be stored. But the most commonly used metadata types are:
- Operating system of the sniffer machine
- Software used to create the capture file (application name and version)
- Name of interface from where packets are captured
- Description of interface from where packets are captured
- Capture filter used when sniffing packets
- Cached name resolution entries (mappings from IPv4 or IPv6 addresses to host names)
- User comments on individual frames (a.k.a. “annotations”),
Extracting Metadata
Some of these metadata types can be displayed in Wireshark by clicking “Statistics > Summary”. Here's the information provided when displaying a Summary in Wireshark on MachineB.pcapng from CloudShark:
However, what is not shown in this summary view is that MachineB.pcapng additionally contains cached name resolution information for two machines.
Here's the list of metadata information extracted from MachineB.pcapng:
| Type | Value |
|---|---|
| shb_os | Windows Server 2003 Service Pack 2, build 3790 |
| shb_userappl | Dumpcap 1.8.4 (SVN Rev 46250 from /trunk-1.8) |
| if_name | \Device\NPF_{D007FF28-3F24-4C1B-8EF5-069A6FB811ED} |
| if_tresol | 0x06 |
| if_os | Windows Server 2003 Service Pack 2, build 3790 |
| nres_ip6record | fe80::9a03:d8ff:fedb:904b = iPhone-von-b1.local |
| nres_ip4record | 192.168.13.124 = iPhone-von-b1.local |
| nres_ip6record | fe80::8685:6ff:fe23:c95d = iPhone-von-Gurkan.local |
| nres_ip4record | 192.168.13.188 = iPhone-von-Gurkan.local |
The metadata apparently contains name resolution info for two iPhones, and we've got their internal IPv4 as well as IPv6 addresses. This would normally imply that the capture file contains frames to or from these IP addresses. However, as shown in the following screenshot from CloudShark, the capture file contains 21 frames but not a single one of them is from or to “iPhone-von-Gurkan” or “iPhone-von-b1”:
Thus, it seems as if the Wireshark pcap-ng host name disclosure bug wasn't fixed in Wireshark 1.8.4 after all.
Megecap Leaks File Paths
It is, however, not only Wireshark that might leak private information in PcapNG metadata. The command line tool Mergecap additionally stores the complete path and filename of the individual capture files that have been combined with the tool.
| Type | Value |
|---|---|
| opt_comment | File created by merging: File1: /home/erik/captures/customer_X/capture_tap0_p5p1.cap File2: /home/erik/captures/customer_X/capture_tap1_p1p1.cap |
| shb_userappl | mergecap |
| if_tresol | 0x06 |
Metadata available in PcapNG file created with mergecap
This is most likely not a bug, but rather information leakage by design, so don't expect this to be mitigated in a future Mergecap release.
Conclusions
As we pointed out in our blog post “HowTo handle PcapNG files”,
the best way to avoid information leakage via PcapNG files is to stay with the good ol' PCAP format
by using the “-P” switch like this:
dumpcap -P -i eth0 -w dump.pcap
Posted by Erik Hjelmvik on Thursday, 14 February 2013 19:25:00 (UTC/GMT)
