About these ads
Home > Security > TCP Split Handshake: Why Cisco ASA is not susceptible

TCP Split Handshake: Why Cisco ASA is not susceptible


As I told yesterday, I was not very satisfied with the updated NSS remediation guide concerning the TCP Split Handshake issue, published after the second round of testing on Cisco and Fortinet devices.

In particular, in case of Cisco, in my opinion the report was poor on details, considering Cisco’s ACL approach suboptimal and definitively coming to the discouraging conclusion that:

Our original results are unchanged, and ultimately Cisco did offer some mitigation steps.

This is clearly in contrast with what stated in the official Cisco post, which declares Cisco ASA firewall not susceptible to the issue, even if, in my opinion, the most disappointing aspect of the story consists in the fact that no other detail is provided on the NSS document, leaving many unresolved questions about the real nature of the issue and the level of vulnerability of Cisco devices.

Since I was really curious to discover were the truth resides, I decided to ask to Cisco Engineers to provide more details on the testing results, and after few hours it is exactly what they kindly did with an accurate and detailed description of the events posted by Joe Karpenko and Omar Santos, the two engineers who took part to the joint session with NSS Labs.

There are 2 connection establishment handshakes associated with this topic, they are as follows:
* Split Handshake (primary concern/issue)
* Simultaneous Open

By default, the Cisco ASA accelerated security path (asp) prevents both the “Split Handshake” and “Simultaneous Open” using the “tcp-dual-open” connection check. The Cisco ASA firewall drops the TCP SYN segment sent from the server (eg: fakestack.rb) when there is an embryonic TCP connection already open between two endpoints.

However, NSS created and demonstrated a brand new test-case which deviates from the 2 connection establishment handshakes mentioned above along with the most commonly used 3-way handshake. This new test-case is not compliant with the TCP connection establishment equirements defined in RFC 793.

For the “Split Handshake”, the first TCP segment sent by the server (fakestack.rb) in response to the clients TCP SYN segment is a TCP ACK segment (also described in the paper, The TCP Split Handshake: Practical Effects on Modern Network Equipment, pg. 200). However, for the new test-case a TCP RST/ACK segment is sent instead. At this point the client would be in a state called SYN_SENT and the server in the SYN_RCVD state.

The protocol specifications for TCP (defined in RFC 793) define how to process TCP segments received in certain states. When an endpoint is in a SYN_SENT state and it receives a TCP RST/ACK segment the endpoint aborts and closes the connection.

During our testing, the client ignores the TCP RST/ACK segment sent by the server (fakestack.rb) and does not abort the connection. Upon seeing the TCP RST/ACK segment sent by the server (fakestack.rb) the Cisco ASA firewall tears down the connection slot. Immediately following the TCP RST/ACK segment sent by the server (fakestack.rb) it sends a TCP SYN segment which initiates a *new* connection establishment and completes a 3-way handshake that complies with the TCP specifications defined in RFC 793.

For the new test-case, access control list rules can be applied using an access-group and used as additional countermeasures to mitigate and prevent unsolicited connection attempts between the endpoints for a TCP conversation when the client does not abort the connection as defined in the RFC protocol specification for TCP.

Given this description of the events, I completely agree with Cisco’s interpretation and I definitively believe there is nothing strange about the behaviour of the ASA firewall, since it immediately tears down the connection slot upon receiving a TCP RST/ACK (how it should be), and immediately allocates a new connection after receiving the new TCP SYN from the server.

Moreover, in the testing scenario the client behaviour does not fit with the TCP RFC. As a matter of fact, page 32 of the TCP RFC 793 states that:

The principle reason for the three-way handshake is to prevent old   duplicate connection initiations from causing confusion.  To deal with   this, a special control message, reset, has been devised.  If the   receiving TCP is in a  non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user.  We discuss this latter case under “half-open” connections below.

Not only. Page 37 of the same RFC, on the paragraph “Reset Processing” states that:

