hackers beware the ultimate guide to network security phần 10 doc

“ Hackers Beware “ New Riders Publishing
731
We can now observe that the passwords are encrypted and the password
type has been changed. These encrypted passwords are noted as type 7
passwords.
Type 3—Cisco IOS Type 5 Passwords
The other type of Cisco password is type 5. This password type is
encrypted using an MD5 hashing algorithm and is used by the Cisco IOS
to encrypt the enable secret password as shown in the following:

enable secret 5 $1$2ZTf$9UBtjkoYo6vW9FwXpnbuA.
The type 5 password encryption uses a stronger method of encryption
than type 7 passwords.
Description of Variants
There are several variants/code that take advantage of the Cisco IOS type
7 password vulnerability. All the variants crack Cisco IOS type 7
passwords, however, the main difference in the variants is the
programming language in which they are coded. Judging from the number
of available variants, it would lead us to believe that the encryption
scheme used in Cisco IOS type 7 passwords is not very strong.
How the Exploit Works
This exploit works in a similarly to the way L0phtcrack decrypts Windows
NT passwords. Rather than trying to obtain a copy of a Windows NT SAM
file, an attacker tries to obtain a copy of the encrypted type 7 password
from a Cisco router usually by obtaining the Cisco IOS configuration file.
To understand how a Cisco IOS type 7 password is cracked, let’s walk
through manually cracking a password. This is how to break the
encryption used for Cisco IOS type 7 passwords:
Assumptions:

1. The encrypted text is already obtained.
It is assumed that the attacker has already obtained the encrypted
text and is ready to decrypt the password.
2. The constant value is known.
A constant value exists which provides a salt in an attempt to
introduce randomness so that two identical passwords when


“ Hackers Beware “ New Riders Publishing
732
encrypted will have different ciphertext, if the salts are different. For
Cisco IOS type 7 passwords the constant is
tfd;kfoA,.iyewrkldJKD. From what I understand, this constant
was obtained by comparing a large number of Cisco IOS type 7
passwords to see if a pattern existed.
We will use the example of the user admin. As we can see from the
following, the plaintext password that was previously cisco has been
encrypted into a Cisco IOS type 7 password.

username admin privilege 15 password 7 0822455D0A16
Given the assumptions stated, here is how to manually exploit the
weakness of the poor encryption implemented in the Cisco IOS type 7
password.
Let xorstring[n] be the value of the nth character in the constant value
stated in Assumption 2. For example, xorstring[5] = k and
xorstring[11] = i.
The encrypted string must be an even length of digits, and the entire
length of the plaintext password is equal to [(length of encrypted
password) - 2 ] / 2. Thus, in our example, we can conclude the length of
the plaintext password is [12-2] / 2 = 5.

Note, that when decrypting Cisco IOS type 7 passwords manually, it is a
good idea to have an ASCII chart available. The following steps show you
how to decrypt type 7 passwords:
1. Take the first two digits of the encrypted text.
In our example, the first two digits of the encrypted text is 08. This
value is used as decimal representation of an index of where to start
taking salts from the constant value.
2. Obtain the current salt.
A is the eighth value in the constant value (tfd;kfoA,
.iyewrkldJKD) as dictated by the first two digits of the encrypted
text. Therefore, our salt is xorstring[08] = A.
3. Take the next two digits of the encrypted text.
In our example, the next two digits of the encrypted text is 22. This
value is the hexadecimal representation of the first character in the
plaintext password XOR’d against the salt (in this case A).


“ Hackers Beware “ New Riders Publishing
733
4. Calculate the first plaintext character in the password.

If we take the hexadecimal representation of the first character in
the plaintext password, (as obtained in Step 3) we see that it is
0x22, which is the decimal equivalent of 34 (2 * 16
1
+ 2 * 16
0
=
34). We also know that our salt in this case is A, which is the
decimal equivalent of 65. Now, we perform the following operation

to obtain the first character of the plaintext password:

0x22 XOR xorstring[08] = first character in plaintext password

Simplify using decimal values:

34 XOR 65 = first character in plaintext password
To easily compute the value of 34 XOR 65, we convert to binary,
and when the values are the same, the result is 0. When the values
are different, the result is 1. This is shown in Figure 17.20.
Figure 17.20. Conversion of decimal to binary and XORing two values
together.

As we can conclude from above, 34 XOR 65 = 99 and the ASCII value of
99 is c. Thus, the first plaintext character in the Cisco IOS type 7
password is c.
1. Obtain the next salt.
Now, we must increment the index value (originally 08) by 1. Thus,
we will use , which is the ninth value in the constant value
(tfd;kfoA, iyewrkldJKD). Therefore, our new salt is
xorstring[09] = ,.
2. Take the next two digits of the encrypted text.
The next two digits of the encrypted text is 45. This value is the
hexadecimal representation of the second character in the plaintext
password XOR’d against the new salt (in this case ,).
3. Calculate the next plaintext character in the password.

If we take the hexadecimal representation of the second character

