============================================================================= "The RootHack Survival Guide" ============================================================================= RootHack - http://www.roothack.org (C) 2003 Preface: ----------------------------------------------------------------------------- I wrote this article because while I feel that the RootHack white papers are an extremely good resource, I feel that more can be learned if the defense and attack techniques used by all the teams were to be compiled into one comprehensive source. That is what I wish to make this file. With each wargame and with each white paper produced, I will try to update this file as best I can. If there are certain techniques that only one team used, I will try to credit that team. If more than one team uses a technique I will consider it public knowledge and not credit anyone with it. However, if you feel that it was your team who rightfully deserves the credit, I will gladly place you in the credits. Any found mistakes, comments, or flames can be directed to visage@javaspot.net. Enjoy. Table of Contents ----------------------------------------------------------------------------- The Pregame Strategy 0x00 The Grace Period 0x01 Creating a secure directory on the gateway system 0x02 Identify your system 0x03 Adding users and changing groups 0x04 Changing passwords 0x05 Downloading and installing a new kernel and any sources or libraries 0x06 Setup Directory Security FSTAB 0x07 Removing User/Group id bits 0x08 Checking world writeable files and directories, and no-user files 0x09 Finding daemons you don't want and how to remove them 0x0A Back dooring your own machine 0x0B Kernel Modules 0x0C Checking where logging output goes 0x0D Running fake daemons 0x0E Other i) Commands to learn ii) Random Ideas The Pregame Strategy ----------------------------------------------------------------------------- No team makes any specific reference to this within their white papers, but it is quite obvious that a successful wargames session cannot be had without prior planning. I recommend you specify jobs to each member of the team and begin compiling a list of exactly what you want to do with the box to secure it, and exactly what you want to do to try to attack. Make sure this list is flexible enough that it can change depending which distro you have. Also, if you have certain members of the team which may be stronger at defending than attacking, you may want them to be the only members accessing the box during the Grace Period. Why have more users connecting to the box than necessary? Each person generally has a specialty. Some users are masters at downloading and upgrading. Others are excellent at finding suids and removing them. Others are good at removing daemons. The list goes on and on with what each member may be good at. The point is that you should decide which members are going to be doing what, and let them do that job. You don't want to have members fighting right before the Grace Period over what they are going to do. You also don't want four people all downloading the new kernel because of a communication error. You will also want to create some secure way of communication: I recommend finding some IRC channel on some unknown server and idling in there to talk. Just a simple precautionary measure to make sure the other teams don't find out your strategies and you have a place to talk about what to do next. 0x00: The Grace Period ----------------------------------------------------------------------------- The Grace Period is the time in between when you get access to your box and when you are allowed to begin conducting attacks. This is the time that your team should be using to develop the security of the box. NOTE: Any team caught attacking during this time period WILL be disqualified. However, social engineering is allowed, but logging in with any information that you may have gathered is strictly prohibited. The Grace Period lasts 24 hours, which should be spent very, very wisely. With four teams downloading massive packages, I recommend you allocate your time with your teammates to download different packages at different times. 0x01: Creating a secure directory on the gateway system ----------------------------------------------------------------------------- Each team is given an account on Acheron, the gateway server to RootHack. On this server, the teams are supposed to be allowed to download any packages, compile any code, or try to remotely attack other teams. NOTE: This does not mean Acheron can be spoofed. That is strictly prohibited. As a primary line of defense, each team should make sure their directory is as secure as possible, making it readable only to themselves. Other tactics that can be used is to change your home directory to a secret location on the box (providing that is okay with epic), or to not use the space all together. Remember, this is just another spot other teams could use to check what you are doing. If you decide to use the box, remember that other teams may be able to see all the things you are doing if epic decides to remove some of the kernel patches currently in place. Not to mention that if your directory is "secret", other teams could easily use the "du" command to find out where your directory is, especially if you are downloading something to it. So while Acheron can make a great temporary spot to download trivial files or test some code, be careful of what you do on it. 0x02: Identify your system ----------------------------------------------------------------------------- Now that you have created your secure account on Acheron, it is time to start securing your box. Step one? Identifying what distro you are running, what version of that distro, and what version of the kernel. The way to do each of these tasks is show below (respectively): 1) cd /etc, look for "distro_version". That is your distro. 2) cat /etc/"distro"_version, where the distro was found above. 3) uname -r (-a for all information) Your system should now be completely identified and you should be ready to get down to work. 0x03: Adding users and changing groups ----------------------------------------------------------------------------- The next step you will want to take is adding some users for your team. This can be done several ways. If you don't have the command "adduser", you can manually create an account by echoing an entry into /etc/passwd and creating a home directory for them. Next I recommend you remove all default users that you know you won't be using. After this, you should create your own group with the "groupadd" command, or by manually adding an entry to /etc/groups. Next, remove all groups that you will not be using. By creating these groups, you can change permissions on certain directories to only allow certain players access to certain parts of your system. It seems trivial, but not allowing newbie player Joe, who's account may be hacked, to access your important scripts may actually save you. 0x04: Changing passwords ----------------------------------------------------------------------------- Passwords should be changed, a lot. It should be mandatory for each player to change their password at least every six hours. To change a password, use the "passwd" command. Changing passwords may also seem like a trivial step, but may prevent some Social Engineering or sniffing problems. Who knows, your password may be sniffed two minutes before you were going to change your password anyway, and the other team may not have enough time to get into your box. 0x05 Downloading and installing a new kernel and any sources or libraries ----------------------------------------------------------------------------- After identifying your system, adding users and groups, and setting a password policy, it is finally time to start downloading programs. One of the first things you may want to do is upgrade your kernel (if you have decided that the current one is not what you want). Epic wrote a very good, easy to follow paper on this that can be found on the RootHack website. The next step you want to take is to download the libraries you know you will need as dependencies that you may not have. You generally will not have to do this because the idea is to strip your box down as much as possible, but if for some reason your box did not come with perl libraries that you need for coding, now is the time to get them. It is also the time to download any compilers, programs, or daemons that you may be installing later on. Might as well get that out of the way. 0x06: Setup Directory Security FSTAB ----------------------------------------------------------------------------- FSTAB is a very, very handy *nix utility that allows for File System Security. There is an indepth paper on FSTAB on the RootHack site, but here are some ideas on what you should do with it: i) Create an FTP only partition with noexec, nouser so that all FTP uploads cannot be accessed by anyone but root and cannot be run from that partition. ii) Seperate / and /home so that you can place restrictions on some partitions and easily do repairs. iii) Perhaps you could put temporary data on a RAM disk to get rid of any information you put on the system through commands with a reboot to not allow any other teams any clue on what you have done. iv) Use nosuid on partitions that the enemy is most likely to get into, knowing where your weakpoints may be. The option nosuid ignores the setuid and setgid bits completely. Note: this can be circumvented easily, but adds just one extra layer on your defense. As you can see, using FSTAB properly is an invaluable addition to your box. 0x07: Removing User/Group id bits ----------------------------------------------------------------------------- This is a pretty key step in securing your box. SUIDs and SGIDs are binaries that allow the user to temporarily run a program as if they were another user. This is especially bad if that user is root. SGIDs set the user temporarily to another group. To find SUIDS and SGIDS, use these two commands respectively: # find / -type f -perm -4000 -print # find / -type f -perm -2000 -print Know that you know where they all are, you can decide which ones you want to keep, and which ones you want to get rid of. 0x08: Checking for world writeable files and directories, and no-user files ---------------------------------------------------------------------------- World Writeable files and directories are a big no-no. They are easy targets because anyone can modify them. To find any world writeable files, use the first command below. To find any world writeable directories, use the second one. #find / -type f -perm -2 -o -perm -20 -ls #find / -type d -perm -2 -o -perm -20 -ls No user files are also dangerous and should be avoided (except in /dev). To find them, use: #find / -nouser -o -nogroup After finding them, verify its integrity, then change the owner. 0x09: Finding daemons you don't want and how to remove them ---------------------------------------------------------------------------- Daemons are generally loaded by inetd, a "super daemon" of sorts. On some newer distributions, xinetd has been used as a "secure" alternative. Their differences are a topic for another paper. All you need to know for now is that daemons are called from (x)inetd when someone tries to conenct to the system. For example, if I tried to telnet to my own box, (x)inetd would tell telnetd to init. The information can be found for this in /etc/inetd.conf and /etc/xinetd/. There are several different configuration files found in /etc/xinetd/ that tell which services are set to run. /etc/inetd.conf has tells you what daemons inetd is set to init. For inetd, those daemons that are commented out (#) will not load. In xinetd, the daemon file has to be removed. After you have completed this, make sure you kill -HUP the (x)inetd pid. If you want to check what services you are running, portscan yourself. 0x0A: Backdooring your own machine ---------------------------------------------------------------------------- This section could be the topic of an entire paper. Perhaps even more than a paper. There are thousands of possibilities. You could simply create a suid, or you could have a program that setgid()s and setuid()s. You could be as complex as to install a kernel module that sets you as root when a certain environmental variable is set to a certain value (thank you eps)! As you can see, the possibilities are endless. But what is the point anyway? Well, lets say your box was to be rooted. How are you going to get back in? Well, if the other team doesn't know that you have a backdoor, or at least hasn't found it yet, you still have a chance of getting your box back and kicking them off and securing it. On the flip side, they can always find your backdoor and use it against you, using it to get root. One idea would be to have 4 or 5 backdoors, each one giving you progressively more and more power. Backdoor A gives you access to backdoor B, which gives you access to backdoor C, etc. By doing this, if the other team is looking for backdoors, it requires to find more than one. And if they are to find one and try to exploit it, they would have to find the ones before it to be able to use it. The problem with this? If they are root and remove one link from the backdoor chain, you are locked out. So you can see the ups and downs of backdooring your own box, and a few of the many, many ways you can do it. I recommend you go find something to read on this. 0x0B: Kernel Modules ---------------------------------------------------------------------------- What are kernel modules? Kernel modules are loadable objects programmed to give administrators (and hackers) more control over the system. For example: the gateway box (as of now) has a kernel module to hide certain processes. There is a plethera of kernel modules available, and you can even code your own. Some hide processes, work as backdoors, give better logging capabilities, add more defense, etcetera. On the flip side, hackers can always use them against you too when you are rooted. They are definitely worth looking at. 0x0C: Checking where logging output goes ---------------------------------------------------------------------------- Logging is very, very important when administrating a box. To find where things are logging to, view the /etc/syslog.conf file. Touching this file (I believe) is off limits! However, it lets you see where epic is sending the log files too (and maybe you can find a way to capture the logs of other people's boxes). Anyway, by looking at this file (I am not going to go into understanding how to read it, find another tutorial), you can see how to check your own logs. Checking your logs...even coding some sort of log sniffer, is crucial! I would recommend you check your logs as often as possible for anomalies. Another thing you might want to check (if epic has set it up this way) are the cron jobs, which may be how epic is sending the log files. He may have it set up that every hour the logs are sent to a backup box. Who know? Your actions will really depend how the logging is set up. Simply realize that your logs may be sent out into the open...but so are the other teams'. 0x0D: Running fake daemons ---------------------------------------------------------------------------- This really isn't that hard. Port scanning becomes a pain when a team has binded 1000 ports to /dev/null, or worse, set up 1000 fake ssh daemons and you have to spend the time to find the real one. By fake ssh daemon, I mean one that would be convincing to a port scanner, such as a daemon that prints some sort of SSH banner and sends a request for key verification. This can be a real big pain to any teams trying to get information on your box. A good tool to set this up is "portsentry". 0x0E: Other ---------------------------------------------------------------------------- This is some other, general information. i) Commands to Learn: a) atrm: deletes all the jobs in the at file of a certain user. b) chgrp: changes the group possession of a file or directory. c) chmod: Changes the permissions of a file/directory. d) chown: changes the owner of a file/directory. e) df: shows free disk space. can be used to find info on other systems. f) du: prints disk usage by each directory and its sub directories. g) find: huge command. look at its arguments to find specific information on files. h) finger: gives you information on a user i) grep: a pattern matching command. very complex and can be used in a varieties of ways. j) groups: see what group a user is in. k) id: shows your group and user ids l) kill: kill terminates a process m) ln: creates a symbolic link between files. n) ps: shows current processes o) strings: pattern matcher for strings in binary files. p) umask: same as chmod q) uname: helps find information on your system r) w: shows you who is on at the time and what they are doing. ii) Ideas: a) Move /bin, /sbin, and /usr/bin so that anyone who does root your system will not be able to use system tools. Change them to something like /bin2, or maybe move them into /tmp or something. When you log on, change your PATH environment setting so you don't have to add the path to every command. b) Open some fake ports. Open a lot of them, making it hard for port scans to be effective. c) Place a fake shadow file in /etc d) Create a chroot environment for programs like SSH, FTP, etc, unless a certain string is sent. e) Code an IPS (Intrusion Protection System) that kills users based on certain "questionable" parameters. For example, if you check that their current process has /etc/passwd in it, you might want to kick them (they could be ripping it and or adding an entry). f) Run MD5 sums on your files. There are several perl tools out there which do this as a cron job (every 5 minutes?). Get creative. Conclusion: ---------------------------------------------------------------------------- That is the end for now. If you have a section you would like to add, send it to me and I will put it in. This file will change with each wargame that takes place, so keep looking for new defense techniques! ---------------------------------------------------------------------------- Thanks to everyone who wrote a great whitepaper. Contact: .irc.hack3r.org #chat .visage@javaspot.net ----------------------------------------------------------------------------