DEV Community: Konark Modi

Watching them watching us - How websites are leaking sensitive data to third-parties.

Konark Modi — Wed, 01 May 2019 18:12:00 +0000

What is a TellTale URL ?

URL is the most commonly tracked piece of information, the innocent choice to structure a URL based on page content can make it easier to learn a users’ browsing history, address, health information or more sensitive details. They contain sensitive information or can lead to a page which contains sensitive information.

We call such URLs as TellTaleURLs.

Let’s take a look at some examples of such URLs.

EXAMPLE #1:

Website : donate.mozilla.org (Fixed)

After you have finished the payment process on donate.mozilla.org, you are redirected to a “thank you” page. If you look carefully at the URL shown in the below screenshot, it contains some private information like email, country, amount, payment method.

PII in URL on donate.mozilla.org

Now because this page loads some resources from third-parties and the URL is not sanitised, the same information is also shared with those third-parties via referrer and as a value inside payload sent to the third-parties.

URL with PII shared when fonts being loaded from Google Apis.

In this particular case, there were 7 third-parties with whom this information was shared.

Mozilla was prompt to fix these issues, more details can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1516699

EXAMPLE #2:

Website : trainline.eu, JustFly.com (Last checked: Aug’18)

Once you finish a purchase like train tickets / flight tickets, you receive an email which has a link to manage your booking. Most of the time, when you click on the link, you are shown the booking details — without having to enter any more details like booking code, username/password.

This means that the URL itself contains some token which is unique to the user and provides access to the users’ booking.

It so happens that these URLs are also shared with third-parties, giving these third-parties highly sensitive data and access to your bookings.

JustFly.com leaking bookingID to 10 third-party domains

trainline.eu sharing booking token with 17 third-party domains.

URL with token being shared via Ref and inside the payload.

EXAMPLE #3:

Website : foodora.de, grubhub.com (Last checked: Aug’18)

One of the pre-requisites to order food online is entering the address where you want the food to be delivered.

Some popular food delivery websites, convert the address to fine latitude-longitude values and add them to the URL.

The URL is also shared with third-parties, potentially leaking where the user lives.

Foodora leaking address details to 15 third-party domains.

To be clear, it’s not just these websites that suffer from such leaks. This problem exists everywhere — it’s a default situation, not a rarity. We’ve seen it with Lufthansa, Spotify, Flixbus, Emirates, and even with medical providers.

Risks of TellTale URLs:

Websites are carelessly leaking sensitive information to plethora of third-parties.
Most often without users’ consent.
More dangerously: Most websites are not aware of these leaks while implementing third-party services.

Are these problems hard to fix?

As a Software Engineer who has worked for some of the largest eCommerce companies, I understand the need to use third party services for optimising and enhancing not only the Digital Product but also how users interact with the product.

It is not the usage of third party services that is of concern in this case but the implementation of these services. Owners should always have the control of their website and what the website shares with third party services.

It is this control that needs to be exercised to limit the leakage of User information.

It is not a mammoth task, it is just a matter of commitment to preserving the basic right to privacy.

For example:

Private pages should have noindex meta tags.
Limit the presence of third-party services on private pages.
Referrer-Policy on pages with sensitive data.
Implement CSP and SRI. Even with a huge footprint of third-party services CSP, SRI are not enabled on majority of the websites.

Introducing Local Sheriff:

Given that such information leakage is dangerous to both users and the organisations, then why is it a wide-spread problem?

One big reason that these issues exist is lack of awareness.

A good starting point for websites is to see what information is being leaked or detect presence of TellTaleURLs.

But in order to find out if the same is happening with the websites you maintain or visit, you need to learn some tools to inspect network traffic, understand first-party — third-party relationship and then make sure you have these tools open during the transaction process.

To help bridge this gap, we wanted to build a tool with the following guidelines:

Easy to install.
Monitors and stores all data being exchanged between websites and third-parties — Locally on the user machine.
Helps identify the users which companies are tracking them on the internet.
Interface to search information being leaked to third-parties.

