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
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.
With aliases in the bashrc you can hijack any command and execute instead of the command any arbitrary commands.
So the command can be extracted, as already stated above, this is not a weakness of sudo but a general one.
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
Simple solution is to not use sudo.
Sorta like Slackware’s default.
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.
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?
You would have to know the root password.
With aliases in the bashrc you can hijack any command and execute instead of the command any arbitrary commands. So the command can be extracted, as already stated above, this is not a weakness of sudo but a general one.
You would have to KNOW the root password.
Oh that’s dastardly