[conspire] About conditioned helplessness

[Rick Moen]

Quoting Luke S. Crawford (lsc at prgmr.com):

> this problem of a authorized user's workstation getting compromised
> is a very difficult one to solve.

I like to think of that as a 'consulting opportunity'.  ;->

If you wanted to hold a conversation about how to do that with an
authorised user's Linux workstation, I'd be glad to do that here.  
If you're referring to MS-Windows workstations... well... I hold that
conversation for free with my friend Becky in Nashville, but everyone
else would need to offer professional consulting rates, two-hour minimum.

> ...if a admin logs in from a compromised box, there really isn't much
> you can do to protect yourself from a sufficiently advanced attacker
> piggybacking on the legitimate connection.

Admins are a particular area of concern because they occasionally need
to elevate privilege on the shared (or key company) hosts they're hired
to look after, just to do their jobs.  As you say, _if_ their
workstations, from which they operate, have become security-compromised
before they SSH/RDP/whatever into the sensitive hosts, and _especially_ 
if they then su/sudo whatever to elevate privilege, then the sensitive
host has a problem.

So, care is logically required in the configuration and operation of the
admin's workstation, and the admin needs to be wary about, say, deciding
to SSH into work from J. Random Friend's malware-infested laptop, or
from a machine at a cybercafe with a keylogger (even if he/she boots a
live distro to do it).  This is why you don't give root to the NOC
tapemonkey.

This is why, if you (as an admin) want to be able to ssh in from
arbitrary machines you don't have any reason to trust, you might want to
put up with the serious hassle of using real one-time pads using SKey or
whatever's the current vogue way of patching that in.

Back when I lived at The CoffeeNet, we had friends who had shell
accounts on security guy Peter Shipley's machine, dis.org.  They carried
around slips of paper in their pockets with a few hundred one-time keys
on them, which they used for authentication for their
shell/IMAP/whatever accounts.  It was a serious hassle for them, but
Shipley had to insist on it, because (as a well-known security maven) he
was the target of every little kiddie who thought it'd be clever to root
Shipley's server.  (And _those_ dis.org users weren't even admins -- but
that's something of an edge case.)


> Now, I think, RSA made an absolutely boneheaded mistake that changed
> the breakin, in their case, from being an embarrassing sidenote to
> it meaning that all their customers were also vulnerable to compromise.
> 
> They use shared secrets for authentication.

Indeed.  There's been a whole lot of snake oil about the usual sort of 
alleged two-factor authentication.


Anyhow, where I was going with this is to consider what are the usual
avenues to machine compromise.  It is of course various.  I would
maintain that something like 'I had Adobe Flash for MSIE with ActiveX
installed, was using my e-mail client with local Administrator
privilege, and who could possibly expect that Bad People could steal
the highly sensitive corporate secret I was handling at the time?' is 
just a bit pathetic and calls for a dual-track remedy of (1) quality
time spent with Windows Policy Editor and (2) horsewhipping of a certain
RSA employee.

But that's not the interesting case, IMVAO.  More interesting is what
happened at Very Ancient Linux Systems, which then operated an
extremely large hosting site for open source projects, Sourcefrog.us.
In the middle of the afternoon, one day, the CTO found himself being
taunted by an unknown intruder on the IT department's very private IRC
channel on its very private IRC server about VALS's sucky corporate
security.

The CTO went into panic damage-control mode, hitting all the Big Red
Switches that cut VALS off from the rest of the world and shutting down
all computers.  Each machine was to be wiped and reinstalled, and for
months employees had no Internet access other than relayed SMTP and 
80/tcp and 443/tcp via a proxy.

The story about how this happened came out only very slowly, even to
VALS employees.  It turned out to involve one of Mr. CTO's direct
reports, an IT employee (not me!), being incautious about traffic in and
out of the sensitive corporate network, and it involved Sourcefrog.us.

That's the interesting part, the role of shared hosts in security
problems, and the role of inter-network traffic.  shells.sourcefrog.us
was/is an SSH shell / development server with thousands of members of
the general public having non-privileged shell accounts.  (Cf.
'hera.kernel.org', with 448 or so.)  Predictably and inevitably, one of
said members of the public was ssh'ing in from a university shared host,
which had long been root compromised by someone.  Mr. Hax0r thus was
able to steal a legit user's credentials for ssh'ing into
shells.sourcefrog.us -- which was actually no huge coup, as Mr. Hax0r 
was already able to sign up for such a shell account directly.

Once into shells.sourcefrog.us, masquerading as the legit user, Mr.
Hax0r probed away at the machine, at his leisure, looking for vulnerable
but privilege local code that he could exploit to gain root.
Eventually, he found one -- and nothing was running on
shells.sourcefrog.us capable of detecting his activity.  Now, armed with
root, he installed a replacement for the normal SSH server and client.
The client, in particular, was trojaned to log and convey to him any and
all use of security tokens (including private key / passphrase) on
outbound sessions to elsewhere.

So far, Mr. Hax0r merely owned Sourcefrog.us, and had no point of entry
into VALS itself.  However, at _this_ point, a certain Mr. Doofus of
VALS IT Dept. made a crucial error.  Doofus SSH'ed into
shells.sourcefrog.us, and then _scp'ed a file back to VALS_.

Doofus could have accomplished his objective by scping the file _from_
VALS's command prompt ('pulling' it), but instead operated from
Sourcefrog.us's command prompt ('pushing' the file).  Because of that
crucial error, he exposed his authentication credentials on
Sourcefrog.us, which immediately were logged and conveyed to Mr. Hax0r
-- who then had free passage, masquerading as Doofus, into VALS.

I'm unclear on whether he was then obliged to crack root again inside
VALS, or whether he just waited for Doofus to do su / sudo over his 
doubled SSH session out to Sourcefrog.us and back.  I'd speculate,
probably the latter.  Either way, hilarity ensued.