Movatterモバイル変換

Network Working Group                                         R. StewartRequest for Comments: 5062                           Cisco Systems, Inc.Category: Informational                                        M. Tuexen                                      Muenster Univ. of Applied Sciences                                                            G. Camarillo                                                                Ericsson                                                          September 2007Security Attacks Found Againstthe Stream Control Transmission Protocol (SCTP)and Current CountermeasuresStatus of This Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Abstract   This document describes certain security threats to SCTP.  It also   describes ways to mitigate these threats, in particular by using   techniques from the SCTP Specification Errata and Issues memo (RFC4460).  These techniques are included inRFC 4960, which obsoletesRFC 2960.  It is hoped that this information will provide some useful   background information for many of the newest requirements spelled   out in the SCTP Specification Errata and Issues and included inRFC4960.Stewart, et al.              Informational                      [Page 1]

RFC 5062                 SCTP Security Attacks            September 2007Table of Contents1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .22.  Address Camping or Stealing  . . . . . . . . . . . . . . . . .23.  Association Hijacking 1  . . . . . . . . . . . . . . . . . . .34.  Association Hijacking 2  . . . . . . . . . . . . . . . . . . .65.  Bombing Attack (Amplification) 1 . . . . . . . . . . . . . . .76.  Bombing Attack (Amplification) 2 . . . . . . . . . . . . . . .97.  Association Redirection  . . . . . . . . . . . . . . . . . . .108.  Bombing Attack (Amplification) 3 . . . . . . . . . . . . . . .109.  Bombing Attack (Amplification) 4 . . . . . . . . . . . . . . .1110. Bombing Attack (amplification) 5 . . . . . . . . . . . . . . .1111. Security Considerations  . . . . . . . . . . . . . . . . . . .1212. References . . . . . . . . . . . . . . . . . . . . . . . . . .121.  Introduction   Stream Control Transmission Protocol, originally defined in   [RFC2960], is a multi-homed transport protocol.  As such, unique   security threats exists that are addressed in various ways within the   protocol itself.  This document describes certain security threats to   SCTP.  It also describes ways to mitigate these threats, in   particular by using techniques from the SCTP Specification Errata and   Issues memo [RFC4460].  These techniques are included in [RFC4960],   which obsoletes [RFC2960].  It is hoped that this information will   provide some useful background information for many of the newest   requirements spelled out in the [RFC4460] and included in [RFC4960].   This work and some of the changes that went into [RFC4460] and   [RFC4960] are much indebted to the paper on potential SCTP security   risks [EFFECTS] by Aura, Nikander, and Camarillo.  Without their   work, some of these changes would remain undocumented and potential   threats.   The rest of this document will concentrate on the various attacks   that were illustrated in [EFFECTS] and detail the preventative   measures now in place, if any, within the current SCTP standards.2.  Address Camping or Stealing   This attack is a form of denial of service attack crafted around   SCTP's multi-homing.  In effect, an illegitimate endpoint connects to   a server and "camps upon" or "holds up" a valid peer's address.  This   is done to prevent the legitimate peer from communicating with the   server.Stewart, et al.              Informational                      [Page 2]

RFC 5062                 SCTP Security Attacks            September 20072.1.  Attack Details      +----------+            +----------+           +----------+      | Evil     |            |  Server  |           | Client   |      |     IP-A=+------------+          +-----------+=IP-C & D |      | Attacker |            |          |           | Victim   |      +----------+            +----------+           +----------+                            Figure 1: Camping   Consider the scenario illustrated in Figure 1.  The attacker   legitimately holds IP-A and wishes to prevent the 'Client-Victim'   from communicating with the 'Server'.  Note also that the client is   multi-homed.  The attacker first guesses the port number our client   will use in its association attempt.  It then uses this port and sets   up an association with the server listing not only IP-A but also IP-C   in its initial INIT chunk.  The server will respond and set up the   association, noting that the attacker is multi-homed and holds both   IP-A and IP-C.   Next, the victim sends in an INIT message listing its two valid   addresses, IP-C and IP-D.  In response, it will receive an ABORT   message with possibly an error code indicating that a new address was   added in its attempt to set up an existing association (a restart   with new addresses).  At this point, 'Client-Victim' is now prevented   from setting up an association with the server until the server   realizes that the attacker does not hold the address IP-C at some   future point by using a HEARTBEAT based mechanism.  See the   mitigation option subsection of this section.2.2.  Analysis   This particular attack was discussed in detail on the SCTP   implementors list in March of 2003.  Out of that discussion, changes   were made in the BSD implementation that are now present in   [RFC4960].  In close examination, this attack depends on a number of   specific things to occur.   1) The attacker must set up the association before the victim and      must correctly guess the port number that the victim will use.  If      the victim uses any other port number the attack will fail.Stewart, et al.              Informational                      [Page 3]

