Cliqz researchers discover privacy issue on bing.com and other Microsoft sites

At Cliqz we have developed an algorithm for detecting unique identifiers sent in the URL parameters of third-party requests. We use this in our anti-tracking system in order to detect and remove browser fingerprints being sent to third-party trackers. After detecting some anomalous behavior, we decided to run this on the third-party hostnames in our data.

Running this analysis, we found several services which seemed to send requests to hostnames which contained a user identifier. Initial inspection suggested that the requests were to APIs which were used once a user had logged in. Further investigation would be required to see if other layers of access control existed to protect these APIs, or just this identifier was enough to access them.

When sending data over HTTPS we expect the data sent to be private, as it is encrypted between your browser and the host server. However, the address the data is to be sent to, i.e. the hostname, is not encrypted: it can be leaked by a DNS lookup or when making a HTTPS handshake. As this information is not private, sending user identifiers in the hostname can lead to both security and privacy issues:

• If this user identifier can be used for authentication, a network snooper would be able to steal this token and use it to authenticate as the user.
• As the user identifier is constant over time, the network snooper can track the activity of a particular user over the whole time frame that they are using this network. An attacker able to observe many different networks (for example, an ISP), would be able to track users across networks.

Our data found hosts with user identifiers under the users.storage.live.com subdomain. These were in the format cid-[16 digit hex].users.storage.live.com. Requests to these hosts were done from several different Microsoft sites, including microsoft.com, bing.com, live.com and office365.com. Local testing showed that this happened when logged in to a Microsoft account on these domains, and this API was used to download and display the user’s avatar in the page.

As the affected Microsoft sites are popular, the privacy implications of the leak of a user identifier were significant. The theoretical attack of tracking users across networks becomes more feasible the more often the user would be expected leak this information. If a user were to use Bing search, or was working on documents in Office 365, they would make these requests often, improving the resolution of the tracking.

Having found the ids being leaked, we looked to see if there were any further attacks possible beyond activity tracking.

The first discovery was that the user identifier was sufficient to download a user’s avatar from their Microsoft account. A request could be made to https://cid-{id}.users.storage.live.com/users/0x{id}/myprofile/expressionprofile/
profilephoto:Win8Static,UserTileMedium,UserTileStatic/MeControlXXLUserTile which would return the avatar if one existed. Thus, users could be potentially deanonymized from this leaked identifier.

Further research found that this issue was previously reported in a blog post in 2015, and was also covered in the tech press. As well as the avatar download, the post described other attacks to extract data from the OneDrive API for a user. For example, one can read and download the contents of this user’s public OneDrive folders by accessing the following URL:

https://cid-{id}.users.storage.live.com/users/0x{id}/LiveFolders/Public

As well as listing the files in the public directory of the user’s OneDrive, this API gives the space used and granted for this account. While gaining access to public files is not exactly a serious flaw, many users would not expect that these files are so exposed to the outside world. Users using the public folder to share files with friends and business associates may not expect that these files can also be downloaded by others with whom the link was not shared.

We were able to find a fix which solved the privacy issue for our users with no negative effect on them or the Microsoft sites they were using. The API requests made to this hostname also included the user identifier as a query string parameter. We found that if the identifier in the hostname is changed or removed it did not affect the result of the request. Therefore, we shipped a rule to our anti-tracking which would rewrite any cid-{id}.users.storage.live.com hostname to cid-0.users.storage.live.com. The prevented network snoopers from seeing user identifiers anymore.

This fix was also included with Ghostery 8, as part of the AI-antitracking feature, extending protection to this group of users too.

We reported the issue to the Microsoft Security Response Center at the end of April 2017. After providing a Proof of Concept of this exploit, they confirmed the issue in August, and credited us on their Security Researcher Acknowledgement page. When we went to verify the fix, we found the following:

• www.microsoft.com: Fixed 30.07.2017.
• support.microsoft.com: Fixed 30.07.2017.
• account.microsoft.com: Fixed 06.12.2017.
• www.bing.com: Fixed 19.02.2018.

While Microsoft acknowledged and started fixing this issue promptly, the delay rolling the fix out to all properties shows the difficulties in fixing such issues in large organizations, particularly when, as in this case, the issue lies in a consumer-facing API which has strong dependencies across multiple teams.