“ Hackers Beware “ New Riders Publishing
734
in the plaintext password, (as obtained in Step 6) we see that it is
0×45, which is the decimal equivalent of 69 (4 * 16
1
+ 5 * 16
0
=
69). We also know that our salt in this case is , which is the decimal
equivalent of 44. Now we perform the following operation to obtain
the second character of the plaintext password:

0x45 XOR xorstring[09] = second character in plaintext password

Simplify using decimal values.
69 XOR 44 = second character in plaintext password
Once again we can perform the same operations as listed to determine the
value of 69 XOR 44, as shown in Figure 17.21.
Figure 17.21. Conversion of decimal to binary and XORing two values together.

As we can conclude from above, 69 XOR 44 = 105 and the ASCII value of
105 is i. Thus the second plaintext character in the Cisco IOS type 7
password is i.
If we continue following Steps 5, 6 and 7 until the encrypted text is
exhausted, we will obtain the plaintext password. For the sake of brevity,
the remainder of the plaintext password is quickly computed in Step 8.
1. Compute the remainder of the plaintext password.

0x5D XOR xorstring[10] = next character in plaintext password

Simplify using decimal values.
93 XOR 46 = next character in plaintext password, as shown in
Figure 17.22.
Figure 17.22. Conversion of decimal to binary and XORing two values
together.



“ Hackers Beware “ New Riders Publishing
735
As we can conclude from above, 93 XOR 46 = 115, and the ASCII value of
115 is s. Thus, the next plaintext character in the Cisco IOS type 7
password is s.
0x0A XOR xorstring[11] = next character in plaintext password
Simplify using decimal values.
10 XOR 105 = next character in plaintext password, as shown in Figure
17.23.
Figure 17.23. Conversion of decimal to binary and XORing two values together.

As we can conclude from above, 10 XOR 105 = 99 and the ASCII value of
99 is c. Thus, the next plaintext character in the Cisco IOS type 7
password is c. At this point, we only have 1 plaintext character to decrypt.
0x16 XOR xorstring[12] = next character in plaintext password
Simplify using decimal values.
22 XOR 121 = next character in plaintext password, as shown in Figure
17.24.
Figure 17.24. Conversion of decimal to binary and XORing two values together.

As we can conclude from above, 22 XOR 121 = 111, and the ASCII value
of 111 is o. As expected, the last plaintext character in the Cisco IOS type

7 password is o. This gives us the expected plaintext password of cisco
for the user admin.
Hence, we can see how easy it is to exploit the poor encryption algorithm
of Cisco IOS type 7 passwords.
Obviously, manually decrypting Cisco IOS type 7 passwords is not a
desirable scenario, especially when computers are much better designed
for brain-numbing calculations than humans. In this case, it would be


“ Hackers Beware “ New Riders Publishing
736
much better to write a script in C or Perl to do these calculations as you
will see in the next section.
How To Use It
There are several programs available that will exploit this vulnerability,
however, we will only show two of the several programs: ios7decrypt.pl
and GetPass! v1.1.

ios7decrypt.pl
This program is a small Perl script that takes input in the form of:

username admin privilege 15 password 7 0822455D0A16
and gives output in the form of:

username admin privilege 15 password 7 cisco
Here is an example of how this program appears when run from the
prompt:

# perl ios7decrypt.pl
username admin privilege 15 password 7 0822455D0A16

username admin privilege 15 password cisco
#
As we can see, ios7decrypt.pl does an excellent job at decrypting Cisco
IOS type 7 passwords, which would otherwise be a manual painstaking
task.
For those that do not have a Perl interpreter and prefer a GUI-based
program, we will cover a program called GetPass! v1.1, which runs on
Windows 9X/NT. It doesn’t get much easier then this.
Simply copy the Cisco IOS type 7 encrypted password and paste it into
the box, as shown in Figure 17.25.
Figure 17.25. Using GetPass! to extract a Cisco encrypted password.


“ Hackers Beware “ New Riders Publishing
737

Voila! You now have the plaintext password. Although this program is
extremely easy to use, one drawback is that it would be very painful to
decrypt a large number of encrypted passwords.
Signature of the Attack
If an attacker is using one of these programs to decrypt your passwords,
then it is already too late. The key is to ensure that the Cisco IOS
configuration files are secured in such a manner, so that an attacker
cannot obtain any encrypted Cisco IOS type 7 passwords. I can think of
three main methods an attacker would try to obtain the Cisco IOS
configuration file:
1. Poll Cisco IOS configuration file through SNMP.
In this scenario, the attacker could try to download the Cisco IOS
configuration file through SNMP. Remember from the previous
exploit, SNMP is a very easy way for an attacker to find out key

information about your network. There are several ways to do this
ranging from custom written code to specific applications, such as
Solarwinds’ SNMP Brute Force Attack
( />e/index.htm). This allows the attacker to gain the configuration file
from the Cisco router and then quickly decrypt any Cisco IOS type 7
passwords. In this case, a network administrator should be looking
for any authorized SNMP polling from either the log that resides
locally in the Cisco routers’ buffer or from a syslog host. All Cisco
router log information should be sent to a syslog server. This way,
all events that occurred on your network can be stored and
reviewed in a central location.
2. Attack the tftp server.
In this scenario, the attacker could try to attack and gain access to a
tftp server to gain access to several Cisco configuration files. Why
would an attacker attempt to gain access to one Cisco router when
he could have access to many? Given the numerous methods to


