Subject: SCTP Vulnerability

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Mar 2001 15:45:01 -0600

Have you seen this one yet?

Problem:

    An SCTP endpoint which implements the "SHOULD" parts of RFC 2960
    Section 8.4 or the MUST parts of Section 5.1 can be made to send
    ABORT chunks to an arbitrary address with arbitrary verification
    tags.

Description:

    Section 8.4:

    Evil endpoint 'E' sends an OOTB packet to 'A' spoofing source
    address of the Target 'T'.  If endpoint 'A' sends ABORT to
    OOTB as it SHOULD from Section 8.4, it will send ABORT to
    'T' with T-bit set and VTAG from attacker's message.

    +------+     SRC:T      +------+     DST:T      +------+
    |      |     DST:A      |      |     SRC:A      |      |
    |  E   |--------------->|  A   |--------------->|  T   |
    |      |     VTAG:Z     |      |     VTAG:Z     |      |
    +------+                +------+     T-Bit      +------+

                HEARTBEAT                ABORT

    The target 'T' is vulnerable (and 'A' gullable) in the COOKIE-WAIT
    and COOKIE-ECHOED states on the selected port.  By flooding, 'E'
    could possibly deny initialization of associations from 'T' to 'A's
    well-known port numbers.

    Solution: Don't send ABORT in response to OOTB as indicated
    in RFC 2960 Section 8.4.

    Section 5.1:

    Evil endpoint 'E' sends an OOTB INIT to 'A' with missing or
    invalid mandatory parameters spoofing source address of the
    Target 'T'.  If endpoint 'A' sends ABORT to OOTB INIT as
    it MUST in Section 5.1, it will send ABORT to 'T', without
    T-bit set and with the VTAG from the attacker's INIT ITAG.

    +------+     SRC:T      +------+     DST:T      +------+
    |      |     DST:A      |      |     SRC:A      |      |
    |  E   |--------------->|  A   |--------------->|  T   |
    |      |     VTAG:0     |      |     VTAG:Z     |      |
    +------+     ITAG:Z     +------+                +------+

             Bad INIT                    ABORT

    The target 'T' is vulnerable (and 'A' gullable) in the COOKIE-WAIT
    and COOKIE-ECHOED states on the selected port.  By flooding, 'E'
    could possibly deny initialization of associations from 'T' to 'A's
    well-known port numbers.

    Solution: Don't send ABORT in response to refused INIT in
    violation of RFC 2960 Section 5.1.

Solution:

    Do not, or throttle, sending ABORT to OOTB packets.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Chip Sharp <[email-masked]>
Date: Mon, 19 Mar 2001 21:42:18 -0500

I'm not sure about these particular issues, but we had discussions of 
several (many) issues surrounding ABORT operation such as this when it was 
added.  I don't remember if these exact cases were discussed.  They are in 
my archives somewhere.

At the time, I believe the argument was that the ABORT provided value that 
offset the potential for misuse.  In addition, there is no amplification.
Therefore, the choice was to utilize the ABORT message even though this 
type of behavior was possible.

Chip

At 03:45 PM 3/19/2001 -0600, Brian F. G. Bidulock wrote:

>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------

---

---

From: [email-masked]
Date: Tue, 20 Mar 2001 14:33:30 +0200

>     Solution: Don't send ABORT in response to OOTB as indicated

	I'm not so sure I'm missing something, but, wouldn't it be that the
ABORT would be rejected if it doesn't have the right verification tag
(peer's one, or ours if the T bit is set)?. During COOKIE-WAIT and
COOKIE-ECHOED states for T, A doesn't have any boundaries at all yet with T,
so, you are right when saying that A would send that ABORT chunk to T, but
it would have the T bit set, and the verification tag set to one random
value chosen by E that doesn't match A's or T's tag, so T would discard
it... wouldn't it?

	T could receive lots of ABORTs, ok, but it will discard them all,
and proceed with the initialization process. As soon as A receives the
COOKIE ECHO chunk, A would start discarding the chunks sent by E, since it
would find an association but the Verification Tag wouldn't match...

	Maybe I'm wrong, but I would say that this wouldn't cause any
trouble...

>     violation of RFC 2960 Section 5.1.

	I think that there is exactly the same problem here with the tags...
In my opinion this attack wouldn't work either...

>     Do not, or throttle, sending ABORT to OOTB packets.

	Thanks!

	BR Iván Arias Rodríguez

---