(Some Details are Clarified) Re: Some ZyXEL Prestige Routers Allow Remote Telnet and FTP Access to the Device in the Default Configuration
|
|
SecurityTracker Alert ID: 1002175 |
|
SecurityTracker URL: http://securitytracker.com/id/1002175
|
|
CVE Reference:
GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Aug 11 2001
|
Impact:
Root access via network
|
|
Version(s): ZyXEL Prestige 642R and 642R-I, V2.50(AJ.4), V2.50(AL.1), V2.50(AL.2)b2
|
Description:
A configuration vulnerability was reported in some ZyXEL Prestige routers that allows remote users to access the router's Telnet and FTP services in the default configuration.
The author of the original report clarifies and corrects the details of the vulnerability.
For the original report, see the Message History.
For the corrected details, see the Source Message.
|
Impact:
A remote user can gain administrative access to the router when in the default configuration. Administrative access allows the user to make configuration changes and upload new firmware.
|
Solution:
Users can apply the FTP_WAN and TELNET_WAN filter rules to block incoming connections to ports 21 and 23. This can reportedly be done by hooking 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=
|
Vendor URL: www.zyxel.com/ (Links to External Site)
|
Cause:
Configuration error
|
Underlying OS:
|
|
Message History:
This archive entry is a follow-up to the message listed below.
|
Source Message Contents
|
Date: Fri, 10 Aug 2001 21:48:56 +0200
Subject: Re: ZyXEL Prestige 642R: Exposed Admin Services on WAN with Default Password
|
It seems that some of the statements made in my original posting
were not fully accurate.
First off, I've been told that P642R's used over PPPoE -are-
vulnerable, unless SUA is disabled too. I have no means to verify
this, so I am unsure whether this is the end of the story.
Second, I stated that setting up SUA Server rules does not work.
This is plain wrong, it -does-, yet for some reason my initial
attempt to do so failed. 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.
Thanks to all those who pointed these details out to me.
Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> It works, but portions of the filter setup process are severely
> underdocumented. You need to be very careful about chaining
> rules together, so that the filter sets have to end with a
> "Check next rule" action for everthing but the last filter set.
> If you end with a Drop/Forward action, the filter does exactly
> that without checking further rules.
You are indeed right. 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. Thanks for pointing this out.
Cheers,
Dan
--
Daniel Roethlisberger <daniel@roe.ch>
PGP Key ID 0x8DE543ED with fingerprint
6C10 83D7 2BB8 D908 10AE 7FA3 0779 0355 8DE5 43ED
|
|
