20-PasswordUserGroup

Default passwords are one of the top actual security vulnerabilities “in the wild”!
Professional penetration testers observe these all the time in organizations.

“Treat your password like underwear.
Don’t show it to strangers,
change it regularly,
and make sure to replace it immediately if there’s a leak…”

1.1 Reading

1.2 Screencasts

1.3 Processes and people

A running program (a process) has the same permissions as the user who executes it
(who is just a process to the OS).
There are exceptions to this rule,
but it explains why there are more users of the system,
than just the basic root and its real users (see /etc/passwd).
Users usually belong to one or more groups (see /etc/group).
Users and groups names are human-friendly identifiers.
The systems uses integers for unique functional identifiers: UIDs and GIDs.
Every file has entities who “own” it, including:
a user, the file’s primary owner,
a group of users (the file’s owner must be a member of this group).
optionally, other users specified by ACL extras.

1.4 Users, Groups, Passwords

1.5 Users

#!/bin/bash

# To view user and group ids
whatis id
which id
man id
id --help
id

# Displays know users
whatis lslogins
which lslogins
man lslogins
lslogins user

# To add a user
whatis useradd
which useradd
man useradd
useradd --help
useradd -D

sudo useradd alice
sudo passwd alice

# On Debian, this is a higher level utility
# On Fedora, it is just like useradd (the lower level)
# OpenSuse does not even bother to alias this "higher" one
# I never bother to use this, since it's non-standard
whatis adduser
man adduser

# Listing current users
whatis users
which users
man users
users --help

whatis whoami
which whoami
man whoami
whoami --help

# Modifying users
whatis usermod
which usermod
man usermod
usermod --help
# more below on usermod!

whatis userdel
which userdel
man userdel
userdel --help

sudo userdel alice

1.6 Groups

#!/bin/bash

# basic listing of groups
whatis groups
which groups
man groups
groups --help

ll /etc/group
stat /etc/group
vim /etc/group

ll /etc/gshadow
stat /etc/gshadow
sudo vim /etc/gshadow

groups
groups bob
groups root

# Creating a group
whatis groupadd
which groupadd
man groupadd
groupadd --help

groupadd awesomegroup

# change group ownership of resource (permissions)
whatis chgrp
which chgrp
man chgrp
chgrp --help

# login to a group
whatis newgrp
which newgrp
man newgrp
newgrp --help

# Like passwd, but for groups
whatis gpasswd
which gpasswd
man gpasswd
gpasswd --help

# to change group password
gpasswd groupname

whatis groupmod
which groupmod
man groupmod
groupmod --help

whatis groupdel
which groupdel
man groupdel
groupdel --help

# delete group
groupdel groupname

# Examples:

# add group
sudo groupadd mygroup

# add user to group
sudo usermod -a -G mygroup alice

# remove alice from group (why?)
# Not appending, so sets alice to only group (alice)
sudo usermod -G alice alice

# add user to group
sudo gpasswd -a username mygrouptoaddto

# remove user from group
sudo gpasswd -d username group

# To set the list of group members,
# write the user names after the --members option
# dividing them with commas and no spaces:
gpasswd --members username_1,username_2 which_group_to_edit

1.6.1 Superuser: root/su

#!/bin/bash

whatis su
which su
man su
which su
su --help

ll /usr/bin/su
stat /usr/bin/su

su
pwd
exit

su -
pwd
exit

# What is the difference between the two su - and su above?

su bob
# note: bob's password needed
exit

su -c whoami
whoami

cd ~
pwd

whoami
su -c whoami root # note: root password needed
su -c whoami alice
# note: alices password needed

# redirecting passwords from scripts (assuming password is password)
# pipe
echo password | su -c whoami alice

# redirect a file in
echo password >file.txt
su -c whoami alice <file.txt

# "here string" a shortened here document (below), redirect text to stdin
su -c whoami alice <<<password

# here document, also redirect text to stdin
su -c whoami alice <<uniquelabelnotincode
password
uniquelabelnotincode

# Hint, the "whoami" command could be a sudo command itself...

# On older Debian distros (which used su from the shadow package),
# you may need "expect" to fill in the password, since it pretends to be a terminal
# On newer distros (which use su from util-linux), it just works like above
# <https://sources.debian.org/src/util-linux/2.33.1-0.1/debian/util-linux.NEWS/>
# <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256>
# <https://unix.stackexchange.com/questions/460478/debian-su-and-su-path-differences>
# The old version of su from shadow: <https://sources.debian.org/src/shadow/1:4.5-1.1/src/su.c/?hl=720#L720>

1.6.1.1 su versus su -

su - invokes a “login shell” after switching the user.
A login shell resets most environment variables,
providing a clean base.

su just switches the user,
providing a normal shell with an environment
(and potentially environment variables)
nearly the same as with the old user.

Imagine, you’re a software developer with normal user access to a machine,
and your ignorant admin just won’t give you root access.
Let’s (hopefully) trick that person.

Now, you ask your admin why you can’t cat the dummy file in your home folder,
it just won’t work!

$ ls -l /home/you/dummy_file
-rw-r--r-- 1 you wheel 41 2011-02-07 13:00 dummy_file

If your admin isn’t that smart or just a bit lazy,
he might come to your desk and try with his super-user powers:

$ ls -l /tmp/shadow_copy
-rw-r--r-- 1 root root 1093 2011-02-07 13:02 /tmp/shadow_copy

