Home > Code, Wargames > Creating ACK-GET packets with scapy

Creating ACK-GET packets with scapy

During the recent Defcon 19 CTF pre-qualifications, one of the challenges included to connect ‘quicker’ to a web server. While figuring out what the solution was for this challenge one of the things I tried was to send the HTTP GET request already in the TCP handshake stage. Sadly enough this had nothing to do with the real solution of this case, the real solution was making use of SPDY to connect to the server, this is also explained by one of the other teams in a write up here. However it was a nice exercise to create packets with scapy again and since I could not find a lot of information on the topic I decided to create this short write up on the topic.

 

Normal TCP Handshake

A normal TCP handshake contains three packets, a SYN packet which is being sent from the client to the server, on which the server replies with a SYN,ACK packet, on which the client on its turn replies with an ACK packet.  This handshake is shown in the schematic overview below. More information on the TCP handshake can be found on Wikipedia here.

Normal TCP handshake overview:

TCP_handshake

 

Normal TCP handshake in Wireshark

Wireshark_TCP_handshake

 

We can create our own packet for this TCP handshake, to do this we will use scapy. A normal TCP handshake in scapy:

 

To make it a bit more easy to read and alter we can also build a Python script which makes use of scapy. Normal TCP handshake in a Python script making use of scapy:

 

The Python script above gives the following output:

 

ACK-GET TCP Handshake

Normally your system will send a GET request after the TCP handshake has been finished, which is shown in the schematic overview below.

 

TCP handshake ACK-GET

 

However, the GET request can actually be send together with the ACK request, without completing the handshake first. Which means the network traffic will look like this:

TCP handshake ACK-GET 2

 

Since the GET request will be send in the same packet as the ACK request, we will call this packet an ACK-GET packet (by lack of a better name).

After successfully sending the ACK-GET packet, the server will respond with the requested data as can be seen in the network traffic in Wireshark below.

Wireshark ACK-GET

 

And of course once again we can use scapy to create out own packets for the ACK-GET request. This is actually pretty simple by just placing a GET request after the normal ACK packet.

 

Since you are not completing the full TCP handshake your operating system might try to take control and can start sending RST (reset) packages, to avoid this we can use iptables:

The best way to see what is happening in the background is to have Wireshark running at the same time. You might want to set a filter in Wireshark to only show the packets involved in our request. Since my script uses the Google website I use the following filter:

To make it a bit more easy to read and alter we can also build a Python script of the ACK-GET request.

TCP handshake with ACK-GET in a Python script making use of scapy:

 

The Python script above gives the following output:

 

This is all it takes to create a HTTP GET request inside a TCP Handshake with scapy. Of course this is just a small proof of concept and it needs some more tweaking to use it to communicate correctly with a HTTP server.

For another example of the usage of scapy see here my write up on one of the Swiss Cyber Storm challenges.

  1. January 27th, 2012 at 19:16 | #1

    Hello,
    First of all, thanks for this post really interesting.
    I tried you script and run it. The problem is that an RST packet is generated automatically after the SYN/ACK from the server.
    How is it possible to avoid it? Because I can’t get the answer for the HTTP request.

    Thanks,
    Tosch

  2. Thice
    February 6th, 2012 at 23:34 | #2

    @Tosch
    To avoid the RST packet to be send use the iptables rule as shown in the article.

  3. Dylanger
    April 2nd, 2012 at 09:12 | #3

    Very helpful! Thanks heaps! :D
    Is it possible to download a file?

  4. Thice
    April 7th, 2012 at 12:18 | #4

    @Dylanger
    It probably is, but that takes some extra effort.

  5. getz
    May 9th, 2012 at 14:19 | #5

    Hi,

    thanks for this great and helpful post;
    I do run into one issue, after it receives the syn/ack it sends the message and immediately after it sends the final ack that should of being to complete the handshake.
    e.g.
    syn ->

    ack ->

    Thanks

  6. Thice
    May 10th, 2012 at 19:02 | #6

    @getz
    I am not sure if I understand you, you are sending the GET request inside the ACK request. What do you mean by that it is sending the ACK request?

  7. obogan
    August 18th, 2012 at 21:41 | #7

    Hi,
    the way you doing your http request with Scapy is not normal, i am astonished that it worked.
    Normally the http header should be inserted in the PSH/ACK (Flags=”PA”) after the ACK who close the three-way handshake.
    you can see it clearly with Wireshark when you go to an url with your browser.
    It should be like that:

    the Hand check
    1> SYN
    2> SYN/ACK
    3> ACK (SPDY use this last ACK to already send the http header ? that possible, because this ACK is really a waste of bandwidth)

    the payload
    4> PSH/ACK [with the http header: GET / HTTP/1.1]
    5> PSH/ACK [Response from the server: HTTP/1.1 200 ok]

    The end of the request
    6> FIN/ACK [Normally, who need to close the connection at the end]

    with scapy you have:

    ACK=ip/TCP(sport=SYNACK.dport, dport=80, flags=”A”, seq=SYNACK.ack, ack=SYNACK.seq + 1)
    ACK=sr1(ACK)
    PSHACK=ip/TCP(sport=ACK.dport, dport=80, flags=”PA”, seq=ACK.ack, ack=ACK.seq + 1) / get
    win,fail=sr(PSHACK) # FIN/ACK can be discarded without big consequence, the server will close the connection anyway

  8. Thice
    August 21st, 2012 at 22:49 | #8

    @obogan
    It seems that you missed the point of this article, the whole idea is that it does work to throw the GET request in to the ACK packet.

  9. anne
    January 21st, 2013 at 15:41 | #9

    Tq for scapy code it works me…
    this thing can be use to test whether reverse proxy is used or not due to differ response header

  10. gabrielle
    May 24th, 2013 at 08:24 | #10

    hi,

    Thanks a lot for your article
    However, I still have one question

    when you send the SYN packet with sr(), you get :

    [*] Sending SYN packet
    Begin emission:
    .Finished to send 1 packets.
    *
    Received 2 packets, got 1 answers, remaining 0 packets

    Since you received 2 packets, I was wondering if there’s a way to get the second packet (which is not considered an answer by scapy…) ?
    Because when we do ans,unans=sr(…), I can’t find it…

  11. Thice
    June 4th, 2013 at 22:04 | #11

    @gabrielle
    Have you checked with a network sniffer (Wireshark) what kind of packets there are on the line?

  1. No trackbacks yet.