Did Wireshark capture an update of Adobe Acrobat Reader over an unencrypted connection?

Question

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 (23.48.202.107), 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 (23.48.202.107)
    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?

Answer 1

I see it's using HTTP instead of HTTPS so yes, it is vulnerable to MITM. However, the software that is downloading the file may be validating it, for example using a checksum or verifying a digital signature.