Re: Warning: Cisco RW community backdoor.
It appears more than one vendor shared the same SNMP library (or SNMP programmer). Folks have sent me evidence at least two other vendor's equipment has similar responses to the same SNMP community string ILMI. However, there are other non-related SNMP issues. Many SNMP implementations included the default community strings "public" and "private". If the operator doesn't change them, the defaults may still work. The other common SNMP implementation issue is if no community string is specified, the SNMP agent accepts any community string. If you are checking your network, I'd suggest checking for all three possibilities.
On 26 Feb 2001, Sean Donelan wrote:
It appears more than one vendor shared the same SNMP library (or SNMP programmer). Folks have sent me evidence at least two other vendor's equipment has similar responses to the same SNMP community string ILMI.
However, there are other non-related SNMP issues. Many SNMP implementations included the default community strings "public" and "private". If the operator doesn't change them, the defaults may still work. The other common SNMP implementation issue is if no community string is specified, the SNMP agent accepts any community string.
If you are checking your network, I'd suggest checking for all three possibilities.
IMHO, if no communities are supplied, the SNMP daemon should not respond at all. While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco. --- John Fraizer EnterZone, Inc
On Mon, Feb 26, 2001 at 11:06:42PM -0500, John Fraizer wrote:
On 26 Feb 2001, Sean Donelan wrote:
It appears more than one vendor shared the same SNMP library (or SNMP programmer). Folks have sent me evidence at least two other vendor's equipment has similar responses to the same SNMP community string ILMI.
However, there are other non-related SNMP issues. Many SNMP implementations included the default community strings "public" and "private". If the operator doesn't change them, the defaults may still work. The other common SNMP implementation issue is if no community string is specified, the SNMP agent accepts any community string.
If you are checking your network, I'd suggest checking for all three possibilities.
IMHO, if no communities are supplied, the SNMP daemon should not respond at all.
While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco.
Please, stop the damn FUD, how do you know it wasn't accidentally left in by a programmer doing debugging? I bet you assume all buffer overflows are purposely put in also, eh? Sure. I expect it to cut back on your confidence in Cisco IOS, but also, what's this noise about code? Do you happen to have a hold on IOS source code or something that you personally audit?
--- John Fraizer EnterZone, Inc
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
On Mon, 26 Feb 2001, Omachonu Ogali wrote:
Please, stop the damn FUD, how do you know it wasn't accidentally left in by a programmer doing debugging? I bet you assume all buffer overflows are purposely put in also, eh? Sure. I expect it to cut back on your confidence in Cisco IOS, but also, what's this noise about code? Do you happen to have a hold on IOS source code or something that you personally audit?
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
I expect an organization as large as Cisco, with a QA section as large as Ciscos to NOT leave things accidentally in code. Buffer overflows, while APIMA, are accidental in nature, sometimes brought on by incompetence, more often brought on my inexperience. As for having IOS source, no, I don't. I won't even say that if I did have access to the source I would have found it. I do know that if the source was open, it would have been found much earlier and I will say that every decent programmer that has put things in code for degugging COMMENTS such code in a manner that it is easy to grep and remove. In Ciscos defence, it appears that the ILMI community is there for ATM functionality. It would have been nice for them to have noticed this "feature" in the SNMP implementation and caused the code to add it to the config where it was PLAINLY visible. Basically, someone, perhaps many people, knew about this issue and did not act on it. This is not IMHO the proper way to treat a security issue. It has already been stated that the damage caused by this "feature" is limited. _ANY_ unauthorized changes to router configs is a VERY BAD thing though and as such, this is a VERY BAD thing. I appreciate your direct approach. In the future, I would also appreciate your not cursing me. I don't know you. You don't know me. Lets be professional, OK? If you choose to reply, please do so off-list. --- John Fraizer EnterZone, Inc
While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco.
Do a "show snmp group" from an enabled console prompt. It does show. DS
On Mon, 26 Feb 2001, David Schwartz wrote:
While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco.
Do a "show snmp group" from an enabled console prompt. It does show.
DS
"sho run" does not show it however. It shows unconfigured interfaces. It doesn't show Cisco backdoors though. Backdoor BAD. Cisco BAD. Beer GOOD! --- John Fraizer EnterZone, Inc
not on a 3640 running 12.0(1)T. (C3640-IS56I-M) Does return info though via a SNMP walk. No ATM interfaces either. doing the below on a 3662 running 12.1(3a)T1 (C3660-IS-M) with an ATM interface (4 port T1 IMA) shows another one "cable-docsis" cable-docsis faithfully pukes up all kinds of info try walking ".1.3.6.1" "ILMI" pukes. Going to be a long night .... Eric At 08:42 PM 2/26/01 -0800, David Schwartz wrote:
While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco.
Do a "show snmp group" from an enabled console prompt. It does show.
DS
========================================================================== Eric Germann Inacom Info Systems egermann@inacomlima.com Lima, OH 45801 Ph: 419 331 9050 ICQ: 41927048 Fax: 603 825 5893 "It is so easy to miss pretty trivial solutions to problems deemed complicated. The goal of a scientist is to find an interesting problem, and live off it for a while. The goal of an engineer is to evade interesting problems :)" -- Vadim Antonov <avg@kotovnik.com> on NANOG
On Mon, 26 Feb 2001, David Schwartz wrote:
While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco.
Do a "show snmp group" from an enabled console prompt. It does show.
On some routers that have the backdoor, "show snmp group" isn't even a valid command. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 27 Feb 2001 jlewis@lewis.org wrote:
On Mon, 26 Feb 2001, David Schwartz wrote:
Do a "show snmp group" from an enabled console prompt. It does show.
On some routers that have the backdoor, "show snmp group" isn't even a valid command.
On 12.0(12) 'sh snmp group' is invalid. On 12.1(6) it works. -Dan
Yes, the info is due to be made public today. We have been making personal calls to numerous ISPs as early of 2/20. Regards, Chris Hallman NSE NSP North Florida 3660 Maguire Blvd., Suite 200 Orlando, Fl. 32803 407-897-8744 office 407-903-7591 off-site office 800-365-4578 pager email: mailto:challman@cisco.com -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of John Fraizer Sent: Monday, February 26, 2001 11:07 PM To: Sean Donelan Cc: nanog@merit.edu Subject: Re: Warning: Cisco RW community backdoor. On 26 Feb 2001, Sean Donelan wrote:
It appears more than one vendor shared the same SNMP library (or SNMP programmer). Folks have sent me evidence at least two other vendor's equipment has similar responses to the same SNMP community string ILMI.
However, there are other non-related SNMP issues. Many SNMP implementations included the default community strings "public" and "private". If the operator doesn't change them, the defaults may still work. The other common SNMP implementation issue is if no community string is specified, the SNMP agent accepts any community string.
If you are checking your network, I'd suggest checking for all three possibilities.
IMHO, if no communities are supplied, the SNMP daemon should not respond at all. While I agree that "public" and "private" are "wellknowns," in most implementations, they at least show up in the code. Cisco chose to hide this one where it would not show up in the code. That IMHO is a very bad thing and does bad things to my confidence level in Cisco. --- John Fraizer EnterZone, Inc
participants (8)
-
Chris Hallman -
Dan Hollis -
David Schwartz -
Eric Germann -
jlewis＠lewis.org -
John Fraizer -
Omachonu Ogali -
Sean Donelan