IP Spoofing and How to Prevent It
Contents
IP
addresses, the ZIP codes of cyber space
Rlogin, the Achilles foot of Unix
Firewalls, the computer’s moat
A Proposed Alternative Protocol
TCP/IP Port Number and Other Options
Key Exchange and Server Host Authentication
WHAT MAKES A SYSTEM SECURE?
(From alt.security FAQ)
"The only system which is truly secure is one which is switched off
and unplugged, locked in a titanium lined safe, buried in a concrete
bunker, and is surrounded by nerve gas and very highly paid armed
guards. Even then I wouldn't stake my life on it."
- originally from Gene Spafford
Does the above statement seem paranoid? Well, it is our belief that by the time you have finished reading this paper you will have changed your mind. As the world becomes increasingly dependent on computer systems for the storage and processing of it’s data, the need for designing secure systems has increased. But the very nature of computer systems, i.e. their connectivity and ease of use, makes the task of designing completely secure systems very difficult, if not impossible.
So most computer designers and users have settled for systems that are “as secure as possible” i.e. systems that make unauthorized access difficult but not impossible. In this paper, we will attempt to discuss the system that is in most common use today and its security weaknesses.
Over the past decade, the number of hacking incidents has increased at an alarming rate. The most notorious of these attacks are those performed by Kevin Mitnick. In this paper will attempt to explain one of the methods used by this hacking guru that gained world wide fame because of its novelty at the time and because the hacked system belonged to a security specialist.
Before delving into the technicalities of system security, there are a number of terms and concepts that should be explained. We will dedicate the firsts few paragraphs of this paper to the explanation of these terms and concepts. It should be realized, however, that it is not the purpose of this paper to explain these terms and concepts in detail, thus we will only introduce these concepts in order to make this paper self contained, if the reader is interested in these topics there are numerous books on the market that provide a much more thorough treatment.
TCP/IP is a suit of protocols that was developed to allow cooperating computers to share resources across a network. It was designed by a group of researchers centered around the Arpanet (Advanced Research Projects Agency), the forerunner of the Internet that was developed by the US military. This suit is the backbone of the Internet.
It should be noted that the TCP/IP suit is not made up of the TCP and IP protocols only; it is a huge suit containing many protocols that facilitate communications between computers across networks. However, the two most important protocols in the suit are TCP and IP, hence its name.
The Internet is a collection of networks including the Arpanet, NFSnet and other military, academic and research networks. These networks are joined together through the public telephone system with the aid of TCP/IP. Most of the protocols in the suit are responsible for low-level data communications functions and are used by many different applications. Examples of these protocols are TCP, IP and UDP. Others, such as ftp, telnet etc., are used for specific tasks such as file transfer and remote login to a computer on the network.
To save time and space we will only explain the TCP and IP protocols in detail, the remaining protocols will be explained as the need arises through out the paper.
TCP: - short for Transmission Control Protocol, this protocol is responsible for breaking up data into datagrams, i.e. small chunks of data that can be transmitted over a network, reassembling them at the other end, resending data that gets lost on the way, and putting things back in the right order. To explain this further, let us assume that you want to transmit a file to some computer on the Internet from your computer. The first thing that TCP does is to break the file into manageable chunks that can be transmitted across the network. To accomplish this task TCP needs to know what packet size your network can handle, this is determined at the time that the connection is established. Each computer involved in the data communication taking place sends the size of datagrams that it can handle and the TCP implementation chooses the smallest. TCP then appends a TCP header to the datagram. This header is made up of 20 octets (the word octet means eight bits, but we don’t use the word byte because not all the computers on the internet use 8-bits bytes), but the most important of these are the source and destination port numbers and a sequence number. The port numbers are used to keep track of different conversations on the Internet, and the sequence numbers are important to determine the order in which to reassemble the data at the other side of the communication channel. The last statement may seem strange to you. But it is possible, and, in fact, probable that two different datagrams from the same file follow different routes to their destination, and there is no way of insuring that the datagrams arriving at the receiving end of the transfer are in the right order without the use of sequence numbers. There is another octet in the TCP header that may be of interest from the security specialist’s point of view. This octet is the checksum; the checksum is a number that is calculated by the computer based on the values in the datagram. When the datagram is received at the other end of the transmission, the receiving computer also calculates the checksum and compares it with the checksum sent with the datagram, if they don’t match then an error in transmission has occurred and the datagram is re-transmitted, otherwise the datagram is accepted. The above is a very brief description of the TCP protocol, for further information see the technical definition of the TCP protocol in the IEEE standards publications and the relevant RFCs.
IP: - short for Internet Protocol, this protocol is responsible for the routing of datagrams from the source computer to the destination computer. At first sight this may seem trivial when compared to the functions of the TCP protocol, but closer examination shows that this is not so. In a large network such as the Internet, the datagram sent from one computer to another may pass through many different networks and computers before it reaches its destination. It is also possible that a certain path on the Internet may be out of service for a certain time period, and it is the task of the IP protocol to overcome all these problems and choose the fastest route between the source and destination of a datagram. The IP protocol is invoked by the TCP layer that passes it the IP address of the destination computer. The IP protocol adds its own header to the datagram to enable gateways and other intermediate systems to handle the datagram. The IP header is made up of a 32-bit source and destination address (this will be explained in detail later), the protocol number and the checksum. The purpose of the checksum, source and destination numbers are as explained above when discussing the TCP protocol. The protocol number is used to determine which protocol invoked the IP protocol, since any protocol in the TCP/IP suit can invoke the IP protocol. This is a very brief explanation of the IP protocol, for further information read the official IEEE or RFC IP standard or any book that treats TCP/IP networks from an implementer’s point of view.
The references in appendix B provide a lot of information about Ethernet headers and other non-TCP/IP protocols such as x11. While this material is not essential for the understanding of this paper, it provides additional information that may be useful if you are considering the possibility of non-TCP/IP based attacks. These topics, however, are beyond the scope of this term paper.
IP
addresses, the ZIP codes of cyber space
When we were discussing the IP protocol, we mentioned that the IP header contained a 32-bit source and destination address. In this sub-section, we will explain the format of this address.
The IP address is divided into four eight-bit numbers, which are written in decimal for simplicity. When the Arpanet was first designed, the number of computers connected to the network was relatively small and the experts at that time developed a system of classifying IP addresses into three categories according to the number of computers available in each organization. This system is now inadequate for the large number of computers connected to the Internet, but it is still used in most old systems. In this paper, we will explain the old class based method of categorizing IP addresses, known as IPv4, because it is still the most common method of managing IP addresses on the Internet.
As we have mentioned before, the IP address is a 32-bit number divided into 4 octets separated by a period. In class A IP addresses the first octet of the IP address is the network number leaving 24-bits for the host numbers. These addresses have their first octet a number between 1 and 126. Class A addresses are reserved for systems that have a lot of computers connected to them and can thus make proper use of the 24 bits used for the host number.
Class
B addresses use the first two octets as the network number thus leaving 16 bits
for the host numbers. These networks use 128.1 through 191.254 as the network
number. These addresses are reserved for networks that don’t need the full 24
bits that are available as host numbers in class A addresses but still need a
relatively large host address space.
Class C addresses use the first three octets for the network number in the range 192.1.1 to 223.254.254. These addresses provide 255 host computers using eight bits for the host address space. These addresses are given to organizations that don’t have a lot of host computers.
Although this system of classified addresses worked out fine for the old systems, it is not flexible enough for systems that do not need the full 24 bits of the Class A addresses but need more than the 16 bits offered by Class B addresses.
To
solve this problem subnets have been developed so that a class B address can be
used to represent more hosts than 16 bits can handle. We will not explain this
system in depth nor will we explain the new classless system of IP addressing,
known as IPv6, which has developed to overcome the limitation of the old system
of classified IP addresses since these topics are beyond the scope of this
paper.
Unix, the lingua franca of computer servers
This section is very pertinent to computer security, because a large amount of the computer servers on the net are running the Unix OS, the security of this system is one of the first topics that need to be covered if we are to understand computer security on the net.
Although there are many other OS’s in use today, the only one that we will explain in depth will be Unix. After we have explained the basics of Unix, we will then explain it’s security weaknesses and how they can be exploited by malicious users.
Unix is the first operating system to be written using a high level language. It was developed as a networking OS that is easy to use and that can be enhanced by shell programming to perform custom operations ( more about this later).
The Unix file system is different from the FAT file system in that it provides a security scheme that operates on the file level. When a user logs on to a Unix, or Linux, machine (s)he is prompted for a user name and password. Based on this user name and password the user is allowed certain rights on individual files. In Unix, there are three categories of users
1) Owner
2) Group
3)
Other
Each of
these categories can be assigned different access rights. Based on these rights
a user can read, write or run a file.
The following is a brief list of the most commonly used
Unix commands
THE COMMANDS
------------------------
ls -This command lists the files and subdirectories in a directory. If you
simply type "ls", it will display the files in your current directory.
You can also specify the pathname of another directory, and it will
display the files in it. It will not display hidden files (files whose
name begins with a period).
Options:
a -This option will display all files, including hidden files.
Example:
$ ls -a
. .. file1 source
$
cd -This is the command used to move from one directory to another. To go
to a directory directly below your current directory, type "cd
<dirname>". To move up to the directory directly above your current
directory, type "cd .." You can also jump to any directory in the
system from any other directory in the system by specifying the path-
name of the directory you wish to go to, such as "cd /usr/source".
Example:
$cd /usr/source
$
pwd -This prints out the pathname of the directory you are currently in.
Useful if you forget where you're at in the system tree.
Example:
$pwd
/usr/source
cat -Displays the contents of a text file on the screen. The correct syntax
is "cat <filename>". You can use basenames or pathnames.
Example:
$cat memo
Bill,
Remember to feed the cat!
-Martha
$
rm -This deletes a file. Syntax: "rm <filename>".
Example:
$rm file1
$
cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you
wish to copy, and file2 is the name of the copy you wish to create. If
file2 already exists, it will be overwritten. You may specify pathnames
for one or both arguments.
Example:
$cp /usr/file1 /usr/file1.backup
stty -Displays/sets your terminal characteristics. To display the current
settings, type "stty". To change a setting, specify one of the options
listed below.
Options:
echo -System echoes back your input.
noecho -System doesn't echo your input.
intr 'arg' -Sets the break character. The format is '^c' for control-c,
etc. '' means no break character.
erase 'arg' -Sets the backspace character. Format is '^h' for control-h,
etc. '' means no backspace character.
kill 'arg' -Sets the kill character (which means to ignore the last line
you typed). Format is the same as for intr and erase,
'^[character]', with '' meaning no kill character.
Example:
$stty intr '^c' erase '^h'
$stty
stty -echo intr '^c' erase '^h' kill '^x'
lpr -This command prints out a file on the Unix system's printer, for you
to drop by and pick up (if you dare!) The format is "lpr <filename>".
Example:
$lp file1
ed -This is a text file line editor. The format is "edit <filename>". The
file you wish to modify is not modified directly by the editor; it is
loaded into a buffer instead, and the changes are only made when you
issue a write command. If the file you are editing does not already
exist, it will be created as soon as you issue the first write command.
When you first issue the edit command, you will be placed at the
command prompt, ":" Here is where you issue the various commands. Here
is list of some of the basic editor commands.
# -This is any number, such as 1, 2, etc. This will move you down
to that line of the file and display it.
d -This deletes the line you are currently at. You will then be
moved to the previous line, which will be displayed.
a -Begin adding lines to the file, just after the line that you
are currently on. This command will put you in the text input
mode. Simply type in the text you wish to add. To return to the
command mode, type return to get to an empty line, and press
the break key (which is whatever character you have set as your
break key). It is important to set the break character with
stty before you use the editor!
/ -Searches for a pattern in the file. For example, "/hello" would
search the file from your current line down for the first line
which contains the string "hello", and will move you to that
line if it finds one.
i -Insert. Works similar to a, except that the text is inserted
before the line you are currently on.
p -Prints out a line or lines in the buffer. "p" by itself will
display your current line. "#p" will display the line "#".
You may also specify a range of lines, such as "1,3p" which
will display lines 1-3. "1,$p" will print out the entire file.
w -Write the changes in the buffer to the file.
q -Quit the editor.
Example:
$edit myfile
Editing "myfile" [new file]
0 lines, 0 characters
:a
I am adding useless text to myfile.
This is a test.
^c [this is assumed as a default break character in this example]
:1,$p
I am adding useless text to myfile.
This is a test.
:2
This is a test.
:d
I am adding useless text to myfile.
:w
:q
$
grep -this command searches for strings of text in text files. The format is
grep [string] [file]. It will print out every line in the file that
contains the string you specified.
Options:
v -Invert. This will print out every line that DOESN'T contain
the string you specified.
Example:
$ grep you letter
you’re late
I think you're going to get caught.
$
who -This will show the users currently logged onto the system.
Example:
$ who
root console Mar 10 01:00
uucp contty Mar 30 13:00
bill tty03 Mar 30 12:15
$
Now, to explain the above output: the first field is the username of
the account. The second field shows which terminal the account is on.
Console is, always, the system console itself. On many systems where
there is only one dialup line, the terminal for that line is usually
called contty. the tty## terminals can usually be either dialups or
local terminals. The last fields show the date and time that the user
logged on. In the example above, let's assume that the current time and
date is March 30, and the time is 1:00. Notice that the time is in 24
hour format. Now, notice that the root (superuser) account logged in on
March 10! Some systems leave the root account logged in all the time on
the console. So, if this is done on a system you are using, how can you
tell if the system operator is really online or not? Use the ps
command, explained next.
ps -This command displays information about system processes.
Options:
u -this displays information on a specific user's processes. For
instance, to display the root account's processes:
$ ps -uroot
PID TTY TIME CMD
1234 console 01:00 sh
1675 ? 00:00 cron
1687 console 13:00 who
1780 tty09 12:03 sh
Now, to explain that: The first field is the process number.
Each and every time you start a processes, running a program,
issueing a command, etc., that process is assigned a unique
number. The second is which terminal the process is being run
on. The third field is when the process was started. The last
field is the base name of the program or command being run.
A user's lowest process number is his login (shell) process.
Note that the lowerst process in the above example is 1234.
This process is being run on the console tty, which means the
superuser is logged on at the system console. Note the ? as the
tty in the next entry, for the cron process. You can ignore any
processes with a question mark as the terminal. These processes
are not being carried out by a user; they are being carried
out by the system under that user's id. Next, note the entry
for process # 1687, on the console terminal, "who". this means
that the superuser is executing the who command...which means
he is currently actively on-line. The next entry is interest-
ing...it shows that the root user has a shell process on the
terminal tty09! This means that someone else is logged in
under the root account, on tty09. If more than one person is
using an account, this option will display information for all
of them, unless you specify the next option...
t -This allows you to select processes run on a specific term-
inal. For example:
$ps -t console
will show all the processes currently being run on the console.
Example:
Remember, options can usually be combined. This will show all
the root user's processes being run on the system console:
$ ps -uroot -tconsole
PID TTY TIME CMD
1234 console 01:00 sh
1687 console 13:00 who
$
kill -Kills processes. Syntax: kill [-#] process#. You must know the process
number to kill it. You can, optionally, specify an option of 1-9, to
determine the power of the kill command. Certain kinds of processes,
like shell processes, require more power to kill. Kill -9 will stop any
process. You must have superuser capabilities fo kill another user's
processes (unless he's using your account).
Example:
$kill -9 1234
1234 killed.
$
write -This command is for on-line realtime user to user communications. To
communicate with a user, type "write <username>". If more than one
person is logged in under that user name, you must specify a specific
terminal you wish to speak to. When you do this, the person you wish
to communicate with will see:
Message from [your account name] tty## [<--your terminal]
Now you can type messages, and they will be displayed on that person's
terminal when you press return. When you are finished, press control-D
to quit.
Example:
$ write root
Hi, I'm a hacker! [This is not advised.]
^d
$
mail -The Unix mail facilities, used to send/receive mail. To send mail,
type "mail <username>". Enter your message and press control-d to send.
To read your mail, type "mail". Your first letter will be displayed,
and then you will be given a "?" prompt.
Here are the legal commands you give at this point:
## -Read message number ##.
d -Delete last message read.
+ -Go to next message.
- -Move back one message.
m -Send mail to user.
s -Save last message read. You can specify the name of the file
to which it is saved, or it will be saved to the default file,
mbox.
w -Same as s, but will save the message without the mail file
header.
x -Exit without deleting messages that have been read.
q -Exit, deleting messages that have been read.
p -Print last message read again.
? -Lists these commands.
Examples:
To send mail:
$ mail root
Hi bill! This is a nice system.
-John
^d
$
To read mail:
From john Thu Mar 13 02:00:00 1986
Hi bill! This is a nice system.
-John
? d
Message deleted.
?q
$
crypt -This is the Unix file encryption utility. Type "crypt". You will then
be prompted to enter the password. You then enter the text. Each line
is encrypted when you press return, and the encrypted form is displayed
on the screen. So, to encrypt a file, you must use I/O redirection.
Type "crypt [password] < [file1] > [file2]". This will encrypt the con-
tents of file1 and place the encrypted output in file2. If file 2 does
not exist, it will be created.
passwd -This is the command used to change the password of an account. The
format is "passwd <account>". You must have superuser capabilities to
change the password for any account other than the one you are logged
in under. To change the password of the account you are currently
using, simply type "passwd". You will then be prompted to enter the
current password. Next, you will be asked to enter the new password.
Then you will be asked to verify the new password. If you verify the
old password correctly, the password change will be complete. (Note:
some systems use a security feature which forces you to use at least
2 non-alphanumeric characters in the password. If this is the case with
the system you are on, you will be informed so if you try to enter a
new password that does not contain at least 2 non-alphanumeric char-
acters.)
su -This command is used to temporarily assume the id of another account.
the format is "su <account>". If you don't specify an account, the
default root is assumed. If the account has no password, you will then
assume that account's identity. If it does have a password, you will
be prompted to enter it. Beware of hacking passwords like this, as the
system keeps a log of all attempted uses, both successful and un-
successful, and which account you attempted to access.
mkdir -This
command creates a directory. the format is "mkdir <dirname>".
rmdir -This command deletes a directory. The directory must be empty first.
The format is "rmdir <dirname>".
mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use
full pathnames, but the new name must have the same pathname as the
old name, except for the filename itself.
We obtained the above explanation from one of the online Unix tutorials, it is by no means a complete list of the commands used in Unix but can serve as a quick introduction to this fascinating operating system.
Now that we have had a brief introduction to the commands used in Unix, let us turn our attention back to the access rights that we mentioned earlier in this paper. When the user performs an “ ls –al “ command on a Unix system something like the following appears :-
drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin
-rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek
In the above example, the directory we are in contains a subdirectory called bin and a file called "startrek". Here is an explantion of the fields: The first field contains the file's type and permissions. Look at the first field of the first line, "drwxrwxrwx". Note the "d" at the beginning. Then see the "-" at the beginning of the first field for the file startrek. This shows the file type. "D" is a directory. "-" is a file. "c" is a device file. ”l” is a link. Now, back to the first field of the first line again. Notice the "rwxrwxrwx". These are the permissions. The permissions are divided into three groups:[user][group][other]. r stands for read, w stands for write, and x stand for execute. "rwxrwxrwx" means that all three classes of users, owner, group, and other, have read, write, and execute permissions to the directory bin. Now look at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some of the permissions. This means that the file was not given that permission. Line 2 shows that the owner has read, write, and execute permissions for the file startrek, members of the owner's group have read and execute permissions but not write (notice the "-" in the place of the group part's w), and all others have only read privileges ("r--"...there are hyphens in the place of the others part's w and x). Now, let's look at the other fields. The second field is a number (in this case, the number is one for each line). This shows the number of copies of this file on the system. The third field shows the name of the owner of file (or directory). The fourth field shows the username of the owner of the file. The fifth field, which is not shown on some systems, shows the name of the owner's group. The sixth field shows the size of the file. the seventh field shows the time and date the file was last modified. the last field shows the name of the file or directory.
Rlogin, the Achilles foot of Unix
Achilles
was a Greek hero how was born to a goddess. The goddess made him immortal by
anointing him with a magic potion that would make him invincible to his enemies,
however she forgot to anoint his heel with the aforesaid potion. When Achilles
was hit in the heel as he was fighting the Trojans he died. What does this have
to do with hacking? Well the rlogin
utility is the Achilles heel of the Unix operating system. It is the weakest
point in an otherwise relatively secure operating system.
The main weakness of the rlogin utility is that it allows IP based authentication. This means that a user can log into a remote system without supplying a password or user name as long as he has a trusted IP.
How does a user get a trusted IP? Well there are two methods; the first is to have a legitimate reason for accessing the remote host on a regular basis. The second is to hack your way into the system. To understand the later we need to understand the former. In Unix, a host trusts another host if that host is recoded in the .rhost file or in the /etc/hosts.equiv file. Once this is done, the trusted host can access the trusting host without giving a password or username. Since the TCP/IP network does not provide any method for ensuring that the IP sent is the actual IP of the sending machine, there is nothing to stop a hacker from forging IP packets that contain the IP of a trusted host so that (s)he can compromise the trusting machine. More will be said about this when we explain the method of IP spoofing.
Firewalls, the computer’s moat
A firewall is a network security product that acts as a barrier between two or more network segments. The firewall is a system (which consists of one or more components) that provides an access control mechanism between your network and the network(s) on the other side(s) of it. A firewall can also provide audit and alarm mechanisms that will allow you to keep a record of all access attempts to and from your network, as well as a real-time notification of things that you determine to be important. The diagram below gives a clearer understanding of this concept: -
 |
A firewall opens communication channels between two or more networks but has no way of knowing what is passing through that channel. As such, the firewall cannot completely eliminate the risk of data driven attacks such as Viruses and Trojans. Firewalls can provide some protection against such attacks, however, by preventing some components such as Activex from being downloaded.
A
usual architecture for firewalls is to make an intermediate level of security
between the internal network and the external network. This layer is called the
DMZ (De-Militarized Zone). It is on this layer that most public information,
such as www, ftp, DNS, e.t.c. is kept. This information is protected by the
firewall, but resides outside the internal network, making access into the
internal network unnecessary for those who want to access this information. The
following diagram represents this concept: -
 |
There are many different types of firewalls, each with its unique features. The following is a brief non-exhaustive list of some of these types: -
1) Packet Filters: - A packet filter operates on IP packets. This device will accept or reject packets attempting to cross the network boundary based on information contained in the IP packet header. This information is limited to source and destination address as well as the TCP / UDP port number. A packet filter is unable to make any decision based on the data contained within the packet, or on the state of the communications channel
2) Circuit Filters: - A circuit filter operates at the next layer in the TCP/IP protocol stack. This device filters connections based on information found within the TCP and UDP packet headers. The information used to mediate access is still host-based (source and destination address and port numbers) but also is able to verify the TCP sequence numbers to mediate only a ‘seemingly’ valid information stream. Circuit filters are able to create rules such as "anybody from this computer is able to use FTP to access that computer". A circuit filter is not able to restrict on the basis of user; only on the basis of hosts. A circuit filter relies on a program called a proxy to filter and route the information.
3) Application Filters(or proxy): - Application filters operate at the top level of the protocol stack and require a special program (called proxy) for every application that is to be mediated. The application filter is able to restrict information flow, based not only on all of the packet header information, but also on information that is located within the data stream itself. Application filters allow rules to be set up so that "this user from this computer is able to retrieve files from that other computer using FTP but this user is not able to deposit files using the same protocol". The filter allows access control not only on a user basis but also on what function that user is trying to perform.
4) Stateful (or dynamic) Filter: - The last type of system to be discussed is a stateful filter or a dynamic packet filter. A packet filter looks at every packet and allows or rejects it based only on the information contained within that packet and ignoring the context of that packet in a communications stream. Stateful inspection means that the packet filtering engine is intelligent enough to understand higher lever information like connections and accept or reject packets within context of that information as well. This allows tighter access control rules than can be built on normal packet filtering routers, and also is faster than proxy based firewalls. This type of device however does not have the granularity in creating access control rules as a proxy based system does
Like most other security measures, the task of firewalls can be classified into two: -
A) Identification
B) Authentication
Identification is the act of telling the firewall who you are and authentication is the proof. The most common means of performing authentication at a firewall, or any other computer system for that matter, is by entering a user name and password. Your user name is your identification to the firewall and your password is the authentication.
There are other means of authentication that firewalls use. One of the most common is IP based authentication. Where the user is granted or denied access based on the value of his/her IP address. In this paper, we will show how attackers can take advantage of this authentication scheme to gain illegal access to a protected network.
A firewall provides control of access from one network to the other. The access control can be based on IP packets (in the case of a packet filter or stateful filter), on TCP data streams or UDP datagrams (in circuit filters), or on application data (in application filters).
Packet filters and stateful filters can mediate based on addresses (source and destination) as well as on port numbers, and some IP status flags (e.g. SYN or ACK flags located in the IP header).
Circuit filters can mediate on addresses (source and destination) IP status flags, port numbers and TCP or UDP status flags and sequencing information. Some circuit filters can require user authentication prior to opening the circuit. The circuit filter acts as a pipe through the firewall, allowing information with certain attributes to flow through. This pipe can be turned off by default and require a user action to open it up, that user action can be an I&A (Identification & Authentication) challenge. Even in this case once the circuit is open it has no notion of the user anymore.
Application filters can mediate on user information and application data as well as on all of the information within the IP and TCP packet headers. Application filters know about users and know about the information they are filtering. This type of filter allows rules to be configured which enable filtering on commands within the application protocol. It may allow FTP commands to be used to retrieve and deposit files but not to overwrite or delete files on the server. This type of firewall component is more configurable by the administrator and is able to support a wider range of security requirements and policies.
It is now
time for us to take a look under the hood. First, here is a list of the tools
you will need to reproduce this attack:-
1) Brain, mind or other thinking device
2) The Unix or Linux OS
3) A library that allows you to write TCP/IP packets to the network
Next are some definitions of the symbols that we will use in our explanation :-
A : Trusting machine (our target J)
B : Trusted machine
C : Our machine
Before a connection can be made between two machines a three way handshake must occur, what follows is a brief explanation of the three way handshake : -
1 A ---SYN---> B
2 A <---SYN/ACK--- B
3 A ---ACK---> B
At (1) the client is telling the server that it wants a connection. This is the SYN flag's only purpose. The client is telling the server that the sequence number field is valid, and should be checked. The client will set the sequence number field in the TCP header to its ISN (initial sequence number). The server, upon receiving this segment (2) will respond with it's own ISN (therefore the SYN flag is on) and an ACKnowledgement of the clients first segment (which is the client's ISN+1). The client then ACK's the server's ISN (3). Now, data transfer may take place.
The
SYN and ACK flags are asserted by setting certain bits in the TCP header to the
correct value. We will append to this paper the code that performs this as well
as the other tasks required for IP spoofing attacks.
It is important to understand how sequence numbers are initially chosen,
and how they change with respect to time. The
initial sequence number when a host is bootstrapped is initialized to one. (TCP
actually calls this variable 'tcp_iss' as it is the initial send sequence
number. The other sequence number
variable, 'tcp_irs' is the initial receive sequence number and is learned during
the 3-way connection establishment. We
are not going to worry about the distinction.)
This practice is wrong, and is acknowledged as so in a comment in the
tcp_init() function where it appears. The
ISN is incremented by 128,000 every second, which causes the 32-bit ISN counter
to wrap every 9.32 hours if no connections occur.
However, each time a connect() is issued, the counter is incremented by
64,000. One important reason behind this predictability is to minimize the
chance that data from an older stale incarnation (that is, from the same 4-tuple
of the local and remote IP-addresses TCP ports) of the current connection could
arrive and foul things up. The concept of the 2MSL wait time applies here, but is beyond
the scope of this paper. If
sequence numbers were chosen at random when a connection arrived, no guarantees
could be made that the sequence numbers would be different from a previous
incarnation. If some data that was
stuck in a routing loop somewhere finally freed itself and wandered into the new
incarnation of it's old connection, it could really foul things up.
Note that
this predictability in ISN incrimination no longer exists in newer versions of
the Unix OS, but since most systems on the net still use the old OS, we will
limit our discussion to the old method of incrimination. It is possible for us
to subvert systems that use the new OS’s using this method but it will take
longer to do so. We would have to send a large number of syn packets and try to
determine the algorithm used to generate and increment the ISN.
In the following explanation, we shall use extracts from the tcpdump that was performed on a system that was attacked by Kevin Mitnick the notorious hacker. The first step that a hacker should perform is to determine with what systems the target has a trust relation. This is easily done by performing a showmount –e or an rpcinfo on the target system. For example
showmount –e A or
rpcinfo –p A
These commands show what systems the target has mounted or used for remote procedure calls, these are the systems that the target will most likely have a trust relation with. If you have access to the target system you can check to see if you have read access to the .rhost files (very unlikely) to give you more information about the machines that the target trusts.
Once you have determined the machines that the target trusts you can begin your attack in earnest. We can then send a lot of SYN packets to determine the algorithm used for incrementing the ISN. What follows is an extract from the tcpdump of Tsutomu Shimomura’s computer that was hacked by Kevin Mitnick who had root access to a machine called toad.com
14:18:22.566069
130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477
130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111
130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096
14:18:22.886128
130.92.6.97.604 > server.login: S 1382726964:1382726964(0) win 4096
14:18:22.943514
130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096
14:18:23.002715
130.92.6.97.606 > server.login: S 1382726966:1382726966(0) win 4096
14:18:23.103275
130.92.6.97.607 > server.login: S 1382726967:1382726967(0) win 4096
14:18:23.162781
130.92.6.97.608 > server.login: S 1382726968:1382726968(0) win 4096
14:18:23.225384
130.92.6.97.609 > server.login: S 1382726969:1382726969(0) win 4096
14:18:23.282625
130.92.6.97.610 > server.login: S 1382726970:1382726970(0) win 4096
14:18:23.342657
130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096
14:18:23.403083
130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win 4096
14:18:23.903700
130.92.6.97.613 > server.login: S 1382726973:1382726973(0) win 4096
14:18:24.003252
130.92.6.97.614 > server.login: S 1382726974:1382726974(0) win 4096
14:18:24.084827
130.92.6.97.615 > server.login: S 1382726975:1382726975(0) win 4096
14:18:24.142774
130.92.6.97.616 > server.login: S 1382726976:1382726976(0) win 4096
14:18:24.203195
130.92.6.97.617 > server.login: S 1382726977:1382726977(0) win 4096
14:18:24.294773
130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096
14:18:24.382841
130.92.6.97.619 > server.login: S 1382726979:1382726979(0) win 4096
14:18:24.443309
130.92.6.97.620 > server.login: S 1382726980:1382726980(0) win 4096
14:18:24.643249
130.92.6.97.621 > server.login: S 1382726981:1382726981(0) win 4096
14:18:24.906546
130.92.6.97.622 > server.login: S 1382726982:1382726982(0) win 4096
14:18:24.963768
130.92.6.97.623 > server.login: S 1382726983:1382726983(0) win 4096
14:18:25.022853
130.92.6.97.624 > server.login: S 1382726984:1382726984(0) win 4096
14:18:25.153536
130.92.6.97.625 > server.login: S 1382726985:1382726985(0) win 4096
14:18:25.400869
130.92.6.97.626 > server.login: S 1382726986:1382726986(0) win 4096
14:18:25.483127
130.92.6.97.627 > server.login: S 1382726987:1382726987(0) win 4096
14:18:25.599582
130.92.6.97.628 > server.login: S 1382726988:1382726988(0) win 4096
14:18:25.653131 130.92.6.97.629 > server.login: S 1382726989:1382726989(0) win 4096
The purpose of these SYN requests is to disable the trusted host from sending a RST (reset) packet when it discovers that the target is acknowledging a SYN packet it never sent.
The next step is to determine the ISN incrementing algorithm. What follows is another extract from the tcpdump of the system hacked by Kevin Mitnick that he used to determine the way in which the ISN was incremented :-
14:18:25:906002 apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack 1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096
14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack 1382726993 win 4096
14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R 1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S 1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S 2022208000:2022208000(0) ack 1382726994 win 4096
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R 1382726994:1382726994(0) win 0
14:18:28.054114 apollo.it.luc.edu.996 > x-terminal.shell: S 1382726994:1382726994(0) win 4096
14:18:28.224935 x-terminal.shell > apollo.it.luc.edu.996: S 2022336000:2022336000(0) ack 1382726995 win 4096
14:18:28.305578 apollo.it.luc.edu.996 > x-terminal.shell: R 1382726995:1382726995(0) win 0
14:18:28.564333 apollo.it.luc.edu.995 > x-terminal.shell: S 1382726995:1382726995(0) win 4096
14:18:28.734953 x-terminal.shell > apollo.it.luc.edu.995: S 2022464000:2022464000(0) ack 1382726996 win 4096
14:18:28.811591 apollo.it.luc.edu.995 > x-terminal.shell: R 1382726996:1382726996(0) win 0
14:18:29.074990 apollo.it.luc.edu.994 > x-terminal.shell: S 1382726996:1382726996(0) win 4096
14:18:29.274572 x-terminal.shell > apollo.it.luc.edu.994: S 2022592000:2022592000(0) ack 1382726997 win 4096
14:18:29.354139 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.354616 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 > x-terminal.shell: S 1382726997:1382726997(0) win 4096
14:18:29.755054 x-terminal.shell > apollo.it.luc.edu.993: S 2022720000:2022720000(0) ack 1382726998 win 4096
14:18:29.840372 apollo.it.luc.edu.993 > x-terminal.shell: R 1382726998:1382726998(0) win 0
14:18:30.094299 apollo.it.luc.edu.992 > x-terminal.shell: S 1382726998:1382726998(0) win 4096
14:18:30.265684 x-terminal.shell > apollo.it.luc.edu.992: S 2022848000:2022848000(0) ack 1382726999 win 4096
14:18:30.342506 apollo.it.luc.edu.992 > x-terminal.shell: R 1382726999:1382726999(0) win 0
14:18:30.604547 apollo.it.luc.edu.991 > x-terminal.shell: S 1382726999:1382726999(0) win 4096
14:18:30.775232 x-terminal.shell > apollo.it.luc.edu.991: S 2022976000:2022976000(0) ack 1382727000 win 4096
14:18:30.852084 apollo.it.luc.edu.991 > x-terminal.shell: R 1382727000:1382727000(0) win 0
14:18:31.115036 apollo.it.luc.edu.990 > x-terminal.shell: S 1382727000:1382727000(0) win 4096
14:18:31.284694 x-terminal.shell > apollo.it.luc.edu.990: S 2023104000:2023104000(0) ack 1382727001 win 4096
14:18:31.361684 apollo.it.luc.edu.990 > x-terminal.shell: R 1382727001:1382727001(0) win 0
14:18:31.627817 apollo.it.luc.edu.989 > x-terminal.shell: S 1382727001:1382727001(0) win 4096
14:18:31.795260 x-terminal.shell > apollo.it.luc.edu.989: S 2023232000:2023232000(0) ack 1382727002 win 4096
14:18:31.873056 apollo.it.luc.edu.989 > x-terminal.shell: R 1382727002:1382727002(0) win 0
14:18:32.164597 apollo.it.luc.edu.988 > x-terminal.shell: S 1382727002:1382727002(0) win 4096
14:18:32.335373 x-terminal.shell > apollo.it.luc.edu.988: S 2023360000:2023360000(0) ack 1382727003 win 4096
14:18:32.413041 apollo.it.luc.edu.988 > x-terminal.shell: R 1382727003:1382727003(0) win 0
14:18:32.674779 apollo.it.luc.edu.987 > x-terminal.shell: S 1382727003:1382727003(0) win 4096
14:18:32.845373 x-terminal.shell > apollo.it.luc.edu.987: S 2023488000:2023488000(0) ack 1382727004 win 4096
14:18:32.922158 apollo.it.luc.edu.987 > x-terminal.shell: R 1382727004:1382727004(0) win 0
14:18:33.184839 apollo.it.luc.edu.986 > x-terminal.shell: S 1382727004:1382727004(0) win 4096
14:18:33.355505 x-terminal.shell > apollo.it.luc.edu.986: S 2023616000:2023616000(0) ack 1382727005 win 4096
14:18:33.435221 apollo.it.luc.edu.986 > x-terminal.shell: R 1382727005:1382727005(0) win 0
14:18:33.695170 apollo.it.luc.edu.985 > x-terminal.shell: S 1382727005:1382727005(0) win 4096
14:18:33.985966 x-terminal.shell > apollo.it.luc.edu.985: S 2023744000:2023744000(0) ack 1382727006 win 4096
14:18:34.062407 apollo.it.luc.edu.985 > x-terminal.shell: R 1382727006:1382727006(0) win 0
14:18:34.204953 apollo.it.luc.edu.984 > x-terminal.shell: S 1382727006:1382727006(0) win 4096
14:18:34.375641 x-terminal.shell > apollo.it.luc.edu.984: S 2023872000:2023872000(0) ack 1382727007 win 4096
14:18:34.452830 apollo.it.luc.edu.984 > x-terminal.shell: R 1382727007:1382727007(0) win 0
14:18:34.714996 apollo.it.luc.edu.983 > x-terminal.shell: S 1382727007:1382727007(0) win 4096
14:18:34.885071 x-terminal.shell > apollo.it.luc.edu.983: S 2024000000:2024000000(0) ack 1382727008 win 4096
14:18:34.962030 apollo.it.luc.edu.983 > x-terminal.shell: R 1382727008:1382727008(0) win 0
14:18:35.225869 apollo.it.luc.edu.982 > x-terminal.shell: S 1382727008:1382727008(0) win 4096
14:18:35.395723 x-terminal.shell > apollo.it.luc.edu.982: S 2024128000:2024128000(0) ack 1382727009 win 4096
14:18:35.472150 apollo.it.luc.edu.982 > x-terminal.shell: R 1382727009:1382727009(0) win 0
14:18:35.735077 apollo.it.luc.edu.981 > x-terminal.shell: S 1382727009:1382727009(0) win 4096
14:18:35.905684 x-terminal.shell > apollo.it.luc.edu.981: S 2024256000:2024256000(0) ack 1382727010 win 4096
14:18:35.983078 apollo.it.luc.edu.981 > x-terminal.shell: R 1382727010:1382727010(0) win 0
Note that each SYN-ACK packet sent by x-terminal has an initial sequence
number which is 128,000 greater than the previous one.
Now
that we have all the information that we need we can forge an IP packet and send
it to A. The forged IP packet will seem, from A’s point of view, to come from
B. Since A trusts B, the packet will be acknowledged without requesting a
password.
A will then send an ACK packet to B. Note that we, C, will not be able to see the packet sent to B since it will go directly to B. However, since we have determined the algorithm that A uses to increment its ISN we can acknowledge the packet without seeing it. We now have a one way communication channel open between A and C. it is one way because all A’s replies will be sent to B which A assumes to be the source of the packets we are sending it.
We can now add + + to the .rhost file so that any machine can access A without giving a password. This can be done by the command : - cat + + >> ~/.rhosts.
Note that all the time we are performing this we have filled up B’s TCP/IP queue will SYN requests so that we disable it from responding to any other traffic on the network. Otherwise when A sends its replies, to the packets that we have sent, to B, B will realize that it is receiving data over a channel that doesn’t exist and thus will send a reset packet and our connection will be broken.
After we have added the ++ to the .rhost file, we can then log off and reconnect with our proper IP. The ++ will make A trust ALL hosts on the net, thus we will not be asked for a password. When we are on the system, we can then put a permanent backdoor into the system so that we can access it when we please and then remove the ++ from the .rhost file. We do this because the ++ in this file will be easily discovered and removed by the administrator and we will thus lose our access.
The backdoor can be a Trojan or an addition to the /ect/passwd file that will allow us to re-enter the system whenever we see fit. The details of writing the Trojan is beyond the scope of this paper but is so simple that anyone with the right knowledge can write one that will allow you to use the system for a very long time.
A Proposed Alternative Protocol
Now that we know how an attack can be carried out, it is time to patch up the holes that arose in our penetration test. We will now deal with the most glaring security hole in the system; that of IP based authentication.
In this section we shall attempt to give the technical specifications for designing a new protocol that will use a combination of RSA and IP based authentication. The features of this proposed protocol are: -
1 Closes several security holes (e.g., IP, routing, and DNS spoof-
ing). New authentication methods: .rhosts together with RSA
[RSA] based host authentication, and pure RSA authentication.
2 All communications are automatically and transparently
encrypted. Encryption is also used to protect against spoofed
packets.
5 Client RSA-authenticates the server machine in the beginning of
every connection to prevent Trojan horses (by routing or DNS
spoofing) and man-in-the-middle attacks, and the server RSA-
authenticates the client machine before accepting .rhosts or
/etc/hosts.equiv authentication (to prevent DNS, routing, or IP
spoofing).
6 An authentication agent, running in the user's local workstation
or laptop, can be used to hold the user's RSA authentication
keys.
The proposed software will consist of a server program residing on a server machine, and a client program residing on a client machine. The connection is initialed by the client. The server will listen to a specific port for connection attempts.
The server and the client will be connected via a TCP/IP [RFC0793] socket that can be used for bi-directional communication. When the client requests a connection to the server, the server accepts the request and sends back its identification string. The client parses the server's identification, and sends its own identification. The purpose of the identification strings is to validate that the connection was to the correct port, declare the protocol version number used, and to declare the software version used on each side (for debugging purposes). The identification strings are human-readable. If either side fails to understand or support the other side's version, it closes the connection.
After the protocol identification phase, both sides switch to a packet based binary protocol. The server starts by sending its host key, server key, and other information to the client. The client then generates a 256-bit session key, encrypts it using both RSA keys (see below for details), and sends the encrypted session key, selected cipher type and other information to the server. Both sides then turn on encryption using the selected algorithm and key. The server sends an encrypted confirmation message to the client. The client then authenticates itself using any of a number of authentication methods such as .rhosts or /etc/hosts.equiv authentication (disabled by default), the same with RSA-based host authentication, RSA authentication, and password authentication.
After successful authentication, the client makes a number of requests to prepare for the session. Typical requests include allocating a pseudo tty, TCP/IP port forwarding, starting authentication agent forwarding, and executing the shell or a command. When a shell or command is executed, the connection enters interactive session mode. In this mode, data is passed in both directions, new forwarded connections may be opened, etc. The interactive session normally terminates when the server sends the exit status of the program to the client.
After the protocol, identification strings, both sides only send specially formatted packets. The packet layout is as follows:
o
Packet length: 32 bit unsigned integer, coded as four 8-bit bytes, msb
first. Gives the length of the
packet, not including the length field and padding.
The maximum length of a packet (not including the length field and
padding) is 262144 bytes.
o Padding: 1-8 bytes of random data (or zeroes if not encrypting). The amount of padding is (8 - (length % 8)) bytes (where % stands for the modulo operator). The rationale for always having some random padding at the beginning of each packet is to make known plaintext attacks more difficult.
o Packet type: 8-bit unsigned byte. The value 255 is reserved for future extension.
o Data: binary data bytes, depending on the packet type. The number of data bytes is the "length" field minus 5.
o Check bytes: 32-bit crc, four 8-bit bytes, msb first. The crc is the Cyclic Redundancy Check, with the polynomial 0xedb88320, of the Padding, Packet type, and Data fields. The crc is computed before any encryption.
The packet, except for the length field, may be encrypted using any of a number of algorithms. The length of the encrypted part (Padding + Type + Data + Check) is always a multiple of 8 bytes. Typically, the cipher is used in a chained mode, with all packets chained together as if it was a single data stream (the length field is never included in the encryption process). Details of encryption are described below.
When the session starts, encryption is turned off. Encryption is enabled after the client has sent the session key. The encryption algorithm to use is selected by the client.
The protocol supports several encryption types. During session initialization, the server sends a bit mask of all encryption methods that it supports, and the client selects one of these methods. The client also generates as 256-bit session key (32 8-bit bytes) and sends it to the server.
We shall support the following encryption algorithms in out proposed protocol: -
1) DES in CBC Mode
2) Triple DES in CBC mode
For the DES: - cipher the key is taken from the first 8 bytes of the session key. The least significant bit of each byte is ignored. This results in 56 bits of key data. DES [DES] is used in CBC mode. The iv (initialization vector) is initialized to all zeroes.
For the triple DES algorithm: - The variant of triple-DES used here works as follows: there are three independent DES-CBC ciphers, with independent initialization vectors. The data (the whole encrypted data stream) is first encrypted with the first cipher, then decrypted with the second cipher, and finally encrypted with the third cipher. All these operations are performed in CBC mode. The key for the first cipher is taken from the first 8 bytes of the session key; the key for the next cipher from the next 8 bytes, and the key for the third cipher from the following 8 bytes. All three initialization vectors are initialized to zero.
(Note: the variant of 3DES used here differs from some other descriptions.)
Data Type Encoding
The Data field of each packet contains data encoded as described in this section. There may be several data items; each item is coded as described here, and their representations are concatenated together (without any alignment or padding).
Each data type is stored as follows:
8-bit byte: - The byte is stored directly as a single byte.
32-bit unsigned integer stored in four bytes, msb first.
Arbitrary
length binary string, first four bytes are the length of the string, msb first
(not including
the length itself). The following
"length" bytes are the string value.
There are no terminating null characters.
Multiple-precision
integer First 2 bytes are the number of bits in the integer, msb first (for
example, the value 0x00012345 would have 17 bits).
The value zero has zero bits. It
is permissible that the number of bits be larger than the real number of bits.
The number of bits is followed by (bits + 7) / 8 bytes of binary data, msb first, giving the value of the integer.
TCP/IP Port Number and Other Options
The server listens for connections on TCP/IP port 22 XXX. The client may connect the server from any port. However, if the client wishes to use any form of .rhosts or /etc/hosts.equiv authentication, it must connect from a privileged port (less than 1024). For the IP Type of Service field [RFC0791], it is recommended that interactive sessions (those having a user terminal or forwarding X11 connections) use the IPTOS_LOWDELAY, and non-interactive connections use IPTOS_THROUGHPUT. It is recommended that keep-alives are used, because otherwise programs on the server may never notice if the other end of the connection is rebooted.
Protocol Version Identification
After the socket is opened, the server sends an identification string, which is of the form "SSH-<protocolmajor>.<protocolminor> <version>\n", where <protocolmajor> and <protocolminor> are integers and specify the protocol version number (not software distribution version). <version> is server side software version string (max 40 characters); it is not interpreted by the remote side but may be useful for debugging.
The client parses this string; if the protocol version number is not supported, it closes the connection and exits. Otherwise, it sends a corresponding string containing its own information. The server parses the client's string, and if compatible, sends the first packet using the binary packet protocol.
By convention, changes, which keep the protocol compatible with previous versions, keep the same major protocol version; changes that are not compatible increment the major version (which will hopefully never happen).
Key Exchange and Server Host Authentication
The first message sent by the server using the packet protocol is SSH_SMSG_PUBLIC_KEY. It declares the server's host key, server public key, supported ciphers, and supported authentication methods. Additionally it contains fields for protocol flags (to be used for compatible protocol extensions). It also contains a 64-bit random number (cookie) that must be returned in the client's reply (to make IP spoofing more difficult). No encryption is used for this message. Both sides compute a session id as follows. The modulus of the server key is interpreted as a byte string (with minimum length to be able to hold the whole value), most significant byte first. This string is concatenated with the server host key interpreted the same way. Additionally, the cookie is concatenated with this. Both sides compute MD5 of the resulting string. The resulting 16 bytes (128 bits) are stored by both parties and are called the session id.
The
client responds with a SSH_CMSG_SESSION_KEY message, which contains the selected
cipher type, a copy of the 64-bit cookie sent by the server, client's protocol
flags, and a session key encrypted with both the server's host key and server
key. No encryption is used for this
message.
The session key is 32 8-bit bytes (a total of 256 random bits generated by the client). The client first xors the 16 bytes of the session id with the first 16 bytes of the session key. The resulting string is then encrypted using the smaller key (one with smaller modulus), and the result is then encrypted using the other key. The number of bits in the public modulus of the two keys must differ by at least 128 bits.
At
each encryption step, a multiple-precision integer is constructed from the data
to be encrypted as follows (the integer is here interpreted as a sequence of
bytes, msb first; the number of bytes is the number of bytes needed to represent
the modulus).
The most significant byte (which is only partial as the value must be less than the public modulus, which is never a power of two) is zero.
The next byte contains the value 2 (which stands for public-key encrypted data in the PKCS standard [PKCS#1]). Then, there are nonzero random bytes to fill any unused space, a zero byte, and the data to be encrypted in the least significant bytes, the last byte of the data in the least significant byte.
This algorithm is used twice. First, it is used to encrypt the 32 random bytes generated by the client to be used as the session key (xored by the session id). This value is converted to an integer as described above, and encrypted with RSA using the key with the smaller modulus. The resulting integer is converted to a byte stream, msb first. This byte stream is padded and encrypted identically using the key with the larger modulus.
After the client has sent the session key, it starts to use the selected algorithm and key for decrypting any received packets, and for encrypting any sent packets. Separate ciphers are used for different directions (that is, both directions have separate initialization vectors or other state for the ciphers).
When the server has received the session key message, and has turned on encryption, it sends a SSH_SMSG_SUCCESS message to the client.
The recommended size of the host key is 1024 bits, and 768 bits for the server key. The minimum size is 512 bits for the smaller key.
Declaring the User Name
The client then sends a SSH_CMSG_USER message to the server. This message specifies the user name to log in as.
The server validates that such a user exists, checks whether authentication is needed, and responds with either SSH_SMSG_SUCCESS or SSH_SMSG_FAILURE. SSH_SMSG_SUCCESS indicates that no authentication is needed for this user (no password), and authentication phase has now been completed. SSH_SMSG_FAILURE indicates that authentication is needed (or the user does not exist).
If the user does not exist, it is recommended that this returns failure, but the server keeps reading messages from the client, and responds to any messages (except SSH_MSG_DISCONNECT, SSH_MSG_IGNORE, and SSH_MSG_DEBUG) with SSH_SMSG_FAILURE. This way the client cannot be certain whether the user exists.
Provided the server didn't immediately accept the login, an authentication exchange begins. The client sends messages to the server requesting different types of authentication in arbitrary order as many times as desired (however, the server may close the connection after a timeout). The server always responds with SSH_SMSG_SUCCESS if it has accepted the authentication, and with SSH_SMSG_FAILURE if it has denied authentication with the requested method or it does not recognize the message. Some authentication methods cause an exchange of further messages before the final result is sent. The authentication phase ends when the server responds with success.
The recommended value for the authentication timeout (timeout before disconnecting if no successful authentication has been made) is 5 minutes.
The following authentication methods are currently supported:
SSH_AUTH_RHOSTS 1 .rhosts or /etc/hosts.equiv
SSH_AUTH_RSA 2 pure RSA authentication
SSH_AUTH_PASSWORD 3 password authentication
SSH_AUTH_RHOSTS_RSA 4 .rhosts with RSA host authentication
SSH_AUTH_RHOSTS
This is the authentication method used by rlogin and rsh [RFC1282].
The client sends SSH_CMSG_AUTH_RHOSTS with the client-side user name as an argument. The server checks whether to permit authentication. On UNIX systems, this is usually done by checking /etc/hosts.equiv, and .rhosts in the user's home directory. The connection must come from a privileged port. It is recommended that the server checks that there are no IP options (such as source routing) specified for the socket before accepting this type of authentication. The client host name should be reverse-mapped and then forward mapped to ensure that it has the proper IP-address.
This authentication method trusts the remote host (root on the remote host can pretend to be any other user on that host), the name services, and partially the network: anyone who can see packets coming out from the server machine can do IP-spoofing and pretend to be any machine; however, the protocol prevents blind IP-spoofing.
Many sites probably want to disable this authentication method because of the fundamental insecurity of conventional .rhosts or /etc/hosts.equiv authentication when faced with spoofing. It is recommended that this method not be supported by the server by default.
SSH_AUTH_RHOSTS_RSA
In addition to conventional .rhosts and hosts.equiv authentication, this method additionally requires that the client host be authenticated using RSA.
The client sends SSH_CMSG_AUTH_RHOSTS_RSA specifying the client-side user name, and the public host key of the client host.
The server first checks if normal .rhosts or /etc/hosts.equiv authentication would be accepted, and if not, responds with SSH_SMSG_FAILURE. Otherwise, it checks whether it knows the host key for the client machine (using the same name for the host that was used for checking the .rhosts and /etc/hosts.equiv files). If it does not know the RSA key for the client, access is denied and SSH_SMSG_FAILURE is sent.
If the server knows the host key of the client machine, it verifies that the given host key matches that known for the client. If not, access is denied and SSH_SMSG_FAILURE is sent.
The server then sends a SSH_SMSG_AUTH_RSA_CHALLENGE message containing an encrypted challenge for the client. The challenge is 32 8-bit random bytes (256 bits). When encrypted, the highest (partial) byte is left as zero, the next byte contains the value 2, the following are non-zero random bytes, followed by a zero byte, and the challenge put in the remaining bytes. This is then encrypted using RSA with the client host's public key. (The padding and encryption algorithm is the same as that used for the session key.)
The client decrypts the challenge using its private host key, concatenates this with the session key, and computes an MD5 checksum of the resulting 48 bytes. The MD5 output is returned as 16 bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (MD5 is used to deter chosen plaintext attacks against RSA; the session id binds it to a specific session).
The server verifies that the MD5 of the decrypted challenge returned by the client matches that of the original value, and sends SSH_SMSG_SUCCESS if so. Otherwise it sends SSH_SMSG_FAILURE and refuses the authentication attempt.
This authentication method trusts the client side machine in that root on
that machine can pretend to be any user on that machine. Additionally, it trusts the client host key.
The name and/or IP address of the client host is only used to select the
public host key. The same
host name is used when scanning .rhosts or /etc/hosts.equiv and when selecting
the host key. It would, in
principle be possible to eliminate the host name entirely and substitute it
directly by the host key. IP and/or
DNS [RFC1034] spoofing can only be used to pretend to be a host for which
the attacker has the private host key.
SSH_AUTH_RSA
The idea behind RSA authentication is that the server recognizes the public key offered by the client, generates a random challenge, and encrypts the challenge with the public key. The client must then prove that it has the corresponding private key by decrypting the challenge.
The client sends SSH_CMSG_AUTH_RSA with public key modulus (n) as an
argument. The server may respond immediately with SSH_SMSG_FAILURE if it does not permit authentication
with this key. Otherwise it
generates a challenge, encrypts it using the user's public key (stored on the
server and identified using the modulus), and sends SSH_SMSG_AUTH_RSA_CHALLENGE
with the challenge (mp-int) as an argument.
The challenge is 32 8-bit random bytes (256 bits). When encrypted, the highest (partial) byte is left as zero, the next byte contains the value 2, the following are non-zero random bytes, followed by a zero byte, and the challenge put in the remaining bytes. This is then encrypted with the public key. (The padding and encryption algorithm is the same as that used for the session key.)
The client decrypts the challenge using its private key, concatenates it with the session id, and computes an MD5 checksum of the resulting 48 bytes. The MD5 output is returned as 16 bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (Note that the MD5 is necessary to avoid chosen plaintext attacks against RSA; the session id binds it to a specific session.)
The server verifies that the MD5 of the decrypted challenge returned by the client matches that of the original value, and sends SSH_SMSG_SUCCESS if so. Otherwise it sends SSH_SMSG_FAILURE and refuses the authentication attempt.
This authentication method does not trust the remote host, the network, name services, or anything else. Authentication is based solely on the possession of the private identification keys. Anyone in possession of the private keys can log in, but nobody else.
The server may have additional requirements for a successful
authentication. For example, to
limit damage due to a compromised RSA key, a server might restrict access to a
limited set of hosts.
SSH_AUTH_PASSWORD
The client sends a SSH_CMSG_AUTH_PASSWORD message with the plain text password. (Note that even though the password is plain text inside the message, it is normally encrypted by the packet mechanism.)
The server verifies the password, and sends SSH_SMSG_SUCCESS if authentication was accepted and SSH_SMSG_FAILURE otherwise.
Note that the password is read from the user by the client; the user never interacts with a login program. This authentication method does not trust the remote host, the network, name services or anything else. Authentication is based solely on the possession of the password. Anyone in possession of the password can log in, but nobody else.
After the
identification and authentication phase, the system can then allow the user to
perform the actions that be wishes to perform in the system. This protocol is
based on some experimental protocols being written for the Linux OS.
However, we will not provide the code necessary to implement this proposed protocol. The technical information that we have provided is sufficient for any person who wishes to implement the protocol.
In the
next section, we shall deal with the patches that have to be made to the
firewall provided with the Linux kernel in order to allow it to avoid IP
spoofing attacks.
Any firewall that shuts out all incoming traffic to the internal network can provide complete protection against IP spoofing attacks. However, such a firewall will also block out legitimate users of the system.
The major problem with IP spoofing is that it allows the attacker to log in as a trusted machine thus allowing him/her to bypass the security measures provided by the firewall.
There is no direct way of stopping IP spoofing attacks (that we know of, anyway!) that doesn’t block all traffic into the network. Therefore, instead of trying to direct our attention to the attack itself, we can design a firewall that will detect and stop some of the activities that have to be performed by an attacker wishing to employ IP spoofing.
As mentioned earlier in this paper, the attacker has to determine the algorithm used to initialize and increment the ISN of the target system. In order to do so (s)he has to send a large number of syn packets and analyze the replies to determine the algorithm.
If the attacker can not determine the aforesaid algorithm then (s)he will not be able to perform IP spoofing. We will try to modify the packet filtering firewall provided with the Linux kernel to enable it to detect when a large number of connections from the same computer has occurred in a short time period. We will the set up the system to reject further connections from that particular machine until proper investigations have been performed.
It is also essential that the attacker be able to fill up the TCP/IP queue of the trusted machine to prevent it from sending a reset signal to the trusting machine when the latter sends the replies to our forged IP packets to the former as explained earlier in this paper. Therefore, if we make the appropriate corrections to the firewall to prevent a DOS (denial of service) attack from occurring on the trusted host, then we will prevent the attacker form succeeding in his/her intensions. The code for these patches as well as all the other code used in this project can be found in appendix E.
As we have mentioned in this report, one of the most glaring security weakness of the Unix and Linux operating system is its ability to perform IP based authentication. This capability is provided through the “r” commands of the system, such as rsh, rlogin etc. This weakness is compounded by the lack of security measures in the TCP/IP protocol suite.
We have shown how this weakness can be taken advantage of by a malicious user, using a method known as IP spoofing. We have proposed two solutions; one is a new protocol that allows RSA based authentication and two is an improvement to the firewall provided with the Linux kernel that will enable it to detect IP spoofing attempts.
Building Internet Firewalls
D. Brent Chapman and Elizabeth D. Zwicky
O’Reilly & Associates, 1995.
ISBN: 1-56592-124-0
Computer Communications Security: Principles, Standard Protocols and
Techniques
Ford, W.
Prentice Hall, 1994.
ISBN: 0-13-799453-2
Computer Security Basics
Russell, D. And Gangemi, G.T.
O’Reilly & Associates, 1992
ISBN: 0-937175-71-4
Firewalls and Internet Security: Repelling the Wily Hacker
Cheswick, W.R., and Bellovin, S.M.
Reading: Addison-Wesley, 1994.
ISBN: 0-201-63357-4
Goncalves, Marcus
McGrew-Hill, 1997
ISBN: 0-07-024645-9
Internetworking with TCP/IP, Volume 1, 3rd Edition
Comer, D.E.
Prentice Hall, 1995
ISBN: 0-13-216987-8
Network and Internetwork Security, Principles and Practice
Stallings, W.
Prentice Hall, 1995.
ISBN: 0-7803-1107-8
Secure Computing Threats and Safeguards
Summers, R.C.
McGraw-Hill, 1997
ISBN: 0-07-069419-2
The Whole Internet, User’s Guide & Catalog
Krol, E.
O’Reilly & Associates, 1992.
ISBN: 1-56592-063-5
HACK: How Mitnick hacked Tsutomu Shimomura with an IP sequence attack
System: TCP/IP
Source: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc
Date: 25 Jan 1995
Web Spoofing: An Internet Con Game
Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach
Technical Report 540-96 (Revised Feb. 1997)
Department of Computer Science, Princeton University
A Weakness in the 4.2BSD Unix (tm) TCP/IP Software
Robert T. Morris
AT&T Bell Laboratories
Murray Hill, New Jersey 07974
Websites
CSE: - http://www.cse-cst.gc.ca/
Alt.security
Atl.warez