“ Hackers Beware “ New Riders Publishing
738
break into servers, the network administrator should always be
looking for any suspicious actions or log entries.
3. Watch for email sent to the Cisco Technical Assistance Center (TAC).
In many cases, when a network administrator has a network
problem that might be related to a Cisco router, a case is opened
with the Cisco TAC, who often asks for a copy of the output from a
show tech-support command. This command outputs almost
everything about the router, including the configuration file. If an
attacker was able to break into the network administrator’s Internet
SMTP server (that is sendmail server) undetected, then the attacker

could monitor and capture messages bound for If
the attacker wasn’t particularly patient, then the attacker could
always create network problems in a hope that this would increase
the chances of a network administrator opening a case with the
Cisco TAC.
Of course, the attacker could use tactics, such as social engineering,
shoulder surfing, or using a sniffer, to obtain passwords to access the
router, but that would not be exploiting the poor encryption algorithm
implemented in Cisco IOS type 7 passwords.
How To Protect Against It?
There is no way to protect Cisco IOS type 7 passwords from being easily
decrypted due to the nature of the weak reversible algorithm that is
implemented.
“Cisco has no immediate plans to support a stronger encryption algorithm
for Cisco IOS user passwords. If Cisco should decide to introduce such a
feature in the future, that feature will definitely impose an additional
ongoing administrative burden on users who choose to take advantage of
it”, as stated by Cisco.
Cisco does make some good recommendations on how to protect against
this type of exploit. In summary, don’t use Cisco IOS type 7 passwords.
“Cisco recommends that all Cisco IOS devices implement the
authentication, authorization, and accounting (AAA) security model. AAA
can use local, RADIUS, and TACACS+ databases”. This is a good
recommendation because it centralizes user management (easier
maintenance) and removes the risks of using Cisco IOS type 7 passwords.
This method of protecting against this vulnerability could also be
complimented by having the authentication portion of the AAA security
model passed on to a device that supports one-time passwords, such as
Security Dynamics SecureID.

“ Hackers Beware “ New Riders Publishing
739
If it is necessary to implement Cisco IOS type 7 passwords on your Cisco
devices, then here are some suggestions you can use to protect from the
3 scenarios discussed:
1. Poll Cisco IOS configuration file through SNMP.
To protect against this type of attack, the network administrator has
a few options:
o Do not implement SNMP. If your device does not respond to
SNMP polling, then the attacker cannot download the
configuration file. This, however, is not often a feasible
solution because the network administrator often needs SNMP
to provide network statistics.
o Implement SNMP access lists. If you must use SNMP, then you
should configure access lists that restrict which hosts can poll
for SNMP-related data. Example:
o
o access-list 1 permit 1.1.1.1
o access-list 1 permit 2.2.2.2
snmp-server community private RW 1
By using the above configuration in your Cisco IOS
configuration file, only hosts 1.1.1.1 and 2.2.2.2 are allowed
privileged SNMP access to your device. Of course, you would
use a much more secure SNMP community string than
private.
2. Attack a tftp server.
To protect your tftp server from attack, you must secure the server
itself both physically and logically. In this case, the administrator
should harden the OS (that is UNIX, Linux, Windows NT, and so

forth) and ensure that all necessary OS and application patches are
installed. The administrator should also regularly port scan this
server to ensure that only the necessary services are running.
Scanning the server regularly should also alert the administrator to
any possible backdoors if suddenly a high port is open!
3. Watch for email sent to the Cisco Technical Assistance Center (TAC).
In this situation, the email server administrator should be watching
for suspicious activity as well as following the steps outlined in
number 2 to ensure that the possibility of having the SMTP server
compromised is reduced. Also, if the Cisco IOS configuration file
needs to be sent to anyone, the network administrator should
ensure that the file is properly sanitized (that is removal of all
password-and security-related information). Another way to prevent


“ Hackers Beware “ New Riders Publishing
740
an attacker from obtaining this information in this manner is to use
a more secure transport. For example, use secure copy rather than
email.
Source Code/Pseudo Code
The following are links to where the various source code/programs can be
found:
SPHiXe’s C version:
Riku Meskanen’s Perl version:

BigDog’s Psion 3/5 OPL version:

Major Malfunction’s Palm-Pilot C port:

Boson’s Windows GetPass:
L0pht’s Palm Pilot version:
Additional Information
The following are references and links to additional information:
• Cisco IOS Password Encryption Facts

• Useful Cisco Password Utilities

• The PC ASCII Chart

• Mudge’s explanation of this vulnerability

• Cisco.txt—Text file from Mudge’s Cisco Type 7 Password Decryptor



“ Hackers Beware “ New Riders Publishing
741
• The Bitwise XOR Operator

