Vulnerability

    Netgear ISDN RT34x router

Affected

    Netgear ISDN RT34x, RH348 router (and possibly the Zyxel P128imh (same firmware))

Description

    Swift Griggs found following.

    Door #1:
    ========
      SYN scan  the router  with nmap.  It'll deny  all connections to
      port 23 after that  for about 5 minutes  per packet.  DoSing  it
      in this  way is  trivial. Of  course spoofed  packets work  just
      great.

    Door #2:
    ========
      Telnet to it.  Sit there. No one else can manage it,  regardless
      of if you have authenticated or not.

    Door #3:
    ========
      Send it tons  of ICMP redirects,  it'll stop routing  packets at
      all  during  the  storm  (which  can  be fairly light) and it'll
      take about 30 seconds to recover. (try winfreeze.c)

    Door #4:
    ========
      Send it  some contrived  RIP packets  with host  routes for your
      favorite people in the office  set to loopback.  The  default is
      to allow RIP-2B in both directions.

    Mike   Wade   added   following.     He   owns   one   of    these
    gimpy-so-called-routers and has found  many bugs that are  similar
    to the  ones you've  mentioned.   Generally, he  found the  TCP/IP
    stack + NAT features to be  of very low quality.  Perhaps  this is
    to be expected  at a low  price point but  their firmware is  just
    plain broken.

    Bug #5:
    =======
      Send a  single UDP  packet between  63000 -  65000 bytes  to the
      router  from  local  or  remote.   This  will lock the router up
      between 15  - 30  seconds and  sometimes reboot.   Sending these
      packets once about every 10 seconds is enough to keep the router
      locked up forever.  Perhaps this is a memory issue?

    Bug #6:
    =======
      Broken  and  sometimes  legit  IRC  DCC  and  Real   Audio/Video
      (film.com's  trailers  usually  sends  my  router  into  endless
      reboots) requests often  cause the router  to reboot when  using
      NAT.  This is obviously just sad coding.

    Bug #7:
    =======
      Legit traffic is  often dropped in  NAT mode after  >12 hours of
      connection  time  (assumption  the   NAT  tables  leak).    Open
      connections are  not affected,  however no  new connections will
      be created.   The only solution  is to disconnect  or reboot the
      router.  This might be related to poor timing out of UDP packets
      such as DNS queries sitting stale in the NAT table.

Solution

    Use an ACL  in the router  to deny access  to everywhere but  your
    management station.  Turn RIP off  if you can, if not then  try to
    only broadcast RIP, not listen.   These routers don't support  any
    other  type  of  distance  vector  protocols, and fortunately they
    don't do link  state protocols at  all (ie.. no  redistribution of
    bogus  routes  learned  and  trusted  by  any  evil  haxx0r on the
    network).