- HACKING UNIX - PART THREE: AFTER THE BREAK-IN ---------------------- Edit started: 01-18-02 (MM-DD-YY) Edit finished: 02-20-02 (MM-DD-YY) By: XT - [DuHo] &** This is a multi-part tutorial, &** please check our website for other &** parts: &** http://duho.cjb.net & & Make sure you have read PART ONE and PART TWO before proceeding & & & ****** INDEX: 0. - Forword 1. - Introduction 2. - Hiding your source location 2.1 Hopping the internet 3. - Wiping the logs 3.1 UTMP 3.2 WTMP 3.3 LASTLOG 3.4 Using logwipers 3.5 Other logs 3.6 Wiping the plaintext logs 4. - Installing rootkits 4.1 Trojaned binaries 4.2 Kernel Modules 5. - Installing backdoors 5.1 Basic local backdoors 5.2 Basic remote backdoors 5.3 Trojaned services 5.4 Advanced Backdooring 5.4.1 Covert channels 5.4.2 WebApplication backdoors 5.4.3 Others 6. - Spy! 6.1 Sniffers 6.2 Other stuff 7. - Final words **************************************************************** 0. Forword This is the third part of the HACKING UNIX series already. To try out stuff discussed in this tutor, try it out on your own system and mail me your IP address ;^}. I have written some code specially for this tutorial. But note that you do not have to understand C programming to read this guide! Also, don't over-estimate my programming skills, I'm still learning... However, feel free to use my source code in your personal programs if you find it usefull. ******** In no way am I nor any member of DuHo responsible for criminal activity or damages caused by (ab)using this information. ******** 1. Introduction You have been up all sunday night, hacking this computer. Your wrists hurt (you probably have some kind of Repetitive Strain Injuri). But you won't give up, yet you hit some more keys on the keyboard. You hear your harddisk copying another program file into memory, the LEDs on your modem light up. You don't know what this program does exactly... all you know it is somehow attacking your victim. While you're waiting, you light up another sigarrette. At THAT moment your monitor prints a hopefull message: sh# _ You get this weird feeling in your stomach. It feels great, but at the same time you're scared! You remember you read that things get logged, and that hackers' remove their traces and make sure they can get back in. But HOW????? Don't worry kid, just follow me. 2. Hiding your source location Okay, say you really got into that system, and you forgot to remove a few (or all ;^)) traces of your visit. If the sysadmin finds you in the logs, or through regular programs... you are nailed. Your inet address will probably show up, and you'll be busted. { Though not many sysadmins check logs all day, believe me. But, you got to be paranoid, and *atleast* make sure there is no chance of detection through regular means. } But because you cannot always be sure you can manipulate logs (e.g. when they use a seperated logging server) and they might have some additional security tools that you aren't aware of, you got to make it really hard for them to actually trace you back to your real home. This can be done in various methods; wingates, dialups from tapped phone-lines, internet cafes or connections from other shells you hacked. 2.1 Hopping the Internet Connecting through hacked shells is like hopping through various hosts on the net before connecting to the victim. { Warning: Even though your real source is hard to trace, remember it's not the same as 'untracable', so do a good job at removing your traces everytime: stay paranoid! } You need your toolbox on these shells you have access to, so you can attack from there. For example: ------------ sample ------------ bash# ./backdoor-client owned.box.net 54232_ Password: t4Ab0$-aa Have a nice time! sh# cd '.. '_ sh# ls_ wu260.c clear.tgz nmap.tgz rootkit.tgz nc.tgz bsd-lkm.tgz libnet.tgz linux-lkm.tgz pwipe.c sh# _ ------------ ~etcetera ------------ If you have the tools you need on an owned box, you can do all the work from there. { Note: It's best to have your complete toolbox (exploits etc.) on the box you are about to use to attack from *before* you attack another system because this saves lots of time uploading stuff you gonna need. } 3. Wiping the logs Most machines you access and play with log many things. If you don't wipe these traces, the admin will understand the system might be hacked and may investigate further. The admin might be paranoid and reinstall the box more secure so you lose access, or even the admin might do anything he can to trace you back, including a call to the FBI! If you are a little bit smart, you will remove traces you left immediately after you got root and you install backdoors that bypass logging for future access. What NOT to do: Don't *delete* logfiles, most admins will find out. You should also *only* remove the entriess that record *your* activities on the system. 3.1 How to find them Most *nix systems have a file called /etc/syslog.conf. Read it, it looks something like this: ---------- auth,authpriv.* -/var/log/auth.log *.*;auth,authpriv.none -/var/log/sys.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log mail.* -/var/log/mail.log user.* -/var/log/user.log *.emerg * ---------- Here you find the logs that are kept by syslog. That is; processes that use the syslog daemon to log events. { Please note that I'm saying that this goes up for the processes that log through syslog daemon *ONLY* } They might also log themselves without using syslog, e.g. in case syslogs' file format doesn't work for them. For example, HTTP requests on Apache servers don't get logged through syslog. And when you accessed the system through a CGI bug, these traces are not removed when you only cleaned syslogs' logs. Therefor you remove entry's from access_log like it's done with this quick&dirty command: ---------- # grep -v '' /path/to/access_log > a && mv a /path/to/access_log ---------- or you could use my plaintext logwiper found in chapter 3.8. But, there are a few special logfiles, and these are (e)special(ly) dangerous ;^) (PHEAR!); utmp, wtmp and lastlog... and because of that I have given each of them a seperate paragraph. 3.2 UTMP You can see yourself in utmp, using: ---------- # who root tty1 Jan 25 19:30 root tty2 Jan 25 19:31 root tty3 Jan 25 20:26 # ---------- We *need* to use a command like 'who' to extract output from the utmp file. That is; it's not a plaintext file, it's binary and you cannot edit it with your plaintext editor (PHEAR MORE!). You need a special logwiper for that one, and we're going to use my favorite logwiper for this job because I'm the one that's writing and you're not. Let me introduce; 'clear', written by van Hauser [thc]. Clear will be utilized in paragraph 3.5, but first a little more background on the UTMP file, why it exists. utmp contains the currently active (logged-in) users. Some programs use this file to lookup these users, and find more info about them. Some programs that depend on the utmp file are 'who', 'w' and they are used frequently. 'w' gives long output; like the source IP address, user idle time, cpu usage, what program he is currently running... etc. 3.3 WTMP wtmp keeps all logins and logouts, in almost the same fileformat as utmp. The command 'last' uses the wtmp file to see which user logged in when, which tty he used, and from where he was connected It looks like this: ---------- # last root tty2 Thu Jan 31 09:09 still logged in root tty1 Thu Jan 31 08:49 still logged in runlevel ~ 2.4.16 Thu Jan 31 08:49 reboot ~ 2.4.16 Thu Jan 31 08:49 shutdown ~~ 2.4.16 Thu Jan 31 08:32 - crash (00:16) runlevel ~ 2.4.16 Thu Jan 31 08:32 root tty1 Thu Jan 31 08:32 - 08:32 (00:00) root tty1 Wed Jan 30 09:56 - 10:16 (00:19) ~etc. wtmp begins Fri Nov 23 21:00:16 2001 # _ ---------- The difference between utmp and wtmp file format is that wtmp includes the '~' and '~~' which indicate shutdown or reboot respectively. 3.4 LASTLOG 'lastlog' contains records containing information about the last time users logged in. A sysadmin might use this command to see for which users shell access can be safely disabled. ---------- # lastlog_ Username Port From Latest root tty2 Thu Jan 31 09:09:12 +0100 2002 bin **Never logged in** daemon **Never logged in** sync **Never logged in** shutdown **Never logged in** halt **Never logged in** mail **Never logged in** nobody **Never logged in** named **Never logged in** l.torvalds pts/3 Sun Jan 6 21:48:35 +0100 2002 b.gates **Never logged in** a.cox pts/5 Sat Jan 2 09:05:01 +0100 2002 r.stallman pts/1 Tue Dec 17 14:52:43 +0100 2001 # _ ---------- All this information is extracted from the lastlog file. 3.5 Using logwipers Okay, it's obvious that you need to remove the traces from the utmp, wtmp, lastlog, utmpx, wtmpx etc. logfiles that may exist on *nix systems. There are log-wiper tools available like cloak, zap and clear. We will use clear for the job, because it is hard to detect a logfile was manipulated when it is used. So download clear13.tgz, it is here: http://www.thehackerschoice.com/releases/thc-uht1.tgz. This package contains clear13.tgz among other quite good unix hacking tools. Clear 1.3 consists of two programs, one for removing only the last entry of the user and one for removing all appearances of the user. Set the right path to wtmp, utmp, lastlog, wtmpx, utmpx or those that exist by editing the #define's in the sources. Using /etc/syslog.conf you can probably find out where they are. 3.6 Other logs If you have read syslog.conf carefully, you noticed that there are more logs than wtmp, utmp etc. These other logfiles are most likely plain text, and their records seperated by newlines. They also have to be manipulated, as they may also contain traces of your activity. You also have to remove traces from webserver logs, ftpd xfer logs, sendmail logs etc, etc. { Warning (once again): *NOT ALL LOGS ARE MAINTAINED BY SYSLOGD* So find them! } 3.7 Wiping the plaintext logs I've written a plain-text logwiper, because I felt like it. It works pretty much like: # grep -v > /tmp/a ; mv /tmp/a ; rm -f /tmp/a The might be your ip-address, in that case... all entries containing your logged ip-address are removed. My tool works like this: ------------------- Compile: # gcc -o pwipe pwipe.c Syntax: # ./pwipe e.g.: # ./pwipe '10.0.0.1' /var/log/httpd/access_log ------------------- It removes the lines from which contain (Yeah I know it's simple). That's all. --- start-of pwipe.c --- /* * Plaintext Log Wipe v1 * 02-08-2002 XT [DuHo] [MM-DD-YYYY] * * Removes lines containing from . * Useful for removing IP-addresses from logfiles for example * * Usage: * gcc -o pwipe pwipe.c * ./pwipe * * ex. * # ./pwipe '192.168.1.231' /usr/adm/messages * * I, nor DUHO is responsible for any damage you might bring to a system * using this tool! * */ #include #include #include int main (int argc, char *argv[]) { FILE *fp; long fsize; long i; char *src; char *dest; char version[] = "Plaintext Log Wiper v1.0 by XT [DuHo]"; printf("%s\n\n", version); if (argc<3) { printf("Syntax: %s \n", argv[0]); exit(0); } // open file read-only if ((fp = fopen(argv[2], "r"))==NULL) { fprintf(stderr, "Unable to open %s\n", argv[2]); exit(1); } // Is there any more direct way to determine filesize? fseek(fp, 0L, SEEK_END); if ((fsize = ftell(fp))<1) { fprintf(stderr, "%s is empty or an error occurred\n", argv[2]); exit(1); } else rewind(fp); // allocate enough memory src = (char *) malloc((size_t)fsize); dest = (char *) malloc((size_t)fsize); // select lines to remove for (i=0;(fgets(src, fsize, fp))!=NULL;) { if ((strstr(src, argv[1]))==NULL) { strncat(dest, src, (size_t)fsize); } else { printf("Selected: %s", src); ++i; } } // reopen file write-only if ((fp = freopen(argv[2], "w", fp))==NULL) { fprintf(stderr, "\nUnable to open file %s for writing\n", argv[2]); exit(1); } // write new logfile to disk if (fputs(dest, fp)<0) { fprintf(stderr, "\nUnable to overwrite file %s\n", argv[2]); exit(1); } else if (i>0) printf("\nSuccesfully removed %d %s!\n", i, i==1 ? "log-entry" : "log-entries"); else printf("\"%s\" not found in %s\n", argv[1], argv[2]); fclose(fp); exit(0); } --- eof --- 4. Installing rootkits Rootkits are used to circumvent logging, hide processes, create backdoors, hide files and directories. When a rootkit system is installed correctly, the attacker is completely invisible for sysadmins through regular tools. 4.2 Trojaned binaries The most common kind of rootkit trojans binaries. Original programs like ls, find, ifconfig, ps, top, netstat, etcetera are replaced with trojaned ones. These trojaned versions hide specific information. In case of 'ls' and 'find' it will hide certain files or directories { which is used for example to hide the directory containing the attackers' toolbox and gathered information (login credentials etc.) } In case of ifconfig it will hide the PROMISC flag for a network interface in case a sniffer runs.*(i'll get back on this) In case of ps and top it will hide processes, like password crackers, network sniffers, attackers' login process. In case of netstat it will hide connections and backdoor-servers. When you have installed the rootkit, check if the creation and modification date is the same as the original, so it will be harder to see it's not a legitimate binary. You can also use a file resizer to change the size of the trojaned binary to that of the original. Allright, the trojaned binary is obviously bigger than the original, but you can strip symbols from the trojaned one using 'strip', and then padd it with garbage till it is exactly the same size as the original for example, or use your assembly skills to shrink it. But then still you can't do much against programs like tripwire. { Programs like tripwire use cryptographic hash signatures that can verify if a binary is legitate. } 4.3 Kernel modules An alternative to trojaned binaries are loadable kernel modules. Kernel modules work like device drivers at kernel level, and are loaded during runtime. They can intercept system calls and through this method hide information, which is interesting to us ofcourse. Kernel modules are harder to detect than trojaned binaries because they don't modify existing binaries. But they can be detected by specific tools, but as far as i know, they only scan for *known* LKM rootkits (so code your own :)). More information on kernel modules (and rootkits): http://www.w00w00.org/files/articles/lkmhack.txt // Linux LKM Tech http://www.thehackerschoice.com/papers/LKM_HACKING.html // Linux LKMs; nearly complete reference http://www.thehackerschoice.com/papers/bsdkern.html // BSD LKMs; attacking FreeBSD http://www.thehackerschoice.com/papers/slkm-1.0.html // Solaris LKMs; attacking solaris http://phrack.org/show.php?p=58&a=6 // Advances in linux kernel hacking Real-life modules: http://www.neuralcollapse.f2s.com/files/Synapsys-lkm.tar.gz // linux lkm http://www.pkcrew.org/tools/Rial.c // linux lkm http://packetstormsecurity.org/groups/thc/slkm-1.0.tar.gz // solaris lkm http://www.team-teso.net/releases/adore-0.42.tgz // my favorite linux LKM 5. Installing backdoors So we have wiped the logs, we have hidden our presence and uploaded the toolbox. We still have to make sure we can get back in. That is; we need to place one or more backdoors into the system. Some more common backdooring techniques will be discussed in this chapter. { "Some more common" means that not even half of the techniques are introduced, this is because I think the number of backdooring techniques are only limited to your imagination. When you have full-access to a system, almost anything becomes possible. } Local, and remote backdoors are explained. { Remote backdoors are individual programs and can be directly interacted with remotely. Local backdoors use existing services which are backdoored. } 5.2 Basic Local backdoors You could simply trojan the login or telnet binary to give you a rootshell when you type in some magic string. e.g.: ------------------- # telnet victim.tv Trying xxx.xxx.xxx.xxx... Connected to xxx.xxx.xxx.xxx. Escape character is '^]'. login: THE_MASTER Telnetd: I'm at your service sir! victim# ------------------- Obviously, this extra feature into telnet is not programmed to log your visit, in fact it might also automatically instruct some local LKM rootkit to hide your process and more. And ofcourse any service with root privilege is a subject for being trojaned this way. 5.3 Basic remote backdoors You may have worked with windows backdoors; netbus, bo or that modified netcat-nt backdoor which pipes a cmd shell for use on NT boxes. For a unix environment you could write backdoor that forwards shell commands to the shell, and returns the results through TCP or UDP connections. The basic remote backdoors are the easiest and most effective way to backdoor a system, but at the same time not very stealthy. A simple portscan reveils the open port, and might be easily recognized by an admin as a non-service. Ofcourse your backdoor could listen on a port that is less likely to raise suspicions (like not using port 1337 or 31337), or use other techniques to let the admin think it is a legitimate and required service (emulating a well-known service or something). Or you could put it on a port, where you would normally find a well-known service. But despite all this, it's not a very elegant method. 5.4 Advanced backdooring In this paragraph I introduce some more advanced techniques used to get back in to a system. 5.1 Covert channels Communication is done through packets. They contain the actual data to be transferred along with a header with the details about the content of the packet. The header contains standard fields and some optional fields with information. Some of these fields can contain random data without the risk of creating an illegal packet. As you may have guessed, a backdoor could communicate with a backdoor client through the use of these covert channels. One of the protocols that can be targeted is ICMP, through the use of the data section (where normally timing information is put) of ICMP ECHO REQUEST and ICMP ECHO REPLY packets (the kind that PING uses). Details about using ICMP for tunneling is detailed in whitepapers released in phrack: http://www.phrack.org/phrack/49/P49-06 http://www.phrack.org/phrack/51/P51-06 It also contains source code of a backdoor using this kind of tunneling. The use of such techniques prevents your backdoor from being detected using regular portscanning techniques, it also won't show up in netstat. A disadvantage is that this kind of tunneling is not very reliable for communication. 5.4.2 Webapplication backdoors I could imagine you writing a simple PHP or CGI script that accepts commands, it could execute these through a SUID shell (a /bin/sh with root privilege). This way you can bypass firewalls that may exist without having to change ruleset. It is also reliable, but may also be discovered by a good sysadmin. 5.4.3 Others I can come up with other types of backdoors. Like a backdoor that doesn't listen to incoming connections, but one that connects to your server... (which might help when bypassing firewalls which filter only incoming connections). You could write an apache module that is a backdoor. You could even put a security problem in a service application so you can get back in for example, just use your imagination! 6. Spy! Spy on the users! Any information from people using the system might help you attacking other systems. From one system you can get into other systems on that network but also on others. Maybe the sysadmin uses the same password everywhere, so check where he connects to and have a look there ;^). 6.1 Sniffers A sniffer is a program that puts a network device into promiscuous mode, which means that it tells the network device to forward any traffic that physically passes the wire. The sniffer then translates traffic to more human-friendly format. Some sniffers only sniff packet headers (used for network debugging), and some also grab packet contents, this includes passwords etc. When people on the system use telnet, ftp, smtp, pop etc. the information is plaintext *not ciphered!* and you gather lots of new logins/passwords which can be used to crack other systems. In some other part of 'Hacking Unix' I will tell you more about this. 6.2 Other stuff Just walk through the target system and you will discover much more information. Sometimes you find plaintext shell script that contain passwords, you can check history files like (.bash_history) which might reveil interesting information, databases with plaintext passwords... anything! 7. Final words (for this part...) This part was more an introduction than a guide. It's impossible to explain all about the methods used in the underground. It's too much, and you would get bored. I hope you atleast understand the importance of wiping traces, and the part of hiding your source location in case they try to trace you back home. Please take a look for new 'Hacking Unix' parts during the next couple of months. XT [DuHo] 2001 Visit http://duho.cjb.net/ for updates or new parts of this tutorial every now and then. -EOF- Size: 24576 bytes chars: 23085 Words: 3493 Lines: 687