Man-in-the-Middle Attack Against Key Exchange
This vulnerability enables a hacker to find the session key distributed by a
key exchange protocol. This is a man-in-the-middle type of attack. An
attacker can exploit this vulnerability without launching a brute force
attack on encrypted messages or breaking into any computer. The hacker
simply manipulates protocol messages and uses an impersonation tool,
such as Hunt.
Exploit Details
• Name: Man-in-the-middle attack against the initiator of Otway-
Rees Key Exchange Protocol.

• Variants: Man-in-the-middle attack against the two parties of
Otway-Rees Key Exchange Protocol.
• Operating System: All operating systems with which the Otway-
Rees Key Exchange Protocol specification may be implemented
because it concerns a specification flaw in the key exchange
protocol.
• Protocols/Services: Otway-Rees Key Exchange Protocol.
• Written by: Frédéric Massicotte
Overview
Since the coming of the Internet in the 1980’s and 90’s, information has
often been transmitted unscrambled and unprotected over the Internet or
various computer networks during remote access, electronic transactions,
and so forth. The problem resides in the fact that the Internet is not a
proprietary network but, instead, consists of thousands of independent
networks. No one has complete control over the route that information
takes on the way to a destination. With the Internet’s current design,
information security has become a priority. Given the billions of dollars
exchanged over the Internet through e-commerce and e-business
transactions, and the real threat posed by the interception of secret
information, we need tools to make electronic transactions over the
Internet secure.
To meet this need, the Internet community has designed new types of
communication protocols that function above normal communication and
transmission protocols, such as TCP/IP, and so forth. These are known as
security or cryptography protocols. SSL (Secure Socket Layer) and SET
(Secure Electronic Protocol) are good examples of security protocols
currently used in e-commerce to make vender-purchaser transactions


“ Hackers Beware “ New Riders Publishing

742
secure. People want assurance that their Internet transactions are secure
and that they will not lose important information, such as credit card
numbers, passwords, and so forth to hackers. There are several types of
cryptography protocols, such as authentication protocols, e-commerce
protocols, key distribution protocols, and so on. In this section, we are
specifically interested in the vulnerability of key exchange protocols. These
protocols are used to distribute a session key to two or more principals to
enable them to communicate in a secure fashion by encrypting future
information exchanges. Virtual Private Networks (VPNs) are good
examples of the use of key exchange protocols. VPNs generally use IKE, a
key exchange protocol, for two entities to exchange a secret session key.
With this key, they are able to communicate in a secure fashion by
encrypting information transmitted in a hostile environment, such as the
Internet. Because a hacker does not have the session key to encrypt
information, it becomes very difficult for him to obtain secret information
by launching a man-in-the-middle attack and monitoring network traffic
with a sniffer.
Protocol Description
No one has complete control over the Internet, and it is almost impossible
to prevent a hacker from launching a man-in-the-middle attack or
retrieving information packets from the network, as Figure 17.26
indicates. One of the solutions to this problem is cryptography and
cryptographic algorithms. If each of the principals has the right key, they
can make their transaction secure by using cryptographic algorithms, as
indicated in Figure 17.27. This key is generally called a session key
because it is only used once for a specific session. This key is only good
for one session, after which, if the two entities want to communicate
again, they must obtain a new key for a new session. However, one
problem remains—how to distribute a session key to the two entities in a

secure fashion. This is a difficult problem, which may be solved by using a
key exchange protocol.
Figure 17.26. Message transmitted in clear text format.

Figure 17.27. Message transmitted in encrypted format.


“ Hackers Beware “ New Riders Publishing
743

Basic Notions
Before explaining the vulnerabilities of key exchange protocols, we must
mention the syntax and symbols used to define security protocol
specifications in general. The following symbols are used to specify
security protocols:
Table 17.1. Symbols used in Security Protocols
A A’s name
B B’s name
S Key Sever
k
as
symmetric key shared by A and S
k
bs
symmetric key shared by B and S
k
ab
symmetric session key shared by A and B
I session number
N

a
random number generated by A
N
b
random number generated by B
The aforementioned symbols are very simple. Upper case letters generally
represent computer entities, called principals. We will discuss these in
greater depth in the discussion on protocol specifications.
Otway-Rees Key Exchange Protocol Specification
When deploying a key exchange protocol in a wide area network, security
people want to ensure that there are no vulnerabilities in protocol
implementation and especially specification design to make it difficult for a
hacker to compromise the security of information transmitted over the
network. When selecting a secure key exchange protocol, we must expect
that the protocol key will never be sent unscrambled in a hostile
environment outside our control, and that, at the end of the protocol, the
entities to receive the session key do actually receive it in a trouble-free
manner, without hackers intercepting it. However, as we will see, without
decrypting any message or attacking or breaking into any computer,
hackers may manipulate information to obtain the session key without
either of the entities detecting the ruse. To illustrate this problem, we are
going to study the Otway-Rees Key Exchange Protocol. The complete


“ Hackers Beware “ New Riders Publishing
744
protocol specification can be found in Bruce Scheier’s book, Applied
Cryptography.
The Otway-Rees Protocol makes it possible to distribute a session key k
ab

