http://www.roe.ch/advisories/R200102-zyxel-wan-admin.txt 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://www.roe.ch/advisories/R200102-zyxel-wan-admin.tar.bz2