<div>Well, that sure was informative.</div>
<div>&nbsp;</div>
<div>My questions to what the advisory means are below.&nbsp; Can anyone answer or correct&nbsp;this at all?<br>&nbsp;</div>
<div><span class="gmail_quote">On 1/3/07, <b class="gmail_sendername">Cisco Systems Product Security Incident Response Team</b> &lt;&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Details<br>=======<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.</blockquote>
<div>&nbsp;</div>
<div>So, other than making a TCP connection to the box, what does the attacker need?&nbsp; Do they need to get&nbsp;the shared secret off some other box in the same administrative domain?&nbsp; How is that shared secret protected, is it stored anywhere else an attacker might have easier access to (
e.g. on Clean Access-managed clients, on the &#39;readable snapshots&#39; below)?</div>
<div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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.</blockquote>
<div>&nbsp;</div>
<div>For &quot;may&quot;, presumably we should read &quot;would, unless the he suddenly fell asleep at the last minute&quot;?&nbsp; Or are there some additional barriers to taking advantage of a successful&nbsp; exploit?<br><br>&nbsp;</div>
</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Readable Snapshots<br>+-----------------<br><br>Manual backups of the database (&#39;snapshots&#39;) taken on CAM are
<br>susceptible to brute force download attacks. A malicious user can<br>guess the file name and download it without authentication. The file<br>itself is not encrypted or otherwise protected.</blockquote>&nbsp; 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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.
</blockquote>
<div>&nbsp;</div>
<div>So, I read this to&nbsp;mean, the snapshot files are still downloadable without authentication,&nbsp;still&nbsp;have&nbsp;easily guessable names,&nbsp;and still contain sensitive information that can aid in an attack (what sensitive information?), but now the attacker has password hashes against which he has to do a three hour offline brute force,&nbsp;or perhaps a&nbsp;twenty second&nbsp;rainbow table lookup, rather than getting the plaintext straight off.
</div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Mark</div></div>