,
created by the trusted server S, to two principals A and B. This key
encrypts the information transmitted between these two principals.
Sharing this key and the cryptographic algorithms creates a VPN-type
communication tunnel between the two principals.
In addition, this protocol authenticates the principals to ensure the
integrity of messages and that the key has been correctly distributed to
the correct principals. This prevents the key from falling into the wrong
hands, such as those of a hacker who is hijacking a session or conducting
a man-in-the-middle attack. The Otway-Rees Key Exchange Protocol is
specified as follows:
Table 17.2. Otway-Rees Key Exchange Protocol
Message 1 A ‡ B: I,A,B { N
a
, I, A, B }
kas

Message 2 B ‡ S: I,A,B { N
a
, I, A, B }
kas
, { N
b
, I , A, B }
kbs

Message 3 S ‡ B: I, { N
a
, k
ab

}
kas
, { N
b
, k
ab
}
kbs

Message 4 B ‡ A: I, { N
a
, k
ab
}
kas

Thus, as we can see, at the end of the protocol, the key k
ab
is received by
A and B, which are now ready to exchange confidential or secret
information.
The message in the form { m }
k
symbolizes that message m has been
encrypted with k using a symmetrical cryptographic algorithm. Before
starting the protocol, each of the principals has certain initial knowledge.
Keys k
as
and k
bs

are permanent keys given to A and B, respectively, as
personal keys. They must share these with the server to communicate
with it. With these permanent keys, the principals are able to obtain a
session key from the server.
The cryptography protocol may be described in more detailed fashion as
illustrated in Figure 17.28
.
Figure 17.28. Otway-Rees Key Exchange Protocol.



“ Hackers Beware “ New Riders Publishing
745
A sends B the protocol session number, its identity, the identity of the
principal with which it wants to communicate, and a message encrypted
with the key k
as
.
B receives A’s message and adds its own message encrypted with the key
k
bs
before sending it to the trusted server S.
S receives the message and is able to retrieve the session number, the
random number from A, N
a
using its shared key k
as
, the random number
from B, N
b

with the other shared key k
bs
, and generates the session key
k
ab
. With this information, S is able to generate message 3 and sends it to
B.
The principal in question receives message 3, removes the last encrypted
part with its shared key, decrypts this sub-message with its key k
bs
,
retrieves the session key k
ab
, and sends the remaining part of the
message to A. In this way, A is also able to retrieve the session key k
ab
,
based on the last part of message 4 by using its shared key k
as
, and the
two principals are able to start communicating.
In addition to using session numbers to ensure message authentication
and integrity, this key exchange protocol uses random numbers, such as
stamps to identify sessions. The random number N
a
can only be known by
A and the trusted server S, because it is always encrypted by the key k
as

when it is transmitted over the network. Therefore, when A receives the

key k
ab
at the end of the protocol, it can be sure that the session key is
genuine and that it was, in fact, generated by the server, by verifying if
the random number received in the last message is the same one
generated in the first message. In this protocol, we can use the same logic
with respect to the random number N
b
for principal B.
In addition, we can see that a session key is always encrypted when it is
transmitted between principals over a computer network. Indeed, the
session key is always encrypted by the keys k
as
and k
bs
, and the only
parties with these keys are the principals A, B, and S. Therefore, a hacker
cannot retrieve the session key in any way if the cryptographic algorithm
is perfect and there are no security vulnerabilities in the protocol
implementation.
If a hacker impersonates principal A to principal B and impersonates B
without A realizing it by launching a classic man-in-the-middle attack with
Hunt-type software or controlling a router through which the information
is transmitted, he will be able to deceive the principals about his identify.
However, he will not be able to retrieve the key, as shown in Figure 17.29.
Figure 17.29. Simple man-in-the-middle attack against Otway-Rees Key
Exchange Protocol.


“ Hackers Beware “ New Riders Publishing

746

How the Exploit Works
Most of the time, hackers exploit security vulnerabilities in software
implementation or find insecure systems to attack. Most of the time, even
the most sophisticated systems maintained by the best security
technicians may have security vulnerabilities. Given their current level of
complexity, it is almost impossible for programs to be completely free of
vulnerabilities or bugs. This is what we must expect with security software
or protocols. However, most security vulnerabilities discovered in recent
years and posted on Internet sites, such as www.securityfocus.com and
www.ntbugtraq.com, or on hacker sites are almost exclusively
implementation vulnerabilities, such as overflow buffers, program errors,
and so forth.
We often forget that some vulnerabilities may only be discernable at the
specification and design level. Even today, it may be difficult to develop
cryptography protocols without vulnerabilities. Otway-Rees Key Exchange
Protocol does, in fact, have a specification vulnerability that enables a
hacker to steal the session key.
In particular, if a hacker wants to steal the session key, he must be able
to determine the content of messages 3 and 4. He may also attack the
server or one of the principals to retrieve the permanent keys or attempt
a brute force attack on the encrypted messages that he retrieved from the
computer network. However, this may be more complicated than
exploiting the protocol vulnerability. Indeed, the hacker may retrieve the
key by simply manipulating information. He has to impersonate principal B
with Hunt-type software. When A is ready to start a protocol session, the
hacker launches the attack as follows:
Table 17.3. Attack Against the Initiator of Otway-Rees Key Exchange Protocol
Message 1 A ‡ I(B): I,A,B { N

a
, I, A, B }
kas

