bugtraq - In response to ISAKMP 'vulnerabilities'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 15 Nov 2005 18:45:48 -0800
From: <sigint@...h.com>
To: <bugtraq@...urityfocus.com>
Subject: In response to ISAKMP 'vulnerabilities'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some thoughts on the ISAKMP advisory.
http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en

While reading over this my first thoughts are 'they wrote a fuzzer,
it exposed some vulnerabilities, interesting but not too
interesting'. I think this advisory is a tad overblown (headlined
on slashdot as 'VPN flaw allows denial of service', yes I know its
only slashdot!). There is no design flaw in ISAKMP that is being
exposed here, merely an ISAKMP fault injection suite that exposed
some implementation bugs (some of which may be exploitable, I have
no idea).

Some quotes from this advisory:

<quote>

The scope was further narrowed to IKE phase 1 with pre-shared
secret authentication. Rationale behind this selection was:
 IKE phase 1 does not require any special preconditions as phase 2
does. Additionally, phase 1 aggressive mode allows sending several
payloads in the first packet.
 IKE phase 1 authentication with pre-shared secret is required from
all ISAKMP/IKE implementations.
 Potential IKE vulnerabilites in above scope can be roughly
categorised based on the on the IKE identity and shared secret:
 A. Vulnerability does not require a valid identity nor a shared
secret (greatest impact).
 B. Vulnerability requires a valid identity but not the shared
secret.
 C. Vulnerability requires both a valid identity and the
corresponding shared secret (smallest impact).

</end quote>

Test cases shown here:
http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp/
indicate some vulnerabilities did not require a valid identity or
shared secret, therefore mitigation mentioned in the advisory:
"If possible, use packet filters and accept ISAKMP negotiations
only from trusted IP-addresses" is irrelevant considering ISAKMP
runs on top of UDP and spoofing an IP address is trivial. All in
all i commend this team for writing this fuzzer and exposing some
flaws in many ISAKMP implementations. Thanks for reading.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkN6resACgkQ8+KJMsQVzCGQCwCgsdiojVpAC3Ja9FHJ92DdbjRYwSYA
oKUGIfaVaCgs2mVHBizhukFPGtLa
=xB6U
-----END PGP SIGNATURE-----

Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485