|
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
' 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.
( $Id: alcatel-bugs.html,v 1.1 2001/04/12
17:05:46 abe Exp abe $ )
|