Message 4 I(B) ‡ A: I, { N
b
, I, A, B }
kas

When A wants to start a session with B, hacker I(B) impersonates B with
Hunt-type software. By placing a sniffer at the right place on the computer
network, he retrieves the first message, the session number, and the
encrypted part of the message, concatenates all the components, and


“ Hackers Beware “ New Riders Publishing
747
sends the result to principal A. This party retrieves the message, verifies
the session number, decrypts the encrypted message with its permanent
key, verifies if it has correctly received the random number that it sent in
message 1, and concludes that the second part of the decrypted message
is the session key. Therefore, the session key for this session is the
message I,A,B. Because this message is sent unscrambled over the
computer network, the hacker may intercept it and, thereby, steal the
secret key. Indeed, principal A does not know the session key before
receiving message 4. Therefore, A will accept any bit string which is the
same length as the session key and encrypted with the right random
number and the key k
as
.

To carry out this attack, a hacker only needs to know the protocol and
how it behaves. He does not need to carry out Steps 2 and 3 of the
protocol. In fact, there is no way for A to know that these two steps in the
protocol have not been carried out.
Thus, the hacker does not need to know the permanent keys and does not
have to encrypt or decrypt any information at all. By simply manipulating
information, he can find the protocol session key and start exchanging
secret information with principal A without anyone suspecting that A is in
the process of exchanging secret information with a hacker.
Figure 17.30 shows how this type of the attack may be carried out on a
network.
Figure 17.30. Attack against the initiator of the Otway-Rees Key Exchange
Protocol.

When A wants to establish a connection with B for this protocol, the
hacker manages to gain control over an entity through which information
is transmitted and uses Hunt-type software to impersonate B. When the
connection is established, A starts a protocol session and sends the
hacker impersonating B the message: I,A,B { N
a
, I, A, B }
kas
.
The hacker receives the message, removes A,B, generates the message:
I, { N
a
, I, A, B }
kas
, and sends it to A. A retrieves the session key I,A,B

“ Hackers Beware “ New Riders Publishing
748
and the hacker does the same with the information retrieved from the
network. Principal A sends encrypted messages with the session key. The
hacker now has complete control over the connection, as if it had never
been encrypted with a session key. To him, the information on the
network appears to be unscrambled.
For more information on session hijacking, see Chapter 5, " Session
Hijacking."
Variants Description
Otway-Rees has several variants of this vulnerability. There are, in fact,
several ways of actually carrying out this attack on a real computer
network. In addition, the hacker has several options concerning which
principal’s identity he may assume to steal the session key and
compromise the security of information transfer. In fact, even if the
hacker does not control the connection between A and B, he will
nevertheless be able to carry out an attack if he is able to monitor traffic
between A and B and control traffic between B and the server. The
variants of the attack are shown in Table 17.4:
Table 17.4. Attack Against the Two Parties of Otway-Rees Key Exchange Protocol
Message 1 A ‡ B: I,A,B { N
a
, I, A, B }
kas

Message 2 B ‡ I(S): I,A,B { N
a
, I, A, B }
kas

,{ N
b
, I , A, B }
kbs

Message 3 I(S) ‡ B: I, { N
a
, I, A, B }
kas
,{ N
b
, I , A, B }
kbs

Message 4 B ‡ A: I, { N
a
, I,A,B }kas
In this attack, the hacker lets principals A and B establish a connection
and exchange the first message in the protocol. Then B must establish a
connection with the server. At this point, the hacker, who has managed to
gain control over the information moving between B and S, uses Hunt-
type impersonation software and, by impersonating the server,
establishes a connection with principal B, who sends him message 2. After
receiving it, the hacker returns the same message after removing the
message A,B. Therefore, based on the protocol, principal B takes the
second encrypted message and finds the session key I,A,B, as A did in
the first attack. Then, according to the protocol specification, B sends
message 4 to principal A, which is, in fact, message 3 without the part
encrypted with B’s permanent key (which was removed before being
sent). At this point, B just follows the protocol specification and has no

way of determining whether the session key that it is going to transmit to
principal A is in fact the right key generated by the server. A then
retrieves the message and also finds the key I,A,B, like the key generated
by the server. A and B can then send each other information encrypted
with this new session key. However, if the hacker is able to sniff the
information moving between A and B, he will be able to decrypt the
information in its entirety without either principal realizing it.


“ Hackers Beware “ New Riders Publishing
749
Figure 17.31 shows one of the methods that a hacker may use on an
actual computer network.
Figure 17.31. Attack against the two parties of the Otway-Rees Key Exchange
Protocol.

Principal A establishes a connection with B for this protocol.
Principal A sends the message: I,A,B, { N
a
, I, A, B }
kas
to B.
When B wants to establish the connection with the server, the hacker
manages to gain control over an entity through which information is being
transmitted and uses Hunt-type software to assume the identity of the
server.
Principal B sends the message I,A,B, { N
a
, I ,A, B}
kas

