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 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=82date=1999-09-8msg=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