Given the above guidelines, browser extension seemed like a reasonable choice. After you install Local-Sheriff, in the background:

Using the WebRequest API, it monitors interaction between first-party and third-party.
Classifies what URL is first-party and third-party.
Ships with a copy of database from WhoTracksMe. To map which domain belongs to which company.
Provides an interface you can search for values that you think are private to you and see which websites leak it to which third-parties. Eg: name, email, address, date of birth, cookie etc.

Revisiting EXAMPLE #1

Website: donate.mozilla.org

The user has Local-Sheriff installed and donates to mozilla.org.

PII in URL on donate.mozilla.org

Clicks on the icon to open search interface.

Local sheriff icon.

Enters emailID used on the website donate.mozilla.org.

Search interface Local-Sheriff

It can be seen that email address used at the time of donation was shared with ~7 third-party domains.

You can try it yourselves by installing it:

Firefox: https://addons.mozilla.org/de/firefox/addon/local-sheriff/

Chrome: https://chrome.google.com/webstore/detail/local-sheriff/ckmkiloofgfalfdhcfdllaaacpjjejeg

More details : https://www.ghacks.net/2018/08/12/local-sheriff-reveals-if-sites-leak-personal-information-with-third-parties/

Source Code : https://github.com/cliqz-oss/local-sheriff

Conferences: Defcon 26 Demo Labs_ ,_ FOSDEM 2019

Code: https://github.com/cliqz-oss/local-sheriff

Chrome store: https://chrome.google.com/webstore/detail/local-sheriff/ckmkiloofgfalfdhcfdllaaacpjjejeg

Thanks for reading and sharing ! :)

If you liked this story, feel free to 👏👏👏 a few times (Up to 50 times. Seriously).

Happy Hacking !

- Konark Modi

Credits:

Special thanks to Remi_ ,_ Pallavi for reviewing this post :)
Title “Watching them watching us “ comes from a joint talk between Local Sheriff and Trackula at FOSDEM 2019.

Everyone one of us is being stalked online.

Konark Modi — Mon, 26 Nov 2018 17:54:33 +0000

Do you know which companies know the news you read, friends you meet, your fitness regime, food you order online, where you live, what music you listen to, where you are travelling this summer, what you are planning to buy?

What if a stranger:

Follows your every move.
Monitors your internet history and computer usage.
Taps your phone calls and messages
Takes your photos without consent.
Shares personal information gathered about you with people you do not know.

Do you think you are being stalked, how will you react?

Change your behaviour
Confront the stalker
Report it to the authorities

What about stalking in the digital world?

In June this year I shared my thoughts about our privacy in the digital world at 15x4 Munich meetup.

The video is available now: 15x4–15 minutes about Your Online Privacy

Slides: https://www.slideshare.net/konarkmodi/our-online-privacy/1

Happy Hacking!

You can follow me on Twitter at Konark Modi

Thanks for reading and sharing ! :)

I found a major flaw in Mozilla’s private browsing mode.

Konark Modi — Sun, 22 Apr 2018 15:45:16 +0000

If left unfixed this flaw could have wreaked havoc but Mozilla’s prompt fixes saved the day.

In this article, I’ll discuss details of a bug I discovered with Mozilla Firefox private browsing mode that made it possible for private browsing sessions to be tracked.

Private Browsing is one of the most widely known and used features in modern browsers today. Browsers continually add many enhancements to private browsing to enhance the users’ privacy.

The features offered might differ from one browser to another, but at the very least a user using private browsing has the two most basic requirements:

Websites visited in private cannot save any data
Visited pages are not saved

Well, I discovered that the Firefox browser Private browsing mode didn’t meet any of the above requirements.

For a website to track a user across private browsing sessions, it needs to use some persistent storage at the browser level.

There are multiple ways of storing data in a browser — LocalStorage, WebSQL and IndexedDB.

I recently came across IndexedDB storage.

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs — Mozilla Developer Network

