[NCLUG] I was hacked!

[Sean Reifschneider]

On Fri, Dec 29, 2000 at 01:08:14AM -0700, John L. Bass wrote:
>Remote updates/management is NOT hands free ... "hands free", is a distribution
>which has been well enough shaken out, that you CAN/WILL be willing to deploy
>for more than 12-24 months without changing in any way.

If you believe you can deploy a system to desktops for 12 to 24 months
without doing any sorts of updates, you deserve what you get...  You're
effectively deciding to put "hands off" over security because there
*WILL* be updates that have to be done in this time.

>the intent to obscure a trojan. It quickly falls back to a trust issue. Can
>you positively prove the NSA or KGB (or less organized hackers) do not have
>a back door installed in the system, carefully constructed from several
>unrelated subsystems?

So, you seem to believe that the requirements you've set up for a desktop
system are unachievable?

>just waits for the machine to boot again and promptly re-infects. So does rebooting
>really "fix" the exploit?

There's only so much you can do without touching the file-system.

It's too bad that tripwire is so painful to set up.  It's a great idea, but
requires too much of an investment up-front...

>I don't know why you brought windows into this?? was there a point I missed?

Apparently...  Windows *IS* currently being deployed "successfully" as a
desktop operating system.  If you're going to talk about what's required
for a successful deployment then it's worthwhile to compare your points
with existing art.

>distributed trust, is still trust that can be subverted or broken. If the individual
>packages contain the signature, then it simply implies that a shadow update server
>requires that a shadow certificate authority must be available to verify the trojan

What makes you think that the certificate authority is an internet server that
you can subvert?  I don't know what the setup for up2date is, but it only
makes sense that the keyring be stored on the local disc.  That's the way
I implemented our tummy.com remote update system...

>Lastly, keybreaking is a matter of odd's. People win the lottery every week with
>odds of 100,000,000:1 by randomly choosing a single correct string of numbers (key).
>A 2048 bit key might be broken in the first 1,000 random attempts to locate it (and

100,000,000:1 odds are a key-space of around 27 bits.  That's with million of
attempts made every week (one could say 100 million).  The odds of a 2048 bit
key being broken in 1,000 random attempts is 10^614:1.  That's a very big
number.  Isn't 10^256 on the order of the number of atoms composing the
planet earth?

Yeah, keybreaking is a matter of odds.  The odds are WAY against you...
distributed.net is currently working on a 64-bit RC-5 key, and has been
for 3 years.  I think you're underestimating the size of the effort
required to break such a scheme...

>Now let's say some crypto nut wins a big lotto, takes his earnings lump sum,
>sets aside a mil or two, and puts the rest up as a bounty for the RH/M$ key.
>Since that has a bigger payback than the current RSA (or other distributed.net)
>prize, it will be the focus of a LOT of effort. Presto, we take 2^70th or so off

I'd be shocked if distributed.net re-directed their efforts to such a thing.
Ignore the moral issues -- it just doesn't make sense from a financial
standpoint.  N million dollars to crack a 2048-bit key when a 64-bit key is
going to take 5 years to crack?  Doesn't make sense...

As I mentioned, once Redhat gets wind that this is happening, all they have
to do is distribute an update with a new 4096-bit key...

>off the odds on a 2048 bit key ... still a big crack, but a 256 bit key with
>nobody looking for it, is much less likely to be broken than a 2048 bit key
>with everybody looking for it (keyspace/cycles looking for it). With a $60mil
>prize, someone might even be tempted to build a VLSI cracker tuned for the project,

We aren't talking about a bunch of computers running for a few years to track
down a 2048-bit key.  We're talking more along the lines of all the computers
on earth having a reasonable chance of finding it before our sun grows cold...
If you want to play the odds, they're much better in Vegas...

>Lastly, there are always the paranoid, who are sure NSA/KGB *ALREADY* have a backdoor.

And you think they'd expose the fact that they have a backdoor by breaking the
key for up2date?

>My point was, the current attacks aren't *EVEN* interesting ... the game is just
>getting started ... do you really disagree? You seemed to imply that the ultimate

There are some reasonable solutions to this problem, that's all I'm saying.
I think that your points that somone has a 10^614:1 chance of hitting the
correct key to break down a system like up2date by trying 1000 random keys
is not beneficial...

>Is your position that all these "trust" issues, have a technological solution?

My position is that discarding current solutions to the problem because of
mythical problems with them is a disservice to the people that the current
systems will help.  If you want the ultimate security, store your system
in a huge block of concrete at the bottom of the ocean.  Don't try to
convince people that they shouldn't be using tools that work today because
they might not work tomorrow.  We don't get anywhere by doing that.

Sean
-- 
 Actual job advertisement:
 Please submit resumes in Word format with subject "Lead Unix Admin" to: [xxx]
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python