Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Tue, 11 Mar 2003 15:32:21 +0200

Brian,

> 
> Ivan, Randall,
> 
> Here is a new source address spoof (DoS and hijack) attack
> on the COOKIE-ECHOED state.  2.6 does not have this correct
> yet (and neither does the RFC).
> 
> IG Section 2.6
> 
>    Upon receipt of an INIT in the COOKIE-ECHOED state, an 
> endpoint MUST
>    respond with an INIT ACK using the same parameters it sent in its
>    original INIT chunk (including its Initiation Tag, unchanged)
>    provided that no NEW address have been added to the forming
>    association. If the INIT message indicates that a new address(es)
>    have been added to the association, then the entire INIT MUST be
>    discarded and NO changes should be made to the existing 
> association.
>    An ABORT MUST be sent in response that SHOULD include the error
>    'Restart of an association with new addresses'. The error 
> SHOULD list
>    the addresses that were added to the restarting association.
> 
> 
> Host A/B                                       Host X   Host C/D
>   |                                               |        |
>   |INIT A:1000 -> X:1000                          |        |
>   |---------------------------------------------->|        |
>   |TCB1:                                          |        |
>   |VT: X                                          |        |
>   |PT: 0                                          |        |
>   |Loc: A:1000                                    |        |
>   |Rem: X:1000                                    |        |
>   |State: COOKIE-WAIT                             |        |
>   |                                               |        |
>   |                  INIT-ACK X:1000 -> A:1000 (D)|        |
>   |<----------------------------------------------|        |
>   |(TCB1 is found)                                |        |
>   |                                               |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |TCB1:                                          |        |
>   |VT: X                                          |        |
>   |PT: W                                          |        |
>   |Loc: A:1000                                    |        |
>   |Rem: X:1000, D:1000                            |        |
>   |State: COOKIE-ECHOED                           |        |
>   |                                  X does not   |        |
>   |                                  send (or delays)      |
>   |                                  COOKIE-ACK   |        |
>   |                                               |        |
>   |T1-cookie timeout                              |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |                                               |        |
>   |T1-cookie timeout                              |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
> Note that X can keep the T1-cookie timeout initially high by
> responding to a retransmitted INIT instead of the first INIT
> above.  T1-cookies doubles with each retransmission up to 60
> seconds, so the sequence is 3sec, 6sec, 12sec, 24sec, 48sec,
> 60sec, 60sec, 60sec which is 273 seconds or about 4 minutes.
> There are ways to extend this period longer.
>   |                                               |        |
>   |                              INIT C:1000 ->  A:1000 (D)|
>   |<-------------------------------------------------------|
>   |                                               |        |
>   |ABORT ERROR (Restart with new addresses)       |        |
>   |------------------------------------------------------->|
>   |                                               |        |
>   |T1-cookie timeout                              |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |                .                              |        |
>   |                .                              |        |
>   |                .                              |        |
>   |                                               |        |
> 
> Following IG Section 2.6 provides for  DoS attack with spoofed
> addresses in address list.

	Well... I think that normally, an attacker is somebody that comes out of the shadow and tries to connect to you, not the opposite... You trying to connect to the attacker that tries a third party not to connect to you seems very weird... I'm not saying that it is completely impossible thought...

	However, in this case, one would normally think that the attacker is in fact Host C/D, not Host X... At the end, it was you the one that decided freely to connect to the attacker... I think that if somebody you try to connect with, results to be an attacker, one can easily ban him...

	I doubt that an attacker is going to be somebody that makes its service known enough so you decide to connect to him... after all, one takes a while to gain your confidence (so you try to connect to him), but it simply takes an attack to lose that confidence... I hope you follow what I'm saying...

	However, this situation has a (not very handy) solution. Let's see...

	Host C/D, seeing that somebody else has forged its address, decides to send an INIT including only one address. If the ABORT includes the extra addresses, it can simply try to establish an association without those ones. This will take the association out of Host X control. If both peers have AddIP, it is easy to add those other addresses later. If not, HOST C/D will have to ABORT the association and then try to establish it again with all the addresses. Of course, during this time Host X may try again to be faster than Host C/D and again keep control of the association... :-(

	Now that I think about it... You may hate what I'm going to say, but... you may not... :-)

	All these problems about hijacking associations and DOS come because the peer didn't show that it really owns the address inside the address list... Why not adding some kind of option that tells the peer to "show" its ownership right after establishing the association?

	However, I fail to see how this could be done... You can only show the ownership if you reply to something sent to that address... And I guess that again the HB mechanism would be the best one...

	I think that in cases where an incoming INIT (not sure about the INIT ACK) adds new addresses (maybe only in cases where the INIT conflicts only with one association), one should try to verify the new addresses included inside the INIT... However, this is not very good idea either... Since you have to send a packet (in order to receive the reply) to verify one address, this could lead to packet multiplication... unless we make first the peer to send to us that same quantity of packets or something... hmm...

	Any idea?

> Host X can refuse access to A for an arbitrary number of multi-homed
> hosts, should A form an association with X.

	But this is the problem... Why would A want to make an association with an attacker? As soon as one realizes that it is an attacker, you will never connect to that host... I don't really think this attack will be possible to do in the real world... :-/

> Here is a reverse hijack:
> 
> Host A/B                                       Host X   Host C
>   |                                               |        |
>   |INIT A:1000 -> X:1000                          |        |
>   |---------------------------------------------->|        |
>   |TCB1:                                          |        |
>   |VT: X                                          |        |
>   |PT: 0                                          |        |
>   |Loc: A:1000                                    |        |
>   |Rem: X:1000                                    |        |
>   |State: COOKIE-WAIT                             |        |
>   |                                               |        |
>   |                  INIT-ACK X:1000 -> A:1000 (C)|        |
>   |<----------------------------------------------|        |
>   |(TCB1 is found)                                |        |
>   |                                               |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |TCB1:                                          |        |
>   |VT: X                                          |        |
>   |PT: W                                          |        |
>   |Loc: A:1000                                    |        |
>   |Rem: X:1000, C:1000                            |        |
>   |State: COOKIE-ECHOED                           |        |
>   |                                  X does not   |        |
>   |                                  send (or delays)      |
>   |                                  COOKIE-ACK   |        |
>   |                                               |        |
>   |T1-cookie timeout                              |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |                                               |        |
>   |T1-cookie timeout                              |        |
>   |COOKIE-ECHO A:1000->X:1000                     |        |
>   |---------------------------------------------->|        |
>   |                .                              |        |
>   |                .                              |        |
>   |                .                              |        |
>   |                                               |        |
>   |                          INIT (IT: Y) C:1000 ->  A:1000|
>   |<-------------------------------------------------------|
>   |                                               |        |
>   |INIT-ACK (IT: X, no tie tags)                  |        |
>   |------------------------------------------------------->|
>   |                                               |        |
>   |                           COOKIE-ECHO C:1000 -> A:1000 |
>   |<-------------------------------------------------------|
>   |Action B                                       |        |
>   |COOKIE-ACK A:1000 -> C:1000                    |        |
>   |------------------------------------------------------->|
>   |TCB1                                           |        |
>   |VT: X                                          |        |
>   |PT: Y                                          |        |
>   |Loc: A:1000                                    |        |
>   |Rem: X:1000, C:1000                            |        |
>   |State: ESTABLISHED                             |        |
> 
> X now knows A's verification tag for its association with C.

	Hmm... no... And this is not even an attack, it is "recovering what is yours"... I don't accept this case... This is actually the way Host C would defend from the situation above...

	Host C sends the INIT, and Host A is in ESTABLISHED, so, as it doesn't add addresses, it replies to C including a NEW IT and also the Tie Tags... At the end, Host C will have its association with Host A, and Host X (the attacker) will lose control over address C, which is not one of its addresses...

	X doesn't know any VT since Host A included a NEW IT inside the INIT ACK sent to C... That's in section 5.2.2...

	Now that I think about new addresses and stuff... Is it there any danger about hijacking another established association, if the new addresses are inside the address list?

	I mean... If somebody claiming to be in this case above, C, includes more addresses inside the address list, but still proves to be C (since it replies to the INIT ACK), isn't he in fact the legitimate owner of any other association that is using C?

	In the case above... Does it really make sense to send an ABORT to C if it would also include, let's say, address D? I don't think so... If it replies to the INIT ACK sent to C, he is C, and thus, I think we should immediately close the other association...

	The rules for this would be something like:

	- If the INIT adding new addresses to an association comes from any of the "known addresses", then act as if it wouldn't be adding addresses.
	- If the INIT adding new addresses to an association comes from any "unknown address", then act "taking care" (either sending the ABORT -which may not be the best idea-, or sending the INIT ACK back to any of the "known addresses" included in the new INIT).

	This way we would avoid these problems about "malicious servers"... Does it make sense? I haven't thought much about it, I might have made a terrible mistake somewhere...

> X can know that the association is established with C because
> COOKIE-ECHOs stop prematurely, or if A does not kick X out of
> the TCB (not stated in RFC or IG), a DATA or HEARTBEAT will
> eventually tell X that it is in the established state.  DATA
> or a HEARTBEAT would also tell X C's verification tag for the
> association.  Or, if X is not kicked out of the TCB, it could
> send an INIT and read C's verification tag out of the tie tags
> in the cookie in the INIT-ACK.

	No... Since you didn't get the VT any of the above is a real treat...

> If X is not kicked out of the TCB then one-way
> eavesdropping is possible.
> 
>   |                                               |        |
>   |DATA (VT: Y)                                   |        |
>   |---------------------------------------------->|------->|
>   |                                               |        |
> 

	Yes, X is taken away, since you restart the association, you rebuild the TCB and only include those addresses that C told you to include...

	The fact that Host A chose a new IT is what makes your assumptions false... sorry... though the idea was interesting...

> Even if X is kicked out of the TCB, X knows A's verification tag
> for the association between A and C.  A simultaneous attack on
> C could yeild C's verification tag for the association.

	This would have been a terrible hole in security for TCB in my opinion... But this hole doesn't, fortunately, exist...

> A DoS attack would be to send an ABORT to A with the known VT
> when the COOKE-ECHO is not received, and start the process again
> with a new INIT.  This DoS attack has the difference over the
> previous one that no ERROR message is sent to C.

	Interesting, but impossible...

> To avoid this problem, INIT received in the COOKIE-ECHO state
> needs to be treated the same as INIT in the ESTABLISHED state
> (new verification tag chosen), or COOKIE-WAIT (sent to X or
> known address of X).  The former is preferrable because it
> does not cause a new denial of service attack.

	See above...

> Closing this latter vulnerability also removes the need to find
> the existing TCB in the COOKIE-ECHO state based on the source
> address list, because a new IT is generated and no tie tags
> populated.

	I love that you always reach the same conclusion... :-)

	Sorry Brian, this attack is not possible to perform...

	BR Iván Arias Rodríguez

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Mar 2003 12:06:13 -0700

Ivan,

On Tue, 11 Mar 2003, [email-masked] wrote:

> >    Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
> >    discarded and NO changes should be made to the existing association.
> >    'Restart of an association with new addresses'. The error SHOULD list

[snip]

Please look at this second case again.  Host A is in the COOKIE-ECHOED
state (not the ESTABLISHED state) and is require to use the same VT
per the paragraph quoted above (and a similar paragraph in the RFC).
Host C is not adding new addresses with its INIT.

> 	Hmm... no... And this is not even an attack, it is "recovering what is
> 	yours"... I don't accept this case... This is actually the way Host C
> 	would defend from the situation above...
> 
> 	Host C sends the INIT, and Host A is in ESTABLISHED, so, as it doesn't
> 	add addresses, it replies to C including a NEW IT and also the Tie
> 	Tags... At the end, Host C will have its association with Host A, and
> 	Host X (the attacker) will lose control over address C, which is not
> 	one of its addresses...

Please look again, Host A is in the COOKIE-ECHOED state when the
INIT arrives.

[snip]

(Your further comments assuming Host A in ESTABLISHED state do not apply.)