[PEN-TEST] VPN security evaluation (fwd)

[Ryan Russell]

Thought this might be of interest to the VPN list.

				Ryan

---------- Forwarded message ----------
Date: Thu, 21 Dec 2000 14:00:31 +0100
From: ingeborn at IXSECURITY.COM
Reply-To: Penetration Testers <PEN-TEST at SECURITYFOCUS.COM>
To: PEN-TEST at SECURITYFOCUS.COM
Subject: Re: [PEN-TEST] VPN security evaluation

We did an initial evaluation of the Contivity some months ago. Here are some
things worth discussing:

The Client

If the users are allowed to use the 'Save password' option, the password is
encrypted and hidden in a windows registry key named 'Errors' ;-) The user name
is encrypted and stored in a key named 'UserErrors'. The user name is also
stored in plaintext in a text file. The user name and password are encrypted in
the same way with the same key. So you will at least have a known plain text
situation. If you have a client to play with you will of course have a chosen
plain text situation which is 'better'. The encryption is done in 64 bit blocks
and the blocks are not chained. This means that no password will ever be
stronger than 8 characters in terms of brute force guessing(!) The marketing
talks about RC4, DES and 3-DES. I would guess DES or 3-DES because of the 64 bit
block scheme, but I don't know for sure, yet. The same password is encrypted
into different cipher texts on different hosts. But the same password is
encrypted to the same cipher text after a re-install. This either means that the
encryption key (or some salt value) is saved on the client host after the
un-install (doesn't look like that) or that the key (or salt) is generated from
something unique on the client host (maybe some serial no etc). If it is the
latter, it is probably the same 'thing' on all hosts and it would be interesting
to know. We didn't find it, but if you do, please let us know. Luckily there is
an option in the server that disallows the user to store the password. I suggest
to use that option.

When a client connects to the VPN server it uses port 50/udp. The authentication
consists of a number of steps (12 if I'm not wrong now). In order to do buffer
overflow checks etc. on each of those steps, we wrote a combined server/client
that acted as a man-in-the-middle at the network/transport layer level. With the
time given we couldn't break any of the application layer level encryption, so
maybe this should be called something like 'bi-directional IP-spoofing' instead.
Anyway, the interesting thing is that when we just forwarded the datasegments of
all packets in both directions (i.e. just changing the IP-address) we ended up
with a situation where the client popped up a dialog stating it was
authenticated and successfully connected to us :-) This may be used to collect
cipher text sessions for further cryptanalysis without the need to be (or break
in to) the ISP etc. This may also be used to trick users into allowing certain
IP-addresses in their personal firewall rule sets etc.

When the client connects to the server (the real one now) and the authentication
is successfully performed the client adds a new default gateway to the local
routing table. This is fine because he should use the VPN-tunnel from now on.
However, with the version we used (2.62) the VPN-session was not disconnected if
the user manually changed the routing table back. This means that a user
infected with your favorite trojan could be set up to act as a gateway into the
internal network. There is a patch for this, I suggest to get it.

The server

The VPN server includes a FW-1 filter module. However Checkpoint's service packs
cannot be applied directly and Nortel does not provide service packs equivalent
to more than FW-1 4.1 SP5. This means that e.g. the authentication weaknesses
presented at Black Hats 2000 are present and 'cannot' be patched. Nortel says
they are going to replace the FW-1 module with something else, but as far as I
know, they havn't done that yet.

There are also a number of older issues with the management interface that you
can find on SecurityFocus. Those are fixed in the latest versions.


Good luck with you evaluation, please get back to tell us about any progress you
make!

Regards,
Anders Ingeborn
iXsecurity, Sweden


PS.  Compaq servers are shipped with a program that includes a remotely
exploitable buffer overflow. We're posting it to Bugtraq along with
proof-of-concept code soon. Don't miss it. There's a lot of Compaq servers out
there...



Can anyone direct me to documents pertaining to the evaluation of VPN
security using
IPSec and the Nortel Network Contivity 1500 Extranet switch.

Thanks

VPN is sponsored by SecurityFocus.COM