gecloud.ch/security-scripts
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

added vpn scripts

Browse source
This commit is contained in:
Peter Baumann 2013-06-04 17:07:08 +02:00
parent 6560762504
commit ec0003bfa8
72 changed files with 424909 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

263
vpn/ike-scan-1.9/udp-backoff-fingerprinting-paper.txt Normal file
View file

@ -0,0 +1,263 @@
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.