My home router is an AVM FritzBox and it's able to log all incoming and outgoing traffic in a file format readable by Wireshark. Some days ago I started capturing all traffic for about an hour to get an understanding of what kind of traffic is leaving and entering my home network and to get more familiar with Wireshark.
Most of the traffic is encrypted with TLS and I am only able to see the domain in the Server Name Indication (SNI) field. I was also intersted in figuring out which traffic is unencrypted.
To only see incoming unencrypted traffic I enter the filter
http.response. There is lots of traffic where the protocol column says
OCSP. To exclude this traffic I update my filter to
(http.response) && !(ocsp).
Now multiple packets are shown, e.g. this one:
Info: HTTP/1.1 206 Partial Content (application/x-msi) Response for URI: http://ardownload.adobe.com/pub/adobe/reader/win/AcrobatDC/2001320074/AcroRdrDCUpd2001320074.msi
Full copy of this packet:
Frame 24636: 1462 bytes on wire (11696 bits), 1462 bytes captured (11696 bits) Raw packet data Internet Protocol Version 4, Src: a23-48-202-107.deploy.static.akamaitechnologies.com (126.96.36.199), Dst: redacted.fritz.box (192.168.redacted.redacted) 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 1462 Identification: 0xebac (60332) Flags: 0x40, Don't fragment Fragment Offset: 0 Time to Live: 61 Protocol: TCP (6) Header Checksum: 0x1415 [validation disabled] [Header checksum status: Unverified] Source Address: a23-48-202-107.deploy.static.akamaitechnologies.com (188.8.131.52) Destination Address: redacted.fritz.box (192.168.redacted.redacted) [Source GeoIP: US] Transmission Control Protocol, Src Port: http (80), Dst Port: 50146 (50146), Seq: 256, Ack: 495, Len: 1422 Source Port: http (80) Destination Port: 50146 (50146) [Stream index: 112] [TCP Segment Len: 1422] Sequence Number: 256 (relative sequence number) Sequence Number (raw): 4050263504 [Next Sequence Number: 1678 (relative sequence number)] Acknowledgment Number: 495 (relative ack number) Acknowledgment number (raw): 2051456861 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window: 245 [Calculated window size: 31360] [Window size scaling factor: 128] Checksum: 0xf913 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [SEQ/ACK analysis] [Timestamps] TCP payload (1422 bytes) Hypertext Transfer Protocol HTTP/1.1 206 Partial Content\r\n Server: Apache\r\n Last-Modified: Wed, 09 Dec 2020 11:36:16 GMT\r\n ETag: "7856800-5b6067797a9f1"\r\n Accept-Ranges: bytes\r\n Content-Type: application/x-msi\r\n Date: Tue, 22 Dec 2020 08:01:54 GMT\r\n Content-Range: bytes 0-1119/126183424\r\n Content-Length: 1120\r\n Connection: keep-alive\r\n \r\n [HTTP response 2/37] [Time since request: 0.016112000 seconds] [Prev request in frame: 24632] [Prev response in frame: 24634] [Request in frame: 24635] [Next request in frame: 25074] [Next response in frame: 25085] [Request URI: http://ardownload.adobe.com/pub/adobe/reader/win/AcrobatDC/2001320074/AcroRdrDCUpd2001320074.msi] File Data: 1120 bytes Media Type Media type: application/x-msi (1120 bytes)
Am I correct to assume that this captured packet is an update of Adobe Acrobat Reader over an unencrypted connection? If yes, could this be used in a man-in-the-middle-attack to insert malicious code into the update or replace it completely?