[oclug] Alcatel DSL Modems
John E Pearson
pearson at lanm-pc.com
Tue Apr 10 08:44:51 EDT 2001
You folks might be interested in the attached.
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>THIS IS EARLY ACCESS INFORMATION. DO NOT RELEASE UNTIL AFTER 0700 GMT
>10 APRIL 2001. THE WEB PAGE REFERRED TO IN THIS NOTE WILL NOT BE
>AVAILABLE UNTIL THAT TIME.
>
>
>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 permits directly bypassing 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, 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
>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 the 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 it 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, also 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 at sdsc.edu or
>+1.858.534.8314.
>
>Correspondence regarding this notice should be sent to
>security at sdsc.edu or by telephone at +1.858.534.5050.
>
>
>( $Id: alcatel-bugs,v 1.7 2001/04/09 20:05:57 tep Exp $ )
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface>
>iQCVAwUBOtIWihTSxpWcaAFRAQHDCgP7BxI/TO0K2j7qXM2S0d8dA1TLeWohqWAu
>sQmeBnuD0l+a8kz43MYxP43ttD2Xb3yph1sSe6zkmcrLCju7DgBxRQCNeAVIgcRo
>zHiBzqbbMdvSjpthHhdyQkKakzoXy93KBUAPkKYDrmKm1eag5V3I6/hG0+MAuMTE
>VfZqx6cUoDI=
>=6MuY
>-----END PGP SIGNATURE-----
More information about the OCLUG
mailing list