[Bda] [Fwd: multiple vulnerabilities in Alcatel Speed Touch DSL mo
skaya@enix.org
skaya@enix.org
Wed, 11 Apr 2001 09:01:46 +0200 (CEST)
un mail un peu long, mais tres complet, sur nos modems "favoris" ...
(qui a dit que les ECI c'etait de la daube :-) ?)
Subject: multiple vulnerabilities in Alcatel ADSL-Ethernet bridge
devices
I. Summary
Researchers associated with the San Diego Supercomputer Center at the
University of California, San Diego have identified multiple
implementation flaws in the Alcatel Speed Touch ADSL "modem" (actually
an ADSL-Ethernet router/bridge). These flaws can allow an intruder to
take complete control of the device, including changing its
configuration, uploading new firmware, and disrupting the
communications between the telephone central office providing ADSL
service and the device.
These flaws allow the following malicious actions:
* changing the device's configuration such that the device can no
longer be accessed;
* disabling the device, either temporarily or permanently (requiring
return of the device to the manufacturer); and
* installation of malicious code, such as a network sniffer
to gather local LAN traffic (that is not being bridged) and
making the box more easily/covertly remotely accessible.
One of the more interesting discoveries was a cryptographic
challenge-response back door that completely bypasses any password
that a user may have set on the device.
All testing to date has been done in LLC/SNAP bridge mode. Routing
mode was not tested. There may be other flaws that are easier to
exploit in that mode.
(Speed Touch is a trademark of Alcatel.)
II. The Alcatel Speed Touch family of devices
This advisory addresses the Speed Touch family of devices, and similar
devices apparently based on related code such as the older Alcatel
1000 ADSL Network Termination device (1000 ADSL). All testing was
performed on the "Speed Touch Home", and limited testing was performed
on the 1000 ADSL. It is strongly suspected that the "Speed Touch Pro"
software is at least very similar to that in the Speed Touch Home, so
it is probable that the Pro is vulnerable to similar attacks. Other
members of the family running software derived from the same code base
would also be expected to share these vulnerabilities.
Note that Alcatel renamed their entire Speed Touch product line a few
weeks ago at CeBIT, so the Home and Pro may have new designations.
The described flaws were demonstrated in all known firmware versions
of the Speed Touch Home, including:
KHDSAA.108 Jul 6 14:03:12 GMT 1999
KHDSAA.132 Nov 19 13:52:05 GMT 1999
KHDSBA.133 Mar 16 17:52:08 GMT 2000
KHDSAA.134 Apr 24 12:48:43 GMT 2000
The Alcatel 1000 ADSL does not have a user-settable password and
therefore does not share the cryptographic back door with the Speed
Touch Home. It has the additional vulnerability that access through
its HTTP server can not be restricted, and shares the TFTP
vulnerabilities described below with the Speed Touch Home. The version
of software in the 1000 ADSL tested was:
KA1HAA.112 Jan 26 09:51:00 GMT 1999
By default, the device uses the IP address 10.0.0.138, although this
can be changed via HTTP, TFTP, or command line (TELNET) interface.
The device can have multiple IP addresses at the same time.
III. The Implementation Flaws
There are several flaws, including user authentication issues;
fully-accessible TFTP servers, and a lack of validation of downloaded
firmware.
III.A Various user authentication issues
The device has several flaws and one interesting "feature" in the area
of authentication.
III.A.1 Open front door - No default password
As shipped, the device allows for configuration read/write access
with no password. This can be accomplished via TELNET or HTTP. The
file structure of the device's file systems can be examined with FTP.
The first mention of this appears to be from November 2000:
http://www.vnunet.fr/actu/article.htm?numero=6197&date=2000-11-06
In this article (in French), they suggest that you might want to set
the password before someone else does it for you.
This information is not listed in the "Default Logins for Network
Devices" page at: http://security.nerdnet.com/index.php
III.A.2 Missing roof - password may be stolen/changed
The password, if set, can be extracted from the device using TFTP.
Or, TFTP can be used to set or change the existing password. None of
these operations require any authentication at all. See (III.B) below
on the use of TFTP.
III.A.3 Cryptographic back door - bypassing the password completely
If for some reason it is inconvenient to obtain or change the password
with TFTP, it can be directly bypassed by logging in as the user
"EXPERT", which will invoke a cryptographic challenge-response
sequence. The password will then be the result of a cryptographic
function applied to the "challenge" string presented immediately
before the request for the password. For example, the FTP and TELNET
dialogs look something like:
ftp> open 10.0.0.138
Connected to 10.0.0.138.
220 Inactivity timer = 120 seconds. Use 'site idle <secs>' to change.
Name (10.0.0.138:root): EXPERT
331 SpeedTouch (00-90-D0-00-00-00) User EXPERT OK. Password required.
Password:
230 OK
ftp>
telnet> open 10.0.0.138
Trying 10.0.0.138...
Connected to 10.0.0.138.
Escape character is '^]'.
User : EXPERT
SpeedTouch (00-90-D0-00-00-00)
Password :
##########----------------------------------------------------------------------
--
*
* ______
* ___/_____/\
* / /\\ ALCATEL ADSL MODEM
* _____/__ / \\
* _/ /\_____/___ \ Version 3.2
* // / \ /\ \
* _______//_______/ \ / _\/______ Copyright 1999-2000.
* / / \ \ / / / /\
* __/ / \ \ / / / / _\__
* / / / \_______\/ / / / / /\
* /_/______/___________________/ /________/ /___/ \
* \ \ \ ___________ \ \ \ \ \ /
* \_\ \ / /\ \ \ \ \___\/
* \ \/ / \ \ \ \ /
* \_____/ / \ \ \________\/
* /__________/ \ \ /
* \ _____ \ /_____\/
* \ / /\ \ /
* /____/ \ \ /
* \ \ /___\/
* \____\/
*
-
-----------------------------------------------------------------------
=>
In both examples above, the "challenge" string is
'SpeedTouch (00-90-D0-00-00-00)'
and the response (typically a ten-digit integer) in this case is
1552815226.
Each device will have a unique response as it has a different Ethernet
MAC address, and the rest of the "challenge" string has sometimes
changed between firmware versions. Neither the encryption algorithm
nor its cryptovariables have been observed to change across devices or
software versions.
The biggest risk of this challenge-response scheme is that anyone who
knows the cryptographic algorithm and cryptovariables used to validate
the response has permanent access to ANY similar Alcatel SpeedTouch
device. There is NO WAY currently known to us for anyone to disable
this back door, other than by downloading our custom firmware (see
III.C below).
It is worth noting that all of these potentially passworded TCP
services are supposedly available ONLY from the LAN side. As the
device is a MAC-layer bridge, it has no way of actually enforcing this
restriction, and in many cases these services are trivially reachable
from the WAN side due to the configuration of the device and other
devices on the LAN.
III.B Open TFTP servers - via LAN, WAN and DSLAM
The open TFTP server is trivially accessible from the "inside" LAN,
and access from the "outside" net may be only marginally more
difficult. It appears to be accessible to the ADSL provider's DSLAM,
or anyone with access to the copper ADSL loop, with no additional
authentication.
As shipped, the device provides an open TFTP server that can be used
to transfer files both to and from the device. This can be used to
extract the configuration from the device, or to change the
configuration of the device, as well as change, destroy or subvert the
device's firmware. For example, an attacker could replace the
device's firmware with malicious code, such as a packet sniffer or a
denial of service "zombie" such as Trin00 or TFN2K.
There is no known way for the user/owner to disable the TFTP server.
There is, of course, no authentication required for any TFTP access.
III.B.1 Access via the inside LAN
Specifically, the TFTP server is available over normal UDP/IP on the
"inside" Ethernet, using any TFTP client. Using TFTP, one can extract
the password and other configuration data, as well as a copy of the
firmware.
More importantly, one can also upload new configuration information,
including a new (or no) password, as well as new (perhaps malicious)
firmware.
III.B.2 Access via the outside WAN (IP)
It is possible to attack from the "outside" WAN via IP protocols by
using any of the well-known methods to "bounce" UDP packets through a
host on the internal network.
This "attack" can be mounted no matter what the IP address of the
Speed Touch device, whether it is still set to a non-routed address,
such as the default 10.0.138, or whether the Speed Touch device has
been set to an address on the inside network. The device's address
does not even need to be known, as the TFTP server in the device
listens to the IP broadcast address (255.255.255.255) IN ADDITION to
any addresses configured by the user/owner.
This behavior makes it trivial to "bounce" attacks through (for
example) the UDP ECHO port of a host computer that is attached to the
"inside" Ethernet network, without concern for what addresses the
Speed Touch device may be configured for or the concern that it may be
on a different logical subnet than the other systems on the inside
Ethernet.
In this example, one can send packets to the TFTP server from the
outside by sending TFTP UDP packets with a source address of
255.255.255.255 and a source port of TFTP to the UDP ECHO port of any
system on the internal network with a functioning UDP ECHO server.
When the "ECHO server" replies to the request, it will interpret the
(now) destination address of 255.255.255.255 as local broadcast, and
the packet will be broadcast on the Ethernet with the destination port
set to UDP TFTP.
Many networking devices (including the Speed Touch) provide a UDP ECHO
service, and in many cases (again, including the Speed Touch) there is
no way to disable the service.
It should be noted that the Speed Touch Home specifically does not
process source-routed packets by default. This decision appears to be
deliberate, as this is an easily configurable option that the
documentation explicitly recommends not be changed. This
configuration is presumably to discourage the obvious attack. The
1000 ADSL appears to not process source-routed packets at all.
However, this option provides some possibilities for the attacker. If
the attacker has only TFTP access (via a "bounce" or some other
mechanism), they could write a new configuration to the device which
would permit source-routing and default routing, and gain full access
either by also setting a new password or by using the cryptographic
back door.
III.B.3 Access via the outside WAN (DSLAM)
The Speed Touch device appears to have TFTP and SNMP servers listening
directly on the WAN side on AAL5-encapsulated VPI/VCIs 15/16 and
15/64. This feature presumably exists so that the ADSL provider has
full access to the device, without any form of authentication.
Therefore the ADSL providers have the ability to upgrade the device,
should Alcatel provide new firmware to address these or other issues.
A paragraph from the _Alcatel Speed Touch Installation and User Guide_,
3EC 16830 AAAA TCZZA Ed. 02, p.152:
17.1 Software Download from the Network
This feature is controlled by the ADSL Provider. At some
point in time he might decide to upgrade the software in your
_Speed Touch_. This download will happen almost unnoticed.
You will see a change in the software version though if you
surf to the _Speed Touch_'s Upgrade page.
These capabilities are also available to anyone with the proper
equipment and access to the copper loop, such as at the residential
TELCO DEMARC outside a home, or a street-side "ped". Theoretically,
anyone who can emulate a central office DSLAM (ATU-C) can "clip on" to
the phone line and take full control of the device. Note that since
some of the same DMT chip sets are sold for use in both remote devices
(ATU-R), such as the Speed Touch, and in central office equipment,
such as DSLAMs (ATU-C), it is probable that constructing an improvised
single-line "portable DSLAM" is not be out of reach for a somewhat
determined attacker.
III.C Inadequate validation of firmware
The Alcatel devices do not appear to do any sort of authenticity or
integrity checking on firmware downloaded to them.
This behavior makes it easier for an abuser to generate a firmware
file that will be accepted as a valid firmware "load". This bogus
firmware could contain malicious code, such as a network sniffer or
denial of service tool.
As a demonstration a modified version of the firmware, with
"interesting" security properties was loaded into a SpeedTouch Home.
The firmware was accepted, decompressed, and executed without
question.
IV. Vendor information
Searches of the www.alcatel.com and associated sites turned up no
security information, other than how to recover or reset the passwords
and other configuration information from the router via physical
access.
An interesting item showed up at:
http://www.alcatel.com/consumer/dsl/supfaqusa.htm#usa3
There's no firewall in the A1000 or Home, does it make these modems
unsafe to use?
Absolutely not. When in standard settings, these modems do not allow
any connection from the outside world to your modem or computer,
except when requested by your machine. This means it only allows
replies on your request, for example the loading of a webpage after
clicking a link. When a computer, unknown to your modem, is trying
to
connect to your modem or computer, it will be blocked.
Caveat emptor.
V. Commentary and Observations
It is remarkable that for every method provided for accessing the box
(HTTP,TELNET, FTP, and TFTP) it is possible to directly bypass any
access controls the owner may try to put in place.
It seems very poor form to let a user set a password that they believe
will be enforced while deliberately leaving such a back door,
especially given that there are other (well documented) mechanisms for
clearing or resetting a password should it become lost.
A malicious firmware load could be carried as a worm or virus payload
to a host on the inside Ethernet, and could survive the eradication of
the worm or virus on the host platform.
One solution to the insufficient firmware validation problem would be
for the firmware loader to verify that the offered firmware load was
signed with a known digital signature key before being accepted for
use.
VI. Some notes on the "EXPERT" mode of operation
The Speed Touch Home has an EXPERT mode (distinct from the use of
EXPERT to bypass the password mechanism) which can be used to discover
interesting information about the ADSL line operational parameters,
ATM cell statistics, etc. This mode can also be used to set a wide
variety of device and interface parameters, as well as partitioning,
formatting, and erasing the flash file system. It can provide
extremely valuable information for debugging an ADSL connection.
Entry to this mode is restricted by the same cryptographic
challenge-response mechanism that is used as a back door to bypass the
password.
If the ADSL provider has not provided the password to the device, a
tool is available to provide the password in the "Alcatel ADSL Modem
Owner's Self-Help Guide", at:
http://security.sdsc.edu/self-help/alcatel
This page has some additional information related to this advisory, as
well as some tools and hints for the Alcatel ADSL modem owner.
VII. Workarounds and patches
None known at this time.
VIII. Authors
Tsutomu Shimomura is a Senior Fellow of the San Diego Supercomputer
Center at the University of California, San Diego. He is a well-known
technologist and security researcher and co-author of _Takedown_, on
his pursuit and capture of computer outlaw Kevin Mitnick.
Tom Perrine is the Manager of Security Technologies at the San Diego
Supercomputer Center. He works in the areas of critical
infrastructure protection, scalable security infrastructure, and
computer intrusion analysis.
The San Diego Supercomputer Center is a research unit of the
University of California, San Diego, and the leading-edge site of the
National Partnership for Advanced Computational Infrastructure. SDSC
is sponsored by the National Science Foundation through NPACI and by
other federal agencies, the State and the University of California,
and private organizations. For additional information about SDSC, see
http://www.sdsc.edu/ or contact David Hart at dhart@sdsc.edu or
+1.858.534.8314.
Correspondence regarding this notice should be sent to
security@sdsc.edu or by telephone at +1.858.534.5050.