||Home : Advisories : RIPE, APNIC, RADB update insecurities|
||RIPE, APNIC, RADB update insecurities
||6th December 2000
-----BEGIN PGP SIGNED MESSAGE-----
I found the following potential issues in the top-level routing
Raju Mathur is not responsible for the misuse of any of the
information and/or program(s) present in this message. The message
and program(s) are provided as a service to the Internet community.
Raju Mathur is not liable for any damages, direct or indirect, caused
by the information or program(s) present in this advisory.
The Routing Registries maintain databases of all routing information
including Autonomous System Numbers and IN.ADDR-ARPA reverse lookups.
The registries display DES-encrypted passwords to the general public,
and the database update process is prone to being cracked.
Contacted RIPE, APNIC and RADB on 25 November, 2000. Responses
indicate that the database format and information revealed were
decided by the community and cannot be changed until the community as
a whole votes to change them. I have a copy of the complete
correspondence if anyone's interested.
If you are a maintainer for an AS or an IN-ADDR.ARPA domain, you can
use any of the following methods to update information about your
records (this is from my personal understanding, there could be minor
differences between different registries):
1. NONE. You send updates by e-mail or through a web form to the
registry, which are reviewed by the hostmaster and applied if they are
syntatically and semantically OK.
2. MAIL-FROM. You send updates by e-mail or through the web form to
the registry, which makes syntax and semantic checks and contacts you
on your registered e-mail address. Once you reply in the affirmative,
the updates are applied.
3. CRYPT-PW. The web forms allow you to apply semantically correct
updates immediately if you choose CRYPT-PW as your authentication
method. You only need your password to change the database. There is
no human review of the update.
4. PGP. You send a PGP-signed message to the hostmaster, who verifies
that the signature is correct, makes syntax and semantic checks and
updates the database.
I'm not going to go into problems associated with MAIL-FROM and NONE
authentication methods since (a) they have already been thrashed out
in the context of the domain registries and (b) they require human
intervention at some point. PGP also seems quite safe (as safe as
using PGP is).
The CRYPT-PW method of update is of interest here. Essentially anyone
who manages to get hold of your plaintext CRYPT-PW (which uses DES as
the encryption method) can masquerade as you and make changes to the
databases without any other human intervention at all. This can lead
to serious security and network outage issues in the short term. So
far I thought that long-term implications were minimal since the
original maintainer would be notified about rogue changes, but I'm not
too sure about what happens if you change the maintainers contact
The problem is that the registries are constrained by their users to
reveal the CRYPT'ed password to the general public through a simple
whois mechanism. Doing a whois on the maintainer object in a registry
reveals the CRYPT'ed password if s/he has one, after which there are
any number of tools which would permit you to attempt to crack or
brute-force the password.
Not really an exploit, but the attached Perl script (which has been
tested on Linux with fwhois) will help you to extract DES-encrypted
passwords from maintainer objects related to a range of Autonomous
System Numbers (ASN's) and put them into a Unix-style password file
which can be fed to Crack & co. for further ``processing''.
Run it as:
who.pl output-file APNIC|RIPE start-asn end-asn
where output-file will be the file with the Unix-style passwd
information including the encrypted password, APNIC or RIPE are which
registry you wish to glean passwords from (it's trivial to modify the
program to glean passwords from RADB) and start- and end-asn's define
the block of AS numbers whose maintainer objects you are trying to to
extract passwords from.
Solutions exist at a number of levels:
1. Personal. Do not use CRYPT-PW as your authentication mechanism if
you are a maintainer. All the registries recommend the use of PGP and
will help you get started with PGP if you need that.
2. Community. Take a decision not to display the authentication
mechanism to the general public, especially the encrypted passwords.
It should be trivial to change the whois server code to conceal the
3. Registry. Encourage all your users to switch to a more secure
method of sending updates. Define a date by which all users must
switch. Remove the ``NONE'' authentication method altogether. For
MAIL-FROM use unique, random identifiers for each request which must
be present in the update confirmation message.
- -- Raju
Content-Disposition: attachment; filename="who.pl"][base64]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
-----END PGP SIGNATURE-----