COMMAND

    ZyXEL Prestige

SYSTEMS AFFECTED

    ZyXEL Prestige 100, 202, 642R and 642R-I 2.50

PROBLEM

    Daniel Roethlisberger  found following.   The ADSL  routers  P642R
    and  P642R-I  have  their  administrative  Telnet and FTP services
    exposed to the WAN  side in default configuration.   Additionally,
    there is the  traditional ZyXEL default  password in place,  which
    many users fail to change (scan result is: approx.  45% of  probed
    Prestiges have the default  password in place).   This combination
    leaves a lot of Prestiges vulnerable to remote attacks,  resulting
    in DoS; malicious firmware being installed; configuration changes;
    possibly retrieval of  ISP login credentials;  and attacks to  the
    internal LAN  by bouncing  off the  router; and  perhaps more.  In
    addition to that, there seems to be a minor configuration problem:
    it seems not possible  to apply more than  one filter rule to  the
    Remote Node filter list.

    The Prestige 642M model is not  affected, as it has no IP  address
    on its WAN  side (PPPoE). In  effect, its administrative  services
    are only accessible  from the LAN.  P642R's used over PPPoE  -are-
    vulnerable, unless SUA is disabled too.

    As the Prestige  642 models use  Alcatel chipsets, but  have their
    own OS  (ZyNOS), they  seem to  be not  vulnerable to the recently
    discovered   open   TFTP   service   and   flawed   EXPERT    mode
    challenge/response authentication  vulnerabilities which  affected
    Alcatel Speed Touch ADSL devices.

    Out  of  the  box,  the  Prestige  642R(-I)  seem to come with the
    administrative interface  wide open  on the  WAN side,  accessible
    from anywhere on the Internet.  Since firmware release AJ.3, there
    are supposed to  be filters for  FTP and Telnet  on the WAN  side.
    The firmware release notes say for AJ.3:

    In  default  ROM  file  settings,  System will block incoming FTP,
    TFTP,  TELNET,  and  WEB  traffic.   However,  in the same release
    notes, the settings for the remote node filters are shown as:

             Menu 11.5 - Remote Node Filter

        Input Filter Sets:
          protocol filters=
            device filters=
        Output Filter Sets:
          protocol filters=
            device filters=

    As you  can see,  no filters  are in  place, even  though they are
    otherwise configured correctly.  They  just did not apply them  to
    the remote node.   The firmware release  notes implicate that  the
    technician  wanted   them  to   block  the   traffic  in   default
    configuration; however,  the documentation  states somewhere  that
    those filters  are not  applied yet.  Additionally, it  seems that
    the  menu  11.5  is  broken,  ie.  one  can  only  assign a single
    filtering rule  per set  of filters.   See SOLUTION  section below
    for details.

    The Prestige is not  vulnerable to the Alcatel  TFTP vulnerability
    because it only allows  TFTP access if the  source IP of the  TFTP
    request is logged in  via telnet at the  same time.  The  Prestige
    is not  vulnerable to  the Alcatel  EXPERT mode  vulnerability, as
    there seems to  be no expert  mode.  Not  completely sure on  this
    though,  because  while  the  Prestige  does  not send a challenge
    upon USER EXPERT, it still  displays a date string in  the banner,
    which  -could-  be  used  for a challenge-response authentication,
    which in turn -could- be flawed.

    An  attacker  knowing  the  password  has  via  WAN  access to the
    administration  telnet  interface,  and  via  FTP/TFTP  to the raw
    configuration memory  image ("rom-0"),  and to  the firmware  file
    itself  ("ras").   It  may  be  possible  to  retrieve  the  login
    credentials to the ISP this way.  An attacker can of course change
    any  configuration  through  the  telnet  interface, including the
    access password of the router itself, rendering it inaccessible.

    Certainly a lot more  interesting is the possibility  of inserting
    new  port  forwarding  rules,  what  ZyXEL  calls  setting up "SUA
    Servers".  This way, an attacker can hop off the router to  attack
    hosts on the LAN, which are thought to be safe behind NAT  (Single
    User Account,  or SUA,  in ZyXEL  terminology).   Forwarding ports
    137-139 to  a windows  host on  the LAN  would probably offer some
    insight into wide open SMB shares on many networks behind such  an
    ADSL  router.   Finding  hosts  on  the  LAN  is  assisted  by the
    built-in ping feature of the Prestige.

    Whoever knows the password can  upload new firmware of his  choice
    across the Internet.  This not only includes legitimate  firmware,
    but also modified firmware, which can be anything from not working
    at all, to incorporating backdoors.  There are two checksums,  one
    for the firmware file as a whole, and one for the ZyNOS  operating
    system itself.

    Now,  the  default  password  crux.   We  know, we know, users are
    responsible for their passwords, etc. etc. etc. *BUT*: Daniel done
    some research on this.  Using simple scripts:

        http://dragon.roe.ch/adsl-probe.tar.bz2

    Daniel scanned the ADSL address ranges of all Swiss ADSL providers
    he  knew  of,  36  class  C  subnets  in  total, and the result is
    terrifying.   Out of  around 1000  open FTP  ports, 900  were from
    P642R's.   Out of  those 900  Prestiges, over  400 had the default
    password in place.  This is 45% of all P642R's with no filters  in
    place.  Of the 10 ISP's he scanned, only a single one (init7)  had
    no vulnerable Prestiges.

    Here's the details of the scan conducted:

        ------------------------------------------
         P642R's with default password in place,
         in relation to number of P642R's found
        ------------------------------------------
         Magnet.com AG       100.0 % (1 of 1)
         VTX                  73.0 % (19 of 26)
         BlueWin              66.4 % (97 of 146)
         EconoPhone           55.4 % (104 of 193)
         Callino              50.3 % (99 of 197)
         DataComm/TiscaliNet  38.1 % (85 of 223)
         Pipeline             11.1 % (1 of 9)
         CyberNet              3.8 % (2 of 52)
         Netstream             3.3 % (1 of 30)
         Init 7                0.0 % (0 of 24)
        ------------------------------------------
         Total                45.4 % (409 of 901)
        ------------------------------------------

    This  scans  might  not  be  representative,  especially for those
    ISP's with very few Prestiges found.  The statistics above do  not
    include routers who have filters  for port 21 in place,  which can
    be  assumed  to  be  power  users  who would probably have changed
    their access  password too.   But those  numbers are  nevertheless
    alarming.

    We don't expect international numbers to differ too much from  the
    Swiss, but we do not know whether this model is in such widespread
    use elsewhere.  Chances are  that it is; according to  ZyXEL, they
    are the worlds number 3 in DSL appliances.

    On a sidenote, the scans also turned up some of these:

        220 Proxy602 Gateway ready, enter user@host[:port]
        220 xxx.xxx.xxx.xxx FTP AnalogX Proxy 4.10 (Release) ready
        220 Internet Gate FTP Proxy Server - Version 1.46d
        220 aproxy FTP checker ready

    If you are wondering what the actual ZyXEL default password is, go
    read the documentation.

