-----BEGIN PGP SIGNED MESSAGE-----
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : Nico de Koo Index : S-96-53
Distribution : World Page : 1
Classification: External Version: 1
Subject : TCP SYN-ACK Attack Proliferates on Internet Date : 19-Sep-96
===============================================================================
By courtesy of NASA Automated Systems Incident Response Capability we received
information on a vulnerability in TCP known as the SYN-ACK Attack.
Since there is no direct solution to this vulnerability CERT-NL recommends
to be aware of this problem and asks to inform CERT-NL in case of occurence
of the described problem on a system in our constituency.
==============================================================================
Two "underground hacker magazines" have recently published code
to conduct attacks by creating TCP "half open" connections. This
code is actively being used to attack sites connected to the
Internet, and there is, as yet, no good defense against it nor
any simple way to trace the origin of the attack.
SYSTEMS AFFECTED
Any system connected to the Internet and providing network
services such as a Web-server or FTP-server is potentially
subject to this attack. The consequences of the attack may vary
between systems however the attack itself is fundamental to the
network protocol used by all systems.
BACKGROUND
When a system attempts to establish a TCP connection to to
another system it initiates the connection via a set sequence of
messages. This applies to all connections, telnet, web, email or
anything else. The originating system sends a SYN packet to the
receiving system, which then acknowledges that packet by sending
an ACK. The originating system acknowledges that response and
the connection is then open and the email can be sent, or the
web-page returned or whatever required transaction can proceed.
PROBLEM
The potential for abuse arises at the point where the receiving
system has sent an acknowledgment back to the sender but has not
yet received the third message in the sequence. It stores the
information on the pending connection in an in-memory data
structure, which is of finite size. This structure can be
overflowed by intentionally creating too many partially-open
connections. This is easily done by sending many SYN packets
without responding to the ACK returned by the target system.
Since the attacker does not respond to the ACK packets, it does
not even need to see them, so it may obscure its own location by
using a false address in the SYN packets it sends. It may vary
the address used so that the packets appear to be legitimate
network traffic.
The upshot of this is that the pending-connections structure
maintained by the victim system will be choked by these bogus
pending connections and the system will be unable to accept any
more incoming network connections, whether legitimate or not,
until the table is emptied out. Normally there is a timeout
associated with a pending-connection, so the bogus connections
will eventually expire and the system will recover, however the
attacker can simply continue sending bogus connection requests
faster than they can expire.
The victim of such an attack will have great difficulty in
accepting any new incoming network connection. Existing incoming
connections will not be affected. The ability to originate
outgoing network connections is unimpaired by the attack.
The location of the attacker is obscured by the fact that most
routers will forward a packet addressed to the victim system even
though the source-address on the packet is completely
implausible. The packet will be forwarded without the route it
followed being recorded anywhere, so when it arrives at the
victim system there is no way to determine its true source.
DETECTING AN ATTACK
Users of the attacked system may notice nothing unusual since the
bogus connection requests may not load the system noticeably, and
the system is still able to establish outgoing connections. The
problem will most likely be noticed by someone attempting to
access one of the services on the victim system.
In order to verify that this attack is occurring, someone on the
attacked system must check the state of the system's network
traffic. On SunOS this may be done by the command:
netstat -a -f inet
Too many connections in the state "SYN_RECEIVED" indicate that
the system is being attacked.
NASIRC has not had the opportunity to test this detection method
on other systems, and we are therefore unable to provide the
exact instructions to use it elsewhere.
RECOMMENDED ACTION
CERT-NL requests that any attacks of this nature be reported via
our usual channels described in the footer of this bulletin.
There is, as yet, no generally accepted solution to this problem.
* Proper router configuration can insure that your site
is not the source of one of these attacks.
The attack program assigns random return addresses to
the packets it generates, so they will generally be
nowhere close to the address of the true source of the
attacking packet. If the router connecting your site
to the Internet is configured to drop all outgoing
packets whose source address is not within your local
network, this will prevent a SYN/ACK attack originating
within your local network from reaching an outside
site.
* A product called "RealSecure" from Internet Security
Systems, Inc. is available for Alpha-testing. It
monitors for SYN packets that are not part of a normal
connection-opening sequence and sends a reset packet
that clears the connection. This is not a perfect
solution because it still allows the bogus connection
request to reside in the target system for some period
of time so a heavy enough bombardment by the attacking
system can still block legitimate network connections.
The Alpha-test version is free, but available for use
for sixty days.
Note that NASIRC has not had the opportunity to test
this product and cannot endorse it.
If you wish to evaluate it, send mail to "majordomo@Iss.net"
and in the body of the message enter:
subscribe RealSecure
The ISS system will respond with information on how to
locate the Alpha-test version of RealSecure and the
license agreement.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ACKNOWLEDGMENTS: Chris Klaus of ISS, Vikram Bajaj of U.
of Penn. and Rahul Dhesi for informative articles
posted to Usenet.
BULLETIN AUTHOR: Fred Blonder
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers.
SURFnet is the Dutch network for educational, research and related institutes.
CERT-NL is a member of the Forum of Incident Response and Security Teams
(FIRST).
All CERT-NL material is available under:
http://www.surfnet.nl/surfnet/security/cert-nl.html
ftp://ftp.surfnet.nl/surfnet/net-security
In case of computer or network security problems please contact your
local CERT/security-team or CERT-NL (if your institute is NOT a SURFnet
customer please address the appropriate (local) CERT/security-team).
CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).
Email: cert-nl@surfnet.nl
Phone: +31 302 305 305
Fax: +31 302 305 329
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands
A 7 * 24 hours phone number is available to SURFnet SSC's and FIRST
members on request.
==============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAwUBMkERmmL2fnkJN/jpAQGLegQAvypUUqhWJRh8g15gE7770XT1doDIL01o
IwHWQEsqaSMGYQkWEL+w63J95pFMn8O8ugJTH0mbsOzJ3CpEqkO7478ZazNFjuBQ
j7m4r32tJAkTXPcXlKfZhBNGw5SHBmkIoSwFaIJbMvBPuO98DwLdKBhSGQKn05Ip
X0XpvQx6SgM=
=FZMt
-----END PGP SIGNATURE-----