Although, as per the documentation, IndexedDB should not be available in private browsing mode.

If you use IndexedDB directly on the webpage, it will throw an error:

But what happens if you combine IndexedDB with Web Workers?

Web Workers makes it possible to run a script operation in background thread separate from the main execution thread of a web application — Mozilla Developer Network

IndexedDB can be accessed in private browsing mode via Web Workers. Not only that, but when the browser is closed, the IndexedDB data is not cleared. This stored data will persist across multiple private browsing sessions because it is not cleared when exiting. 😮

So let’s look at a few ways this issue could be abused.

A malicious website can leverage IndexedDB and track users across private browsing sessions. For example, say you visited badsite.com, which uses Web Workers and IndexedDB in private browsing mode. Close the private browsing window, close Firefox, start Firefox again, start private browsing mode, and again visit badsite.com. The website will be able to access the data from your previous private browsing session, as the data is still stored in IndexedDB.

Let’s assume siteA.com loads an analytics script from BadAnalyticsSite.com. Then another website, siteB.com , also loads an analytics script from the same website BadAnalyticsSite.com. Since the malicious website BadAnalyticsSite.com uses Web Workers and IndexedDB, the website BadAnalyticsSite.com can now track users of websites siteA.com and siteB.com across all their private browsing sessions.

IndexedDB adheres to a same-origin policy, which means that every database has a name that identifies it within an origin. Because domain name is used as part of the file name, this can result in serious issues when used in private mode.

For example, if a user visits a test webpage (demo) which uses Web Workers + IndexedDB hosted on cdn.cliqz.com, and loads a resource from konarkmodi.github.io, the following two entries are created on disk.

Location of IndexedDB: <em>profile/storage lists Poc web pages.

Because of the above flaw, a website/tracker could effectively generate a fingerprint and save it. Even if a user were to clear the website history or select the option “forget about this site,” the IndexDB storage is not removed. This can create a permanent storage for a website or a tracker that can be leveraged forever.

Mozilla encourages security research for their products. In their own words:

The Mozilla Client Security Bug Bounty Program is designed to encourage security research in Mozilla software and to reward those who help us create the safest Internet software in existence.

I reported this issue in October 2017 via their Bug Bounty Program, and the issue was fixed in November 2017. They were prompt to identify and fix the issues.

For more details, you can read the complete bug report at Mozilla’s Bugzilla.

I really appreciate Mozilla’s efforts and actions in fixing issues with the highest priority when it comes to the privacy of its users.

Happy Hacking!

You can follow me on Twitter at Konark Modi

Thanks for reading and sharing ! :)

If you liked this story, feel free to 👏👏👏 a few times (Up to 50 times. Seriously).

Credits: Special thanks to Remi and Pallavi for reviewing this post :)

Originally published at medium.freecodecamp.org on April 22, 2018.

Breaking bad to make good: Firefox CVE-2017–7843

Konark Modi — Sun, 22 Apr 2018 15:45:16 +0000

Private Browsing Mode (PBM)is one of the most widely known and used feature in not just Firefox but any major browser. Browsers are continuously trying to add more & more features to PBM to enhance users’ privacy.

The features offered might differ from one browser to another, but at the very least a user using PBM in any browser has two most basic expectations:

Websites visited in private cannot save any data, and
Visited pages are not saved.

Well, Firefox Private browsing mode was not meeting any of the above expectations.

Technical Details:

For a website to track a user across private-browsing sessions, it needs to use some persisted storage at the browser level.

There are multiple ways of storing data in browser: LocalStorage, WebSQL & IndexedDB.

I recently came across IndexedDB storage, although as per the documentation IndexedDB should not be available in PBM.

If you use IndexedDB directly on the webpage, it will throw an error:

But what happens if you combine IndexedDB with Web Workers?

Fallout:

IndexedDB can be accessed in PBM via Web Workers. Not only that, at browser shutdown it is not cleaned. This stored data will persist across multiple private browsing mode sessions because it is not cleared when exiting.

