- Test - lists.nanog.org

FW: CERT Advisory CA-2003-06 Multiple vulnerabilities in SIP
by St. Clair, James 21 Feb '03

21 Feb '03

-----Original Message----- From: CERT Advisory [mailto:cert-advisory@cert.org] Sent: Friday, February 21, 2003 10:25 AM To: cert-advisory(a)cert.org Subject: CERT Advisory CA-2003-06 Multiple vulnerabilities in implementations of the *** PGP Signature Status: unknown *** Signer: Unknown, Key ID = 0xD9513B39 *** Signed: 2/21/2003 10:19:02 AM *** Verified: 2/21/2003 1:09:03 PM *** BEGIN PGP VERIFIED MESSAGE *** CERT Advisory CA-2003-06 Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP) Original release date: February 21, 2003 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected SIP-enabled products from a wide variety of vendors are affected. Other systems making use of SIP may also be vulnerable but were not specifically tested. Not all SIP implementations are affected. See Vendor Information for details from vendors who have provided feedback for this advisory. In addition to the vendors who provided feedback for this advisory, a list of vendors whom CERT/CC contacted regarding these problems is available from VU#528719. Overview Numerous vulnerabilities have been reported in multiple vendors' implementations of the Session Initiation Protocol. These vulnerabilities may allow an attacker to gain unauthorized privileged access, cause denial-of-service attacks, or cause unstable system behavior. If your site uses SIP-enabled products in any capacity, the CERT/CC encourages you to read this advisory and follow the advice provided in the Solution section below. I. Description The Session Initiation Protocol (SIP) is a developing and newly deployed protocol that is commonly used in Voice over IP (VoIP), Internet telephony, instant messaging, and various other applications. SIP is a text-based protocol for initiating communication and data sessions between users. The Oulu University Secure Programming Group (OUSPG) previously conducted research into vulnerabilities in LDAP, culminating in CERT Advisory CA-2001-18, and SNMP, resulting in CERT Advisory CA-2002-03. OUSPG's most recent research focused on a subset of SIP related to the INVITE message, which SIP agents and proxies are required to accept in order to set up sessions. By applying the PROTOS c07-sip test suite to a variety of popular SIP-enabled products, the OUSPG discovered impacts ranging from unexpected system behavior and denial of services to remote code execution. Note that "throttling" is an expected behavior. Specifications for the Session Initiation Protocol are available in RFC3261: http://www.ietf.org/rfc/rfc3261.txt OUSPG has established the following site with detailed documentation regarding SIP and the implementation test results from the test suite: http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/ The IETF Charter page for SIP is available at http://www.ietf.org/html.charters/sip-charter.html II. Impact Exploitation of these vulnerabilities may result in denial-of-service conditions, service interruptions, and in some cases may allow an attacker to gain unauthorized access to the affected device. Specific impacts will vary from product to product. III. Solution Many of the mitigation steps recommended below may have significant impact on your everyday network operations and/or network architecture. Ensure that any changes made based on the following recommendations will not unacceptably affect your ongoing network operations capability. Apply a patch from your vendor Appendix A contains information provided by vendors for this advisory. Please consult this appendix and VU#528719 to determine if your product is vulnerable. If a statement is unavailable, you may need to contact your vendor directly. Disable the SIP-enabled devices and services As a general rule, the CERT/CC recommends disabling any service or capability that is not explicitly required. Some of the affected products may rely on SIP to be functional. You should carefully consider the impact of blocking services that you may be using. Ingress filtering As a temporary measure, it may be possible to limit the scope of these vulnerabilities by blocking access to SIP devices and services at the network perimeter. Ingress filtering manages the flow of traffic as it enters a network under your administrative control. Servers are typically the only machines that need to accept inbound traffic from the public Internet. Note that most SIP User Agents (including IP phones or "clien"t software) consist of a User Agent Client and a User Agent Server. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound traffic to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound traffic to non-authorized services. For SIP, ingress filtering of the following ports can prevent attackers outside of your network from accessing vulnerable devices in the local network that are not explicitly authorized to provide public SIP services: sip 5060/udp # Session Initiation Protocol (SIP) sip 5060/tcp # Session Initiation Protocol (SIP) sip 5061/tcp # Session Initiation Protocol (SIP) over TLS Careful consideration should be given to addresses of the types mentioned above by sites planning for packet filtering as part of their mitigation strategy for these vulnerabilities. Please note that this workaround may not protect vulnerable devices from internal attacks. Egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound traffic to the Internet. In the case of the SIP vulnerabilities, employing egress filtering on the ports listed above at your network border may prevent your network from being used as a source for attacks on other sites. Block SIP requests directed to broadcast addresses at your router. Since SIP requests can be transmitted via UDP, broadcast attacks are possible. One solution to prevent your site from being used as an intermediary in an attack is to block SIP requests directed to broadcast addresses at your router. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. America Online Inc Not vulnerable. Apple Computer Inc. There are currently no applications shipped by Apple with Mac OS X or Mac OS X Server which make use of the Session Initiation Protocol. Borderware No BorderWare products make use of SIP and thus no BorderWare products are affected by this vulnerability. Clavister No Clavister products currently incorporate support for the SIP protocol suite, and as such, are not vulnerable. We would however like to extend our thanks to the OUSPG for their work as well as for the responsible manner in which they handle their discoveries. Their detailed reports and test suites are certainly well-received. We would also like to reiterate the fact that SIP has yet to mature, protocol-wise as well as implementation-wise. We do not recommend that our customers set up SIP relays in parallel to our firewall products to pass SIP-based applications in or out of networks where security is a concern of note. F5 Networks F5 Networks does not have a SIP server product, and is therefore not affected by this vulnerability. Fujitsu With regards to VU#528719, Fujitsu's UXP/V o.s. is not vulnerable because the relevant function is not supported under UXP/V. IBM SIP is not implemented as part of the AIX operating system. IP Filter IPFilter does not do any SIP specific protocol handling and is therefore not affected by the issues mentioned in the paper cited. IPTel All versions of SIP Express Router up to 0.8.9 are sadly vulnerable to the OUSPG test suite. We strongly advice to upgrade to version 0.8.10. Please also apply the patch to version 0.8.10 from http://www.iptel.org/ser/security/ before installation and keep on watching this site in the future. We apologize to our users for the trouble. Hewlett-Packard Company Source: Hewlett-Packard Company Software Security Response Team cross reference id: SSRT2402 HP-UX - not vulnerable HP-MPE/ix - not vulnerable HP Tru64 UNIX - not vulnerable HP OpenVMS - not vulnerable HP NonStop Servers - not vulnerable To report potential security vulnerabilities in HP software, send an E-mail message to: mailto:security-alert@hp.com Lucent No Lucent products are known to be affected by this vulnerability, however we are still researching the issue and will update this statement as needed. Microsoft Corporation Microsoft has investigated these issues. The Microsoft SIP client implementation is not affected. NEC Corporation =================================================================== NEC vendor statement for VU#528719 =================================================================== sent on February 13, 2002 Server Products * EWS/UP 48 Series operating system * - is NOT vulnerable, because it does not support SIP. Router Products * IX 1000 / 2000 / 5000 Series * - is NOT vulnerable, because it does not support SIP. Other Network products * We continue to check our products which support SIP protocol. =================================================================== NETBSD NetBSD does not ship any implementation of SIP. NETfilter.org As the linux 2.4/2.5 netfilter implementation currently doesn't support connection tracking or NAT for the SIP protocol suite, we are not vulnerable to this bug. NetScreen NetScreen is not vulnerable to this issue. Network Appliance NetApp products are not affected by this vulnerability. Nokia Nokia IP Security Platforms based on IPSO, Nokis Small Office Solution platforms, Nokia VPN products and Nokia Message Protector platform do not initiate or terminate SIP based sessions. The mentioned Nokia products are not susceptible to this vulnerability Nortel Networks Nortel Networks is cooperating to the fullest extent with the CERT Coordination Center. All Nortel Networks products that use Session Initiation Protocol SIP) have been tested and all generally available products, with the following exceptions, have passed the test suite: Succession Communication Server 2000 and Succession Communication Server 2000 - Compact are impacted by the test suite only in configurations where SIP-T has been provisioned within the Communication Server; a software patch is expected to be available by the end of February. For further information about Nortel Networks products please contact Nortel Networks Global Network Support. North America: 1-800-4-NORTEL, or (1-800-466-7835) Europe, Middle East & Africa: 00800 8008 9009, or +44 (0) 870 907 9009 Contacts for other regions available at the Global Contact <http://www.nortelnetworks.com/help/contact/global/> web page. Novell Novell has no products implementing SIP. Secure Computing Corporation Neither Sidewinder nor Gauntlet implements SIP, so we do not need to be on the vendor list for this vulnerability. SecureWorx We hereby attest that SecureWorx Basilisk Gateway Security product suite (Firmware version 3.4.2 or later) is NOT VULNERABLE to the Session Initiation Protocol (SIP) Vulnerability VU#528719 as described in the OUSPG announcement (OUSPG#0106) received on Fri, 8 Nov 2002 10:17:11 -0500. Stonesoft Stonesoft's StoneGate high availability firewall and VPN product does not contain any code that handles SIP protocol. No versions of StoneGate are vulnerable. Symantec Symantec Corporation products are not vulnerable to this issue. Symantec does not implement the Session Initiation Protocol (SIP) in any of our products. Xerox Xerox is aware of this vulnerability and is currently assessing all products. This statement will be updated as new information becomes available. Appendix B. - References 1. http://www.ee.oulu.fi/research/ouspg/protos/ 2. http://www.kb.cert.org/vuls/id/528719 3. http://www.cert.org/tech_tips/denial_of_service.html 4. http://www.ietf.org/html.charters/sip-charter.html 5. RFC3261 - SIP: Session Initiation Protocol 6. RFC2327 - SDP: Session Description Protocol 7. RFC2279 - UTF-8, a transformation format of ISO 10646 8. Session Initiation Protocol Basic Call Flow Examples 9. Session Initiation Protocol Torture Test Messages, Draft _________________________________________________________________ The CERT Coordination Center thanks the Oulu University Secure Programming Group for reporting these vulnerabilities to us, for providing detailed technical analysis, and for assisting us in preparing this advisory. We would also like to acknowledge the "RedSkins" project of "MediaTeam Oulu" for their support of this research. _________________________________________________________________ Feedback on this document can be directed to the authors, Jason A. Rafail and Ian A. Finlay. ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-2003-06.html ______________________________________________________________________ CERT/CC Contact Information Email: cert(a)cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo(a)cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 2003 Carnegie Mellon University. Revision History Feb 21, 2003: Initial release *** END PGP VERIFIED MESSAGE ***

