Vulnerability

    WebRamp routers

Affected

    WebRamp routers

Description

    James Egelhof and John Stanley  brought following to public.   The
    WebRamp  (at  least  Entre,  the  ISDN version) includes a default
    username of "wradmin" and password of "trancell."  This gives  you
    full access to the device,  either through the CLI or  the Windows
    management software (which seems to use the CLI).  You can use the
    CLI to set  up a "Remote  Office" connection profile.   If you  do
    this, you can make  the WebRamp call up  a remote site and  attach
    it to your network.  Or, you could change the ISP phone number  to
    something  else,  and  thereby  get  the  WebRamp  to divulge your
    password.  Other uses for this access are pretty obvious.

Solution

    The easiest way to prevent  unwanted access to your WebRamp  is to
    change  the  Admin  Password,  and  as  with  all  things security
    related, change it often.   To completely block telnet access  (so
    that the session  can't even be  initiated) from the  WAN you have
    two options.

    Method 1:  Enable a Visible  Computer for each  active modem  port
               and pointing to IP addresses that are not being used in
               your LAN (e.g. 192.168.1.254  is a good place  to start
               as DHCP is not likely to ever pass it out), and uncheck
               both of the divert incoming boxes.

    Method 2:  Enable  a Local Server of  the Telnet and Web  type and
               point them to an IP address that is not in use on  your
               network.   Then  telnet  into  the  webramp and use the
               divertport to  disable all  incoming diversions.   This
               will only work for modem 1.  If you are using 2 or more
               modems use method one.

    Last  but  not  least,  engineering  has  agreed  to incorporate a
    change in the M3 families code to mimic the 310.  This would allow
    the user to  simply check one  box to disallow  WAN access to  the
    httpd  and  telnetd  processes.    Since  there  are   workarounds
    available, and useability/functionality  is not impaired,  this is
    considered to  be a  low priority  and may  be incorporated in the
    next point release.