Onderwerp: Security flaw in ALCATEL/THOMSON Speed Touch Pro ADSL modems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


TITLE: Security flaw in ALCATEL/THOMSON Speed Touch Pro ADSL modems
(http://www.speedtouchdsl.com/)

TYPE: DNS poisonning over DHCP

QUOTE from http://www.speedtouchdsl.com/:

It's all about the bottom line, isn't it? That's why your competitors
are in business. You're constantly looking for ways to save time and
increase efficiency. Take a look at the full-featured SpeedTouch Pro
ADSL Router, now that's something the whole office can get on board with.
At up to 200 times faster than traditional modems, and with the
capabilities
to dynamically assign IP addresses, or allow multiple systems to share a
single IP address, the Speed Touch Pro is all about ROI. And the color of
the SpeedTouch Pro? It's in the black, of course.

DETAILS:

Speed Touch Pro ADSL modem suffers two security flaws allowing an
insider to poison the intranet zone
configured in the modem's embedded DNS server.
By sending two requests to the modem's DHCP server, an attacker can
remotely modify
any static DNS entry with an arbitrary address (valid within the DHCP
scope though) opening a convenient way (just another one)
to various harmful spoofing attacks.
It is unlikely that a lot of offices are using Alcatel DNS/DHCP
servers but if yours does then read the
following.


EXPLOITATION:

Upon complete DHCP negociation, Alcatel modem will try to register the
client's DHCP HOSTNAME option into its local DNS domain.
At this point, it will care about the hostname syntax and will also
check it for redundancy.
It will simply discard any DNS dynamic update if the proposed hostname
already exists.
If it doesn't, an entry is added to the end of the local zone file.
However any new DHCP request for an already existing lease, including
a redundant HOSTNAME, will bypass this checking.
We have now two entries with the same hostname but two differents ip
addresses.

Problem:
A problem still remains because Alcatel DNS resolves intranet names
with first match found in the file
therefore if the fake entry is located below the legitimate one in the
zone file (upper ones having precedence),
the DNS will simply never resolve target with our fake address.
Two scenarios are possible:
#1- The site administrator has added the static entry *after* we got
the lease the first time
making us conveniently located above the target in the file,
in such a case game is over in one more DHCP packet.
#2- The target is above (ie: has higher precedence) in this case
another flaw can save us.
When deleting a DNS entry from the web interface, an administrator
actually delete all entries sharing the same name
without being notified, then if we can trick the admin into deleting
our DHCP lease he will also delete his legitimate server name
cleaning the place for scenario #1 again.

For easy DHCP testing, try DHCPing:
http://c3rb3r.openwall.net/dhcping/


VENDOR STATUS:

ALCATEL staff has been contacted through their support website on Jul
2nd 2004 but never replied.


WORKAROUND:
Before any update to the intranet zone: Unplug your modem's internal
NIC and delete all DHCP entries taking care of redundant entries to
not delete
your own hosts, then make changes and replug.
AND consider using a more robust DNS/DHCP solution like ISC DHCP suite
for instance.


AUTHOR: Gregory Duchemin (c3rb3r at sympatico.ca)



- --
Gregory Duchemin <c3rb3r at sympatico.ca>
GPG key ID: B3A649D6 fp: 0800 2CB5 7823 436D 438F 8A27 F4AD 9F19
B3A6 49D6
http://mdcrack.openwall.net - bruteforce your hashes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBlFH09K2fGbOmSdYRAqQFAKDmtq4KlIkBg8RDU6q9/tpRHDKmqACfZ7ap
49E1XA/PfvLVSMf8XJYNn1w=
=nsTP
-----END PGP SIGNATURE-----

Dear Gregory Duchemin,

In case of the product like ADSL modem is, it's not a bug, but a leak of
feature to secure DHCP and/or dynamic DNS updates, because it's a way
DHCP and DNS are supposed to work and it's impossible to fix it without
implementing protocol extensions. This products are targeted for SOHO
(any corporate user already have DNS/DHCP server implemented) where this
kind of attack does not lead to any serious threats.

--Friday, November 12, 2004, 9:02:28 AM, you wrote to bugtraq@securityfocus.com:


GD> Upon complete DHCP negociation, Alcatel modem will try to register the
GD> client's DHCP HOSTNAME option into its local DNS domain.
GD> At this point, it will care about the hostname syntax and will also
GD> check it for redundancy.
GD> It will simply discard any DNS dynamic update if the proposed hostname
GD> already exists.
GD> If it doesn't, an entry is added to the end of the local zone file.
GD> However any new DHCP request for an already existing lease, including
GD> a redundant HOSTNAME, will bypass this checking.
GD> We have now two entries with the same hostname but two differents ip
GD> addresses.

--
~/ZARAZA
Ïîÿâèëñÿ íîâûé òèï ýëåìåíòàðíûõ ÷àñòèö - øêâàðêè.
Íå î÷åíü áîëüøèå, ñëåãêà ïîäãîðåâøèå. (Ëåì)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Dear 3APA3A,

3APA3A wrote:

| Dear Gregory Duchemin,
|
| In case of the product like ADSL modem is, it's not a bug, but a
| leak of feature to secure DHCP and/or dynamic DNS updates,
| because it's a way DHCP and DNS are supposed to work and it's
| impossible to fix it without implementing protocol extensions.

The first flaw lies in a lack of (hostname) collision checking when
collision happens within a valid (already) registered lease, Alcatel
firmware simply doesn't validate any further Hostname given to it,
once the first checking has occured.
Second flaw (a direct consequence of the first) appears when deleting
a record for the zone (from the web interface), all collisions will
then be deleted at once. Such behavior was obviously not expected by
programmers.

This doesn't require protocol extension, the same care (user input
validation) should be applied for *all* DHCP packets received and not
only the first one. All the programmatical logic is already there but
not correctly implemented.

It is correct behavior for a standard DNS to round robbin between
several ip adresses when a zone administrator has configured it for
this purpose BUT NOT when it comes from a user exploiting a flaw in
the server.
Moreover Speed touch Pro DNS has no round robbin feature.:-) yes this
is really a bug

To summarize a bit, this flaw allows to corrupt the local zone file
managed by the device and may allows an
internal user to trigger DNS based spoofing attacks.

| This products are targeted for SOHO (any corporate user already
| have DNS/DHCP server implemented)

| where this kind of attack does not lead to any serious threats.
|
In this case, i agree and as mentionned in my post:

"It is unlikely that a lot of offices are using Alcatel DNS/DHCP
servers but if yours does then read the
following."

however for offices that may actually use it, *threat is serious*.
Gregory

| --Friday, November 12, 2004, 9:02:28 AM, you wrote to
| bugtraq@securityfocus.com:
|
|
| GD> Upon complete DHCP negociation, Alcatel modem will try to
| register the GD> client's DHCP HOSTNAME option into its local DNS
| domain. GD> At this point, it will care about the hostname syntax
| and will also GD> check it for redundancy. GD> It will simply
| discard any DNS dynamic update if the proposed hostname GD> already
| exists. GD> If it doesn't, an entry is added to the end of the
| local zone file. GD> However any new DHCP request for an already
| existing lease, including GD> a redundant HOSTNAME, will bypass
| this checking. GD> We have now two entries with the same hostname
| but two differents ip GD> addresses.
|



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBlmZx9K2fGbOmSdYRApT5AKCIp6yHxELcdgVgw9nZRh 0XDo4agACgySRv
edspt0QTZY57qNd34TtALMM=
=E2Gv
-----END PGP SIGNATURE-----