1 0

Support needed in LA (Downtown)
by Sven Engelhardt 21 Feb '03

21 Feb '03

Hello, can anyone provide a contact of a professional service company available in Downtown LA, I have a router there that needs to be packed up for shipment early next week. Please reply off-list. thanks in advance, Sven Engelhardt Manager Network Engineering -- Tiscali International Network phone: +49 6103 91 64 80 Robert Bosch Strasse 32 fax: +49 6103 91 64 64 D-63303 Dreieich / Germany e-mail: sven(a)tiscali.net

1 0

Staten Island refinery fire
by Kai Schlichting 21 Feb '03

21 Feb '03

News reports say that about 10:10am EST, a refinery (Mobile Port) at the channel between New Jersey and Staten Island caught fire due to a propane barge explosion: When I passed by the Verrezano Narrows bridge (on the other side of S.I., towards Brooklyn) at around 10:25am, there was a GIANT plume of smoke rising at least several miles into the air before being blown by the wind in south/south-eastern direction. www.news12.com and www.ny1.com are completely slashdotted right now, with www.cnn.com having slowed to a crawl.

1 0

Re: Homeland Security Alert System
by Martin Hannigan 21 Feb '03

21 Feb '03

On Thu, Feb 20, 2003 at 08:08:58PM -0500, Richard Irving wrote: > Yes. > > But, until elections 2004, the "FUD" field is hardcoded to "High". > > However, if there are changes to the -=actual=- dhs.gov status, > it sends out an automatic Amazon.Com order for > Hip Boots for all members of the list. > > Would you like to subscribe to the notification list ? [ snip ] > >Is anyone running an automated Terror Alert system that's > >real time with the DHS? Ok, that was interesting. :) The diving thing is my fun stuff. I'm actually working in Security. :) I was writing a little tool that scanned their page for the alert image name change, but that's subject to them making changes to their site and the images are multi layer graphics, etc. etc. I'm going to call them and see if they can offer a place to poll something simple that we can trip changes off in the NOC. If anyone does have some insight to anything they are doing, or a good contact number for the DHS webite, please ping me in email and I'll follow up if I find something or get them to do something. -M

