27

I know that the sudo password protects my computer from being locally hacked by someone having physical access to it (edit : actually, it doesn't). My password is strong enough for that purpose, but I know that it is not strong enough if someone can brute-force it remotely.

Can anybody access my computer in root mode using my sudo password with no physical access to the computer, on a standard Ubuntu desktop installation ?

  1. If you do have a network access, definitely yes (Short answer)
  2. If you do not pay enough attention to security, yes (Long answer)
  3. If you have "ssh" running, and no 2FA , yes (comments and answers)
  4. One can access your computer as root without sudo/user password
10
  • 1
    they can access via SSH and sudo to root. Oct 9, 2015 at 13:34
  • 1
    exactly. to harden this you can use 2FA. Follow this guide Oct 9, 2015 at 13:44
  • 1
    But "openssh-server" is not installed by default.
    – mxdsp
    Oct 9, 2015 at 13:54
  • 1
    then you are saved from SSH attack. There are many possible hacking techniques people use. Oct 9, 2015 at 13:56
  • 1
    There is simply no such thing as a "sudo password".
    – hobbs
    Oct 9, 2015 at 18:21

5 Answers 5

35

I know that the sudo password protects my computer from being locally hacked by someone having physical access to it.

I do not want to scare you too much, but if someone has physical access you handed access over to them regardless of how strong your password is. It will take 1 reboot by someone for that someone to be able change your root password (can be done from "grub rescue" without the need to supply your current password). By the way: this method is considered valid and a feature, and an accepted security risk (otherwise you would never be able to fix your system in case the password did get compromised).

but I know that it is not strong enough if someone can brute-force it remotely.

Here comes something else in play: a ROUTER should be smart enough to lock access from the outside if it is a repeated request asking for the same information over a short period of time. Basically what you have here is a DOS attack (or a DDOS if 2+ computers attacking you). A router should kill that connection and enforce a waiting period before accepting new requests from that connection.

Can anybody access my computer in root mode using my sudo password with no physical access to the computer, on a standard Ubuntu desktop installation ?

They first need to connect, then provide the sudo password. "root" mode is disabled and you can not directly log in to a "#" prompt.

Note that it is possible to abuse a service. If you have "ssh" running on that machine and they can "ssh" to your system, and get a hand on your username and password for that user (and as it is an admin user your sudo password too) they can access your machine and mess it up. By the way: if they do it like that they must have knowledge of your system first (like your password).

But then there is an issue with that (and any other method): how did they get your password? They can NOT get it from your system itself. And in general guessing is not worth the trouble. If it was socially engineered ... then your problem is there, not with the security model of your system, Ubuntu or Linux in general.

As long as your sudo password is yours you will/should be fine. And you will be even better off if it is a strong password (maybe easy to remember for you but not guessable by others). An example I used before when discussing this: If your dog is named "Abwegwfkwefkwe" using "Abwegwfkwefkwe" as a password is BAD even though it looks good (since someone could ask you: 'what is your dog's name' and they try that as a free guess). If you have no relation to "Abwegwfkwefkwe" it is a good password.

Best advice I can give:

  • do not enter your admin password when asked for it unless you know it was expected to be asked. If you open a browser and are given a popup that looks like our "asking for admin account password" ... stop ... and think first.

  • do not leave your system unattended when the "sudo" grace period is active. sudo --reset-timestamp removes the current grace period and will ask for the password again when you next use "sudo". Lock your screen when you go AFK.

  • do not install services or software for the fun of it. If you do not need ssh do not install ssh, if you do not use a webserver do not install a webserver. And have a look at the currently running services. If you do not use BT on a notebook, disable it. If you do not use a webcam disable it (if active). Delete software you do not use anymore.

  • and for the really paranoid (and yes Paranoid Panda I am looking at you): change the password every so often. You can even install rootkit hunters to check for inappropriate access.

  • backup your important data to something that you keep off-line. So even if you do find someone on your system you can format it, and start over with a new install and your data restored.

9
  • 2
    You can abbreviate sudo --reset-timestamp to sudo -k, or sudo -K for the truly paranoid (only necessary if the attacker can set system time to arbitrary values, at which point you've probably already lost).
    – Kevin
    Oct 9, 2015 at 14:31
  • Jups. I used the long version so it is clear what it does. "-k" does the same indeed.
    – Rinzwind
    Oct 9, 2015 at 14:41
  • 1
    @mxdsp: Encryption can prevent people from reading the contents of the encrypted partitions, if the passphrase is strong enough, but it may be possible to get the encryption key out of a running or recently shut down computer. Crypto is also a very fast-moving field, and you will need to keep up with new developments, lest your encryption become obsolete and easily broken.
    – Kevin
    Oct 9, 2015 at 15:00
  • 1
    @mxdsp yes. For one: you can format a disk and when the data is gone... you are the one with the problems.
    – Rinzwind
    Oct 9, 2015 at 17:23
  • 1
    The first part implicitly assumes no full disk encryption.
    – otus
    Oct 10, 2015 at 5:26
6

Yes they can.

There are multiple ways to do so though, and brute-forcing the sudo password is probably not the first one.

First off, the sudo password is your user's password; so really what they'd need to get is your password.

Second, cracking a user's password using brute-force to access a system is probably the last resort.

There are way more elegant (but mostly more effective) ways of breaking into another system.

Typically an attacker will either just go and try to exploit the most common vulnerabilities (the most known probably being getting a user shell by any means and exploit a ShellShock to get a root shell) or do a finest job along the lines of:

  • Scanning the open ports on the system in order to get information such as:
    • Operating system version
    • Running services version
  • Exploiting known operating system or running services' bugs (buffer overflows, ...) in order to get at least a user shell and then try to get a root shell (again, maybe exploiting a ShellShock)

Brute-forcing the sudo / user's password may be an attempt in case a root shell can't be obtained otherwise, but for example exploiting a service running as root won't require the attacker to brute-force the sudo / user's password.

4
  • 1
    Thank you. briefly, it means that an attacker do not need the sudo password to get root access ?
    – mxdsp
    Oct 9, 2015 at 15:03
  • 2
    @mxdsp Exactly. Put it like that: if an attacker manages to get a sudoer user shell by any mean (for example exploting a sudoer user's running program) he might use known exploits (in my answer I mentioned the most infamous) to get a root shell, bypassing the need of the user's / sudo password. Even better, if he manages to exploit a service running as root, he's directly root.
    – kos
    Oct 9, 2015 at 15:21
  • 1
    @mxdsp Now we're quite generalizing, but see this video to understand for example how an user without sudo rights (=~an user as which an attacker is logged in but which the attacker doesn't know the password of) may get a root shell just by exploiting known bugs (in this case the infamous ShellShock).
    – kos
    Oct 9, 2015 at 15:21
  • 1
    @mxdsp On a side not I didn't mean sudoers user, just user. That's not necessary, I was just thinking too many things at the same time.
    – kos
    Oct 9, 2015 at 16:04
3
  1. If I have learned anything in the last few years on security, then one thing: Nothing is impossible.

  2. As long as you have access to a network, definitely. Each service running on your system that can be accessed over the network is theoretically vulnerable and thus a potential weakness.

And therefore, for an attacker with enough ideas it is possible. You can make your system as secure as possible, but you cannot get to 100% safety ever.

It is therefore important to assess what is possible with justifiable technical effort and what protects you so well that you yourself can no longer work.

5
  • 1
    I do have a network access. Can be more specific about how probable that kind of attack could be ?
    – mxdsp
    Oct 9, 2015 at 13:37
  • 1
    use two factor authentication. You need to edit PAM.D and so on. Oct 9, 2015 at 13:41
  • @Arronical the link is from this forum as well and very nice guide as well. Oct 9, 2015 at 14:03
  • @Arronical i have put it in the question comment. This guide Oct 9, 2015 at 14:10
  • Sorry @AizuddinZali I hadn't refreshed the page!
    – Arronical
    Oct 9, 2015 at 14:14
2

I know that the sudo password protects my computer from being locally hacked by someone having physical access to it (edit : actually, it doesn't). My password is strong enough for that purpose, but I know that it is not strong enough if someone can brute-force it remotely. Can anybody access my computer in root mode using my sudo password with no physical access to the computer, on a standard Ubuntu desktop installation ?

sudo password is not solely for local protection, it's purpose is to add an extra layer of security to root privilege use. Good discussion can be found here https://superuser.com/a/771523/467316

Your password may not be as strong as you think. Right now I'm cracking 20-40% of my client's Active Directory hashes for those I've seen before, those that have bad password rules are getting 70% cracked. I recommend 16 character, complex passwords. oclHashcat and Radeon graphics cards can do a lot of damage. Add in all of the password dumps from every breach in the past 5 years and you tend to get a good dictionary from which to work.

If you're using SSH at all make some adjustments in the sshd_config

sudo nano /etc/ssh/sshd_config

The MUSTS right out of the gate (last one to disable the ftp server if you aren't using it).

Protocol 2
X11Forwarding no
PermitEmptyPasswords no
MaxAuthTries 5
#Subsystem sftp /usr/lib/openssh/sftp-server

Save it, restart ssh

sudo service ssh restart

Use public key encryption Start by creating yourself a key at your remote machine (using puttygen or whatever flavor your OS has available). Copy the public key to your Ubuntu machine under the user you wish to login as authorized_keys file (you'll probably have to create it)

sudo nano /home/yourdumbusername/.ssh/authorized_keys

copy the public key in this format

ssh-rsa 23r0jfjlawjf342rffjfa89pwfj8ewfew98pfrfj8428pfwa9fupfwfcajwfpawf8rfapfj9pf892jpfjpwafj8a where-ever-you-have-your-private-key-for-your-own-notes

save it, and setup your sshd_config to allow for public key login

sudo nano /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

save and restart ssh

sudo service ssh restart

Try SSHing to your ubuntu host from your private keyed computer using public key encryption. If all went well go back to ubuntu host and disable password authentication.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no

Save and restart ssh

sudo service ssh restart

Try sshing from private keyed computer again to confirm.

Want to add more? setup a non-privileged account, turn PermitRootLogin no, restart ssh, add your public key to the new account's authorized_keys, login as non-privileged account, su to your root or privileged account when you need to root or privilege your way through things.

0
2

sudo's purpose is not password related but instead to give certain users root-ish capabilities while restricting others over a machine without requiring them to present the root login (password/key/security token/etc). For example at my work, day to day workers can only start/shut down/ install & upgrade their stations ( from a company vetoed repository) via sudo. They are not given the other root liberties such as purposefully removing / , formatting devices, adding and removing users, deciding which kernel modules should be blacklisted or what runs in crontab ( etc, etc, etc). Whereas at your home, your sudo allows full access to the machine. In regards to the password, in reality it's your user account's password that sudo requires ( the very same one you would use to log in, if autologin is not enabled.) And that password has the same vulnerabilities as any other password out there.

Bad Tip : If you want to make root a regular account on a sudo enabled unix ( linux/apple osx) run the following

sudo -s
passwd
Enter your unix password:

At this point root has a regular password, and you can just log out and log in as root with the mentioned password in the "old fashion way".

In regards to security, if one program (say web server, mysql, php daemon, sshd) runs as an elevated account .. say root and has a known exploit out there, then attackers might not need any security credentials to gain access. They can make use of the vulnerability of the program and just spawn a new shell from this program running as root. However this is pretty rare since distro managers are aware of like issues and do an outstanding job on building a well thought and usually safe default environment.

In the other operating system a similar operation to sudo would be right click and run as System Administrator ( or the UAC privilege nagging).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .