-----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-----