5 4

RE: Homeland Security Alert System
by St. Clair, James 21 Feb '03

21 Feb '03

Martin, >From the NANOG perspective, the best place to tie your own alert system to nat'l threat levels is with the Telecomm ISAC, which is run out of the NCS. That is the 27/7/365 commander center for telecomm sector security. Bear in mind, a change in the HSAS may NOT be as a result of a specific threat to Telecomm, so get with the ISAC instead. Jim -----Original Message----- From: Martin Hannigan To: nanog(a)merit.edu Sent: 2/20/03 7:35 PM Subject: Homeland Security Alert System Is anyone running an automated Terror Alert system that's real time with the DHS? -M

1 0

The Cidr Report
by cidr-report＠potaroo.net 21 Feb '03

21 Feb '03

This report has been generated at Fri Feb 21 21:46:27 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-02-03 119071 85433 15-02-03 119072 85385 16-02-03 118946 85348 17-02-03 118884 85299 18-02-03 118939 85352 19-02-03 119053 85338 20-02-03 119156 85478 21-02-03 119400 85502 AS Summary 14614 Number of ASes in routing system 5749 Number of ASes announcing only one prefix 1577 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Possible Bogus Routes 10.0.0.0/8 AS4637 REACH Reach Network Border AS 192.168.0.0/16 AS4637 REACH Reach Network Border AS Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Feb03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 119491 85471 34020 28.5% All ASes AS3908 1062 565 497 46.8% SUPERNETASBLK SuperNet, Inc. AS18566 482 6 476 98.8% COVAD Covad Communications AS701 1577 1145 432 27.4% ALTERNET-AS UUNET Technologies, Inc. AS4151 524 92 432 82.4% USDA-1 USDA AS7018 1427 1034 393 27.5% ATT-INTERNET4 AT&T WorldNet Services AS4323 529 170 359 67.9% TW-COMM Time Warner Communications, Inc. AS7843 569 234 335 58.9% ADELPHIA-AS Adelphia Corp. AS7046 578 246 332 57.4% UUNET-CUSTOMER UUNET Technologies, Inc. AS6197 478 158 320 66.9% BATI-ATL BellSouth Network Solutions, Inc AS1221 1119 821 298 26.6% ASN-TELSTRA Telstra Pty Ltd AS4355 402 120 282 70.1% ERMS-EARTHLNK EARTHLINK, INC AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS1239 960 680 280 29.2% SPRINTLINK Sprint AS705 447 194 253 56.6% ASN-ALTERNET UUNET Technologies, Inc. AS4814 261 15 246 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS1 666 435 231 34.7% GNTY-1 Genuity AS6347 330 101 229 69.4% DIAMOND SAVVIS Communications Corporation AS6198 433 204 229 52.9% BATI-MIA BellSouth Network Solutions, Inc AS22291 243 32 211 86.8% CHARTER-LA Charter Communications AS17676 227 26 201 88.5% GIGAINFRA XTAGE CORPORATION AS690 498 308 190 38.2% MERIT-AS-27 Merit Network Inc. AS209 523 335 188 35.9% ASN-QWEST Qwest AS4134 304 117 187 61.5% CHINANET-BACKBONE No.31,Jin-rong Street AS2386 443 263 180 40.6% INS-AS AT&T Data Communications Services AS2048 260 87 173 66.5% LANET-1 State of Louisiana AS852 604 445 159 26.3% ASN852 Telus Advanced Communications AS7303 240 90 150 62.5% AR-TAST-LACNIC Telecom Argentina Stet-France Telecom S.A. AS17557 340 190 150 44.1% PKTELECOM-AS-AP Pakistan Telecom AS22773 181 31 150 82.9% CCINET-2 Cox Communications Inc. Atlanta AS6140 283 137 146 51.6% IMPSAT-USA ImpSat Total 16285 8295 7990 49.1% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: [Re: M$SQL cleanup incentives]
by Joshua Smith 21 Feb '03

