Slashdot Mirror
VPN Flaw Allows Denial of Service
An anonymous reader writes "Finnish researchers at the University of Oulu have found a vulnerability in ISAKMP (Internet Security Association and Key Management Protocol) -- the technology used in IPsec virtual private network and firewall products from a range of networking companies, including Cisco and Juniper Networks. Cisco said the security flaw could cause devices to reset over and over, which could cause a temporary denial-of-service attack. It did not mention the possibility of the device being taken over by an intruder, while Juniper said it has been aware of the problem since June, so software issued on or after July 28 provide fixes for the flaw."
and not an implementation failure. So how exactly are individual vendors patching it without changing the protocol? Or are they making changes in the protocol that would be "invisible" to the outside world?
http://www.ee.oulu.fi/research/ouspg/protos/testin g/c09/isakmp/index.html
"ABSTRACT
The Internet Security Association and Key Management Protocol (ISAKMP), is designed to establish, negotiate, modify and delete Security Associations. ISAKMP provides a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism. Internet Key Exchange (IKE), a derivate of ISAKMP, is a key protocol in the Internet Security Architecture (IPsec). A subset of IKE Phase 1 negotiation was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Results were gathered and reported. Some of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for evaluation and development of ISAKMP/IKE products."
The blurb has nearly no meaningfull information whatsoever. The only meaningfull bit is the recommendation not to use aggressive mode.
Well... We kind'a all know this already. The weaknesses of agressive mode were all over BUGTRAQ more then 2 years ago and if you are still using it you "Get whatever Christmas you deserve".
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Gotta love a company that keeps administrators like me with job security :)
FTFA:
That doesn't strike me as a protocol problem.
We have been running IPsec on Cisco routers for quite some time.
We have always had an explicit allow list for isakmp packets only for the known peers, and a deny with logging for all other sources.
Over the years, there have been only very few logged packets. No need to tell you how many NETBIOS and other wellknown exploitable service packets have been counted (we don't even log these).
It does not look like IPsec is a popular attack vector. Same for PPTP, by the way.
"Juniper said it has been aware of the problem since June, so software issued on or after July 28 provide fixes for the flaw."
Gee, thanks for letting the rest of the world know too!
It's good that they found it now, as the new copyright law will make such research illegal in finland starting next year..
Feed a server carefully crafted, malformed packets and it may behave in unpredictable ways. We show that several IPSec implementations of IKE V1 don't behave properly.
Not news kids, just development as usual.
Oh, and I like the bit about "possibly executing code." That, I believe, is FUD. Prove that you can execute code.
Some lab ran a protocol tester against some ISAKMP implementations and found a few issues. No reason to panic as long as the vendors fix it. It is pretty common to fix these sorts of bugs it complicated protocols like ISAKMP.
Mike Borella http://www.borella.net/mike
Your TLAs are broken.
Gah, I like to think that I'm technically savy, but when there are 2 FLAs and a SLA in a row, and I don't know what any of them mean, I feel a little sad.
Just when we thought we where all going to be saved by a saint we all find out we are doomed!
If you happen to see this post even partly you can say the internet is still party working.
... since my router started randomly reloading a few days ago. I wonder if Cisco will release a patched version of the IOS that's free, cause I cannot afford the "cisco tax". I bought that router while I was a student ( and in the cisco academy program ) to practice with the IOS. I had been using the router for my cable connection since then. But, if I cannot get a free update I'll be going to get one of those inexpensive linksys or netgear routers for my home connection now.
Yay, I now have a $500 cisco paper weight.
Does anyone out there know if OpenBSD is affected or not?
TIA.
It's funny, the instant I saw this headline, I got booted from my wireless network. It uses, you guessed it, the Cisco VPN Client!
And then, not two minutes later, I got booted again while trying to preview the first half of this message.
This sig is false.
I'm just going to link something: http://openvpn.net/
Mod me down with all of your hatred and your journey towards the dark side will be complete!
OpenVPN has had several VERY STUPID security problems discovered recently. Why not just keep using ipsec, but don't buy a shitty broken implimentation from cisco? http://www.openbsd.org/
From CheckPoint Solutions:
Solution ID: #sk31316
Product: VPN-1/FireWall-1
Version: NG AI, NGX
Last Modified: 14-Nov-2005
Symptoms
On Monday, November 14th, NISCC has issued a warning about a possible denial of service condition for IKEv1. No known exploit exists.
(NISCC Vulnerability Advisory 273756)
Cause
This issue was identified using the PROTOS ISAKMP Test Suite for IKEv1 which was published through NISCC.
The issue is due to a problem with the implementation of the IKE protocol.
The issue might cause a crash of the IKE daemon (vpnd) during the processing of IKE packet 5.
An attacker needs to perform a full IKE negotiation with the attacked VPN gateway in order to cause the denial of service condition; no single packet attack is possible.
No further exploit is possible.
There is no possibility of code execution relating to this issue.
Given the nature of the issue, crafting an exploit is extremely difficult.
Solution
Install the latest HFA (HotFix Accumulator)
Juniper does not issue patches to JunOS, including ex-Netscreen ScreenOS. In order to get the latest firmware, you must have a support contract with Juniper at a cost of hundreds to thousands per year per device. If you have let your contract lapse, you need to pay the fee for every year since your last subscription up to the present year. They will not simply sell you the firmware, even if you have a legitimate licencse and registered device. If you use an EOL device, such as the common Netscreen 5XP, you are SOL.
This is ridiculous!
We've been using this unpatched VPN to communicate to the outside world for months and we've never had any prob...[NO CARRIER]
- Michael T. Babcock (Yes, I blog)
They tested a bunch of implementations and a bunch of them failed out over 5000 different tests. How is this a problem with the protocol itself as opposed to how a bunch of vendors decided to implement it?
Might've been better phrased if it read as a vulnerability with "a number of popular implementations of IKEv1" as opposed to a vulnerability with the protocol.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
If you're not using the VPN features, then you can just block packets on Port 500 and you won't have to worry about it.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks