2

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?

5

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.

1
  • 1
    This seems like a good point. It's not terribly important to trust the source of a program if the program itself can be verified, e.g. using a signed executable. However, it's still not great to be using HTTP for this sort of thing in case the updater is sending potentially sensitive information (such as your OS version, or the fact that Adobe Reader is installed on your system, which might encourage other MITM attacks designed to exploit bugs in that software).
    – Andrew Ray
    Dec 29 '20 at 4:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.