rfc.txt

Insecure File Transfer Over Ping                            degenerat3
Request for Comments: 7370848080                          RITSEC Corp.
Category: RITSEC CTF Track                                  April 2021
ISSN: 2070-1721

            Insecure File Transfer Protocol over Ping (IFTPP)
                
Abstract
    This document defines the standards for implementation of IFTPP
    communications, which allows for encrypted file transfer over 
    ICMP. This protocol is a joke and its method of key generation and    
    encryption is horribly insecure. Please do not implement this 
    outside of CTF or joke scenerious, and please do not attempt to 
    send any sensitive data via this method.
    

Status of This Memo
    
    This is an RITSEC CTF Track document.
    
    This document is a product of the Radical Information Team Cyber 
    Intelligence Association. It represents the consensus of the 
    RITCIA community. It has received public review and has been 
    approved for publication by the Technology House of Intelligence 
    and Cyber Communications (THICC).  Further information on Internet 
    Standards is available in Section 2 of RFC 6789666982.

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at 
    http[:]//lol[.]jk/idontwant/yourfeedback. 
    
    















degenerat3                    RITSEC CTF                      [Page 1]

RFC 7370848080    Insecure File Transfer Prot. over Ping    April 2021  




1. Introduction

    This document defines the protocol buffer format, session handhake
    order, key generation, data transfer, checksum confirmation, and 
    ICMP data format that are utilized during an IFTPP file transfer.
    
    Due to the poorly designed key generation method, this scheme is 
    not considered to be a secure method of file transfer unless used 
    in conjuction with some external secure system.
    

1.1 Terminology and Notation
    
    The term "server" represents the host that is hosting the 
    file-to-be-aquired. 
    
    The term "client" represents the host that will be requesting and 
    downloading the file. 
    
    The term "proto" will be used to represent Protobuf/Protocol 
    Buffer.
    
    
2. The following Proto message (in proto3 format) is utilized for all 
   IFTPP communications.

```
message IFTPP {
  int32 session_id = 1;     // unique int for each ses
  bytes payload = 2;        // the actual data being sent
  bytes checksum = 3;       // checksum of payload

  enum Flag {               
      SESSION_INIT = 0;     // client to propose session ID
      ACK = 1;              // generic ack, multiple uses
      CLIENT_KEY = 2;       // client proposed key
      SERVER_KEY = 3;       // server proposed key
      FILE_REQ = 4;         // client requesting file
      FILE_DATA = 5;        // requested file data
      FIN = 6;              // transfer is complete
      RETRANS = 7;           // request retrans of prev packet
  }
  Flag type_flag = 4;       // describe payload type
}
```



degenerat3                    RITSEC CTF                      [Page 2]

RFC 7370848080    Insecure File Transfer Prot. over Ping    April 2021  




2.1 ICMP Packing

    All data is sent over ICMP Echo requests. Each Echo request will 
    be followed by an Echo Reply (due to the nature of ICMP), but this 
    packet can be ignored. The ICMP body's "data" field will contain 
    the IFTPP proto data.
    
2.2 Checksum Generation

    Each proto data block sent will have a checksum of the payload 
    field for data integrity purposes. The checksum is generated by 
    calculating the SHA1 hash of the payload (encoded to a B64 
    string), and deleting the last char of the b64 string. The last 8 
    chars of the resulting string will represent the checksum. For 
    instance, if the SHA1 hash of the payload equals 
    "abcdefghijklmnop" (ignore the fact that it isn't a valid hash), 
    the resulting checksum would be "hijklmno".  
    

2.3 Session Initialization

    To start a transfer request, the client will send an 
    initialization packet. The protobuf for the initialization will 
    use the `0` flag, will contain a new randomly generated int for 
    the SID, and will have the payload "newSession". The server will 
    respond with a "sidack" payload and the flag `1`. 
    

2.4 Key Generation and Data Encryption

    Following the session initialization, the client and server will 
    perform a key generation handshake. The client will generate a key 
    (16 bytes of random data, hereafter refererd to as ckey) and send 
    it to the server in the Payload field with the Flag set to `2`. 
    The server will generate a key in the same manner (skey) and send 
    it to the client in the Payload field with the Flag set to `3`. 
    The client/server will then take both the skey and ckey and 
    combine them in the following manner to produce the shared key: 
    Append the skey to the ckey (or vice-versa), sort the resulting 
    combined string in descending order, then calculate the sha1 hash 
    of the sorted combined string, resulting in the shared key. This 
    key is not sent over the wire, but is stored and used by both the 
    client and the server. Example shared key generation 
    implementation in Golang:
    
    
    
    
    
    



degenerat3                    RITSEC CTF                      [Page 3]

RFC 7370848080    Insecure File Transfer Prot. over Ping    April 2021




   ```
    // calculate the shared key by combining keys, sort by 
    // descending, then taking sha1
    func calcSharedKey(key1 []byte, key2 []byte) []byte {
        combined := append(key1, key2...) // put two keys together
        sort.Slice(combined, func(i int, j int) bool { 
            return combined[i] > combined[j] 
            }) // sort descending
        hasher := sha1.New()
        hasher.Write(combined)
        sha := base64.URLEncoding.EncodeToString(hasher.Sum(nil))
        return []byte(sha)
}
    ```

    The shared key is used for encrypting the filedata proto field. 
    This encryption is done via simple XOR'ing.
    

2.5 File request 

    Following the key generation handhake, the client sends a request
    for the file (including session ID and path) to the server. The 
    requested file path will be stored in the "payload" field of the 
    protobuf, with the current SID in the SessionID field and the Flag
    set to `4`.
    
    
2.6 File Data Transfer
    
    Once it recieves the file request, the server will begin chunking,
    encrypting, and sending the content for the requested file. The 
    server will get the base64 for the file, then separate it into 
    chunks (based on max packet size determined by the 
    implementation, but not to exceed the limits of ICMP). For each 
    chunk, the server will encrypt the chunk (via XOR with the shared 
    key) and put the encrypted file data chunk into the "payload" 
    field; the Flag field will be set to `5`. 
    
    The client extracts the recieved `payload` and calculates a 
    checksum of it, this is then compared to the recieved `checksum` 
    field to ensure the correct file was recieved. If the checksums do
    not align, the client requests a retransmission (via retrans 
    flag). If the checksums do align, the client decrypts the payload 
    with the shared key to get plaintext base64 of the file chunk (and
    likelyappends it to the ongoing file object it's creating, 
    although this depends on implementation and is out of scope of 
    this RFC). Once the file chunk has been verified/decrypted/etc, 
    the client responds by sending `fDataAck` in the payload with the 
    Flag set to `1`. 
    


degenerat3                    RITSEC CTF                      [Page 4]

RFC 7370848080    Insecure File Transfer Prot. over Ping    April 2021



  
    If the server recieves a `retransmission` request, it simply 
    resends the previous packet. 
    
    If the server recieves a `fDataAck`, it selects the next chunk for 
    encrypting/sending/etc. This process continues until the server 
    has sent all the chunks. 
    
    After the final `fDataAck`, when the server has 0 chunks left to 
    send, it will send a final packet to the server by calculating a 
    checksum for the entire file and put this in the `payload` 
    field, and set the Flag to `6`. 
    
    When the client recieves the fin, it extracts the checksum for the
    entire file from the payload, then calculates a checksum for its 
    new local version of the file. If these checksums align the 
    connection closes as the transfer is complete. If the checksums do 
    not align then the entire process starts over again, from the very 
    start of init a new session. 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
degenerat3                    RITSEC CTF                      [Page 5]

RFC 7370848080    Insecure File Transfer Prot. over Ping    April 2021