On a server I have a public key auth only for root account. Is there any point of logging in with a different account?
The sudo password can be easily extracted by modifying the bashrc.
And who is going to edit your .bashrc?
The attacker that is currently with user privileges on the server?
How did the attacker gain your user’s privileges? Malware-infected user installation? A vulnerability in genuine software running as your user? In most scenarios these things only become worse when running as root instead.
The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.
So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.
So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo
Oh that’s dastardly
Simple solution is to not use sudo.
Sorta like Slackware’s default.And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.
$ su -
And how would you not be able to hijack the password when you have control over the user session?
Nah just set up PAM to use TOTP or a third party MFA service to send a push to your phone for sudo privs.
…and if you don’t have your phone attached to your hand…?
I…I don’t understand the question.
Also, yubikey or any other token. Plenty of MFA options compatible with sudo.
Then you can’t gain root privileges on your server. Are you really arguing for less security because it’s inconvenient?
This is end-user behavior and it’s honestly embarrassing. You should realize your security posture is much more important than “I left my phone on the other room”
that’s why root owns my .bash* stuff
If the .bashrc is immutable, the attacker can’t remove it.
That’s how it works.?
It’s .bashrc, not bashrc, and .bashrc is in the home directory.
If .bashrc is immutable, it can’t be removed from home.
you’re right. that’s something i wanted to look into. guess setfacl would do the trick?
thanks
This was downvoted, but is a good question.
If your account is compromised, the shell init code could be modified to install a keylogger to discover the root password. That’s correct.
Still, that capture doesn’t happen instantly. On a personal server, it could be months until the owner logs in next. On a corporate machines, there may be daily scans for signs of intrusion, malware, etc. Either way, the attacker has been slowed down and there is a chance they won’t succeed in a timeframe that’s useful to them.
It’s perhaps like a locking a bike: with right tool and enough time, a thief can steal the bike. Sometimes slowing them down sufficiently is enough to win.
@ShortN0te @truthfultemporarily What does sudo have to do with ssh keys?