RFC 5062                 SCTP Security Attacks            September 2007   2) SCTP's existing HEARTBEAT mechanism as defined already in      [RFC2960] will eventually catch this situation and abort the evil      attacker's association.  This may take several seconds based on      default HEARTBEAT timers but the attacker himself will lose any      association.   3) If the victim is either not multi-homed, or the address set that      it uses is completely camped upon by the attacker (in our example      if the attacker had included IP-D in its INIT as well), then the      client's INIT message would initiate an association between the      client and the server while destroying the association between the      attacker and the server.  From the servers' perspective, this is a      restart of the association.2.3.  Mitigation Option   [RFC4960] adds a new set of requirements to better counter this   attack.  In particular, the HEARTBEAT mechanism was modified so that   addresses unknown to an endpoint (i.e., presented in an INIT with no   pre-knowledge given by the application) enter a new state called   "UNCONFIRMED".  During the time that any address is UNCONFIRMED and   yet considered available, heartbeating will be done on those   UNCONFIRMED addresses at an accelerated rate.  This will lessen the   time that an attacker can "camp" on an address.  In particular, the   rate of heartbeats to UNCONFIRMED addresses is done every RTO.  Along   with this expanded rate of heartbeating, a new 64-bit random nonce is   required to be inside HEARTBEATs to UNCONFIRMED addresses.  In the   HEARTBEAT-ACK, the random nonce must match the value sent in the   HEARTBEAT before an address can leave the UNCONFIRMED state.  This   will prevent an attacker from generating false HEARTBEAT-ACKs with   the victim's source address(es).  In addition, clients that do not   need to use a specific port number should choose their port numbers   on a random basis.  This makes it hard for an attacker to guess that   number.3.  Association Hijacking 1   Association hijacking is the ability of some other user to assume the   session created by another endpoint.  In cases of a true man-in-the-   middle, only a strong end-to-end security model can prevent this.   However, with the addition of the SCTP extension specified in   [RFC5061], an endpoint that is NOT a man-in-the-middle may be able to   assume another endpoint's association.Stewart, et al.              Informational                      [Page 4]

RFC 5062                 SCTP Security Attacks            September 20073.1.  Attack Details   The attack is made possible by any mechanism that lets an endpoint   acquire some other IP address that was recently in use by an SCTP   endpoint.  For example, DHCP may be used in a mobile network with   short IP address lifetimes to reassign IP addresses to migrant hosts.        IP-A                 DHCP-Server's       Peer-Server          |          |       1  |-DHCP-Rel(IP-A)---->|       2  |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost         time          |          |-DHCP-new-net------>|       3  |<---Assign (IP-A)          |       4  |<------------Tag:X-DATA()------------------          |          |-------------INIT()------------------------>       5  |<------------INIT-ACK()---------------------          |       6  |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------>                   Figure 2: Association Hijack via DHCP   At point 1, our valid client releases the IP address IP-A.  It   presumably acquires a new address (IP-B) and sends an ASCONF to ADD   the new address and delete to old address at point 2, but this packet   is lost.  Thus, our peer (Peer-Server) has no idea that the former   peer is no longer at IP-A.  Now at point 3, a new "evil" peer obtains   an address via DHCP and it happens to get the re-assigned address   IP-A.  Our Peer-Server sends a chunk of DATA at point 4.  This   reveals to the new owner of IP-A that the former owner of IP-A had an   association with Peer-Server.  So at point 5, the new owner of IP-A   sends an INIT.  The INIT-ACK is sent back and inside it is a COOKIE.   The cookie would of course hold tie-tags, which would list both sets   of tags that could then be used at point 6 to add in any other IP   addresses that the owner of IP-A holds and thus acquire the   association.   It should be noted that this attack is possible in general whenever   the attacker is able to send packets with source address IP-A and   receive packets with destination address IP-A.Stewart, et al.              Informational                      [Page 5]

RFC 5062                 SCTP Security Attacks            September 20073.2.  Analysis   This attack depends on a number of events:   1) Both endpoints must support the SCTP extension specified in      [RFC5061].   2) One of the endpoints must be using the SCTP extension for mobility      specified in [RFC5061].   3) The IP address must be acquired in such a way as to make the      endpoint the owner of that IP address as far as the network is      concerned.   4) The true peer must not receive the ASCONF packet that deletes IP-A      and adds its new address to the peer before the new "evil" peer      gets control of the association.   5) The new "evil" peer must have an alternate address, aside from the      IP-A that it can add to the association, so it can delete IP-A,      preventing the real peer from re-acquiring the association when it      finally retransmits the ASCONF (from step 2).3.3.  Mitigation Option   [RFC4960] adds a new counter measure to this threat.  It is now   required that Tie-Tags in the State-Cookie parameter not be the   actual tags.  Instead, a new pair of two 32-bit nonces must be used   to represent the real tags within the association.  This prevents the   attacker from acquiring the real tags and thus prevents this attack.   Furthermore, the use of the SCTP extension specified in [RFC5061]   requires the use of the authentication mechanism defined in   [RFC4895].  This requires the attacker to be able to capture the   traffic during the association setup.  If in addition an endpoint-   pair shared key is used, capturing or intercepting these setup   messages does not enable the attacker to hijack the association.4.  Association Hijacking 2   Association hijacking is the ability of some other user to assume the   session created by another endpoint.  In cases where an attacker can   send packets using the victims IP-address as a source address and can   receive packets with the victims' address as a destination address,   the attacker can easily restart the association.  If the peer does   not pay attention to the restart notification, the attacker has taken   over the association.Stewart, et al.              Informational                      [Page 6]

RFC 5062                 SCTP Security Attacks            September 20074.1.  Attack Details   Assume that an endpoint E1 having an IP-address A has an SCTP   association with endpoint E2.  After the attacker is able to receive   packets to destination address A and send packets with source address   A, the attacker can perform a full four-way handshake using the IP-   addresses and port numbers from the received packet.  E2 will   consider this a restart of the association.  If and only if the SCTP   user of E2 does not process the restart notification, the user will   not recognize that the association just restarted.  From this   perspective, the association has been hijacked.4.2.  Analysis   This attack depends on a number of circumstances:   1) The IP address must be acquired in such a way as to make the evil      endpoint the owner of that IP address as far as the network or      local LAN is concerned.   2) The attacker must receive a packet belonging to the association or      connection.   3) The other endpoint's user does not pay attention to restart      notifications.4.3.  Mitigation Option   It is important to note that this attack is not based on a weakness   of the protocol, but on the ignorance of the upper layer.  This   attack is not possible if the upper layer processes the restart   notifications provided by SCTP as described insection 10 of   [RFC2960] or [RFC4960].  Note that other IP protocols may also be   affected by this attack.5.  Bombing Attack (Amplification) 1   The bombing attack is a method to get a server to amplify packets to   an innocent victim.5.1.  Attack Details   This attack is performed by setting up an association with a peer and   listing the victims IP address in the INIT's list of addresses.   After the association is setup, the attacker makes a request for a   large data transfer.  After making the request, the attacker does not   acknowledge data sent to it.  This then causes the server to re-   transmit the data to the alternate address, i.e., that of the victim.Stewart, et al.              Informational                      [Page 7]

RFC 5062                 SCTP Security Attacks            September 2007   After waiting an appropriate time period, the attacker acknowledges   the data for the victim.  At some point, the attackers address is   considered unreachable since only data sent to the victims address is   acknowledged.  At this point, the attacker can send strategic   acknowledgments so that the server continues to send data to the   victim.   Alternatively, instead of stopping the sending of SACKs to enforce a   path failover, the attacker can use the ADD-IP extension to add the   address of the victim and make that address the primary path.5.2.  Analysis   This attack depends on a number of circumstances:   1) The victim must NOT support SCTP, otherwise it would respond with      an "out of the blue" (OOTB) abort.   2) The attacker must time its sending of acknowledgments correctly in      order to get its address into the failed state and the victim's      address as the only valid alternative.   3) The attacker must guess TSN values that are accepted by the      receiver once the bombing begins since it must acknowledge packets      it is no longer seeing.5.3.  Mitigation Option   [RFC4960] makes two changes to prevent this attack.  First, it   details proper handling of ICMP messages.  With SCTP, the ICMP   messages provide valuable clues to the SCTP stack that can be   verified with the tags for authenticity.  Proper handling of an ICMP   protocol unreachable (or equivalent) would cause the association   setup by the attacker to be immediately failed upon the first   retransmission to the victim's address.   The second change made in [RFC4960] is the requirement that no   address that is not CONFIRMED is allowed to have DATA chunks sent to   it.  This prevents the switch-over to the alternate address from   occurring, even when ICMP messages are lost in the network and   prevents any DATA chunks from being sent to any other destination   other then the attacker itself.  This also prevents the alternative   way of using ADD-IP to add the new address and make it the primary   address.Stewart, et al.              Informational                      [Page 8]

RFC 5062                 SCTP Security Attacks            September 2007   An SCTP implementation should abort the association if it receives a   SACK acknowledging a TSN that has not been sent.  This makes TSN   guessing for the attacker quite hard because if the attacker   acknowledges one TSN too fast, the association will be aborted.6.  Bombing Attack (Amplification) 2   This attack allows an attacker to use an arbitrary SCTP endpoint to   send multiple packets to a victim in response to one packet.6.1.  Attack Details   The attacker sends an INIT listing multiple IP addresses of the   victim in the INIT's list of addresses to an arbitrary endpoint.   Optionally, it requests a long cookie lifetime.  Upon reception of   the INIT-ACK, it stores the cookie and sends it back to the other   endpoint.  When the other endpoint receives the COOKIE, it will send   back a COOKIE-ACK to the attacker and up to HB.Max.Burst HEARTBEATS   to the victim's address(es) (to confirm these addresses).  The victim   responds with ABORTs or ICMP messages resulting in the removal of the   TCB at the other endpoint.  The attacker can now resend the stored   cookie as long as it is valid, and this will again result in up to   HB.Max.Burst HEARTBEATs sent to the victim('s).6.2.  Analysis   The multiplication factor is limited by the number of addresses of   the victim and of the endpoint HB.Max.Burst.  Also, the shorter the   cookie lifetime, the earlier the attacker has to go through the   initial stage of sending an INIT instead of just sending the COOKIE.   It should also be noted that the attack is more effective if large   HEARTBEATs are used for path confirmation.6.3.  Mitigation Option   To limit the effectiveness of this attack, the new parameter   HB.Max.Burst was introduced in [RFC4960] and an endpoint should:   1) not allow very large cookie lifetimes, even if they are requested.   2) not use larger HB.Max.Burst parameter values than recommended.      Note that an endpoint may decide to send only one Heartbeat per      RTT instead of the maximum (i.e., HB.Max.Burst).  An endpoint that      chooses this approach will however slow down detection of      endpoints camping on valid addresses.   3) not use large HEARTBEATs for path confirmation.Stewart, et al.              Informational                      [Page 9]

RFC 5062                 SCTP Security Attacks            September 20077.  Association Redirection   This attack allows an attacker to wrongly set up an association to a   different endpoint.7.1.  Attack Details   The attacker sends an INIT sourced from port 'X' and directed towards   port 'Y'.  When the INIT-ACK is returned, the attacker sends the   COOKIE-ECHO chunk and either places a different destination or source   port in the SCTP common header, i.e., X+1 or Y+1.  This possibly sets   up the association using the modified port numbers.7.2.  Analysis   This attack depends on the failure of an SCTP implementation to store   and verify the ports within the COOKIE structure.7.3.  Mitigation Option   This attack is easily defeated by an implementation including the   ports of both the source and destination within the COOKIE.  If the   source and destination ports do not match those within the COOKIE   chunk when the COOKIE is returned, the SCTP implementation silently   discards the invalid COOKIE.8.  Bombing Attack (Amplification) 3   This attack allows an attacker to use an SCTP endpoint to send a   large number of packets in response to one packet.8.1.  Attack Details   The attacker sends a packet to an SCTP endpoint, which requires the   sending of multiple chunks.  If the SCTP endpoint does not support   bundling on the sending side, it might send each chunk per packet.   These packets can either be sent to a victim by using the victim's   address as the sources address, or it can be considered an attack   against the network.  Since the chunks, which need to be sent in   response to the received packet, may not fit into one packet, an   endpoint supporting bundling on the sending side might send multiple   packets.   Examples of these packets are packets containing a lot of unknown   chunks that require an ERROR chunk to be sent, known chunks that   initiate the sending of ERROR chunks, packets containing a lot of   HEARTBEAT chunks, and so on.Stewart, et al.              Informational                     [Page 10]

RFC 5062                 SCTP Security Attacks            September 20078.2.  Analysis   This attack depends on the fact that the SCTP endpoint does not   support bundling on the sending side or provides a bad implementation   of bundling on the sending side.8.3.  Mitigation Option   First of all, path verification must happen before sending chunks   other than HEARTBEATs for path verification.  This ensures that the   above attack cannot be used against other hosts.  To avoid the   attack, an SCTP endpoint should implement bundling on the sending   side and should not send multiple packets in response.  If the SCTP   endpoint does not support bundling on the sending side, it should not   send in general more than one packet in response to a received one.   The details of the required handling are described in [RFC4960].9.  Bombing Attack (Amplification) 4   This attack allows an attacker to use an SCTP server to send a larger   packet to a victim than it sent to the SCTP server.9.1.  Attack Details   The attacker sends packets using the victim's address as the source   address containing an INIT chunk to an SCTP Server.  The server then   sends a packet containing an INIT-ACK chunk to the victim, which is   most likely larger than the packet containing the INIT.9.2.  Analysis   This attack is a byte and not a packet amplification attack and,   without protocol changes, is hard to avoid.  A possible method to   avoid this attack would be the usage the PAD parameter defined in   [RFC4820].9.3.  Mitigation Option   A server should be implemented in a way that the generated INIT-ACK   chunks are as small as possible.10.  Bombing Attack (amplification) 5   This attack allows an attacker to use an SCTP endpoint to send a   large number of packets in response to one packet.Stewart, et al.              Informational                     [Page 11]

RFC 5062                 SCTP Security Attacks            September 200710.1.  Attack Details   The attacker sends a packet to an SCTP endpoint, which requires the   sending of multiple chunks.  If the MTU towards the attacker is   smaller than the MTU towards the victim, the victim might need to   send more than one packet to send all the chunks.  The difference   between the MTUs might be extremely large if the attacker sends   malicious ICMP packets to make use of the path MTU discovery.10.2.  Analysis   This attack depends on the fact that an SCTP implementation might not   limit the number of response packets correctly.10.3.  Mitigation Option   First of all, path verification must happen before sending chunks   other than HEARTBEATs for path verification.  This makes sure that   the above attack cannot be used against other hosts.  To avoid the   attack, an SCTP endpoint should not send multiple packets in response   to a single packet.  The chunks not fitting in this packet should be   dropped.11.  Security Considerations   This document is about security; as such, there are no additional   security considerations.12.  References12.1.  Normative References   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,              Zhang, L., and V. Paxson, "Stream Control Transmission              Protocol",RFC 2960, October 2000.   [RFC4460]  Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and              M. Tuexen, "Stream Control Transmission Protocol (SCTP)              Specification Errata and Issues",RFC 4460, April 2006.   [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and              Parameter for the Stream Control Transmission Protocol              (SCTP)",RFC 4820, March 2007.   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,              "Authenticated Chunks for Stream Control Transmission              Protocol (SCTP)",RFC 4895, August 2007.Stewart, et al.              Informational                     [Page 12]

RFC 5062                 SCTP Security Attacks            September 2007   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.              Kozuka, "Stream Control Transmission Protocol (SCTP)              Dynamic Address Reconfiguration",RFC 5061,              September 2007.   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",RFC 4960, June 2007.12.2.  Informative References   [EFFECTS]  Aura, T., Nikander, P., and G. Camarillo, "Effects of              Mobility and Multihoming on Transport-Layer Security",              Security and Privacy 2004, IEEE Symposium , URLhttp://research.microsoft.com/users/tuomaura/Publications/              aura-nikander-camarillo-ssp04.pdf, May 2004.Authors' Addresses   Randall R. Stewart   Cisco Systems, Inc.   4785 Forest Drive   Suite 200   Columbia, SC  29206   USA   EMail: rrs@cisco.com   Michael Tuexen   Muenster Univ. of Applied Sciences   Stegerwaldstr. 39   48565 Steinfurt   Germany   EMail: tuexen@fh-muenster.de   Gonzalo Camarillo   Ericsson   Hirsalantie 11   Jorvas  02420   Finland   EMail: Gonzalo.Camarillo@ericsson.comStewart, et al.              Informational                     [Page 13]

RFC 5062                 SCTP Security Attacks            September 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use of   such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at   ietf-ipr@ietf.org.Stewart, et al.              Informational                     [Page 14]