Websites: As a website, you can leverage IndexedDB & be able to track users across PBM session. So if you visit “A.com — which uses Webworkers + IndexedDB” in private browsing, close private browsing window, close Firefox, start Firefox, start private-browsing, visit A.com”, then “A.com” will still be able to access the data previously stored in IndexedDB.
Third-parties: Let’s assume A.com loads analytics script from t.com, similarly B.com also loads t.com. Since t.com uses web workers + IndexedDB. t.com, t.com can now track users’ all PBM sessions across domains A.com, B.com and so on.
Disk leaks: IndexedDB adheres to a same-origin policy which means every database has a name that identifies it within an origin. Because domain name is used as part of the file name this can have serious issues when used in private mode.

As an example: On visiting a test webpage which uses Web Worker + IndexedDB hosted on cdn.cliqz.com which loads a resource from konarkmodi.github.io the following two entries are created on disk.

Location of IndexedDB: <em>profile/storage lists Poc web pages.

Because of the above flaw, a website/tracker could effectively generate a fingerprint & save the fingerprint. Even on the “clear history” signal or the option “forget about this site”, this storage is not removed. Hence creating a permanent storage for a website or a tracker, that can be leveraged forever.

Report & Fixes:

Mozilla encourages security research for their products. In their own words:

“The Mozilla Client Security Bug Bounty Program is designed to encourage security research in Mozilla software and to reward those who help us create the safest Internet software in existence.”

I reported this issue in October 2017 via their Bug Bounty program . They were prompt to identify & fix the issues. This was fixed in November 2017 with Firefox 57.0.1.

For more details you can read the complete bug report at Mozilla’s Bugzilla.

I really appreciate Mozilla’s efforts and actions in fixing issues with highest priority when it comes to users’ privacy.

Happy Hacking !

- Konark Modi

Thanks for reading and sharing ! :)

Credits: Special thanks to Remi_ ,_ Pallavi for reviewing this post :)

Airline websites don’t care about your privacy follow-up: Emirates responds to my article with…

Konark Modi — Tue, 06 Mar 2018 22:04:08 +0000

Airline websites don’t care about your privacy follow-up: Emirates responds to my article with full-on denial

Yesterday, The Register wrote about my exposé on the privacy failings of airline websites.

When I published my original article last Friday, Emirates had failed to respond to my request for comments. But Emirates did respond to The Register, with the following statement:

Comment from Emirates on theregister.co.uk

Their statement is not only vague — it is factually incorrect. And I feel it’s my professional duty to call them out on this.

A breakdown of their statement, and how their logic breaks down when you really think about it

Issue #1

First Emirates says, “We can confirm that none of the security vulnerabilities highlighted will allow a breach (unauthorised access) of personal data on our website or mobile app.”

How does Emirates define breach? Well, Wikipedia defines a data breach like this:

“A data breach is a security incident in which sensitive, protected or confidential data is copied, transmitted, viewed, stolen or used by an individual unauthorised to do so.”

In its Privacy Policy, Emirates highlights the importance of safeguarding Booking Reference information:

Update 8th March, 2018: Another exhibit how Emirates seems to have forgotten to pay heed to their own advice “keep your Booking Reference safe” and is still sending it to Google Analytics from mobile app, via key:cd8 (unmasked). I have masked the fields in the picture to ensure Privacy.

Sending PNR via field cd8 to Google-Analytics.

For any changes to an existing booking, a Booking Reference number and Last name is all that is required. There is no requirement to verify who initially made the booking and whether the person making the changes is authorised to do so or not.

Emirates.com and the Emirates mobile app version (6.1.0) both allow access to their Manage Booking section based only on these two data points. This a standard practice across airlines, and this is not the point of contention for the purposes of this article.

But this is when it gets worrisome

As of March 6th, 2018, Booking Reference number and Last Name, among many other data points, are still being sent to the third-parties implemented. Does Crazy Egg, Boxever, Coremetrics need Booking Reference Number and Last name for showing Heat Map of the page? I don’t think so.

This is the problem area — passing on user’s personal information to third parties who have absolutely no need for this information to render their services to Emirates “for the purpose of improving the online browsing experience.”

The importance of using HTTPS links has been established over and over again by everyone who is anyone in the field of Technology. HTTP links are not only vulnerable to Man-In-The-Middle attacks but can also suffer from injection of malicious data.

I am not sure how Emirates is confident enough to “confirm that none of the security vulnerabilities highlighted in (Mr. Modi’s) article will allow a breach (unauthorized access) of personal data on our website or mobile app” when track.emirates.email still does not have any SSL. How do they plan to avoid Man-in-the-Middle attacks?

Issue #2

Emirates says, “Whilst we do use a number of third party analytical tools on our sites for the purpose of improving the online browsing experience, we continually review how these are implemented.”

I shared in the article how Passport information and contact details were earlier un-obfuscated on both website and Mobile app. While the website was fixed when I checked last in February 2018, the mobile app continues to be problematic in this area. This can happen only when there is a lack of communication between the Website and Mobile Development Team or they did not “continually review the implementation” across all products.

Another question that begs to be answered is what are the parameters for reviewing the implementation of third parties. Unless the mandate is strictly to NOT leak any kind of user-information, the reviews could be of anything and would not have the slightest impact on the security and vulnerability of user information being freely passed on the third parties.

The last time this issue was highlighted to Emirates was in October 2017. In the 5 months that have passed since then these issues were not picked up by the review team. Maybe they are not as “continuous” as Emirates claims them to be.

Issue #3

Emirates says, “Customers can find out more about how we use personal data and how they can opt out by reading our privacy policy on emirates.com”

Third-parties listed on Privacy Policy page.

Third-parties actually present.

Upon a thorough review of Emirates’ Privacy & Cookie Policy, these are the points to note:

It does not list ALL the implemented third-parties and the information being shared with them. Third parties like Boxever, ads-twitter.com, Coremetrics, Imigix, bing and many other that I had aggregated from their website are not even mentioned in their Privacy Policy.
Opt-out options available only mentions ways using about cookies, YourOnlineChoices. This means that not only the information provided in Privacy Policy is incomplete but also does not share any options to opt-out of services CrazyEgg, BoxEver, Coremetrics etc. The process is tedious and cumbersome.
The option to opt-out is biased based on the country of residence of the users. If you are a resident of EU you can use this link to opt-out. If you are a resident of USA this is the link to opt-out. But if you are a resident of any other region, I am sorry to break it to you that you have been short-changed.

Opting-out of cookies is not going to have any impact on the data leaks highlighted in the article because the referrer is not being cleaned. Anybody with basic tech knowledge can confirm this.

In Short

Even if the user somehow manages to opt-out of all the trackers using the methods listed and not listed, Emirates will still leak the Booking Reference and Last Name which is enough to access all other sensitive information because the implementation of these third-party services on Emirates.com is flawed.

Emirates needs to understand that once the information has been shared with third-parties, there is very little they can do to control how it is being used or might be used in the future, as they have themselves mentioned in their privacy policy.

It is one thing for Emirates to think that these issues are not critical enough for them to take necessary actions to fix them. It’s an entirely different thing to say that the information shared in the article is “not true”.

I hope they fix these issues sooner rather than later.

Happy Hacking !

- Konark Modi

Thanks for reading and sharing ! :)

If you liked this story, feel free to 👏👏👏 a few times (Up to 50 times. Seriously).

Credits: Special thanks to Remi_ ,_ Pallavi for reviewing this post too :)

Adoption of HTTPS protocol on government serviceÂ websites

Konark Modi — Wed, 19 Apr 2017 22:47:15 +0000