21 Feb '03

Iljitsch van Beijnum <iljitsch(a)muada.com> wrote: > > On Thu, 20 Feb 2003, William Allen Simpson wrote: > > > Worse, it only takes 1 infected host to re-infect the entire net in > > about 10 minutes. So, the entire 'net has to cooperate, or we'll see > > continual re-infection. > > Only if people didn't fix their servers. And if they didn't, this > "reverse" denial of service attack is a good reminder. what was that one worm from a year or two ago that was eliminated from the net, oh yeah, code red......if they didn't fix themselves the first round, what makes you think they will fix it the second time, or the third... > > > Unfortunately, this is a cost that prevents pain to others, rather > > than self-inflicted pain. Another pollution of the commons issue. > > Seems to me that filtering is no longer necessary unless you have reason > to believe your customers are going to install new vulnerable boxes or > vulnerable software on existing boxes AND their pipe to you is so big > the excess traffic is going to hurt you more than them. > the reason is that ms sql and msde are vulnerable out of the box, and since ms is such a popular o/s, you can be reasonably certain that new vulnerable boxes are installed everyday. and while a vulnerable box on a small pipe may slow the initial growth, how long would it take to find another vulnerable box on a big pipe? i still get 8K plus hits against my acls per day for udp/1434...(75 in the time it took to write this email) joshua "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

