ZyXEL Prestige 642R: Exposed Admin Services on WAN with Default Password

[Daniel Roethlisberger <daniel () roe ch>]

ZyXEL Prestige 642R: Exposed Admin Services on WAN with Default Password

AFFECTED

        ZyXEL Prestige 642R and 642R-I
            V2.50(AJ.4)
            V2.50(AL.1)
            V2.50(AL.2)b2 (seems to be latest public beta)
            and probably all other (earlier) versions too.

NOT AFFECTED

        ZyXEL Prestige 642M



        
SUMMARY

        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. The same holds true for
P642R and 642R-I models when used in "bridge mode", with PPPoE.
But that configuration is very unlikely to be in widespread use.

        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 [1] and flawed EXPERT mode
challenge/response authentication [2] vulnerabilities which
affected Alcatel Speed Touch ADSL devices. Though I am not fully
sure on that second one.




DETAILS

        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:

2. 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 [1] 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. I am 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 ;)




IMPLICATIONS

        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. I do not know how the Prestige
reacts when it gets firmware with wrong checksum uploaded.
However, those checksums are only 16 bits large, and I don't think
it would be too hard to fix them up.

        If one believes the recent warning from Italy [3], then
attacks on ADSL router firmware are already taking place out
there. 




PASSWORDS

        Now, the default password crux. I know, I know, users are
responsible for their passwords, etc. etc. etc. *BUT*: I've done
some research on this. Using simple scripts [4] I've scanned the
ADSL address ranges of all Swiss ADSL providers I know 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 I
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.

        I don't expect international numbers to differ too much
from the Swiss, but I 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 :P

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

        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?

        I do hope though that ZyXEL will release a fixed firmware
that has the telnet and FTP access closed down for good on the WAN
side. Not just those filters in place, but closed down properly --
don't even listen on the WAN interface at all -- as now setting up
up "SUA Servers" on ports 21 and 23 will for obvious reasons fail,
even though the Prestige documentation claims it does (they even
use them in the example SUA Server Setup). For suiting all
possible applications, it should be a configurable whether the
device listens on the WAN interface or not; with factory setting
set to not listening. If this is already configurable today, eg.
through the command line mode, then ZyXEL should document it, and
set the default settings to not listening.

        For now, owners should apply the FTP_WAN and TELNET_WAN
filter rules on their Prestige that intercepts incoming
connections to ports 21 and 23. The only thing you should need to
do is hook filter rules 3 and 5 into the Remote Node Setup (menu
11.1 -> 11.5), like so:

                         Menu 11.5 - Remote Node Filter

                    Input Filter Sets:
                      protocol filters=3,5
                        device filters=
                    Output Filter Sets:
                      protocol filters=
                        device filters=

        Unfortunately, though this is how it *should* work --
according to the documentation you should be able to specify up to
4 filters delimited by commas -- it does *not*. I was only able to
get a single filter active at a time. Check if it works on your
box, if not, you need to go into the filter set configuration 
(menu 21), and combine the FTP_WAN and TELNET_WAN into a single
filter with 2 entries. Consult the documentation on how to do this
if you are unsure.
                        
        ADSL providers could periodically scan their address
ranges for vulnerable Prestige's, either using their own scripts
or mine [4], in order to notify people with vulnerable Prestiges.
The output of my scripts is easily awk-able, makes for a nice cron
job. While they are at it they might probe for open proxies too :P




VENDOR

        I've notified ZyXEL by email, but got no response.
Unfortunately, they don't seem to have any valid security contact
listening on standard security email aliases, thus my notification
may have been swamped by their support/info departements. Maybe
they don't care about the issue, I don't know. I hope to finally
reach ZyXEL through BugTraq, too. Mentioned ISPs received a copy
of this as well, if they have standard security email aliases in
place (security, security-alert and secure).




LEGALISTICS

        Copyright (C) by my humble self, today and ever after.
Reproduction of this text in any way is hereby granted as long as
due credit is given. If you extend, distribute or otherwise make
use of the scripts, please lemme know. And remember, anything I
assumed or concluded herein may be completely inaccurate.




REFERENCES

[1] http://www.securityfocus.com/bid/2566
[2] http://www.securityfocus.com/bid/2568
[3] http://www.securityfocus.com/archive/1/201859
[4] http://dragon.roe.ch/adsl-probe.tar.bz2




Cheers,
Dan


-- 
   Daniel Roethlisberger <daniel () roe ch>
   PGP Key ID 0x8DE543ED with fingerprint
   6C10 83D7 2BB8 D908 10AE  7FA3 0779 0355 8DE5 43ED