<div>Hello Gaus</div>
<div> </div>
<div>Thanks for the response, it was quite helpful. I have a few questions & comments inline below.</div>
<div> </div>
<div>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).
</div>
<div> </div>
<div>Regards</div>
<div>Mark</div>
<div><br> </div>
<div><span class="gmail_quote">On 1/9/07, <b class="gmail_sendername">Damir Rajnovic</b> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello Mark,<br><br>Sorry for this belated response.<br><br>On Thu, Jan 04, 2007 at 11:59:34AM -0700, Mark Senior wrote:
<br>> Well, that sure was informative.<br>><br>> My questions to what the advisory means are below. Can anyone answer or<br>> correct this at all?<br><br>I am the person who wrote this advisory so maybe I can help here.
<br><br>> >Unchangeable Shared Secret<br>> >+-------------------------<br>> ><br>> >In order for Cisco Clean Access Manager (CAM) to authenticate to a<br>> >Cisco Clean Access Server (CAS), both CAM and CAS must have the same
<br>> >shared secret. The shared secret is configured during the initial CAM<br>> >and CAS setup. Due to this vulnerability the shared secret can not be<br>> >properly set nor be changed, and it will be the same across all
<br>> >affected devices. In order to exploit this vulnerability the<br>> >adversary must be able to establish a TCP connection to CAS.<br>><br>><br>> So, other than making a TCP connection to the box, what does the attacker
<br>> need? Do they need to get the shared secret off some other box in the same<br>> administrative domain? How is that shared secret protected, is it stored<br>> anywhere else an attacker might have easier access to (
e.g. on Clean<br>> Access-managed clients, on the 'readable snapshots' below)?<br><br>Being able to establish a TCP connection is the first requirement. After<br>doing so the attacker will be able to talk to CAS and instruct it to do
<br>whatever (s)he wants it to do. Just finishing three way handshake is not<br>sufficent to exploit this.</blockquote>
<div> </div>
<div>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?
</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I do not have answer if this is also stored in clients. Will verify and<br>get back to you later.<br><br>>
<br>> Unchangeable Shared Secret<br>> >+-------------------------<br>> ><br>> >Successful exploitation of the vulnerability may enable a malicious<br>> >user to effectively take administrative control of a CAS. After that,
<br>> >every aspect of CAS can be changed including its configuration and<br>> >setup.<br>><br>><br>> For "may", presumably we should read "would, unless the he suddenly fell<br>> asleep at the last minute"? Or are there some additional barriers to taking
<br>> advantage of a successful exploit?<br><br>It is "may" because if you run software release 3.6.1 then your passwords<br>are encrypted but you are still affected by both of these issues. On the<br>other hand, if you are using version
3.5.8 then your passwords are not<br>stored encrypted.<br><br><br>> >Readable Snapshots<br>> >+-----------------<br>> ><br>> >The snapshot contains sensitive information that can aide in the<br>> >attempts, or be used to compromise the CAM. Among other things, the
<br>> >snapshot can contain passwords in cleartext. Starting with the<br>> >release 3.6.0, passwords are no longer stored in cleartext in the<br>> >snapshot files.<br>><br>><br>> So, I read this to mean, the snapshot files are still downloadable without
<br>> authentication, still have easily guessable names, and still contain<br><br>Not quite. You can not read snapshot files without authentication if you<br>are running fixed software (3.5.10 and 3.6.2 and onwards).</blockquote>
<div> </div>
<div>Ah, that makes more sense! I'd missed the fact that 3.6.1 and 3.6.2 were both mentioned.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> sensitive information that can aid in an attack (what sensitive<br>> information?), but now the attacker has password hashes against which he has
<br><br>Information like web server version can aide in an attempt to compromise<br>a device.<br><br>> to do a three hour offline brute force, or perhaps a twenty second rainbow<br>> table lookup, rather than getting the plaintext straight off.
<br><br>You are assuming that we are using the same format as LM. If we would do<br>so, then you would be correct that the hash can be cracked in few seconds<br>by using rainbow tables. We do not use LM format.</blockquote>
<div> </div>
<div>Strictly speaking, I'm only assuming that the hashes are in a format for which rainbowtables exist or could be pregenerated - essentially, anything without a salt (<a href="http://rainbowtables.com">rainbowtables.com
</a> has an nice collection).</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">It is alwasy possible to crack the password using brute force but we hope<br>that users are using passwords sufficently long to make this process too
<br>time consuming.</blockquote>
<div> </div>
<div>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.
</div>
<div> </div>
<div>Not that that's Cisco's problem...</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Regards,<br><br>Gaus<br><br><br>==============<br>Damir Rajnovic <<a href="mailto:psirt@cisco.com">psirt@cisco.com
</a>>, PSIRT Incident Manager, Cisco Systems<br><<a href="http://www.cisco.com/go/psirt">http://www.cisco.com/go/psirt</a>> Telephone: +44 7715 546 033<br>200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
<br>==============<br>There are no insolvable problems.<br>The question is can you accept the solution?<br><br><br></blockquote></div><br>