3 2

Re: scripts to map IP to AS?
by Stephen Gill 21 Feb '03

21 Feb '03

Hi Johannes, ] > Anybody have a pointer to scripts to map IP to AS? ] Grab a routing table snapshot from the routeviews archive and run it ] through parse_bgp_dump from CAIDA's CoralReef package. Then use ] CAIDA::ASFinder or Net::Patricia to do the lookups. In fact I have 2 scripts to do just this. - Script #1 uses a route-server for a smallish list of IPs. - Script #2 uses the method listed above and pipes IPs into the CAIDA lookup tree of a BGP table offline. Once you've installed CoralReef it's really not much more work to get the customization you need for lookups. Contact me off-list if you're interested in either one. Cheers, -- steve

1 0

Homeland Security Alert System
by Martin Hannigan 21 Feb '03

21 Feb '03

Is anyone running an automated Terror Alert system that's real time with the DHS? -M

2 1

Blocked by msn.com MX, contact for MSN.COM postmaster ?
by Miquel van Smoorenburg 20 Feb '03

20 Feb '03

I found out that our outgoing SMTP servers have been blocked by the msn.com MXes. In a nasty way, too -- no SMTP error, the TCP connection is simply closed by them immidiately after establishing it. We're not listed on any RBL/DNSBL and have an active abuse desk. I mailed postmaster(a)msn.com, msnhst(a)msn.com, noc(a)microsoft.com, but didn't get a reply from any of them. Does anyone here know who to talk to ? Thanks, Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams.

5 4