Howto check for exploitable programs and backdoors
Posted by Jason Sat, 14 Oct 2006 16:26:00 GMT
One way for an attacker to escalate their privileges on an exploited system are through SUID or SGID programs. I will not make the assumption that SUID and SGID are fully understood, so I will begin with a brief overview. There are certain situations when a user account needs permissions to perform an action that are above those that are granted. An example of this would be the last time you logged into your user The intention of this article is to document possible ways that an attacker could escalate their privileges through vulnerabilities in the design of the filesystem. An example of this would be when you log into your user account and change your password (You do change your password often, don't you?). When a user types the command 'passwd' to update their password, this is updating the passwd and shadow files found in /etc. Now, you may have never thought of this before, but if you take a closer look these files are not owned by your user account and do not grant you the privilege of being able to write to these files. If you take a look you will see something like this:eleven@peeps /etc $ ls -al passwd shadow
-rw-r--r-- 1 root root 2358 Sep 20 21:12 passwd
-rw------- 1 root root 736 Sep 20 21:12 shadow
eleven@peeps /etc $
So, the million dollar question. If your user account does not have the permission granted to write to these files, how are you as a user able to change your password? Hmmm... Good question isn't it? Enter the concept of SUID and SGID. Exactly what is happening here? Let me explain. When you change the password of you user account using the 'passwd' command, you are authorized to change your password, but you are not allowed to make any changes to the passwd file. This is because the 'passwd' command is being executed as root, not as your user level privileges. The 'passwd' command is an example of a program that has its SUID bit set, which means that this file is executed with the permissions of the files owner, not the user who is executing it. Similarly, when the super user sets the SGID bit, the program is executed with the permissions of the the file's group owner.
How can you tell if a program binary has its SUID bit set? Well, taking our passwd binary from our example above, if you list the information on this binary you will see something like:
eleven@peeps /etc $ ls -al /bin/passwd
-rws--x--x 1 root root 28576 Jul 16 14:28 /bin/passwd
eleven@peeps /etc $
Normally, you will see 'rwx' which stands for read, write, execute. Notice that for this file you see 'rws' instead. Having the 's' in the owner bits signifies that this is an SUID file. This is important for any sysadmin to be aware of, as a poorly crafted SUID or GUID binary can aid an attacker in escalating his privileges with ease. A more common threat would be that if the attacker has already obtained root level access, he can then install his own SUID binaries in well hidden places on the filesystem to grant him a level of access to do whatever he wants, commonly install backdoors for easy future access.
So now that you understand what SUID and SGID is, the next question is how can they be detected. Luckly, unix is smart enough to know whether SUID and GUID files are binaries or simply shell scripts. Since its easy to change a harmless looking shell script into a backdoor, most systems will ignore SUID and GUID bits that are given to scripts. SUID and GUID binaries are what is regarded as a larger threat and they can be detected by executing the following script as root:
find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -al {} \;
This will detect all SUID and GUID binaries on a system. If you want to do a complete audit, looking for all files with bits set SUID or GUID regardless of whether they are shell scripts or binaries, the following script would accomplish this:
find / \ ( -perm -4000 -o -perm -2000 \) -type f -exec file {} \; | grep -v ELF
This script assumes that you are working with a system that uses ELF format executables. If you are on an older distribution that is still using a.out (or AIX which uses XCOFF) you will need to change the 'ELF' in the above script with the binary format your operating system uses. Since this article is security related, if you are not 100% sure what type of binary format your system uses, please don't guess. It is easy to check by using the 'file' command. Just execute this command against the binary for your shell. I use bash, so I would do this:
eleven@peeps /etc $ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
eleven@peeps /etc $
And there you have it, ELF. Now the big question, do you feel like doing this daily or weekly? Will you remember to do this often enough where it will be of use? Or, will you think for a quick minute "hrm, that's cool..." and proceed to surfing the net and forget to ever put your time spent reading this to good use? Personally, I don't want to spend the time on this. So, that's what we have cron for. This is really only necessary for the paranoid, however, paranoia is simply being aware of the facts. Open up your trusty editor and add this as a crontab entry, (note, this should all be on one line)
0 4 * * * find / \( -perm -4000 -o -perm -2000 \) -type f \
> /var/log/suid_guid_log.current &&
diff /var/log/suid_guid_log.current /var/log/suid_guid_log &&
mv /var/log/suid_guid_log.current /var/log/suid_guid_log
This cron script will scan all the files that have SUID or SGID bits set and compare the current list to that of the day before, leaving a current list of all SUID and SGID files in /var/log/suid_guid_log.
Hope it helps!
Composed by Jason K. Jackson
This site is completely supported by Google advertising.