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-----