263 lines
12 KiB
Text
263 lines
12 KiB
Text
NTA MONITOR UDP BACKOFF PATTERN FINGERPRINTING WHITE PAPER
|
|
|
|
Author: Roy Hills
|
|
Date: 17 January 2003
|
|
|
|
This paper may be freely distributed providing that the contents are not
|
|
altered in any way. The latest version is available at:
|
|
http://www.nta-monitor.com/tools/ike-scan/
|
|
|
|
1. ABSTRACT
|
|
|
|
This paper discusses how it is possible to determine which implementation of
|
|
a UDP service is being used from the retransmission backoff pattern. It
|
|
uses IKE (Internet Key Exchange) as an example UDP service which can be
|
|
identified in this way, although the technique may also be applicable to
|
|
other UDP services.
|
|
|
|
The paper also describes an example program called "ike-scan" which is able
|
|
to discover and identify IPsec VPN systems running IKE. This program is
|
|
publicly available under the GNU Public License (GPL). See
|
|
http://www.nta-monitor.com/tools/ike-scan/ for details.
|
|
|
|
2. OVERVIEW
|
|
|
|
Although most services on the Internet use the TCP transport, some use UDP
|
|
instead. Because UDP is not a reliable transport, it is up to the application
|
|
to provide the reliability itself if needed. The main technique used to
|
|
ensure reliability is retransmission with backoff which allows the application
|
|
to tolerate lost or damaged packets.
|
|
|
|
Retransmission backoff involves re-sending a packet if a response is not
|
|
received from the peer within a given time, the assumption being that
|
|
the original packet must have been lost or damaged in transit. There are
|
|
several variables involved with the retransmission strategy, including:
|
|
|
|
a) How long to wait before re-sending the packet?
|
|
|
|
b) How should the re-send delay change for subsequent packets, e.g. should
|
|
the delay remain constant, or should it increase with each re-send.
|
|
If the delay is to increase, what algorithm should be used (e.g. linear
|
|
or exponential) and what parameters should be used?
|
|
|
|
c) How many packets should be sent before giving up?
|
|
|
|
Often, the exact retransmission strategy is not specified by the relevant
|
|
standard which means that each developer will typically choose their own
|
|
scheme. Because there are a number of variables involved, and there is no
|
|
"obviously correct" choice of strategy, this results in most implementations
|
|
having distinct backoff patterns or "fingerprints". This distinctive
|
|
fingerprint could be used to determine which vendor's implementation is
|
|
being used.
|
|
|
|
Potentially any UDP based service which needs to implement reliable data
|
|
transfer and does not have the retransmission strategy defined by the
|
|
appropriate standard may be subject to identification through this
|
|
backoff fingerprinting method. The specific UDP service which has been
|
|
investigated in detail is IKE.
|
|
|
|
For IKE, the use of retransmission is mandated by RFC 2408 (ISAKMP - the
|
|
protocol framework used by IKE) Section 5.1 but the exact backoff strategy is
|
|
not defined. RFC 2408 suggests basing the retransmission times on measured
|
|
round-trip times. However this is not practical for the first transmitted
|
|
packet because there are no previous round-trip times to use. It is first
|
|
packets transmitted by the VPN server which are used by the "ike-scan" program
|
|
to determine the backoff fingerprint.
|
|
|
|
The retransmission and backoff strategy for various different IKE
|
|
implementations has been studied, and it has been found that:
|
|
|
|
a) Most, if not all, IPsec VPN vendor implementations have different
|
|
IKE retransmission and backoff strategies; and
|
|
|
|
b) It is possible to reliably match these patterns to determine which
|
|
IKE implementation a particular host is using.
|
|
|
|
Sometimes the backoff pattern changes from one version of a product to
|
|
another which provides more information and allows different versions of
|
|
a particular implementation to be distinguished from each other.
|
|
|
|
3. ISSUES
|
|
|
|
Although just being able to discover an IPsec VPN system running IKE
|
|
and determine which IKE implementation it is using is not a vulnerability
|
|
in itself, this information can be valuable to a potential attacker.
|
|
|
|
For example, knowing that there is an XYZ brand of VPN server at a
|
|
given address could prompt an attacker to download the appropriate VPN
|
|
client and try some username/password guessing. Alternatively, the
|
|
attacker could search for known vulnerabilities associated with the XYZ
|
|
VPN server.
|
|
|
|
Some IKE implementations don't log IKE activity if the handshake does
|
|
not complete. Because it is not necessary to complete the IKE handshake
|
|
to discover and fingerprint the system, these systems will not log the
|
|
scanning activity and their owners will not be aware that their system has
|
|
been scanned. "ike-scan" does not complete the IKE handshake and can therefore
|
|
be used to check if a given implementation will log this sort of scanning.
|
|
|
|
This choice not to log if the handshake doesn't complete, and particularly
|
|
if the initial cookie exchange does not complete, may be based on the
|
|
recommendation in RFC 2408 section 1.7.1 that "A 'cookie' ... is aimed at
|
|
protecting the computing resources from attack without spending excessive
|
|
CPU resources ..." i.e. nothing "expensive" should be done until the cookie
|
|
exchange completes. Although this is normally taken to apply to the
|
|
CPU-intensive cryptographic functions, it could also be applied to logging
|
|
if log storage were considered expensive. On the other hand, RFC 2408
|
|
section 5.1 says that "If the retry counter reaches zero (0), the event,
|
|
RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file".
|
|
This would also apply when a system is scanned. In summary, the RFC seems
|
|
to leave the choice to log or not up to the implementation.
|
|
|
|
In the course of performing many security assessments and penetration
|
|
tests for customers, we have found that VPN systems often provide full
|
|
access to the internal network which makes them tempting targets to an
|
|
attacker. In addition, many people assume that their VPN servers are
|
|
invisible and impenetrable which is a dangerous assumption given that
|
|
the "ike-scan" program shows that IPsec VPN systems can be discovered and
|
|
identified. When this potential for discovery and identification is combined
|
|
with the fact that several VPN vulnerabilities have been discovered in the
|
|
past few months, it would seem to be only a matter of time before hackers
|
|
start to target VPN systems.
|
|
|
|
The aim of this white paper and the associated "ike-scan" program is to
|
|
demonstrate the problem so that it is understood by the security community
|
|
and VPN vendors. The program also allows organisations to test their own
|
|
networks to see what information a hacker could discover and close any
|
|
holes before they can be exploited.
|
|
|
|
4. EXAMPLE PROGRAM
|
|
|
|
The program "ike-scan" demonstrates detection and identification of IPsec
|
|
VPN systems. The backoff patterns are stored in a text file which makes
|
|
it easy to add new patterns as they are discovered.
|
|
|
|
This program is available for free download from:
|
|
http://www.nta-monitor.com/tools/ike-scan/
|
|
|
|
ike-scan sends an initial IKE main-mode packet to each of the specified
|
|
hosts and records all the responses returned. It will display the responses
|
|
received which discovers which hosts are running IKE and will return a
|
|
response (most IKE implementations will respond in the default configuration,
|
|
but not all). It can also record and display the retransmission backoff
|
|
pattern for each responding host and attempt to match this pattern against
|
|
a database of known patterns to "fingerprint" the IKE implementation.
|
|
|
|
The program handles retry and retransmission with backoff to cope with packet
|
|
loss. It also limits the amount of bandwidth used by the outbound IKE packets.
|
|
|
|
The IKE packet exchange between ike-scan and a VPN server which returns a
|
|
handshake response is shown below:
|
|
|
|
Packet No. ike-scan VPN Server
|
|
---------- -------- ----------
|
|
|
|
1 Header, SA --->
|
|
2 <--- Header, SA
|
|
3 <--- Header, SA
|
|
4 <--- Header, SA
|
|
|
|
In this packet exchange, the ike-scan program sends a packet containing
|
|
a Header and an SA (Security Association) to the VPN server. The VPN server
|
|
then responds with a Header and SA. ike-scan records the time of this
|
|
response packet for later fingerprinting, but it does not respond to it.
|
|
Because the VPN server does not receive a response from ike-scan, it assumes
|
|
that the packet must have been lost, so it re-sends the packet after a
|
|
delay. As the VPN server never received any response from ike-scan, it keeps
|
|
resending the same packet using its retransmission strategy until it gives
|
|
up.
|
|
|
|
When the last packet has been received from the VPN server, ike-scan has
|
|
the receive times for all of the packets. These receive times can be used
|
|
to display the retransmission strategy and also attempt to match this
|
|
strategy against known strategies.
|
|
|
|
An example run of the program is shown below:
|
|
|
|
$ ike-scan --showbackoff 172.16.2.2 10.0.1.98
|
|
Starting ike-scan v1.0 with 3 hosts (http://www.nta-monitor.com/ike-scan/)
|
|
172.16.2.2 IKE Handshake returned (1 transforms)
|
|
10.0.1.98 IKE Handshake returned (1 transforms)
|
|
|
|
IKE Backoff Patterns:
|
|
|
|
IP Address No. Recv time Delta Time
|
|
172.16.2.2 1 1042797936.905288 0.000000
|
|
172.16.2.2 2 1042797938.901378 1.996090
|
|
172.16.2.2 3 1042797940.904158 2.002780
|
|
172.16.2.2 4 1042797942.906987 2.002829
|
|
172.16.2.2 5 1042797944.909644 2.002657
|
|
172.16.2.2 6 1042797946.912480 2.002836
|
|
172.16.2.2 7 1042797948.915286 2.002806
|
|
172.16.2.2 8 1042797952.920635 4.005349
|
|
172.16.2.2 9 1042797956.926155 4.005520
|
|
172.16.2.2 10 1042797960.931677 4.005522
|
|
172.16.2.2 11 1042797964.937201 4.005524
|
|
172.16.2.2 12 1042797968.942691 4.005490
|
|
172.16.2.2 Implementation guess: Firewall-1 4.1/NG
|
|
|
|
10.0.1.98 1 1042797937.070152 0.000000
|
|
10.0.1.98 2 1042797952.061102 14.990950
|
|
10.0.1.98 3 1042797967.064137 15.003035
|
|
10.0.1.98 Implementation guess: Cisco IOS / PIX
|
|
|
|
In the above example, the ike-scan program was run with the --showbackoff
|
|
option against the two hosts 172.16.2.2 and 10.0.1.98. The program first
|
|
discovers that both hosts are running IKE and that both of them will return
|
|
an IKE handshake response as shown by the "IKE Handshake returned". lines.
|
|
|
|
The program then records and displays the retransmission backoff pattern that
|
|
the VPN servers use when re-sending its response to the IKE packet sent by
|
|
ike-scan. The pattern responses contain the following four columns:
|
|
|
|
IP Address The IP address of the VPN server that this pattern relates to.
|
|
|
|
No. The number of the response packet from this host with the
|
|
first response packet being 1.
|
|
|
|
Recv time The time when this response packet was received. This time
|
|
is shown as the number of seconds and microseconds since
|
|
midnight on Jan 1, 1970 (the Epoch used by Unix systems).
|
|
|
|
Delta Time The difference between the time when this response packet was
|
|
received and the time when the previous response packet was
|
|
received. This is always zero for the first response packet.
|
|
The difference is shown in seconds and microseconds.
|
|
|
|
5. CONTACT ADDRESS
|
|
|
|
Please send any questions or comments to ike-scan@nta-monitor.com
|
|
See the ike-scan homepage at: http://www.nta-monitor.com/tools/ike-scan/
|
|
|
|
6. GLOSSARY OF TERMS
|
|
|
|
IKE Internet Key Exchange. The protocol used by IPsec to exchange keys
|
|
and authenticate the users or devices at either end of the VPN. IKE
|
|
is defined in RFC 2409.
|
|
|
|
IPsec Internet Protocol SECurity, security functions (authentication and
|
|
encryption) implemented at the IP level of the protocol stack. Most
|
|
VPN implementations use IPsec.
|
|
|
|
TCP Transmission Control Protocol. The most common transport protocol in
|
|
the TCP/IP protocol suite. TCP is a reliable protocol. TCP is
|
|
defined in RFC 761.
|
|
|
|
UDP User Datagram Protocol. One of the transport protocols in the TCP/IP
|
|
protocol suite. UDP is an unreliable protocol, that is UDP does not
|
|
guarantee data delivery. UDP is defined in RFC 768.
|
|
|
|
VPN Virtual Private Network. Allows local area networks to communicate
|
|
across public networks such as the Internet, typically over an
|
|
encrypted channel.
|
|
|
|
RFC Request for Comments. The standards documents for Internet protocols.
|
|
RFCs are available from http://www.ietf.org/rfc.
|
|
The RFCs relating to IKE are:
|
|
RFC 2407 - The Internet IP Security Domain of Interpretation for ISAKMP
|
|
RFC 2408 - Internet Security Association and Key Management Protocol
|
|
RFC 2409 - The Internet Key Exchange (IKE)
|
|
|
|
Cookie A unique 64-bit value used by IKE to identify peers and prevent some
|
|
Denial of service attacks.
|
|
|