I think most people looked at it and went "huh?".
The short answer is you SHOULDN'T be able to. That's kinda the whole concept of a seed key and rotating keys/session keys after that.
If someone can easily get the keys then things aren't very secure, now are they?
Depending on what ESP transform set you are using, and whether you know the pre-shared key or not, you can guess other values and predict the next key perhaps. But at that point I would recommend you upgrade your security!
So the answer is supposed to be "no".
I think you misunderstood. I am not trying to intercept or predict encryption keys for an IPSec connection from somewhere in the middle. I am trying to literally login to my device and see what encryption key is being used for a particular IPSec tunnel that is originating on my device.
On some linux servers there is a command to do this, but I haven't found such a command in Cisco IOS. Effectively, I would like to be able to get the encryption keys for an IPSec session from one of my routers so that I can decrypt packet captures that are taken just as the traffic leaves my network, and thus verify the contents at the perimeter of the network. Does that make more sense?
It's not a gap in security to see dynamic encryption keys on an IPSec session that I control...
Just a challenge I guess. I had some success today, but just didnt find much time to work on this. The biggest challenge was finding a program to read the core dump (which is a binary file). What I did was a core dump with known IPSec Keys (manual). I was able to find them in the dump and found that they were always prepended with the following hex "00 00 00 00 0D 0D 0D 0D". They were also followed by a very specific string.
I then performed a core dump with ISAKMP enabled. I haven't had a chance to examine that core dump. Fortunately, its my weekend so perhaps tomorrow I will get a chance.
Also, if a challenge isnt a good enough reason, there is a practical application in the event you only have a sniffer available in such a location that the traffic has already been encrypted.
I think Scott's comment hit the nail on the head - at which point you can decrypt via man-in-the-middle, your security is no longer secure. While this could be viable from a pen-test or security assessment skill, I hope it is never a viable troubleshooting tool. When it is, you have larger issues at play.
Well, as I stated above, I am not attempting any kind of man in the middle attack. I am retrieving an encryption key on a router for an IPSec session that originated from that router.
All that said, today I had success. As it turns out, Cisco stores the encryption key in DRAM as expected. What I then did is setup and IPSec tunnel with manual encryption and authentication keys (disabled isakmp). I used 3DES and MD5. I then captured encrypted traffic using wireshark. Then, I performed a core dump of one endpoint router. I searched that core dump to find my static encryption and authentication keys. Then, I looked for what was in memory directly before the keys. What I found is that directly before the inbound encryption key is a very specific hex string...
03c06030h: 00 00 00 00 63 C0 60 0C 63 C0 60 1C 07 D0 00 19 ; ....cÀ`.cÀ`..Ð..
03c06040h: 00 01 00 02 00 02 00 00 63 88 11 B8 ; ........cˆ.¸
The left side is address in memory in hex. Thus, the hex string is 00 00 00 00 63 ..... 11 B8. Exactly 16 bytes after B8 begins the inbound encryption key, which is 24 bytes long. Immediately after the encryption key is the 16 byte authentication key.
So, to test the theory, I then used ISAKMP to build an IPSec tunnel with the same transform set. I captured some traffic, wireshark shows this only as ESP. In reality it was telnet traffic traversing a GRE tunnel, which then was protected by the IPSec session. I then performed a core dump of the endpoint again (this takes a while, I am using GNS3 and dumping via FTP to my PC). I then searched the core dump for the precise hex string that had prepended my encryption key (the 00 00 00 63....11 B8 string). Then counted 16 bytes forward, then copied the next 24 bytes hoping it was my encryption key. I then copied the next 16 bytes hoping it was the authentication key. I then plugged these guys into wireshark (preferences->ESP) for the inbound SPI and successfully decrypted the IPSec tunnel. Now I can see the capture contains telnet inside GRE inside ESP. Freakin awesome...
I cannot stress enough that in no manner have I cracked the security of IPSec. I have simply found a way to access something that Cisco should have just written a command for. If someone is managing an IPSec tunnel and controls one end, then there is no reason that they shouldn't be able to get the keys for it.
I will attach a doco and captures shortly, just cleaning them up.
That is awesome. I love it when people think outside of the box. I agree this is in no way breaking the ISAKMP process. This would require a compromised tunnel endpoint, in which case anything is possible. This illustrates how we must be holistic in our thinking when it comes to security, including physical security of the security devices.
While an entertaining and educational experience, you've simply discovered WHERE in the packet that the keys are shown. Bear in mind that this can be figured out via the RFCs as well. If you have manual keys you aren't following the exact same processes that would be otherwise demonstrated.
I do agree with the idea that if someone has physical access, most of your security information is screwed anyway, but this just brings up a whole slew of things about stories where people spy on their employees or bosses, or any other variation of industrial espionage.
This is why god invented tasers.
So basically, you used a known manual key to help you figure out how to find the key location in a core dump. You found that it was preceeded by a certain hex pattern each time. Then you enabled isakmp to negotiate a key that was unknown to you, found the key in memory (via core dump) and decrypted the traffic with Wireshark. What did you use to look at the core dump, just a hex editor?
Message was edited by: Paul Stewart
Mr. Stewart has this exactly correct. I am not sure what Mr. Morris is talking about, I did not locate the encryption key in the packet (i wasn't trying to intercept a tunnel rekey, that would be very difficult because I would have to crack DH algorithm).
Mr. Stewart, I used UltraEdit-32 to view the core dumps. They have a free 30 day trial that I used. Good question
Okay, so if you're interested, I have attached a word document with sections of the core dump that contain the keys. It also has directions for using wireshark to decrypt the packets. I have also attached a capture of some traffic. Finally, I have attached a picture of the topology used and configs from both routers.
IPSec-ISAKMP.zip 31.2 K
I know this is over an year old. But this idea is really useful in some cases.
I have an IPSEC site-to-site tunnel with another firm. I am using a Cisco ASA and they are using a checkpoint firewall.
When interesting traffic hits the ASA, the tunnel comes up, Phase-1 and Phase-2 is successful. But the remote site keeps dropping the packets.
There are a lot of ways to go about troubleshooting this, but having ESP packet captures on either side and actually making sure that the data inside is what you expect it to be elimites any doubts you may have about the tunnel.
Again, we are NOT talking about MITM attack here. I know my pre-shared key. The case here is, I want to know the IPSEC key, to decrypt ESP traffic to look inside them and know for sure that the tunnel is indeed encryting the data as it should be.
Thank you for sharing your knowledge. I will definitely use this technique as the last straw.