, { Nb , I , A,
B}
kbs
to the server impersonated by the hacker.
The hacker returns almost the same message, but without the sub-
message A,B.
Principal B finds the session key, which is the same as the message I,A,B.
Principal B sends the message I, { N
a
, I , A, B}
kas
to principal A to end
the protocol.
The hacker finds the session key I,A,B and he easily finds the session key
with the message that B sent him.
A and B start exchanging secret encrypted information with the session
key. Using his sniffer placed between the two principals, the hacker is able
to decrypt all the information as if it were being transmitted on the
network unscrambled.


“ Hackers Beware “ New Riders Publishing
750
How To Use It
To my knowledge, no software exists to carry out this type of attack or to
exploit this type of vulnerability in this protocol or in other security
protocols. With respect to attacks, it is easy for a knowledgeable hacker,
who controls the router through which information between A and B is
transmitted, to control the information using a filter and, thereby, retrieve
the session key.

There might not be software to carry out this type of attack, but there is a
tool, designed at Laval University in Québec City, which was developed to
perform automatic verification of security protocols. We only have to
provide this tool with a protocol specification similar to the format of the
Otway-Rees Protocol specification. We will discuss how this tool works in
the next section.
Signature of the Attack
The signature of this attack is relatively easy for a configurable intrusion
detection system to identify.
Network Point of View
Even if a hacker successfully steals the session key, in all these types of
attacks, the hacker is only able to generate a single session key—the
session key I,A,B. Therefore, if the network Intrusion Detection System is
able to follow the details of an Otway-Rees Key Exchange Protocol
session, and it sees that the message { N
a
, I , A, B}
kas
sent with
message 1 is in fact the same message contained in the second part of
messages 3 and 4, or that message { N
b
, I , A, B}
kbs
sent in message 2
is the same as the third part of message 3, it can determine that there is
definitely a problem because the probability that the bit string
representing the session key would be the same as that representing
message I,A,B is very low. In fact, there is almost no chance of this
situation occurring, which means the rate of false positives for this type of

attack is very low. As well, the server should not be permitted to generate
this type of key, thus, enhancing the signature detection activity. In short,
a network-type detection intrusion system can, without decrypting any
information at all, detect this type of attack.
The Intrusion Detection System may also be able to verify if all protocol
steps have been carried out and, if not, warn that there is a problem.
So, an Intrusion Detection System that can monitor a session of this
protocol has the capability to keep all the messages transmitted for this
session between the principals in its memory for a session S. By
comparing some part of message 1 and some part of message 4, you will


“ Hackers Beware “ New Riders Publishing
751
be able to easily detect this attack. The rules that are able to follow a
session of the protocol that may be added to an IDS are written in pseudo
code, as follows:
IDS Rules to Prevent the Man-in-the-Middle Attack Against Otway-Rees

If (S.Message1.kas) = (S.Message3.kas) or
(S.Message1.kas) = (S.Message4.kas)
alarm administrator "Stolen Key"
Else if (S.Message2.kbs) = (S.Message3.kbs)
alarm administrator "Stolen Key"
In this case, the specification S.MessageN.K specifies the sub-message
encrypted with the key K in the message N from the session S. Even if
these messages are encrypted, if the part of message 1 that is encrypted
with the permanent key of A is the same as the part of message 4
encrypted with the same key, this means that the key is the message
I,A,B for the current session.

Host Point of View
From the host’s point of view, the protocol may include a mechanism to
protect against this attack. Indeed, if one of the principals notices that the
session key is in fact the same key, the same message as I,A,B, from a
binary point of view, it can conclude that a hacker is attempting to steal
the session key, if the server is not able to generate this key. The pseudo
code is the following:
Program Adjustment to Prevent the Man-in-the-Middle Attack Against Otway-
Rees

If sessionKey = sessionNumber + firstPrincipal.name +
secondPrincipal.name
drop connection
alarm user "Stolen Key"
How to Protect Against Otway-Rees Key Exchange
Protocol Exploit
This attack has a very specific and precise signature, irrespective of how
the hacker orchestrates the attack.
Implementation Level
The attack signature is clearly identified from a binary point of view by the
fact that during a specific protocol session, the session key is the message
I,A,B,. However, the hacker proceeds, and the only key that he is able to


“ Hackers Beware “ New Riders Publishing
752
steal as session key is the message I,A,B, which he retrieves from the
network.
Therefore one way to protect against this attack is to configure the
network- oriented or host-oriented Intrusion Detection System to follow

