<br><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 12:54 AM, Zephyr Pellerin <span dir="ltr"><<a href="mailto:zephyr.pellerin@gmail.com">zephyr.pellerin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> Does anyone know the author of that site? �I'm simultaneously impressed<br>
> and a bit concerned because I'm not very confident about their threat model.<br>
> It seems like the threat model includes offline attacks but it has -- in<br>
> the scheme of things -- very little test for structure so it doesn't really<br>
> know the difference between passwords built Diceware-style out of words and<br>
> completely random strings.<br>
<br>
</div>Come come, any hacker worth their salt hasn't kept D8.dic on their box<br>
since the turn of the century. It's prohibitively expensive and today<br>
developers basically manufacture exploitable software as a release<br>
requirement. sudo, the privilege escalation binary we all know and<br>
left, just had an exploitable FORMAT STRING bug in it (Didn't we get<br>
rid of all of those in like, 1999?).<br>
<br>
Backdoored login scripts or LDAP forest managers are considerably more<br>
likely than someone cracking a dump, especially considering<br>
xp_cmdshell is default in SQL08, file reading queries in pgsql are as<br>
well ( COPY X from Y where Y is a filepath is a real thing), and ways<br>
to turn sqli into shells on mysql are too numerous to list.<br>
<br>
Still, the real weakest chain in your security is your web browser and<br>
what plugins your�web browser�loads - flat out. This has been the<br>
preferred method to pop people-you-don't-know's box for at least 3<br>
years (Or at least since that pesky /GS switch & --stack-protection<br>
happened :) �Thats doubly true of breaking server side daemons - Any<br>
application developer worth his salt (or using these newfangled ORMs)<br>
will use prepared queries or a DB firewall, will be installed on a box<br>
with address randomization, safe exception handlers, W^X etc, but will<br>
probably not check his box for kernel mode rootkits that are hooking<br>
his tty every day.<br>
<br>
The fact that people care about passwords reflects a little (a lot?)<br>
out of date perception of how it's actually done. Virtually all<br>
computers compromised today are done with either a clever web bug or<br>
some memory corruption bug (perhaps not accounts, but certainly<br>
computers). �Just because the deep well of stack based buffer<br>
overflows has (mostly) dried up doesn't mean use after frees and<br>
friends don't�happen all the time, and no matter what your platform<br>
is, if you *really* think your patch cycle is 0 day turnaround.. well,<br>
I'd take a hard look at your sanity (laff).<br>
<br>
As far as how hotmail is being compromised, theres been quite a few<br>
bugs in password recovery in both hotmail & yahoo's systems. Don't<br>
rely on them for �security, Even our venerable lord Gmail has had it's<br>
fair share of remote mail reading bugs -</blockquote><div><br></div><div>I agree that bad security is commonplace, and there are many areas which are not covered.</div><div><br></div><div>I have noticed a pattern though, which is that it's a lot easier to point out security vulnerabilities than it is to talk about how to harden and protect against them. �People post "exploits" -- they don't post "exploits" and "how this could have been prevented or�ameliorated" and then "how to design to protect against this class of problem."</div>

<div><br></div><div>Which is what I'm trying to do with the webapp-hardening thing -- if there are kernel mode rootkits out there that are compromising you, what's the correct response to that? �How do you assess the risk and counter it? �I'm sure that we could better educate people -- if you were giving a talk on how to do good security, how would you do it?</div>

<div><br></div><div>Will.</div></div><br>