How Hackers Think
This is a bit technical, but it’s a good window into the hacker mentality. This guy walks step by step through the process of figuring out how to exploit a Cisco vulnerability.
Comments
Roy Owens • December 5, 2005 12:21 PM
As a system grows in complexity, inevitably it will pass the point where no one person does, or can, know the whole system.
Security becomes political, with each faction having different, often conflicting, needs. The security people want things tight to make their jobs easier. The oversight people want things open to them to make their jobs easier.
Hackers would naturally target areas where disparate needs have forced compromises, so the compromises get compromised, no surprise.
trader • December 5, 2005 1:38 PM
Same site displays major IE6 vulnerability as well: infection via bypass of ” Do you want to download this … ? ” screen.
MS Secure Computing ?
trader
Jason Marshall • December 5, 2005 2:40 PM
I feel that these XSS problems, as well as SQL injection problems, are strictly an issue of representation, not of emerging complexity. We have a bad habit of constructing systems, even critical systems, in which large parts of their information is represented as unstructured data (eg, ‘plain’ text). And then when that data contains structure (such as malignant logic), we feign surprise.
If you don’t want your system confusing text with structure, don’t represent structure as text, or text as structure.
It’s not enough to have mechanisms in the system to sanitize unstructured data (like text output into an HTML document, or query parameters into a SQL expression). Presumably the turn-around time on this exploit indicates that Cisco already possessed this capability. Rather, one has to guarantee that they such mechanisms are always applied exactly once (at least once for security, no more than once for proper system behavior). I can equally presume that the fast turnaround indicates that Cisco did NOT cure the problem, but instead treated the symptoms (escaping text on a couple of output pages).
Delores Quade • December 5, 2005 4:53 PM
“As a system grows in complexity, inevitably it will pass the point where no one person does, or can, know the whole system.
Security becomes political, with each faction having different, often conflicting, needs. The security people want things tight to make their jobs easier. The oversight people want things open to them to make their jobs easier.
Hackers would naturally target areas where disparate needs have forced compromises, so the compromises get compromised, no surprise.”
It is so depressing to “step back in” to the security discussions (after a 5 year hiatus) only to see that we are still exactly where we were when I left.
Even worse, there have been years and years (like.. over 20 for greybeards and at least 11 years for the others) of educational strategy tactics highlighting these issues and how to solve them via conferences, whitepapers, training, books, (even some worthy vendors contributed), regarding the problems with the scenarios Roy presents above.
“As a system grows in complexity, inevitably it will pass the point where no one person does, or can, know the whole system.”
This doesn’t have to be the case. Think compartmentalization.
“Security becomes political, with each faction having different, often conflicting, needs.”
This is solveable. Think compartmentalization. (not silos)
“The security people want things tight to make their jobs easier.”
This is understandable and highly achieveable.
“The oversight people want things open to them to make their jobs easier.”
This has always been the biggest problem. Just say NO.
dq.
Sundar • December 6, 2005 12:41 AM
The article is too good. It’s long since I have read an article on vulnarability going to this depth of details.
jmr • December 6, 2005 9:20 PM
@ Jason Marshall
Okay, so tell me what the root problem is and how they could solve it? If the user wants to be able to view the memory dumps, well then, the user should be able to view the memory dumps.
Actually, I can offer a suggestion, but it requires cooperation from browser authors and site developers:
Have a web server provide pre-created signed indicators of scripts and frames present on a page. That way pages w/ signed script couldn’t execute arbitrary script or view arbitrary frames. This is a purely defensive measure, limiting the flexibility of the page in a particular dimension. Code-access-security is a well-known concept in Java and .NET, why not on HTML pages?
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Stephen • December 5, 2005 12:18 PM
Very nice. I’d like to see this level of detail in more vulnerability write-ups.