[VPN] Application timeouts over VPN...HELP!

[safieradam]

Well said.  This is the primary concern.

In addition:

1) Complexity and Audit - A minor benefit is added complexity for decryption
attacks and an audit trail to pin-point attack times.  A decryption attack
needs some kind of identifiable data to know that it succeeded.

The session encryption is based on a symmetric key which is re-negotiated
per SA policy timers.  Often this is as long as 8-24 hrs but can be reset to
shorter periods for improved security (I like 15 minutes for connections
that are not very busy, longer if traffic volume is high and renegotiation
creates too much overhead).  The longer the session is open with a given
symmetric key the longer an attacker has to figure out the symmetric key,
break into the session and hijack the TCP connection.  While TCP connections
can usually span multiple sessions the attacker has a limited time to launch
an attack before the session key changes.

If there is no data flowing on an established connection the attacker can
probe the end systems with a single packet and verify s/he really broke the
code and is still in the same session.  Most systems don't monitor or log
existing open sessions for single packets.  But attackers must initiate a
new connection to test the key and session lifetime if the IP connection is
down.  Initiating a new connection sometimes leaves a mark in logs (what is
your logging and monitoring policy?) and can help alert IDS's or awake
operators that something is not Kosher (why is the 2AM dump happening at 12
and is so short?)

2) Application authentication - In a well written application the end points
_Should_ also re-authenticate with each TCP connection, preferably with
something more secure than a plain password ( I like digital signatures).
The attacker must now wait and monitor for a new session before launching an
attack or might set off alarms during failed login-on attempts. (You do have
a log in failure policy, right?)  Even with reusable passwords the attack
complexity increases - attackers have to have captured the initial log-in
within the session with the broken key.

3) Session tear down - Ideally VPN implementations tear down idle low-volume
sessions when the last IP connection is ended. The attacker now has to wait
for another session, break the keys and try to launch an attack.  Nobody
likes a deadline - the length of the IP session.  Sort of links to number 4
as well.

Memory fades and it's been a while since I dug into the detail but I think I
saw a least one vendor establish a new session for every IP connection, and
close the session with the ending of the IP connection.  Might have been a
side effect of the testing protocol.

4) Resources - Leaving a TCP session open takes up resources in the firewall
which must retain state information.  (Tell the project leader to pony up an
additional $100,000 for bigger firewall boxes if he must do this.  At least
it will improve your security budget if he falls for it.)

5) Dropped connections / QoS - Are quality of service, up time and disaster
recovery security group concerns?  A VPN Security Association (SA) has a
session lifetime.  My experience with inter-vendor VPN (as of testing 2+
years ago) is that most handle the session renegotiation OK but some drop
all connections when it's time to renegotiate the SA, especially with other
vendor's VPN boxes.  The IP state can be lost and the IP connection of a
brain dead application is henceforth blocked until a new IP session is
started (by restarting the application?  Ouch!).  I believe this has
improved with more recent releases and continued interop testing so brain
dead applications can do better now.  But since communication links are not
stable the application better handle it (what is your quality of service
agreement and will the developers pay for a 100% up time guarantee?  You
could have some fun with this but remember, when you apply a new firewall
policy/configuration you may be droping connections).

6) Legacy security staff paranoia - In the good old days, when firewalls
were just becoming available and VPN meant a multiplexed line, passwords
were a main defense strategy.  An open IP session was subject to hijacking
without the need for the password.  Security people learned to raise the
specter to justify our salary.  The fear persists in our psyche even with
VPN.

7) Bad programming - Lack of communication session robustness and disregard
for system resources makes me question the quality of the software and
security awareness of the programmers.  Being a former programmer, before
the days of OOP, I understand the desire to get the basic code written and
the avoidance of error trapping code that adds so much overhead and time to
a simple and otherwise short module.  But sloppy and rushed programming with
a "we'll fix that later" attitude is one reason why we have so many security
holes in application software.

8) I'm sure I missed something.  See 6.

Adam Safier



----- Original Message -----
From: "Ryan Malayter" <rmalayter at bai.org>
To: <vpn at lists.shmoo.com>
Sent: Wednesday, April 09, 2003 1:36 PM
Subject: RE: [VPN] Application timeouts over VPN...HELP!


From: Alex Pankratov [mailto:alex at cipherica.com]
>can you explain why *exactly* it's
>a "bad security" ? Especially given
>that the TCP connection in question
>is IPsec'ed in first place.

If the tunnel is left open, and the engineer's workstation is online and
idle, the workstation becomes a vector for compromising the security of
the encrypted traffic.

If the workstation is unmanned, and the screen is accidentally left
unlocked, someone could walk up and compromise the shared secret key by
looking at the Ipsec cleint settings. Or someone could walk up and hack
the OS (many prviliege-elevation hacks on Windows NT/2000/XP and other
OS require console access), or use a debugging tool to dump the memory
and find the shared secrets or session keys.

These attacks could be nearly as harmful as if the tunnel was down,
since a remote-control backdoor or whatever could be installed, which
could later be used compromise encrypted traffic. However, if these
attacks are made while the VPN is up, then devices on the other end of
the VPN connection become ready and easy targets of opportunity for the
attacker. (There are usually loose - if any - Firewall rules applied to
a VPN connection, so remote-compromise attacks would be much easier).

Now, if all devices at the endpoints of the VPN are physically secure,
and properly firewalled, then you don't have to worry too much about
idle tunnels being a security risk.

<flame_bait>
If fact, I'd go so far as to say strong encryption is basically
redundant on a VPN. Even on a VPN with lowly single-DES encryption,
hacking the endpoint workstations or servers (either remotely or
physically) is likely to be an easier attack than breaking the VPN
encryption.
</flame_bait>

Regards,
-ryan-
_______________________________________________
VPN mailing list
VPN at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn