full-disclosure - Re: Cisco Security Advisory: Multiple Vulnerabilities in Cisco Clean Access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 12 Jan 2007 13:53:12 +0000
From: Damir Rajnovic <gaus@...co.com>
To: Mark Senior <senatorfrog@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, psirt@...co.com
Subject: Re: Cisco Security Advisory: Multiple
	Vulnerabilities in Cisco Clean Access

Hi Mark,

On Tue, Jan 09, 2007 at 12:40:47PM -0700, Mark Senior wrote:
> Perhaps you can't comment, which I respect, but I wonder - is there a
> general Cisco policy on vulnerability announcements being short on technical
> detail like this?  This advisory seemed pretty much standard for advisories
> coming from Cisco, which is to say that the reader is often left to draw
> inferences, which are not always correct (though perhaps mine were more
> incorrect than the average reader's).

The policy is to strive to provide as much details as possible for 
administrators to determine their exposure but, at the same time, not to
make too easy for bad guys to exploit vulnerability. Again, the emphasis
is on exposure which does not necessary means that all technical details
are necessary. 

Sounds easy in theory but not always easy in practice. Therefore we
appreciate feedback on how are we doing.

> Just to make sure I'm understanding this - would the attacker need the
> shared secret in order to get the CAS to do anything - i.e. are we talking
> about a compromise of (the shared secret from) one Clean Access box in an
> admin domain being expandable to all the Clean Access boxes in that admin
> domain?  Or, is the ability to carry on a TCP conversation sufficient, no
> prior access to a shared secret required?

Yes, the attacker must know the shared secret. Due to the vulnerability
the shared secret is the same for all affected devices. So, if you have
affected device then, in a way, you have and know it.

> In practice, I suspect that if the attacker has downloaded the hashes, the
> damage is done.  The best you can realistically expect of typical ops groups
> is that they will make the attacker wait a week or two, instead of half an
> hour.  If you're lucky, you might realize that someone has the hashes and
> change all the passwords, and pray your folks didn't just increment the
> number at the end of their passwords like usual.
> 
> Not that that's Cisco's problem...

We can encourage customers not to do that by enforcing rules when they
change passwords. So we can help :)

Regards,

Gaus

==============
Damir Rajnovic <psirt@...co.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution? 

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/