5 ms·

Can't duplicate. Also, I'm a bit curious how this person is able to see HTTP2 contents in Wireshark, given its almost-mandatory TLS. Also, I'm extremely surpris

Can't duplicate. Also, I'm a bit curious how this person is able to see HTTP2 contents in Wireshark, given its almost-mandatory TLS. Also, I'm extremely surprised that Microsoft would send telemetry without encryption. Also, I'm a bit curious why this looks more like a request that it would send when someone types a search into the Startmenu rather than the Run box. In fact, when typing into (or even running from) the Run box, I see no network requests over ports 80/443. When typing into the Startmenu, I see network requests going to the same M$ IP shown (204.79.197.200), but they are, of course, TLS-encrypted on port 443. Even if I block port 443 in the Windows firewall, it does not fall back to port 80. This is either false, or version dependent. I would lean towards the former. Frankly, if this is real, a bigger problem than the sending of telemetry is the sending of unencrypted telemetry.

josephcsible 5y ago
> Also, I'm a bit curious how this person is able to see HTTP2 contents in Wireshark, given its almost-mandatory TLS. Also, I'm extremely surprised that Microsoft would send telemetry without encryption. Install your own root CA then MITM it?
- jfrunyon 5y ago
  Well, firstly, it wouldn't be port 80 in that case.
  - zamadatix 5y ago
    Could be an artifact of however the proxying or decryption is done, particularly if the goal was to have the traffic be decrypted as it went across the NIC not just to get a copy of the data being proxied locally. Or it could be an artifact of bad editpcap-ing. Same with the all 0s Ethernet source/destinations. Either way I don't think it was the run box that triggered it. Either they didn't know the original run box is still a thing and the field in the taskbar is a search box or they have clipboard history enabled and didn't realize that's a cloud function while they were ctrl+c and ctrl+v-ing into the box.
    - jfrunyon 5y ago
      Frankly, I can't think of any way to proxy or decrypt it that would result in the packets still being destined for the same Microsoft IP, but with port 80 instead of 443. The only explanation I could think of was that it falls back to HTTP if HTTPS is unavailable and they blocked port 443, which not only would be bat**** insane, but I tested and that does not occur.
      - zamadatix 5y ago
        "Many also interpreted the screen shot as if the traffic was sent in clear text. That is not the case, whatever you type on the Win start menu is sent using HTTPS over TCP 443. We used a TLS proxy to decrypt the TLS traffic in order to show what is being sent to Microsoft." https://twitter.com/netresec/status/1440298939509399553 https://twitter.com/netresec/status/1440298939509399553
        jfrunyon 5y ago
        Yeah, turns out their capturing proxy just creates inaccurate pcaps. Who woulda thunk.
- gaius_baltar 5y ago
  I wonder if this is the result of some tool that intercepts all traffic in Layer 2 and rewrites everything to put a MitM proxy while keeping the original IP addresses. It can even be running in a different machine, with the traffic coming through an actual NIC and cable (so the OS being analyzed does not see strange network interfaces nor changes behavior when it detects that it is running in a VM). Does somebody know about such a tool? It does not explain the port 80, however.
  - mr_mitm 5y ago
    I wrote such a tool once: https://github.com/SySS-Research/Lauschgeraet https://github.com/SySS-Research/Lauschgeraet Unfortunately, no one really uses it (not even me) and it is probably full of bugs.
  - netresec 5y ago
    The PCAP in the referenced tweet was created using PolarProxy, which decrypts and re-encrypts TLS traffic while saving the decrypted traffic to a PCAP file.
- mr_mitm 5y ago
  Only if you also disable all ciphers with perfect forward secrecy and hope that there is still a cipher overlap with the server.
  - netresec 5y ago
    MitM'ing the traffic using a trusted root CA allows TLS traffic to be decrypted, even if perfect forward secrecy is used. That's what we did to produce the decrypted PCAP shown in the Wireshark screenshot.
    - mr_mitm 5y ago
      If you use an HTTP proxy or terminate the TLS connection in some other way, yes. I was thinking of the situation where you use Wireshark directly on one of the endpoints, i.e. a passive MitM attack.
- netresec 5y ago
  You are completely right. The traffic was sent as TLS encrypted HTTP/2 traffic to Microsoft. We decrypted it using PolarProxy in order to see what was transmitted. The screenshot in the tweet shows the decrypted PCAP generated by PolarProxy.
ec109685 5y ago
As with many things, the initial outrage will get much more publicity than any follow on correction. This blog posts talks about how you can see everything Windows sends with its telemetry system here: https://www.neweggbusiness.com/smartbuyer/windows/should-you-disable-windows-10-telemetry/ https://www.neweggbusiness.com/smartbuyer/windows/should-you... I wish more people would follow the maxim, "extraordinary claims require extraordinary evidence".
- jfrunyon 5y ago
  That app doesn't show some requests which I know Windows does make, like Start menu searches. And frankly I wouldn't trust it to be accurate even if I couldn't find anything which wasn't included. Agreed w/r/t outrage and the maxim, though.
- selfhoster11 5y ago
  With Microsoft these days, claiming that they won't backstab you is the extraordinary claim. You may disagree, but their track record is pretty poor.
not1ofU 5y ago
After reading the full twitter thread, that tweet got called out fairly quickly. For, as you say "search into the Startmenu rather than the Run box" - which turns out is encrypted (443 / start menu - not run box). Also the PCAP is said to be more than a year old (which in fairness, is still pretty shoddy)
NiekvdMaas 5y ago
OP has posted an update, it was not the run dialog but the start menu search after all...
- netresec 5y ago
  Yes. Sorry for the confusion. The original tweet has now been removed and a correction has been posted instead.
netresec 5y ago
You are correct. This traffic was not generated by typing text into the "run box", it was generated by typing text into the "start menu box". We are very sorry for the confusion this has caused. The wireshark screenshot shown in our tweet was showing TLS traffic that has been decrypted by PolarProxy. That’s why it shows up as HTTP/2 traffic over TCP port 80.
- nevi-me 5y ago
  Wouldn't the safest option be to delete the tweet? It took reading around to see that this is incorrect. EDIT: Thanks for deleting it
  - netresec 5y ago
    We first tried to post replies with corrected information, but it didn't seem to help. The tweet has now been deleted and a correction tweet has been posted instead.

josephcsible 5y ago

> Also, I'm a bit curious how this person is able to see HTTP2 contents in Wireshark, given its almost-mandatory TLS. Also, I'm extremely surprised that Microsoft would send telemetry without encryption. Install your own root CA then MITM it?

jfrunyon 5y ago
Well, firstly, it wouldn't be port 80 in that case.
- zamadatix 5y ago
  Could be an artifact of however the proxying or decryption is done, particularly if the goal was to have the traffic be decrypted as it went across the NIC not just to get a copy of the data being proxied locally. Or it could be an artifact of bad editpcap-ing. Same with the all 0s Ethernet source/destinations. Either way I don't think it was the run box that triggered it. Either they didn't know the original run box is still a thing and the field in the taskbar is a search box or they have clipboard history enabled and didn't realize that's a cloud function while they were ctrl+c and ctrl+v-ing into the box.
  - jfrunyon 5y ago
    Frankly, I can't think of any way to proxy or decrypt it that would result in the packets still being destined for the same Microsoft IP, but with port 80 instead of 443. The only explanation I could think of was that it falls back to HTTP if HTTPS is unavailable and they blocked port 443, which not only would be bat**** insane, but I tested and that does not occur.
    - zamadatix 5y ago
      "Many also interpreted the screen shot as if the traffic was sent in clear text. That is not the case, whatever you type on the Win start menu is sent using HTTPS over TCP 443. We used a TLS proxy to decrypt the TLS traffic in order to show what is being sent to Microsoft." https://twitter.com/netresec/status/1440298939509399553 https://twitter.com/netresec/status/1440298939509399553
      - jfrunyon 5y ago
        Yeah, turns out their capturing proxy just creates inaccurate pcaps. Who woulda thunk.
