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! :>

Racket vs Packetfu in Metasploit

Why the hell did I think I wrote this in packetfu? Looks like my hard disk contains a traffic hijacker glad to HSRP written with the racket lib. That was wrote a long time ago and I decided to push it before I forget it another time in the not-so-used inodes.

http://dev.metasploit.com/redmine/issues/4568

AFAIK, Tod is doing some nice work actually on the packetfu lib. Stay tuned for the next clash regarding networking lib in ruby. Racket or Packetfu? It seems the future will be a plentiful of Packetfu!

EAP-MD5 sucks *for real*

EAP-MD5 is deprecated since Windows Vista in the Microsoft world.

A KB exists to pinpoint the dictionary attack. That’s not the case for Cisco. EAP-MD5 is so great you can still use it on the Cisco’s IP phones. Also, I have found no documents referring to the EAP-MD5 security weakness but the deployment guides that helps the poor administrators to be powned in the future. Hopefully when Cisco stamps a customer network as safe glad to an audit (Probably running by a CISSP leet) then the customer feels indestructible until a real pentester (not the CISSP’s well-suited guy) manages to break-in on their invulnerable network in seconds.

Reality is bad. Help your customer to kill EAP-MD5 forever by using my metasploit module which worked succesfully on wired and wireless 802.1x environments.

You could also use the following script from LaNMaSteR53 if you are in love with python. Or the well-known xtest and eapmd5pass which is not needed to comment anymore.

Go for another scheme or… or…sorry definitely no EAP-MD5 even tunneled as it remove the dictionary attack but add the man in the middle scenario to the attacker.

Evangelism for the win.

XeroX and netsec-catalog

New Metasploit module developed: https://dev.metasploit.com/redmine/issues/4007 (XeroX workcentre users enumeration)

New repository containing network security documents and videos : http://code.google.com/p/netsec-catalog/

See you later.

Links of the day - malware oriented

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:

revision 17: http://code.google.com/p/routerdefense/source/detail?r=17

Cheers

packetfu now includes HSRP layer

Hi packets monkeyz and others,

Better late than never.. contribution to the packetfu project to add the HSRP layer.

The first application layer added to the project by the 24 of December 2010!

http://code.google.com/p/packetfu/source/detail?r=156

http://code.google.com/p/packetfu/source/detail?r=157

A Cisco HSRP traffic hijacker is already coded to be included into metasploit but waiting some rex and packetfu libs to be updated before going in the wild…

Just wish I will not forgot to update it …

Cheers :~

Metasploit updates

Cisco bar magic potion

Hi,

Ingredients:

  1. Google Chrome (my main browser)
  2. TamperMonkey
  3. 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.