RE: MS09-048 includes fixes for TCP/IP implementation issues reported more than a year ago
b...@home.com wrote: > Does anyone have a reference pointing to the original announcement on > here for these vulnerabilities? I would like to research them > regarding the potential continued vulnerability of XP, since MS did > not provide a patch for XP products. CERT-FI was the coordinator for these vulnerabilities, and the CERT-FI advisory (referenced in the previous message from Juha-Matti Laurio) is the best overall announcement. Jim -- James N. Duncan, CISSP Manager, Juniper Networks Security Incident Response Team (Juniper SIRT) E-mail: jdun...@juniper.net Mobile: +1 919 608 0748 PGP key fingerprint: E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821
Re: The Trivial Cisco IP Phones Compromise
-BEGIN PGP SIGNED MESSAGE- Ofir Arkin writes: > The referred paper lists several severe vulnerabilities with Cisco > systems' SIP-based IP Phone 7960 and its supporting environment. These > vulnerabilities lead to: complete control of a user's credentials; total > subversion of a user's settings for the IP Telephony network, and the > ability to subvert the entire IP Telephony environment. Malicious access > to a user's credentials could enable "Call Hijacking", "Registration > Hijacking", "Call Tracking", and other voice related attacks. The > vulnerabilities exist with any deployment scenario, but this paper deals > specifically with large scale deployments as recommended by Cisco. > > A PDF version of the paper is available from: > >http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf This message contains Cisco responses to the issues described in the white paper referenced above. 1. Access to the Cisco 7960 IP phone: A Cisco model 7960 IP phone running a SIP-compatible image has a password that can be set by the IP phone administrator. The default password is "cisco" if the password has not been set to some other value. Cisco strongly recommends setting the password to something other than the default. The key sequence of "**#" is not intended as a password. It is clearly and publicly documented in many places within Cisco's product literature. The key sequence is solely intended to protect against casual or accidental changes to the phone's configuration. 2. Abuse of the TFTP service: Although the author is correct that various attacks against the TFTP service can be mounted, there are several measures that can be employed by the IP phone administrator and the organization to mitigate the risk. If the network is firewalled properly so that the different network segments are compartmentalized as the Cisco SAFE white papers recommend, then the TFTP server will only respond to legitimate requests. The TFTP server does not need to reside on the same network segment as the IP phone. If RFC 1918 addressing is employed for the IP phones and proper ingress/egress filtering is in place as recommended, then any such attack is highly unlikely to succeed from outside the enterprise VoIP network, even with the use of UDP. Access to the physical networks from within the enterprise may make it easier to succeed with the attack, but if the VLANs are properly protected and MAC addresses monitored per the SAFE documents -- for example, by using arpwatch or arpsnmp -- then an attack may be detected by the IP phone administrators. 3. Manual modification of the IP phone configuration: At some level, successful attacks would require such physical access to the local network segment or the IP phone that the attacker could simply use the IP phone itself to commit toll fraud and some of the other improper acts listed in the paper. Physical access to network hardware is a long-standing, well-known problem in the industry. This is an especially important consideration for IP phones located in public or semi-public areas such as building lobbies. The IP phone admistrator should use all available mechanisms to secure any IP phones that are exposed to unauthorized manipulation. As always, Cisco is interested in protecting our customers' networks and is continually striving to improve the security of our products. We appreciate the seventeen days of advance notice we received from the author and his willingness to discuss the issue with us. We are unaware of any confirmed incidents of malicious exploitation of the issues in the author's paper and ask that any such exploitation be reported to the Cisco PSIRT, [EMAIL PROTECTED], as soon as possible. == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [EMAIL PROTECTED] Phone(Direct/FAX): +1 919 392 6209 -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQB1AwUBPYoyi95wH2yjJs+JAQFDxAL8DkZSBdl1BRXgUfqqqw0E2E1eIyM/guy5 rdNeEZEBiq7lSbqRwW4c+whG+3TKRKo8aV9rX2JkTWkwJ6JHxWeOKY5xHh1eGeiK kuyGHbGy1Sp+5Jr9Vol0nqBk3igYFxhi =/Mz6 -END PGP SIGNATURE- == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [EMAIL PROTECTED] Phone(Direct/FAX): +1 919 392 6209
Re: Cisco TFTPD 1.1 Vulerablity
Siberian writes: > [Sentry Research Labs - ID0201061701] > (c) 2001 by www.sentry-labs.com > [...] > Topic: > Security Bug in CISCO TFTPD server 1.1 > > Vendor Status: > Informed (06/17/01) Just for the record, I checked with my teammates and can't find any record that you contacted the Cisco Product Security Incident Response Team (PSIRT). We're the group that handles vulnerabilities in all Cisco products and we're easily reachable. It would've been more helpful if you had contacted us privately beforehand and given us an opportunity to make fixed code available before you posted the vulnerability. If you did contact someone at Cisco, could you let us know who that was so we can follow up with that person? We'd like to make sure the process works as best as it can. If I am in error, please correct me. I have not yet validated the vulnerability, but will look into it as soon as possible. Regardless of the path the report took to get to us, we appreciate the time and effort that goes into such reporting. Ultimately, everybody benefits from full disclosure of product security vulnerabilities. Thanks. Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <[EMAIL PROTECTED]> Phone(Direct/FAX): +1 919 392 6209
Re: Cisco HTTP possible bug:
[EMAIL PROTECTED] writes: > Summary of responces in this thread: > > Model IOS version Confirmed > - --- -- > C2924XL - No > C2900X11.2(8)SA1 No > 7206 12.1(1a)T1 No > 7206 12.0(9)SYes > 5300 12.1(1.3)T No > 4000 11.0No > 3640 12.0(7)TYes > 2621 12.0(5)T1 Yes > 2514 11.2(17)Yes > 2501 12.0-4.TYes > 2501 12.0(8) Yes Thanks. This is helpful. If it's not too much trouble, it would be particularly useful if we knew the image names for each test, e.g., c7200-inu-mz.111-24, since that tells us a lot more about the content of the image and the platforms it runs on. The image name is available in the output of a "show ver" in enable mode, and it would mean adding an extra column to your table. For example, I'm very curious about the 7206 running 12.0(9)S and the 5300 running 12.1(1.3)T. From inspecting the code, I believe they should be vulnerable, *if* they're running the affected image. But I can't tell that for certain without the image name. Thanks again. Jim -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <[EMAIL PROTECTED]> Phone(Direct/FAX): +1 919 392 6209
Re: Cisco HTTP possible bug:
-BEGIN PGP SIGNED MESSAGE- Keith Woodworth writes: > If you have: > > ip http server > > in your running config (not a great idea to have on a live router IMO) on > your router and you do: > > http:///%% > > it crashes said router. I confirmed this on my 1005 running 11.1(24) and > another fellow said it worked on his 2621 and 2524. Though he didnt give > IOS versions. > > Had to power cycle the 1005 to get it to work again. Couldnt reach it with > telnet, http or via console cable. > > Just an observation. Yep, it's a defect. We confirmed it and the development engineers are working on it right now. We will post a formal advisory as soon as have a reasonably complete fixed version section. A workaround is to turn off management via HTTP by configuring: no ip http server and saving the configuration so that it is not enabled at the next reload. It would have been *really* nice to receive a direct notification about this problem instead of posting it publicly. If Cisco didn't have a response team or we failed to respond, I could understand posting it directly to the list. All of the members of the Cisco Systems Product Security Incident Response Team endorse the concept of full disclosure forums like BUGTRAQ -- without them, you have no effective way to force the vendor to attend to security vulnerabilities -- but simple politeness should encourage some attempt to contact the responsible vendor before blasting the vulnerability all over cyberspace. We will follow up with any additional information as warranted. Please send any queries, comments, etc., to [EMAIL PROTECTED] and not directly to me. Thanks. Jim - -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <[EMAIL PROTECTED]> Phone(Direct/FAX): +1 919 392 6209 -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQB1AwUBOQjzw95wH2yjJs+JAQE8BQMAqvPz6u0hzrLUfHVgmi/z1Cj0PM7a8Kxb ARnZCYuX5DOX7Ly4jf92GIRxp1w16Z/01wX+4XjrTHJvfOGMfgUODBYNRf4K8T8G SftFN/PTPwtesOhXLkQo8FCWiDyw/P1g =AbGZ -END PGP SIGNATURE-
Re: Cisco NAT DoS (VD#1)
Blue Boar writes: > A Cisco security guy posted a message to the list asking that they be given > advanced warning before posts about Cisco bugs are allowed through. I > explained that the nature of the list is vulnerabilities that are still in > development, but that I would be happy to make sure they got a copy of any > Cisco-related problems to the e-mail address(es) of their choice. This was > all started by this message, so clearly Cisco is aware of the issue. As > far as I know, they haven't done anything about it. > > There was no further comment on this particular issue, so I'm posting it > for wider dissemination. > > BB > > From: > http://securityfocus.com/templates/archive.pike?list=82&date=1999-09-8&msg=37 > [EMAIL PROTECTED] > > >To: Exploit-Dev > >Subject: Cute little Cisco NAT DoS > >Date: Fri Sep 10 1999 17:36:23 > >Author: Blue Boar > > > > > >I was doing some research the other day about Network Address Translation > >(NAT) on a cisco box. The configuration I was using when I found this > >problem was NAT overload. I had an inside net, 192.168.0, and a Windows PC > >sitting at 192.168.0.2. The outside interface was another ethernet (the > >were both FastEthernet, actually.. this was a 2621.) > > > >I was playing with an FTP client on the 192.168.0.2 machine, watching the > >translation tables with the sho ip nat trans command. I was trying to see > >if I could get the Cisco to open arbitrary holes to other hosts by sending > >manual PORT commands. I didn't get that to work, but I found a cute little > >problem. > > > >At the time, I was telnetted to the router from the outside, which is how I > >was watching the translations table. From the inside, I issued the command > >PORT 192,168,0,2,0,23 (I was listening on port 23 with netcat). > > > >My telnet session to the outside died. > > > >I was a bit puzzled. I telnetted back right away, and that worked. I > >repeated the test a few times to convince myself it was doing what I > >thought it was. Whenever I issues that PORT command, my telnet connection > >died. > > > >I have to assume that since the NAT config I used uses the router's own > >(outside) IP address that the NAT is interfering with the router's own > >listening ports. Make me wonder what else could be done with this... > > > >BB Despite the late response, we _have_ been working on this problem. We have confirmed the behavior as documented by Blue Boar. The section of code responsible for the behavior has been identified and a fix is in development. We have considered workarounds, but have not yet defined any that are suitable for public dissemination and discussion. Because of the amount of time that has passed, we (the Cisco Product Security Incident Response Team and other Cisco Customer Advocacy staff) felt that a status report and acknowledgement were necessary even though we do not have a fix ready for distribution at this time. As soon as we have something else useful to say, we will post a follow-up message. In the meantime, sending messages to us asking about this problem will very likely slow down our efforts to produce a remedy. As always, we ask that you send notices of security vulnerabilities in any Cisco product to the Cisco PSIRT at <[EMAIL PROTECTED]>. Advance notice would be nice, but is not required -- any notice is preferred over the risk of not hearing about the problem at all, including incomplete schemes that may or may not constitute actual product vulnerabilities. More PSIRT information is available at the URL in my signature block below. The messages and events that have lead up to this response have generated a lot of thoughtful discussion internal to the team about how to improve our handling of cases like this. We are working on that, too, but we won't be posting a security advisory about it. Instead, we hope that you will notice improvements over time. This message is one such attempt. Thanks. Jim -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <[EMAIL PROTECTED]> Phone(Direct/FAX): +1 919 392 6209
Re: CISCO and nestea.
Vit Andrusevich <[EMAIL PROTECTED]> writes: > Hello. > > Sorry if it was known before.. > > My CISCO 2600 with NAT IOS 12.0 crashes when I try to run nestea DoS attack > against one of my servers. > > The victim of nestea attack was one of my NT servers which was "under NAT". Basil V. Dolmatov <[EMAIL PROTECTED]> writes: > 12.0(what?) > > It was a bug in IOS several months ago, which was fixed already. > > Upgrade your IOS. Basil is correct. Thanks. Vit, just to make sure that is the correct answer, could you please send us the output from a "show tech" command? Thanks. There's always a chance you may have uncovered a new problem. As always, the best place to send questions and reports about possible vulnerabilities in any Cisco product is to the Cisco Product Security Incident Response Team, <[EMAIL PROTECTED]>. You can read about us at <http://www.cisco.com/warp/public/707/sec_incident_response.shtml>. Check with us first to avoid wasting bandwidth by posting unnecessary or inaccurate messages to critical mailing lists like BUGTRAQ. We provide 24x7 response to reports of vulnerabilities in Cisco products and to requests to assist customers with security incidents. It's also faster to send us e-mail directly -- BUGTRAQ is an incredibly useful list, but as an e-mail gateway it's not as efficient as e-mail addressed directly to us at <[EMAIL PROTECTED]>. :-) The Cisco Product Security Incident Response Team is affiliated with the Forum of Incident Response and Security Teams, <http://www.first.org/>. Thanks. Jim -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.