In the SYN-SENT state (a RST received in response   to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

Which is exactly the occurrence in the above scenario when the client receives the TCP RST/ACK.

The sum of the two assertions definitively means that the tested scenario is probably not fully compliant to RFC 793 since, as stated by Cisco Engineers, upon receiving the TCP RST/ACK from the server, the client should reset the connection, free the socket and revert to LISTEN state, which corresponds, according to RFC 793, to a state waiting for a new connection request from any remote TCP and port.

And even if could be acceptable to perform a test in similar conditions not covered by the RFC 793, similarly I do not find anything strange or suboptimal in deploying ACLs to prevent unsolicited connection attempts between the endpoint. As I told yesterday, a firewall should protect critical assets from unsolicited connections independently from the risk of a TCP Handshake attack…

Again, I would like to thank the Cisco Engineers for their kindness and the transparency with which they quenched my curiosity thirst.

P.S.: A final thought from my youth

Now the big picture is clear! Few years ago, when I was younger and at the end of my short and shining system engineer life, I stumbled upon the curious case of a custom application which suddenly stopped to work after an upgrade of the firewall. Deeper analysis showed that each session of the application used the same TCP port for source and destination (the port number was used to identify the customer sigh!). Moreover the server used to terminate the connection with a TCP RST/ACK and to immediately open a new connection with a SYN packet with the same source and destination port number of the previous session. Does it sound familiar to you after reading the post? Yes it does! At that time we spent many hours on insulting the dangerous mind of the programmer and his strange interpretation of the TCP-IP RFC (but the client port should not be allocated on the random Ephemeral Port Range from 1024 to 65535?). After many years I got it!: he was a precursor of the TCP Split Handshake attack.

You will be asking which was the firewall that since then proved not to be susceptible to TCP Split Handshake… I will never say it! Not even under torture. I only may say that in order to fix the problem we had to perform a very unlikely tuning on the timeout parameters of the firewall queues…

About these ads
  1. needtoknow
    June 19, 2011 at 1:34 pm | #1

    Paolo,

    I posted this on the Cisco blog but maybe you have something to add as there has been no reply yet

    SNIP
    Russ,

    Can you please explain the following because my read of RFC 793 doesn’t indicate what was posted from the 2 engineers

    The protocol specifications for TCP (defined in RFC 793) define how
    to process TCP segments received in certain states. When an
    endpoint is in a SYN_SENT state and it receives a TCP RST/ACK
    segment the endpoint aborts and closes the connection.

    RFC 793 says

    If the
    receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
    SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP is in one of the synchronized states (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
    aborts the connection and informs its user.

    I am not sure if the term receiving here is referring to the server side or any socket (client or server) that is receiving a RST.

    Irregardless, if the ASA tears down the connection how is it possible for fakestack.rb to

    “it sends a TCP SYN segment which initiates a
    *new* connection establishment and completes a 3-way handshake that”

    Wouldn’t the ASA deny this by default as it it is a session initiated from a low security to a high security interface?
    Can you provide an example of how ACL’s would be used to mitigate this issue ? Or why they are required ?
    SNIP

  2. June 20, 2011 at 2:32 pm | #2

    Ciao SNIP,

    unfortunately, I have no other information, since no configuration was unleashed. Let us say that in principle I agree with you, by default the ASA should drop all connections from a lower security zone to an higher sceurity zone without an explicit allow rule. Since in the Cisco post is not specified the Security Level of the interfaces I presumed it was a traffic allowed by an existing rule which must be tuned to drop unsolicited connections.

    I must however confess that after reading your comment and a subsequent jump to the original Cisco Post , I noticed the answer to the comment of May, the 24th, which at first glance seems to indicate that the second SYN still comes from the client rather than the server after the ACK/RST. Anyway since this is unlikely as in this case we should not speak about TCP Split Handshake rather than “Double Client Handshake” (and there is nothing strange about it) it probably indicates that the server is in a higher security zone which would explain why the second SYN is able to pass through the firewall and needs specific ACLs to be blockeed.

    Hope it helps.

    Paolo.

  3. Yew Chuan
    July 14, 2011 at 9:35 am | #3

    Hye Paolo,

    I am interested on the segment where you mentioned your final thought from your youth.

    I am having problem here where I see after server replied with a SYN/ACK, client keep on replying with R/ACK. And one thing that gained my attention is like what you said: “each session of the application used the same TCP port for source and destination”.

    The connection established between client and server is VPN, and it is within a trusted environment. Thus, from my point of view, I do not think that it is caused by TCP Split Handshake attack. I suspect it may related to some misconfiguration at the firewall level? Agree? Client is using Cisco ASA firewall.

    Thanks in advance.

  4. July 14, 2011 at 7:45 pm | #4

    Ciao Yew, from what you say I think you are right and the problem you encountered may be related to a misconfiguration.

    Keep in mind that:

    When I met this problem the first time, it was with a Checkpoint Firewall iwith no VPN but instead with an application badly written which used TCP ports to identify the customer and hence, for each customer, the ports were always the same for source and destination. The fact that the appliction always used the same port and also that the server closed the session in an RFC-uncompliant way (that is with an RST/ACK immediately followed by a SYN with the same port without waiting for the ACK from the client) had the result to fall in a scenario very close to the one depicted in the NSS Labs test. It was a kind of “involontary” TCP Split Handshake only due to the poor attention for TCP RFC from the developers.

    In that circumstances we tried an ASA (or maybe it was a PIX) to verify if it was prone to the same issue. Since we were in a scenario very close to the one depicted above, we did not encounter the same issue.

    Definitively from the given information i think it may be a misconfiguration even if the information you kindly provided is not enough for a complete diagnosis. Does the endpoint which terminates the session receive an ACK from the peer? Does this happen inside the VPN (I suppose IPSEC). If this is the case you may be pretty sure that the session is closed correctly and the issue is at the application level.

    Hope it helps.

    Ciao.

    Paolo.

  1. May 12, 2011 at 11:24 pm | #1
  2. May 12, 2011 at 11:30 pm | #2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 2,714 other followers