Otway-Rees Protocol sessions. Based on the messages exchanged, it must
then verify if the session key is in fact the same, from a binary point of
view, as the message consisting of the session number and the identity of
the two principals.
The Intrusion Detection System is able to detect this attack even if the
message is encrypted. From the host’s point of view, it is also very easy
for each of the principals, before validating the session key, to determine
from a binary point of view, if the key is in fact the message consisting of
the session number, their identity, and the identity of the principals with
whom they have initiated a protocol session.
Design Level
From a software perspective, it is possible to solve this problem by adding
code to prevent this situation and to configure our Intrusion Detection
Systems to handle this. However, it should be remembered that this
vulnerability is related to the specification, and it is at this level that we
can find a better way of preventing groups of hacker from exploiting this
vulnerability. Therefore, it is necessary to find ways of creating protocols
that have no vulnerabilities from the specification point of view or have
verification tools to check them.
No tools yet exist to create custom security protocols without specification
vulnerabilities. Some research is being conducted in this area, however,
there is still work to accomplish.
Several tools for verifying protocols do exist. In particular, the LSFM group
at the Computer Science Department of Laval University in Québec City
has developed a tool to perform automatic verification of security
protocols. Supplied only with a protocol specification similar in format to
the Otway-Rees Protocol specification, the tool is able to turn back all
protocol attacks based on a specification vulnerability. The operation of
this software is simple. The tool is given the protocol specification and the
protocol’s principal that will be attacked. After the option “Check Flaw” is

chosen, the tool starts processing, as shown in Figure 17.32.
Figure 17.32. Graphical interface of the security protocols analyzer.


“ Hackers Beware “ New Riders Publishing
753

The software then reports all the specification-based attacks against this
protocol that it detected. Thus, according to the attack, we can define the
protocol’s problems and weaknesses to make an adjustment to the
specification, making the protocol more secure. It does not suggest
solutions to a problem, but it provides general information about the
problem. Figure 17.33 shows the attacks against the protocol:
Figure 17.33. Graphical interface giving the solution to a user.

This type of software may be very useful for identifying the design
vulnerabilities affecting current means of exchanging keys, performing
authentication, and so forth.
The code for the tool we just discussed is unfortunately not distributed.
For more information, you may contact its authors at Laval University.


“ Hackers Beware “ New Riders Publishing
754
Source Code
To my knowledge, no software exists that is able to threaten and attack
this protocol, and no source code is available. However, if a hacker
controls an entity, such as a router that is able to filter information and
make decisions on messages, and if this entity is located on the link
through which information is transmitted in an Otway-Rees Protocol, it

would be easy to write a short program to carry out this attack. For the
sake of concision, the pseudo code for the program specification for
reproducing the attack against the two parties of the key exchange
protocol is not presented here. However, with the pseudo code presented
here, it is easy to understand how such a program would be developed.
For the attack against the initiator of Otway-Rees Key Exchange Protocol,
the program could contain the following instruction:
Pseudo Code

get setup for the man-in-the-middle attack

if packet.protocol = Otway-Rees
if packet.data = Otway-Rees.message1
firstPrincipal = packet.data.firstPrincipal
secondPrincipal =
packet.data.secondPrincipal
sessionNumber =
packet.data.sessionNumber
messagetoSend = packet.data –
firstPrincipal –
secondPrincipal
sessionKey = sessionNumber +
firstPrincipal +
secondPrincipal
Send messagetoSend to the
firstPrincipal
Send sessionKey to the hacker
Else if
Don't touch it or send it to the right person
Additional Information

There are many types of specification vulnerabilities in security protocols
(for example key exchange protocols, authentication protocols, e-
commerce protocols, and so forth). Remember that a specification
vulnerability implies that there will be an implementation vulnerability,
even if implementation is perfect.
Additional information can be found at:


“ Hackers Beware “ New Riders Publishing
755
• B. Schneier: “Applied Cryptography”. Wiley, Second Edition, 1994.
• J. Clark. “Attacking Authentication Protocols”. High Integrity
Systems, 1 (5) :465-474, March 1996
•
• J. Clark and J. Jacob. “On Security of Recent Protocols”. Information
Processing Letters, 156 (3): 151-155, November 1995.
• J. Clark and J. Jacob. “A Survey of Authentication Protocols”,
November 1997.
• J. Clark and J. Jacob. “Draft: Implementation Dependencies and
Assumptions in Authentication Protocols”.
• S. Northcutt: “Network intrusion Detection:An Analyst’s Handbook”.
New Riders, First Edition, 1999.
•
•
• F. Massicotte: “Une théorie pour le type de faille dans les
cryptoprotocoles”, Master Thesis, Laval University, Québec, Canada,
237 pages.
HTTP Tunnel Exploit
The httptunnel exploit consists of two components, the client and the
server portion. The client component, htc, resides on the attacker’s

computer. The server portion, hts, resides on the victim’s server.
Exploit Details
• Name: Httptunnel, and the most current released version is 3.03. A
development version, 3.2, is available through CVS download.
• Variants: The main exploit is developed for the Linux/UNIX
environment by the original author. However, there are also NT
binaries.
• Operating System: Httptunnel is required to run on a Linux or
UNIX type operating system. The restrictions are limited to
compiling the binary file on the host machine.
• Protocols/Services: Httptunnel exploits the fact that most
firewalls have a proxy for http by creating a data tunnel. To utilize
the data tunnel, another service is used to send and receive data
across the established connection, such as telnet. The utility can be
configured for http proxies that have buffering configured.
• Written by: Paul Lochbihler
Protocol Description
The exploit uses the http protocol to deliver data across the tunnel with
the use of HTTP PUT and HTTP GET commands. All data sent to the victim
machine is done through the PUT command and data is returned through
the GET command. The client makes all requests.