Last week, Freedom of the Press Foundation announced the project “secure the news which tracks the adoption of HTTPS on news websites.
Inspired by it, we decided to do an analysis on Government of India digital services and track the adoption of HTTPS across them.
Digital India is a campaign launched by the Government of India to ensure that Government services are made available to citizens electronically by improving online infrastructure and by increasing Internet connectivity or by making the country digitally empowered in the field of technology.
Launched on 1 July 2015 by Prime Minister Narendra Modi, the initiative spans across three core components:
The creation of digital infrastructure
Delivery of services digitally
Digital literacy

The Digital India programme has, as of date, a total 1995 services listed on their website, categorised as below:

While some of the services are more information centric with respect to policy updates, etc, there are a few websites that deal with user information on everyday basis, ex: Air India, passport services, Income and Taxation services, Citizenship and Visas, Online hospital appointments etc.

From the list of services, we analysed 874 valid domains for adoption of HTTPS protocol. Our findings are:

a. 31% have a validÂ HTTPS

b. Only 7.4% default toÂ HTTPS

c. Less then 1.5% have HSTSÂ enabled

d. Merely 2 sites are on the HSTS preloaded list

What does this mean?

While this is a great first step for the government towards bringing in transparency and accountability by going digital, the next steps ought to be towards privacy & security of user information and data protection. Actively adopting security measures will definitely result in lesser vulnerability of data thefts/ hacks or other cyber threats that present itself in friendly or unfriendly environment. The primary, and also the simplest, step towards data protection and privacy is adopting HTTPS protocol.

Prologue on HTTPS or why is it importantÂ ?

HTTPS connection is easily recognised by the most novice of Internet users for the lock icon it displays in your web browser’s address bar (the “S in HTTPS means “secure”).

It signifies that the connection between you and the website you are reading is encrypted, so someone spying on your internet connectionâ€Š–â€Šwhether a criminal trying to eavesdrop on you through public WiFi or a government that has access to raw Internet trafficâ€Š–â€Šcannot see the information that you are transmitting.

A regular HTTP connection means that such attackers can potentially see the search terms or articles you are reading, spy on your username and password, or spoof a website to steal your personal information. Unencrypted HTTP traffic is also easier to filter and block, allowing for selective censorship of articles, subjects, specific reporters or outlets by authoritarian governments.

Protects user’s sensitive information.
Protects integrity of your website.
It is the future of the web.
10 good reasons to switch to HTTPS

Rise of HSTS

HSTS(HTTP Strict Transport Security), is a relatively new standard that aims to bolster the strength of HTTPS connections.

When a web server implements and enables HSTS, all browsers that connect to it will be forced to do so strictly via HTTPS. That means, there won’t be that exploitable vulnerability wherein a browser would initially connect via HTTP before it gets redirected to HTTPSâ€Š–â€Šexcept for that very first instance that the browser makes contact with the web server.

Major benefits of having a site on HSTS are the following:

..* Defence against sslstrip-like attacks. The initial navigation to somewebsite.com is automatically upgraded to HTTPS

..* Zero tolerance for certification problems. The user is not permitted to “click through anything such as a self-signed cert.

If you have a site wide implementation of SSL, as an additional layer of security, the website owners could also apply for HSTS Preloading. A detailed explanation on why HSTS preloading matters specially for sites dealing with sensitive user data can be found here.

Resources and tips for deploying HTTPS by default

List of recommended resources to help you understand HTTPS and how to go about deploying it:

Federal government adoption of HTTPS
EFFâ€Š–â€ŠHow to deploy HTTPS correctly
Mozillaâ€Š–â€ŠSecurity/Guidelines/Web Security
Ivan Ristic’s Bulletproof SSL and TLS
Google Developer’s Blogâ€Š–â€ŠEnabling HTTPS on Your Servers
Let’s Encrypt

Next steps and To-do’s

This blog post is certainly the first step.
We are currently working on making it a formal project, with automation to verify the adoption of HTTPS.
Make all the codebase + data open and put it on Github.
Create a more comprehensive list, based on services that the websites offer.
Expand to other countries government services as well.
Contribute rulesets to HTTPS Everywhere extension.

Team

Bibhas, Pallavi, Konark