Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) In Defense Of Ascend...

On 18 Mar 1998 tqbf@secnet.com wrote:

> >                b) Why did they not send (gasp!) an e-mail, and 
> >                   copy not only tech support, but also some 
> >                   Ascend execs?  
> 
> Why WOULD we send a security advisory to Ascend execs? Why would a company
> make it that difficult to contact them regarding security concerns?

Good point.

> >        If the SNMP write community is guessed for ANY device,
> >        the guesser can wreck all sorts of havoc with that
> >        device.  No startling news here.        
> 
> You are wrong about this. The problem with Ascend (and it is a problem,
> and it is NOT a general problem with all routers) is twofold:
> 
> 	A.) SNMP "write" is ENABLED BY DEFAULT with a WELL-KNOWN
>  	    DEFAULT COMMUNITY.
> 
> 	B.) SNMP "write" access allows an attacker to obtain the
> 	    PLAINTEXT PASSWORDS FOR THE BOX.
> 
> Can you do that on a Cisco?

No, you can't with a cisco.  However, anyone who had half a brain and
about 15 minutes could have breezed through the SEC - Security supplement
part of their manual and read about what needed to be done to SNMP.  I
agree it is somewhat of a flaw to turn on SNMP by default, but not taking
the time to read the documentation, especially a section labeled Security
Supplement shows a lot more user error than error on Ascend's part.  

The fact that this security advisory is pretty much copied form page
1-5 of the security supplement is somewhat sad, and makes me wonder if
people actually take the time to read documentation.

Here's what Ascend had to say about it in the manual I have dated 1996:

"Title: Changing SNMP read-write community strings"

"When the Ascend MAX is shipped from the factory, it has a default
read-write community string of 'write.'"

"NOTE: The MAX supports TFTP loading and saving of it's system
configuration using SNMP SET commands.  The configuration file saved via
TFTP contains all system passwords.  For this reason, we strongly
recommend that you change the default write community string as one of
your first steps in configuring the system."

I respect the work SNI has done (Balista is a great tool) and that of
Rootshell.com and Kit Knox.  But security advisories, especially the kind
like this that create quite a stir in the news channels, should NEVER be
used in place of reading the manual.  

I too have reported a reproducable bug in Ascend software to bugtraq, but
only after reading the manual to make sure I wasn't going to look like an
idiot for going over something that had been adequately covered in the
docs.  For the record, the bug worked even with the precautions and
switches talked about in the manual.

> >        But what it does NOT do is suggest that the reader run out
> >        and buy products from SNI, which may have been the only
> >        way to prevent SNI from ambushing Ascend on this issue.        
> 
> >        SNI's actions amount to simple extortion.  At least Ascend,
> 
> You are suggesting that we are extorting from Ascend. That is absolutely
> rediculous; the claims you're making aren't making Ascend look any better.

I think the fact that Ascend acknowledged this risk in their 1996
documentation shows that it's all a matter of what you read.  Someone who
reads Bugtraq and doesn't read their documentation is starting from the
wrong spot as far as security goes, and this does little to encourage any
vendor to do their own security testing when no one reads it anyway.  Any
vendor willing to add their own security supplement isn't all bad, and I
recommend everyone on this list take the 15 minutes it takes to read it if
they haven't.

> SNI has been responsible for no less than 25 OTHER security advisories,
> detailing problems as severe or more severe than this one. Organizations
> that have been directly impacted by our advisories include
> Livingston/Lucent, Microsoft, Solaris, and Checkpoint. Not one of these
> companies has brought legal action against us for "extortion", nor have
> they publically decried our work. Perhaps you were unaware of this, and
> figured this advisory was us singling out Ascend? 
> 
> Why didn't that happen here? Because we found it extremely difficult to
> find a contact at Ascend. 

Hehe... welcome to the club.  I'd like to be the first to officially apply
for the job of Ascend Security Coordinator. :)

> It is possible that my organization has more experience finding and
> publishing security holes than any other organization on the planet. We
> take responsible distribution of security information extremely seriously.
> We deal with CERT, and with FIRST (do you know what FIRST is? And you
> still feel qualified to discuss this?). We /always/ contact vendors prior
> to releasing information. 
>
> What we do not do is blindly send e-mail to CERT and to random addresses
> at the vendor saying "look at this new hole that you have no patch for".
> We call CERT to obtain a vendor contact (CERT has no Ascend vendor
> contact). We call the vendor to locate their security contact and obtain a
> PGP key for transmitting the information.
> 
> We were unable to do this, here, for reasons I have already explained.

I think that's the most responsible actions anyone could have taken, if
this hadn't already been addressed 2 years ago.

> No, it was a security advisory.

Exactly.  When the Ascendkill2.c program came out as well (btw, an
excellent discovery by Kit), most of us had filters on our edge
routers and/or Ascend Equipment before the exploit was widely available,
largely because of that advisory.  I got the first one from this list, not
Bugtraq.

Joe Shaw - jshaw@insync.net
Devil's Advocate and NetAdmin - Insync Internet Services
All misspellings are intentional and caused by my quest for knowledge and
lack of sleep.

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
Follow-Ups: References: