Decrypt IPSEC traffic with wireshark
I’ve setup a VPN IPSEC link between a Cisco and a Linux to demo the ESP decrypting feature of wireshark.
After having configured both sides of the IPSEC link, it’s time to test from the Cisco router:
ping 192.168.3.1 source 192.168.2.1 size 123 data CAFE
Type escape sequence to abort.
Sending 5, 123-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
Packet has data pattern 0xCAFE
..!!!
Success rate is 80 percent (3/5), round-trip min/avg/max = 1/3/4 ms
Sucess! The 2 first dot are because it took seconds to bring up the tunnel.
As you can see in the following trace, the icmp-request is unencrypted. Righ after we see some ESP traffic. Could it be the icmp-replies?
No. Time Source Destination Protocol Info heure
fw-1 chain
12 6.376835 10.100.100.200 10.100.100.100 ESP ESP (SPI=0x09bfd93b) 2011-07-17 20:36:08
.629993
13 6.376835 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=1/256, ttl=255) 2011-07-17 20:36:08
.629993
14 6.376933 10.100.100.100 10.100.100.200 ESP ESP (SPI=0x8134dedc) 2011-07-17 20:36:08
.630091
15 6.383264 10.100.100.200 10.100.100.100 ESP ESP (SPI=0x09bfd93b) 2011-07-17 20:36:08
.636422
16 6.383264 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=2/512, ttl=255) 2011-07-17 20:36:08
.636422
17 6.383348 10.100.100.100 10.100.100.200 ESP ESP (SPI=0x8134dedc) 2011-07-17 20:36:08
.636506
18 6.385546 10.100.100.200 10.100.100.100 ESP ESP (SPI=0x09bfd93b) 2011-07-17 20:36:08
.638704
19 6.385546 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=3/768, ttl=255) 2011-07-17 20:36:08
.638704
20 6.385614 10.100.100.100 10.100.100.200 ESP ESP (SPI=0x8134dedc) 2011-07-17 20:36:08
.638772
21 6.387761 10.100.100.200 10.100.100.100 ESP ESP (SPI=0x09bfd93b) 2011-07-17 20:36:08
.640919
22 6.387761 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=4/1024, ttl=255) 2011-07-17 20:36:08
.640919
23 6.387827 10.100.100.100 10.100.100.200 ESP ESP (SPI=0x8134dedc) 2011-07-17 20:36:08
.640985
Now, go find information that wireshark requires to decode the ESP traffic. Note that some implementation like the Cisco’s one doesn’t disclose the keys with a command. However it’s possible to find it within the Cisco IOS arcanes by drilling into a core dump and look for the good hex string. On Linux, you could use the ip xfrm state command to display the automatically generated session specific encryption and authentication keys:
$ sudo ip xfrm state
src 10.100.100.100 dst 10.100.100.200
proto esp spi 0x8134dedc reqid 0 mode tunnel
replay-window 4
auth hmac(md5) 0xa45c1bde51d20a61381025a1d55b675f
enc cbc(des3_ede) 0x7926ddbf7170fe9ece55bffede0e74e5a0b532958bcd0bc2
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 10.100.100.200 dst 10.100.100.100
proto esp spi 0x09bfd93b reqid 0 mode tunnel
replay-window 4
auth hmac(md5) 0x09be7b297316b0085a5c99fd59745b54
enc cbc(des3_ede) 0xe4f6a1c56f8c31ff6c76a3ac24f284aaeb3a653cde839dcd
sel src 0.0.0.0/0 dst 0.0.0.0/0
Now, go to the wireshark preferences and fill the ESP protocol by the gathered information.
- Tick the ‘Attempt to detect/decode encrypted ESP payloads’ box
- SA #1 : IPv4|10.100.100.100|10.100.100.200|0x8134dedc
- Encryption algorithm #1: TripleDES-CBC [RFC2451]
- Authentication algorithm #1: HMAC-MD5-96 [RFC2403]
- Encryption Key #1: 0x7926ddbf7170fe9ece55bffede0e74e5a0b532958bcd0bc2
- Authentication Key #1: 0xa45c1bde51d20a61381025a1d55b675f
- SA #2 : IPv4|10.100.100.200|10.100.100.100|0x09bfd93b
- Encryption algorithm #2: TripleDES-CBC [RFC2451]
- Authentication algorithm #2: HMAC-MD5-96 [RFC2403]
- Encryption Key #2 : 0xe4f6a1c56f8c31ff6c76a3ac24f284aaeb3a653cde839dcd
- Authentication Key #2 : 0x09be7b297316b0085a5c99fd59745b54
After clicking the Apply button, the white magic occurs and a new tab called “Decrypted Tab” appears at the right of the frame’s one:
No. Time Source Destination Protocol Info heure
fw-1 chain
1 0.000000 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=1/256, ttl=255) 2011-07-17 20:36:08
.629993
2 0.000000 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=1/256, ttl=255) 2011-07-17 20:36:08
.629993
3 0.000098 192.168.3.1 192.168.2.1 ICMP Echo (ping) reply (id=0x0008, seq(be/le)=1/256, ttl=64) 2011-07-17 20:36:08
.630091
4 0.006429 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=2/512, ttl=255) 2011-07-17 20:36:08
.636422
5 0.006429 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=2/512, ttl=255) 2011-07-17 20:36:08
.636422
6 0.006513 192.168.3.1 192.168.2.1 ICMP Echo (ping) reply (id=0x0008, seq(be/le)=2/512, ttl=64) 2011-07-17 20:36:08
.636506
7 0.008711 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=3/768, ttl=255) 2011-07-17 20:36:08
.638704
8 0.008711 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=3/768, ttl=255) 2011-07-17 20:36:08
.638704
9 0.008779 192.168.3.1 192.168.2.1 ICMP Echo (ping) reply (id=0x0008, seq(be/le)=3/768, ttl=64) 2011-07-17 20:36:08
.638772
10 0.010926 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=4/1024, ttl=255) 2011-07-17 20:36:08
.640919
11 0.010926 192.168.2.1 192.168.3.1 ICMP Echo (ping) request (id=0x0008, seq(be/le)=4/1024, ttl=255) 2011-07-17 20:36:08
.640919
12 0.010992 192.168.3.1 192.168.2.1 ICMP Echo (ping) reply (id=0x0008, seq(be/le)=4/1024, ttl=64) 2011-07-17 20:36:08
.640985
Congrats! You are now able to read through IPSEC!
BPF aka Boolean Packet Filter language
Yes. BPF is Berkeley Packet Filter but could be renamed Boolean Packet Filter as the filter function output a true or false regarding a packet traveling from the kernel to the application.
This result can be obtained glad to a directed acyclic control flow graph composed of comparison predicates and boolean operations.
Here is how to decrypt the language helped by the next two examples. The people accustomed with the randomly chosen assembly languages should enjoy the syntax :-)
On a side snote, wireshark 1.6.0 feature a BPF compiler in the capture wizard to impress your girlfriend.
pello@Networker:~$ sudo tcpdump -i eth0 -d “ip”
(000) ldh [12] (Load a half-word (16 bits) at the position 12 in decimal)
(001) jeq #0x800 jt 2 jf 3 (jt = jump to (002) if true / jf = jump to (003) if false)
(002) ret #65535 (65535 = TRUE) <= DELIVERED TO THE APP (WIRESHARK by example)
(003) ret #0 (0 = FALSE) <= DELIVERED TO IGNORE LAND
Another example .. a little bit more complicated:
pello@Networker:~$ sudo tcpdump -i eth0 -d “tcp port 22”
(000) ldh [12]
(001) jeq #0x86dd jt 2 jf 8 (Check if IPv6)
(002) ldb [20] (Move to position 20 - Next header field - IPv6 branch)
(003) jeq #0x6 jt 4 jf 19 (Check if IPv6 next header is TCP)
(004) ldh [54]
(005) jeq #0x16 jt 18 jf 6 (Check if TCP source port equals 22 - IPv6 Branch)
(006) ldh [56]
(007) jeq #0x16 jt 18 jf 19 (Check if TCP destination port equals 22 - IPv6 Branch)
(008) jeq #0x800 jt 9 jf 19 (Check if IPv4 from instruction 000)
(009) ldb [23] (Move to the 23th byte position of the packet starting from the link layer header (Ethernet in this case) and read 1 byte considering 1 byte equals to 8 bits)
(010) jeq #0x6 jt 11 jf 19 (Check if TCP - Ipv4 branch)
(011) ldh [20]
(012) jset #0x1fff jt 19 jf 13 (Bitwise and with the IP fragmentation bit mask check. If non-zero then this is a fragmented packet so we cannot find the TCP header in this packet |=> ignored)
(013) ldxb 4*([14]&0xf) (Seek the IP header length bitwise and with 0xf then multiplicate it by 4. The result is stored as a Byte in the index register: x)
(014) ldh [x + 14] (TCP source port position derived from x - IPv4 branch - 16 bits)
(015) jeq #0x16 jt 18 jf 16 (True if 22)
(016) ldh [x + 16] (TCP destination port position derived from x - IPv4 branch - 16 bits)
(017) jeq #0x16 jt 18 jf 19 (True if 22)
(018) ret #65535
(019) ret #0
As a next step of playing with BPF filters the reader could reverse the order of the ‘and’ filters and observe the difference. As an example: “tcp port 22 and host 127.0.0.1” versus “host 127.0.0.1 and tcp port 22”
Happy BPF! :>
networkvulns twitter account
3 hours later… the networkvulns proof of concept is born.
The tool is a mix of python modules: pyparsing, sqlite3, oauth, python-twitter.
His goal is to tell you if the software your network device runs is safe or not:

You must follow @networkvulns in order to get the reply via a direct message.
Example of valid request: fortinet,fortigate,4.0MR2
As you understand it follows the precept of: vendor, product, version.
The database contains infoblox and fortinet products at the moment:
sqlite> select distinct product from vulns;
fortianalyzer
fortiap
fortibridge
forticarrier
forticlient
fortidb
fortiexplorer
fortigate
fortigate-one
fortilog
fortimail
fortimanager
fortiscan
fortiswitch
fortiweb
netmri
nios
portiq
vnios
2011-02-27 update:
- whitelist database instead of a blacklist’s one
- fortinet and infoblox products now supported
Routerdefense 0.5.1 BGP quick update
Minor add to Routerdefense:
- BGP maximum as-path limit support. Did you know the average AS-PATH is 4.64?
- eBGP infrastructure ACL support
revision 17: http://code.google.com/p/routerdefense/source/detail?r=17
Cheers
Cisco bar magic potion
Hi,
Ingredients:
- Google Chrome (my main browser)
- TamperMonkey
- ciscobar.user.js
Result: the annoying blue Cisco bar is automagically removed from cisco.com pages.
Cheers
dorkmaster 0.1
Hi Hackers,
dorkmaster 0.1 is out.
It check your company’s data leak prevention policy against the google and bing search engines.
Testing against the google hacking and bing hacking database from the diggity project.
http://code.google.com/p/dorkmaster
Keep in mind that search engines are more evil than the interns.
Please generate your Bing App ID here to enable the bing feature.
Cheers :~
BruCON 2010 security conference
Hi Hackers,
I’ll be there from 23th of september until 26th for attending and giving a lightning talk about routerdefense.
Schedule:
First day
- KEYNOTE: Memoirs of a Data Security Street Fighter
- You Spent All That Money And You Still Got Owned…
- GSM security: fact and fiction
- The Monkey Steals the Berries
- Cyber [Crime|War] - connecting the dots
- Embedded System Hacking and My Plot To Take Over The World
- The WOMBAT Project: Recent Developments in Internet Threats Analysis
- Project Skylab 1.0: Helping You Get Your Cloud On
- Lightning talks day 1
- Podcasters Meetup
- Powerpoint Karaoke
Second day
- Your Project: From Idea To Reality
- Nokia NFC Malicious Content Sharing
- Finding Backdoors in Code
- Fireshark - A tool to Link the Malicious Web
- Head Hacking – The Magic of Suggestion and Perception
- Top 5 ways to steal a company
- CsFire: browser-enforced mitigation against CSRF
- Lightning talks day 2
See you!
SPF DNS top domains report
As of 24th july: dig +short TXT -f top10 | grep spf | wc -l => 7 dig +short TXT -f top100 | grep spf | wc -l => 67 No ip6 filtering within the top100
IEEE member card.
1 year later update: Feel like to be a spam victim of IEEE during 1 year.
I haven’t renew the memberhsip as I don’t outlined any personal benefits.