SOLUTION

    ZyXEL Prestige 642M is not affected.  Well, obviously, all  owners
    of  a  Prestige  642R  or  642R-I  should change their password to
    something other than the default.  But when will hardware  vendors
    begin to ship such devices with random passwords instead of  fixed
    default passwords?

    It seems  that SUA  Server rules  take precedence  over the  local
    admin services after all. One possible workaround for the  exposed
    ports is in fact  to set up SUA  Server rules for ports  21 and 23
    which point  to a  non-existant IP  address.   This is  in fact an
    easier  solution  than  correcting  and  applying the filter rules
    (see below), if not the most clean.

    The preconfigured  rules TELNET_WAN  and FTP_WAN  both have  match
    action  Drop  and  non-match  action  Forward in factory defaults.
    Which  means  chaining  them  together  within  a filter list will
    fail.  Which in turn means  that ZyXEL did not only choose  to not
    apply the filters, but  also set them up  in such a way  that they
    need to be modified in order to apply them both successfully.

    It  seems  that  some  ZyXEL  regional  offices  have  reacted and
    reworked the configuration of all P642R firmware releases.   Their
    fixed firmware is available at

        ftp://ftp.europe.zyxel.com/

    Unfortunately, there  seems to  be a  bit of  a release  managment
    problem within ZyXEL;  the fixed firmware  is some releases  older
    than  the  latest   firmware  available  from   the  Swiss   ZyXEL
    distributor, Studerus AG.   This also confirms  that the  firmware
    that  was  fixed  after  Sean  Boran  reported this issue to ZyXEL
    Switzerland in  June/July was  only available  within Switzerland,
    and not elsewhere.  Here's the details:

                ftp.europe.zyxel.com        www.zyxel.ch
        R-11    v2.50(AJ.2)r2 09/01/2000    v2.50(AJ.4)C0 07/03/2001
        RI-13   v2.50(AL.0)r2 08/08/2000    v2.50(AL.2)b2 05/22/2001
        R-61    v2.50(AN.1)r2 02/02/2001    -

    Not Vulnerable:

        ZyXEL Prestige 642M
        ZyXEL Prestige 642M-I

    If you have access to a ZyXEL router, check whether admin services
    are open to the Internet, and let us know about the results.