MORE SSH Hacking: heads-up

[netmask]

> To my knowledge the word sniffing does not only belong to observing network 
> traffic. See i.e. 
> http://www.seifried.org/security/articles/20020126-keyboard-sniffing.html or 
> http://www.wired.com/news/privacy/0,1848,49455,00.html.

True.. I guess in the world of corporate America that I work in, on our 
networks and under ITIL we use 'sniffing' only to pertain to packets.

I would call keyboard 'sniffing' to be logging, interception, etc.. but yes, 
in a way.. you're sticking your nose out there and seeing what goes by... That 
was completely my mistake.

>> Lastly, you might be able to record it via injected modules using LD_PRELOAD..
>> But i've never researched this method in depth..   You can easily use
>> LD_PRELOAD though to bypass restricted shells. (Nothing to do with this).
>
> Well, you are right in may aspects. Maybe I was too short with my
> comment. I did not say and didn't want to say that logging in as normal
> user and then su to root is insecure at all. I just wanted to say that
> it weakens the root login, against the possibility to use public key
> authentication with SSH login. Not more, not less. I am no hacker nor
> cracker, so I have no proof of concept for using the possibility to
> "listen" to the input a user makes when su'ing. Again: it would be a
> local hack. I am not speaking about decrypting the SSH connection,
> either established by password auth nor by pubkey auth. The "weak" point
> is the local system, given the attacker has local unprivileged user
> permissions.

I know you weren't talking about decrypting ssh, etc. While I'm not a big fan 
of allowing any remote root access.. I do see where you are coming from.. If 
someone compromised your home machine/certificate/passphrase, they would have 
instant root access to your sshd box.  However, if you were ssh'ing and 
su'ing, and they had compromised the box doing the ssh'ing, they'd still 
compromise root if you ever su'd.

Remote root access via keys and using 2 factor authentication (tokens, etc) 
wouldn't be too bad at all..  but for the purposes of auditing, its usually 
not plausible. There needs to be an audit trail. I think the way to go would 
be using su, and still having 2 factor.. At the same time, I use gr-security 
on my kernels which doesn't allow a user to put anything in their own path 
(gets around their account being compromised, and someone trojan'ing su).

It's never completely fool proof.. and using RSA tokens certainly isn't 
affordable or easy for a home user. Things like S/Key are, but they're a pain 
to carry around a list of passwords.. Biometrics aren't really plausible (and 
are a bad thing in general in my opinion.. If someone ever compromises your 
thumb print..  Oops, you're screwed forever)

Both ways have their issues.. Personally, I'm not a fan of passwords at all.. 
But if you use public key, then you run into the problem of your users not 
setting passphrases on their keys at all.. Which you can't really control.. 
and then their windows/linux box getting compromised, and the attacker doesn't 
even have to go through the hassle of sniffing their passphrases.. they just 
walk onto your system.. as a normal user. Then they can attempt to escalate 
privs from there.

So anyway.. I see where you're coming from, and I see the extra risk of a user 
account being compromised and then someone attempting to escalate from there 
if they are a user that has 'su' ability.   But this is also the reason that 
root users should be extremely limited..   sudo is great for doing this, as 
long as you know exactly what you're doing.. So many applications have shell 
escapes..  like giving sudo vi, is just like giving sudo bash..   sudo cat, 
gives shadow file (also gives raw access to /dev devices..  sudo cat 
/dev/hda|strings)

However you can restrict sudo down pretty well, require absolute paths, etc.

anyway.. I've rambled enough.