You maybe noticed that the corrupted $PATH variable was not reset.
This wouldn’t have happened, if the admin invoked su - instead.

1.6.2 sudo

https://en.wikipedia.org/wiki/Sudo
It originally stood for “superuser do”,
Older versions of sudo were designed to run commands only as the superuser.
The later versions added support for more running command options,
not only running as the superuser,
but also as other (restricted) users,
and thus it is also commonly expanded as “substitute user do”.

1.6.2.0.1 sudo group

1.6.2.0.2 wheel group

1.6.2.0.3 Benefits and costs

Discuss:
What are some advantages of sudo over su?
Are they justified?
Are there advantages of su over sudo?

#!/bin/bash

whatis sudo
which sudo
man sudo
sudo --help

whoami
sudo whoami
sudo -u bob whoami

ll /etc/sudoers
stat /etc/sudoers
sudo vim /etc/sudoers

# Fedora and OpenSuse
sudo usermod -a -G wheel bob

# Debian wheel group is called sudo
sudo usermod -a -G sudo bob

sudo vi /etc/sudoers

whatis visudo
man visudo
sudo visudo

# Note, when you make someone part of the sudo group,
# you need to restart, to get a login shell.
# However, you can su - user into the newly sudo'ed account,
# to use it with a login shell right away.

1.7 Password management

1.7.1 /etc/passwd

The entries in /etc/passwd occupy exactly one line each,
and have the following form:
nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

An example would be:
xfze:$$1zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:Daniel Ernesto Ortiz Costa:/home/xfze:/bin/bash

Note: now in “modern times”,
the hash is usually in /etc/shadow instead,
leaving an x in the field instead,
if it’s hashed in shadow.

#!/bin/bash

whatis passwd
man 5 passwd

stat /etc/passwd
ls -l /etc/passwd
vim /etc/passwd

# check out bob's line in the file, and identify each field

1.7.2 /usr/bin/passwd

#!/bin/bash

whatis passwd
which passwd
man 1 passwd
passwd --help

sudo stat /usr/bin/passwd
sudo ls -l /usr/bin/passwd

# Change your own
passwd

# Change another user
sudo passwd user

su -c passwd user

su
passwd user

1.7.3 /etc/shadow

#!/bin/bash

whatis shadow
man 5 shadow

# What about the permissions of the file with hashes and salts?
sudo ls -l /etc/shadow
sudo stat /etc/shadow
# This may differ on a debian system

# setuid bit can be set by
chmod u+s /path/to/file.txt
chmod g+s /path/to/file.txt

sudo vim /etc/shadow
# check out bob's line, along with each field.
# Note: what is the number code for hash function ID?

# To see which hash you're using:
whatis crypt
man 5 crypt
# /\$6$

# Convert to shadow and back:
whatis pwconv
man pwconv

whatis pwunconv
man pwconv

1.7.3.1 Hashing manually

#!/usr/bin/python3

import crypt

# param1: password, param2: $hashmethod$salt$
crypt.crypt('password', '$6$salt')

# the same (it's smart enough to ignore $)
crypt.crypt('badpassword', '$6$salt$')

# check bob's password hash, re-generate it using the same salt

#!/bin/bash

# where salt and password are variables, aptly named, there are two alternative methods:

# Method 1
man openssl passwd
man openssl-passwd
openssl passwd -6 -salt $salt $password

# Method 2
man mkpasswd
mkpasswd -m sha-512 $password $salt
# mkpasswd differs by distribution too.

1.7.4 Login password check

How does the system launch this whole system at login?
20-PasswordUserGroup/Capture.JPG

1. Once init process completes run-level execution and executing commands in /etc/rc.local, it will start a process called getty. Getty is the process which will take care of complete login process.
2. The getty process initiates login command and gives users with login: prompt display on the terminal screen and wait’s for user to enter username. Once user enter his login name, this in-turn will prompt for user password. The password what user typed will be hidden and will not be shown on screen.
3. Now getty will check user credentials by verifying it with /etc/passwd and /etc/shadow file, if password matches it will initiates user properties gathering else getty will terminate login process and re-initiates once again with new login: prompt. This is done for three times in most Linux/Unix flavors. If user failed to enter correct password for three consecutive times, getty disable terminal for 10 seconds by using PAM module to control unauthorized logins.
4. Now the getty process read the user properties like username, UID, GID, home directory, user shell from /etc/passwd file to respective system variables $USER, $UID, $GID, $HOME, and $SHELL.
5. Once it gathers all the properties and before the start of user shell it read /etc/motd file and display it’s content as banner message to user.
6. Now getty process reads /etc/profile file for shell related settings and for importing any alias or some sort of variables which we have to set for user shell. start-up scripts
7. Once it completes reading /etc/profile file, it will read user home directory content and change user shell properties according to .bashrc, .bash_profile if his default shell is bash. The getty process get shell details from /etc/passwd file.
8. Getty now starts a software, which is called as user shell for interacting with user directly. The getty process get this information from $SHELL variable which it already parsed from `/etc/passwd` file. Now it presents `$PS1` prompt for user to execute their commands.
9. From here on-words user can start executing their commands at the terminal. All the above stuff is monitored by kernel in the background. In our next posts we will see how log out process and shutdown process works in detail.

1 20-PasswordUserGroup