gaius_baltar 5y ago
I wonder if this is the result of some tool that intercepts all traffic in Layer 2 and rewrites everything to put a MitM proxy while keeping the original IP addresses. It can even be running in a different machine, with the traffic coming through an actual NIC and cable (so the OS being analyzed does not see strange network interfaces nor changes behavior when it detects that it is running in a VM). Does somebody know about such a tool? It does not explain the port 80, however.
- mr_mitm 5y ago
  I wrote such a tool once: https://github.com/SySS-Research/Lauschgeraet https://github.com/SySS-Research/Lauschgeraet Unfortunately, no one really uses it (not even me) and it is probably full of bugs.
- netresec 5y ago
  The PCAP in the referenced tweet was created using PolarProxy, which decrypts and re-encrypts TLS traffic while saving the decrypted traffic to a PCAP file.
mr_mitm 5y ago
Only if you also disable all ciphers with perfect forward secrecy and hope that there is still a cipher overlap with the server.
- netresec 5y ago
  MitM'ing the traffic using a trusted root CA allows TLS traffic to be decrypted, even if perfect forward secrecy is used. That's what we did to produce the decrypted PCAP shown in the Wireshark screenshot.
  - mr_mitm 5y ago
    If you use an HTTP proxy or terminate the TLS connection in some other way, yes. I was thinking of the situation where you use Wireshark directly on one of the endpoints, i.e. a passive MitM attack.
netresec 5y ago
You are completely right. The traffic was sent as TLS encrypted HTTP/2 traffic to Microsoft. We decrypted it using PolarProxy in order to see what was transmitted. The screenshot in the tweet shows the decrypted PCAP generated by PolarProxy.

ec109685 5y ago

As with many things, the initial outrage will get much more publicity than any follow on correction. This blog posts talks about how you can see everything Windows sends with its telemetry system here: https://www.neweggbusiness.com/smartbuyer/windows/should-you-disable-windows-10-telemetry/ https://www.neweggbusiness.com/smartbuyer/windows/should-you... I wish more people would follow the maxim, "extraordinary claims require extraordinary evidence".

jfrunyon 5y ago
That app doesn't show some requests which I know Windows does make, like Start menu searches. And frankly I wouldn't trust it to be accurate even if I couldn't find anything which wasn't included. Agreed w/r/t outrage and the maxim, though.
selfhoster11 5y ago
With Microsoft these days, claiming that they won't backstab you is the extraordinary claim. You may disagree, but their track record is pretty poor.

not1ofU 5y ago

After reading the full twitter thread, that tweet got called out fairly quickly. For, as you say "search into the Startmenu rather than the Run box" - which turns out is encrypted (443 / start menu - not run box). Also the PCAP is said to be more than a year old (which in fairness, is still pretty shoddy)

NiekvdMaas 5y ago

OP has posted an update, it was not the run dialog but the start menu search after all...

netresec 5y ago
Yes. Sorry for the confusion. The original tweet has now been removed and a correction has been posted instead.

netresec 5y ago

You are correct. This traffic was not generated by typing text into the "run box", it was generated by typing text into the "start menu box". We are very sorry for the confusion this has caused. The wireshark screenshot shown in our tweet was showing TLS traffic that has been decrypted by PolarProxy. That’s why it shows up as HTTP/2 traffic over TCP port 80.

nevi-me 5y ago
Wouldn't the safest option be to delete the tweet? It took reading around to see that this is incorrect. EDIT: Thanks for deleting it
- netresec 5y ago
  We first tried to post replies with corrected information, but it didn't seem to help. The tweet has now been deleted and a correction tweet has been posted instead.