Reporting a Google Chrome vulnerability and fixing our user insights process to safeguard our zero-knowledge web service
Logging in-app user activity is a tricky issue. On the one hand, input from user activity provides useful information for troubleshooting and improving the user experience. However, activity logging should be done with utmost care to keep users’ privacy and security intact. Balancing these two is a challenge, but we at Tresorit believe that strong privacy, security, and smooth user experience can coexist.
To ensure this is a continuous process though. We recently discovered two issues with activity logging of sharing links that could have risked a part of our zero-knowledge service. Fortunately, our security team discovered the issues in a timely manner and worked to solve them immediately. These two issues made Tresorit users vulnerable to a limited number of our own developers, not to outsiders. In plain words, this vulnerability could have affected users if one our colleagues acted maliciously to access user content. We can confirm that this did not occur. We haven’t been hacked by outside parties, the security and privacy of our users were never compromised. However, it was crucial fix these issues to guarantee the integrity of our zero-knowledge web access.
In this blogpost, we provide a detailed background of the issues, explain how we managed them, and share the lessons we learned.
The Google Chrome issue
The background
At Tresorit, our primary focus is the security of our users. On top of our patented end-to-end encryption, we develop our service following the defense-in-depth approach. This means that we build multiple security layers into our product on all platforms. This time we have found out that it was one of these additional layers that created a potential security issue due to a bug in Google Chrome. After careful investigation, we identified the vulnerability in Chrome, reported it to the responsible parties at Google and they have already fixed it. We discovered the bug on March 7th, 5pm CST and notified Google immediately. Their team fixed the issue on April 28th, and released the fix on June 5th. The issue was named as CVE-2017-5075.
One of the additional security layers we apply on our website, and web client is Content Security Policy (CSP). It is a collection of rules and policies that help to detect and mitigate certain types of attacks and prevent exploiting certain vulnerabilities. They protect our users in multiple scenarios: from hackers who could inject malicious codes on our website with Cross Site Scripting (XSS), harmful browser extensions, and even from our own developers in the case there’s accidentally a security issue within their code. If a CSP is violated because of suspicious activity, the harmful code will be blocked, and the browser will send an automatic report about the incident to our team. This is where we discovered a vulnerability in Google Chrome which, in theory, could have put our zero-knowledge principles at risk. Zero-knowledge means we never have access to the passwords and files of our users.
When a browser – for example, Google Chrome – sends reports about CSP violations happening on certain websites, they strip the URL address of the website and send only a part of that. Browsers should comply with a standard on this, specified by the W3C. Due to a bug, however, Google Chrome sent the full URL of our web client instead of a part of that. According to the standard, fragmentation identifier (anything after the # sign) should not be sent to the server. Because of this bug, logs containing file, folder and tresor links were saved to our servers. This means that theoretically, some of our backend developers with higher access rights could have been able to access the links and, in the case of links without password protection, consequently the shared data. According to our records, none of our team or a third party has ever looked into these links.
The scope of the issue
Our web team received CSP reports containing approximately 4000 links. Roughly half of these violations resulted from suspicious browser extensions. Another half of them from an incorrect font setting on our website that caused the system to send CSP reports even though there was no malicious activity going on. The issue only affected Google Chrome users. All other non-Chromium based browsers have been correctly stripping the fragment before sending us the report.
What we did to fix this
We discovered the bug on March 7th, 5pm CST and notified Google immediately. Their team fixed the issue on April 28th, and released the fix on June 5th. Following the industry best practice to protect users from hackers who might exploit known vulnerabilities, we held back with this announcement until Google released the update.
As soon as we found the incorrectly fragmented links in our logs, we disabled the CSP violation reports. After March 7th, 5:30pm CST, no link has been saved to our servers. Our security team has permanently removed all logs that contained links from our database.
The issue with App Insights logging
The background
Our web team uses Microsoft App Insights to log certain user interactions on our website and web client. These logs are useful resources that help us improve user experience and provide information for troubleshooting in case a user has a problem with Tresorit. We log solely usage data on errors, performance metrics, usage of certain Tresorit features, and other similar activities. We never log any data that is related to user content. App Insights stores these logs on Tresorit’s Azure servers, and we never forward the logged data to any third-parties. The logs are accessible only for a limited number of our backend and web developers with higher permission levels. Also, we strictly follow the Do Not Track policy: if a user opts out of tracking, we respect this decision and will not log their activity.
To ensure zero-knowledge service, we are careful to make sure that sensitive data will never be sent to the servers. File and folder names are never sent to us, and we meticulously sanitize all sensitive information that is related to user content and encryption.
After an update in App Insights, our third party independent security reviewer discovered on May 19th that some of the saved logs contained unsanitized information including URLs of file, folder, and tresor links. This means that certain developers in our team could have accessed these links, and in case of links without password protection, the content as well. Here again, we can confirm that this never happened.
The scope of the issue
The logs containing links were sent to our servers from December 2016 to May 22nd, 2017. As the logs were saved to a database table that our web team has never checked, no one from our team or a third party has ever seen these links or accessed their contents.
What we did to fix this
As soon as we discovered the issue, we have started investigating the depth of the issue, and whether any links have been duplicated or synced to our other systems. After we could make sure such thing did not happen, we have completely disabled logging from our web client and we have also permanently deleted all logs that contained links. Since then, we have been working on completely reconfiguring our logging process. Until this is finished, we have separated the logs coming from the web client and are manually verifying our new sanitization process.
What do you need to do?
There is no need to update your Tresorit, as the web client uses the latest version whenever you open it. Tresorit updates are also automatic.
The links created during these periods are secure to use. As a precautionary measure, we recommend you always use password protection and set download limits when sharing sensitive files, folders, and tresors with a link. This provides enhanced security and more control over your files. Please stay tuned for our detailed blog post with pro tips from our web team on sending links securely.
We use logging solely for improving user experience and troubleshooting. We never forward this data to third-parties. For users who don’t want their activity logged though, we recommend disabling it. You can disable tracking in your browser (see more info on Do Not Track Us) or use trusted plugins like EFF’s Privacy Badger.
One lesson: security bug reporting is crucial
Sharing security issues immediately between development teams is crucial. Because people use multiple services together, the tech community should also collaborate to improve the security of digital services by notifying each other about vulnerabilities.
We also encourage developers and researchers to share any security concern at security@tresorit.com. If you are using Tresorit and have any questions about the issues detailed in this post, please contact our support team here.
What will we do?
One of Tresorit’s most popular features is sharing via a link, which allows our users to securely share files, folders, and tresors with anyone, even those without a Tresorit account. We’re proud that Tresorit is completely secure and zero-knowledge even when accessed from the web: our end-to-end encryption works when you manage and share your files in the Tresorit Web Access. We are not able to access what you store and share with Tresorit, neither can hackers or surveillance authorities. To ensure this in the future, we’re committed to continuously improving our product, and stay attentive to potential vulnerabilities in Tresorit and other services that might compromise our users’ security.
