When we purchase something new, in most cases there is an unspoken understanding about the transaction. For example, if it is food, you can read what is in it and purchase it. If you don’t end up liking the taste, it probably won’t kill you. If we buy a car, it is assumed that it will meet all safety standards. If we purchase a widget of some sort for a specific purpose, it will do what it advertises else we will return it for a refund. When it comes to software, the rules are generally the same; however, there seems to be an emerging twist in the market: data theft.
When we install software on our computers and mobile devices, most of us believe that the evaluation or free version will try to entice us to purchase the full version with additional features. This is how they make money. However, most of us never thought to question what the software vendor might also be taking from our devices that we wouldn’t want to share. We decided to investigate a couple vendors and the result for some of us is a bit chilling.
For example, with the recent formal notice to Microsoft by France’s National Data Protection
Commission (CNIL), it is apparent that Microsoft is taking too many liberties with user data.
While Microsoft provides a number of settings that you can disable to stop them from taking your personal information (PI), none of these settings are disabled by default, and many of them are difficult to disable. Additionally, for privacy advocates, the controls offered to the user by Microsoft don’t sufficiently stop the OS from connecting online and communicating with Microsoft’s servers. In other words, even if you turn all sharing options off, Microsoft is still sending some data back to the mother ship.
How can I see what Microsoft is taking?
To start, let’s go over what Microsoft is actually taking from users by default. If you’ve received your Windows 10 machine from a manufacturer or installed Windows 10 and selected “Use
Express settings” during setup, you have the default settings, which are the least respectful of your privacy.
The above settings allow Microsoft to retrieve information about your contacts, calendar details, text and touch input, location data, and much more. The OS sends this information back to Microsoft where it could be used for personalization and to target you with ads.
The primary feature of the Windows 10 OS that requires these details is Cortana, Microsoft’s intelligent personal assistant. Since Cortana depends on personalization from your voice input, calendar details, and contacts, it requires that you allow Microsoft to access these details in order to function. Disabling such access, for example, will disable Cortana.
With that in mind, let’s look at the information that Microsoft has access to even when you’ve turned off all of the default privacy settings.
Even after disabling everything I could find, I noticed that some form of metadata was still being sent to Microsoft every 5 minutes. Microsoft was making a connection to ssw.live.com over an HTTP connection on port 80. The content was encrypted in a way that made it impossible to determine what was being sent. This is an interesting choice, as Microsoft could have sent the data over HTTPS via port 443 to prevent eavesdroppers from looking at the data; instead, however, they used an unencrypted HTTP connection over port 80. This extra effort to encrypt indicates that Microsoft not only didn’t want non-authorized users of the machine from accessing the data—they also didn’t want the end-user knowing what was being sent.
When we did a bit more digging, we found that there is a group policy feature called Allow Telemetry, which is a setting that determines how many telemetry details are sent back to Microsoft.
We discovered that the only way to disable this entirely, unfortunately, is to purchase an Enterprise version of Windows 10. As such, this encrypted data being sent to ssw.live.com, we suspect, contains details about your profile. If nothing else, it could contain your Internet facing IP address as this provides an approximate geolocation, which would be required to make a connection to Microsoft.
Using NetFlow and DNS, we can also see some details about what is being sent to Microsoft.
Take a look at the image below. You will notice a connection to both:
Both of these contain information about you and your device based on the settings you’ve selected in your Windows 10 privacy settings.
Can you completely block this traffic?
Now that you know where your data is being sent, taking additional steps to prevent Microsoft from accessing this information is more straightforward. There are a few things that you can do to block this traffic completely.
- Disable telemetry (Enterprise only)
- By disabling the telemetry setting (along with all the other privacy settings) in
Windows 10, you can prevent Microsoft from accessing your data. This, however,
only applies to Enterprise versions of Windows 10 and Windows Server.
- Block access to Microsoft servers
- By doing a look-up of the servers that Windows 10 connects to, you can block access to these servers via firewall rules, etc. For example, if I look updmd.metaservices.microsoft.com, I can see that there are four IP addresses associated with the domain (184.108.40.206, 220.127.116.11, 18.104.22.168, and 22.214.171.124).
Adding these IP addresses to the firewall rules would prevent the data from getting out of the network. You should be careful about doing this, though, as Microsoft could change these IPs and you may end up blocking more critical services like Windows Update.
- Block access via DNS
- Since we know that Microsoft is taking data via two DNS names (ssw.live.com and dmd.metaservices.microsoft.com) we can create an entry in our corporate DNS to redirect traffic to these domains to another location (e.g. 127.0.0.1). This would effectively prevent Microsoft from accessing your data. Keep in mind, though, that Microsoft could change these domains in future releases/updates to Windows 10, and you would need to update these entries.
Regardless of the option you select, you should be sure to disable as much as possible so that, should you connect outside the corporate network, you aren’t sending out all the data you were trying to block.
Barnacules Nerdgasm has a great YouTube video showcasing what you can do to block access, with options for both a clean install and post-install changes: https://www.youtube.com/watch?v=u1kGMCfb2xw
Are there other companies doing this?
While it would be great to say that only Microsoft is doing this, it just isn’t the case. Plixer recently discovered that the Plantronics headsets that we use and connect to our PCs via Plantronics Hub were sending encrypted data over HTTP port 80 that we could not decode.
Rather than using TLS (HTTPS) to encrypt the data, Plantronics took an extra step to make sure that the message couldn’t be easily unencrypted using TLS DPI or Man in the Middle (MITM) techniques. We also found that they send the information frequently; in fact, they were sending messages every minute back to api.plantronicsmanager.com. We were wondering what information they were sending back and found nothing mentioning it in the Plantronics EULA at the time this document was created. We are concerned that they are sending back the phone numbers that we dialed or perhaps the details on the quality of the calls we are making (e.g. jitter, packet loss, etc.). As a consumer, we definitely want to know what information they are taking from our computers. In the case of Plantronics, it appears we have no choice.
In an earlier version of the Plantronics software (HUB 3.7.1) we found a setting that does not appear to be available in (HUB 3.8.2).
Version 3.7.1 below:
Version 3.8.2 below:
Obviously, it is a bit concerning if Plantronics no longer wants to give its customers the ability to turn off the phone home capability.
Getting sneaky about Phone Home
To make the phone-home less obvious, the Plantronics software sent the data to an IP address hosted by Amazon AWS. We discovered this by correlating the DNS records with the NetFlow data using the Scrutinizer Incident Response System. Notice below that just before the connection from the Source to the Destination (~compute.amazonaws.com) the machine did a look-up on Dst FQDN: api.plantronicsmanager.com.
Below is a capture taken after installing Plantronics HUB v.3.7.1.
Below is a capture taken after installing Plantronics HUB v.3.8.2.
Notice above in v.3.8.2 that not only did they change Content Delivery Networks from Amazon AWS to Akamai Technologies, but they also started sending the data to a different FQDN: firmware.plantronics.com.
As a result of not being able to configure the software not to send information back to Plantronics, we decided to block the traffic from reaching the Internet by redirecting DNS look-up requests targeting the planstronicsmanager.com 2nd-level domain.
After reaching out to Plantronics via their online chat service to discuss the above, they apparently declined and terminated the chat session.
Another company that we noticed sending data from our devices was McAfee (now part of Intel Security). They provide the antivirus software on our desktops and laptops. McAfee was a bit different, however; they would send data using a DNS look-up instead of HTTP/HTTPS, which made for many interesting DNS queries to sites like: a-0.19.a7000001.90d0083.1644.1ff1.36d4.210.0.pse53rw8vethftele7m28hf5uv.avts.mcafee.com
The above DNS query is especially troublesome because the above DNS look-up in many companies bypasses security mechanisms. We are confident that this is exactly why McAfee uses this tactic.
Here is a synopsis on how DNS works:
- Software on my PC wants to make a connection to the domain: mcafee.com
- My PC checks its local cache and host file to see if it can resolve the domain locally. If it can’t, it reaches out to the corporate DNS.
- The DNS attempts to resolve the FQDN (i.e. the very long string above) but can’t, which means it has to recursively try and resolve it by reaching out to root or at the very least mcafee.com.
- The Authoritative DNS for mcafee.com receives the request for the very long string, logs it, and does not reply or possibly sends back a NXDomain message, basically telling your computer that it couldn’t resolve the FQDN.
Hidden in the very long string of a-0.19.
a7000001.90d0083.1644.1ff1.36d4.210.0.pse53rw8vethftele7m28hf5uv.avts.mcafee.com is an encrypted message that is parsed, stored, and becomes part of “big data” at McAfee.
The above tactics in a sense use the local DNS as a proxy to establish a type of DNS tunnel to take information out of the company without directly making a connection to the Internet.
Instead, the DNS does the dirty work for the end system.
While we agree that McAfee is a friendly vendor, we would like to know what they are sending, we want to be able to decrypt it using traditionally accepted decryption methods, and we want the ability to turn it off. As with Plantronics, the information is sent in a nonsensical manner, preventing anyone but McAfee from knowing what details the messages contain.
A Call for Action
The rush to collect big data to run analytics on customers is pushing the boundary on ethical information theft. It is our concern that the vendors we trust are taking excessive liberties with the ability to take our Personally Identifiable Information (PII).
It may be time for our government to intervene and get involved to create legislation that prevents companies from doing it. Laws should cover, but not be limited to:
- Proprietary encryption methods that cannot be unencrypted by the companies hosting the data being taken. The consumer should have the ability to look inside the traffic leaving the company.
- End User License Agreements (EULAs) must clearly disclose 100% of the information being taken from the consumer’s device.
- Phone home connections must be made with HTTPS, or other government-approved methods. For example, leveraging the DNS as McAfee is doing to tunnel information out of the organization should not be permitted.
- If the software allows the user to disable privacy settings, it must clearly indicate what can’t be turned off and what information is still going to be sent.
Block the Theft
By simply observing the traffic from the desktops loaded with your business applications, you can determine which applications are phoning home. Do not rely on packet capture or NetFlow/IPFIX analysis alone. In order to gain 100% visibility into these data thefts, correlate the flows with the DNS logs. This process will disclose connections such as those to Plantronics that were actually creating connections to Amazon AWS and Akamai Technologies. Once the initial domain requested is identified, it can be blocked or redirected at the DNS.
Hopefully, our government will get involved, as we fear that soon, the practice of not allowing these connections back to the Internet could end up crippling the software that we need to run our businesses.
Contact Plixer to learn more about this type of theft.