DailyBread

TCP Flow Control

From this article, let's see some basic stuff for TCP related. In RFC 793, there are comment for 'flow control' as following :

RFC 793 

https://tools.ietf.org/html/rfc793#page-15

flow Control:

TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received.  The window indicates an allowed number of octets that the sender may transmit before receiving further permission.

In TCP header, there are Window and Control field which can be used for flow control.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

Window:  16 bits
The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept.

Sliding window

WINDOW AND ACKNOWLEDGEMENT STRATEGY IN TCP : http://www.ietf.org/rfc/rfc813.txt

The window mechanism is a flow control tool.  Whenever appropriate, the  recipient of data returns to the sender a number, which is (more or less) the size of the buffer which the receiver currently has  available for  additional  data.   This number of bytes, called the window, is the maximum which the sender is permitted to  transmit  until  the  receiver returns  some additional  window.

http://www.omnisecu.com/tcpip/tcp-sliding-window.php

• The sending device can send all packets within the TCP window size without receiving an ACK, and should start a timeout timer for each of them.

• The receiving device should acknowledge each packet it received, indicating the sequence number of the last well-received packet. After receiving the ACK from the receiving device, the sending device slides the window to right side.

Slow Read DoS attack

• Reference : http://sdiwc.us/digitlib/journal_paper.php?paper=00001342.pdf

Example

{{ TBD }}

References :

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://www.rhyshaden.com/tcp.htm

http://www.tcpipguide.com/free/t_TCPMessageSegmentFormat-3.htm

https://www.youtube.com/watch?v=ADiuHeoT2GA

http://www.freesoft.org/CIE/Course/Section4/8.htm

{{ SECURITY Network packet Forensic }} 

Chapter 17 : Wireless Packet Analysis

With [Aircrack-ng] tool, you can try to de-crypt the messages of WEP from PCAP.

Depends on the release version of aircrack-ng tool, you may need to change the execusion file name like below :

From WiKipedia, you can check the simple method how to encrypt the message.

• In Open System authentication, the WLAN client need not provide its credentials to the Access Point during authentication. Any client can authenticate with the Access Point and then attempt to associate. In effect, no authentication occurs. Subsequently WEP keys can be used for encrypting data frames. At this point, the client must have the correct keys.

• In Shared Key authentication, the WEP key is used for authentication in a four-step challenge-response handshake:

1. The client sends an authentication request to the Access Point.
2. The Access Point replies with a clear-text challenge.
3. The client encrypts the challenge-text using the configured WEP key and sends it back in another authentication request.
4. The Access Point decrypts the response. If this matches the challenge text, the Access Point sends back a positive reply.

• After the authentication and association, the pre-shared WEP key is also used for encrypting the data frames using RC4.
  

• At first glance, it might seem as though Shared Key authentication is more secure than Open System authentication, since the latter offers no real authentication. However, it is quite the reverse. It is possible to derive the keystream used for the handshake by capturing the challenge frames in Shared Key authentication.

{{ SECURITY Network packet Forensic }} 

Chapter 17 : Wireless Packet Analysis

WLAN standard

• https://en.wikipedia.org/wiki/Template:802.11_network_standards

For the encryption, 802.11 is widely using WEP(Wired Equivalency Protocol). This protocol will encrypt each MAC frames with 40bit WEP key and random 24 bits Initialization Vector(IV) as RC4 Stream encryption method. But it should share the KEY ID and IV with plain text between AP and the devices which can be the threaten for the security.

{+WPA/WPA2-}

To make a connection, a device will send 'Probe Request' with AP's SSID information. If the AP can accept the request, it will reply 'Probe Response'. This procedure can be use for Service denial attack with massive 'Probe Request' trials.

Following is an example of simple WiFi connection.

1) Probe Request > Probe Response

2) Authentication

3) Association Request > Association Response

4) Key negotiation

5) Transfer data

As the packet has been encrypted, there is no message available to check from [Conversation] window.

If you know the key of the encryption, Wireshark will support the decryption. 

Now, you can see the decrypted messages from [Conversation] window 

References :

http://www.tcpdump.org/

www.iana.org/assignments/port-numbers

{{ SECURITY Network packet Forensic }} 

Chapter 13-1 : Shell code packet analysis

From following example, there is some suspicious data to run [calc.exe].

After converting it hex format, there are many 0x90 in-front of the data. This could be NOP(No Operation) code to use buffer overflow attach. To know what those codes mean, it should be converted to assembly code. The last 4 bytes will indicate the CRLF (Carriage Return) to change the line for HTTP. Let us make some assumption it will be a shell code.

Wireshark provides a good way to display the data for C array type as following.

After copy the content to a text file, change it to a binary file. And try to check whether it's real binary code or not.

References :

http://codinguy.net/2013/06/03/insertion-encoderdecoder-shellcode/

http://gnuwin32.sourceforge.net/packages/hex2bin.htm

{{ SECURITY Network packet Forensic }} 

Chapter 9-2 : Port scan and Packet analysis

For TCP scan, 3-way handshaking will be used to check the opened ports.

Fro UDP scan, if some ports are opened then there will be no response. So in this case, you can checked 'ICMP unreachable' message for the closed ports.

In [Conversation] menu, select [UDP] tab.

There is no TCP like session establishment procedure. But there is ICMP protocol which is belong to layer 3.

And using filter, you can checked the open UDP ports.

   [ip.src==192.168.0.112 && ip.dst==192.168.0.15&&udp&not icmp]