Category Archives: Privacy

Law enforcement bodies ask social media to open end-to-end encryption (E2EE) for them

Cryptography, Encryption, Decryption, Cybercrime, Cyberterrorism, Cyberwarfare, Government and Regulation, News, PrivacyEitan Caspi
Interesting. Does these almost same-time publications are a coincidence? I tend to doubt it.
 
Both law enforcement bodies in Europe and Australia publicly turn to the private market, with focus on Social Media, asking it to ease its end-to-end encryption (E2EE), so law enforcement can read relevant data, for law enforcement reasons.
 
In my view this can mostly one of two:
1. Law enforcement has a real problem here
2. Law enforcement has the ability to overcome end-to-end encryption (E2EE) so they use these publications to pretend to be helpless against it, hence building the criminals/enemies confident that these platforms are safe for them, so they will act freely in them and so the law enforcement bodies will be able to spy on them
 
If it is the first reason – then I think it looks like we are escalating towards a clash.
 
News article
“Police Chiefs Call for Solutions to Access Encrypted Data in Serious Crime Cases”
 
The Europol post about it
 
The declaration (PDF file)
 
News article
“The director general of Australia’s lead intelligence agency and the commissioner of its Federal Police yesterday both called for social networks to offer more assistance to help their investigators work on cases involving terrorism, child exploitation, and racist nationalism.”

Bug Bounty – when love is gone + Facebook privacy concern

Bug Bounty, Privacy, What have I discovered?Eitan Caspi

One of the things I do not like for a long time, beyond the specific case described below, whose purpose was only to check the issue with the company, because it is clear to me that this is not a real vulnerability, but in my opinion only an unnecessary disclosure of private information to the client side – is that the Bug Bounty programs Kill the simple, largely innocent relationship between the reporter and report recipients.

Many times you just want to report relatively simple things, not terribly dangerous, not RCE, not SQLi, but defense is built from many layers and every closure helps protect, but “when money comes in – love is gone”, if I can describe it using an allegory.

Often times, especially in bug bounty outsourcing companies, such as HackerOne, they immediately close the report and even give you a “negative score” (which means you sent them nonsense and you are wasting their time) if you haven’t reached the reporting threshold that has a monetary reward. In my opinion, this approach is anti-information security and will only keep people from reporting to them, thus they are damaging their information security, because of their attitude.

The case below is with Facebook, which I believe discloses personal information to the client side without justification, or at least without a justification that is clear to me.

I understand and generally agree with their answer, but my security approach is to minimize exposure as much as possible, and I do not see in this case a justification for this exposure.

I wrote to them:

Title – Private user data from Facebook to Instagram

Vuln Type – Identification / Deanonymization

Product Area – Web

Description/Impact:

Hello,

I was wondering why when I try to login to Instagram, the site already knows my user name and suggest me login using it, so I investigated about it using Fiddler (I have matching saved Fiddler sessions).

The bottom line for this case is that in a reply to a POST method request to https://www.instagram.com/accounts/fb_profile/?hl=en, the client side gets a JSON plain text data (over HTTPS) with the following details, some originated from the already-Facebook-authenticated-client:

1. Instagram ID (assumed, the field is called “id”)

2. name – full name (first and family)

3. mobile_phone – full account mobile phone, with the international prefix, even if the relevant Instagram account has not set any mobile phone data at his/her Instagram account. Hence I guess it is a Facebook account data

4. email – the account’s FB email address, even if the FB account email address is different from the one at Instagram

5. username – the Instagram user name value, the one displayed to the user on the web page

I read the Instagram privacy policy and I see you mention that you can and will share user data between Facebook products and services, like between FB and Instagram, so in this front we are OK.

Also, the above process is done over HTTPS, so it *should* be secure during transit.

My claim is this:

It looks like most of the shared data is not needed for the login process but it is still sent to the client side, where it may be exposed or altered in various ways, like in companies that decrypt their internet traffic using their own cert at their IPS/UTM, hence allowing them to read the so called “secure” https data; or 3rd party browser plugins/extension at the client side; or any unknown other client side vulner or malware.

I guess that if you will only send the textual user name it will be enough – as it will be displayed for the user on the auto-login button and you will take care of the rest “behind the curtain”, with only minimal user data.

And if you do need, for some reason, to send all the above data to the client side – at least encrypt it, don’t send it as plain text.

Repro Steps

1. Use the latest chrome with a proxy extension, I like “Proxy SwitchyOmega” https://chrome.google.com/webstore/detail/proxy-switchyomega/padekgcemlokbadohgkifijomclgjgif?hl=en

2. Install the latest Fiddler and set it to decrypt HTTPS and click on the “Decode” toolbar button to auto-decode all incoming traffic, since the relevant response is GZIP encoded

3. Set the Chrome proxy plugin to direct its traffic to the Fiddler IP and port

4. Log into Facebook, verify Fiddler capture the traffic

5. Load the Instagram home page, https://www.instagram.com/?hl=en

6. Stop the Chrome extension from sending data to Fiddler (set it to “Direct”)

7. At Fiddler search for your phone number or just find the URL line of https://www.instagram.com/accounts/fb_profile/?hl=en

8. Review this line’s response pane in either RAW mode or JSON mode and you will see the above mentioned account details

Thanks.

Eitan Caspi

Israel

They replied:

Hi Eitan,

This is intentional behaviour in our product. If someone is browsing under the presence of UTM devices / malicious extensions / malware then their threat model is already compromised (eg. traffic passing through UTM can also include password / cookies of the user).

As such, we do not consider it a security vulnerability, but we do have controls in place to monitor and mitigate abuse.

Capture of the private data

It is not a vulnerability. It is a feature. A Zendesk customer? Act now!

Data Leakage, Government and Regulation, Privacy, Tips, Vulnerabilities, What have I discovered?Eitan Caspi

I am not a Zendesk expert but I have seen enough. Here is my story.

The short version:

If in your ZD settings the check box of “Require authentication to download” (in the site path of Admin > Settings > Tickets) is NOT selected (hence Disabled) – there are web address/URLs at sub-domain sites of zdusercontent.com that store files that are accessible without any authentication, anonymously, and they can be files that hold private data of your customers.

This check box is disabled by default! By a ZD intentional decision. Customers of ZD may not even know that and not change this default and thus the files will remain accessible anonymously. Not nice. I guess not GDPR compliant.

ZD support article about this check box – https://support.zendesk.com/hc/en-us/articles/203927716-Attachments-in-Zendesk-Support#sec5

Some of this data is indexed by Google, sample searches:

site:zdusercontent.com

https://www.google.co.il/search?q=site%3Azdusercontent.com

site:zdusercontent.com receipt

https://www.google.co.il/search?&q=site%3Azdusercontent.com+receipt

And so on – try the words like bank , “credit card”

Also, if you go to the following link you can find who ZD customers are

https://www.zendesk.com/why-zendesk/customers/

And then you can search by their names, Say, Uber

site:zdusercontent.com uber

https://www.google.co.il/search?q=site:zdusercontent.com+uber

These URLs are quite long and use complex and random characters, so they are not easy at all to guess. But, they can be sent to your customers from the ZD system as links in emails (which can be exposed in many ways) or they can be logged in your security systems, hence exposed to your IT team (see the longer version of this story below).

Since these URLs are accessed anonymously, I guess the only possible way to track who used them is by source IP, which of course can easily not be the real IP of the person who initiated this access (say if the person is using a proxy server or public VPN service).

So, my recommendation to you is to enable this check box, which will change this behavior and any access to any attachment file will force the accessing person to first be authenticated by the ZD system.

This may have negative operational results for the ease of your customers’ access to these files – so weight the pros and cons before doing this change.

The long story:

One day last week, as I was reviewing our gateway alerts, I noticed a strange link, beginning with a sub-domain of zdusercontent.com and followed by medium size string of a URL parameter. I searched to find who is the owner of this domain and found it is owned by ZD. Cool. Safe. I clicked it.

A JPG file loaded into my browser. It was a photo a customer of ours took, to prove his identity, a personal identification document… whoaaa… what???

Although I knew I didn’t log into ZD recently, I cleared my browser’s cache and all cookies, and tried again. The same…

I tried using another browser. The same.

I tried from another PC inside the company. The same.

I tried from my private mobile phone, I tried from my home. All the same.

I tried another link found for this domain – a zip file with multiple files sent by another customer. Not nice, not at all.

Woooo, I said to myself, we’re going to make tons of money on this one via a bug bounty. Zero authentication for customers’ private data. No joke.

So, I found ZD bug bounty page at HackerOne – https://hackerone.com/zendesk

It didn’t mention that the domain of zdusercontent.com is included in the bounty program.

I didn’t give up – I asked HackerOne about it, but quickly I learned HO is not really responsive nor knowledgeable so I turned directly to ZD security.

They promised me that zdusercontent.com is included in the bounty and that they wish to accept my report. (BTW, even now this domain is not mentioned as eligible to their above bug bounty page).

So I PGPed my findings and sent it to ZD, including an offer to simply block search engines from indexing these sites with a simple robots.txt file.

They replied:

”

To summarize the issue you reported to us, you found files (Zendesk ticket attachments) were indexed by the Google search engine and could be accessed publicly, without authentication, and in some instances without the token parameter in the URL. If I have missed anything please correct me.

This specific topic is something which has been brought to our attention before and has been discussed internally. I want to assure you everything is currently working as intended. All Zendesk accounts have an admin setting to require authentication to view/download a ticket attachment: https://support.zendesk.com/hc/en-us/articles/203927716-Attachments-in-Zendesk-Support#sec5. If you are worried about potential information disclosure please enable that setting to restrict access to all ticket attachments, including the files which are indexed by search engines. In that page you can see the only time ticket attachments are indexed by search engines is when the links are posted on third-party public websites. The files being indexed are not being leaked from Zendesk, but intentionally posted to public locations. This setting exists because the feature of publicly shareable ticket attachments are a popular request from our customers. That being said, I completely agree with you that there is no reason to not include a robots.txt file for that domain. There is currently an open request to implement robots.txt on a few domains which handle customer attachments which should be rolled out by the end of the year, if not much sooner.

In the meantime, if enabling the “require authentication” for attachments doesn’t fit your organization’s needs, please take a look at our Attachments API which would allow you to handle attachments on an individual basis. You can redact comment attachments via the information provided here: https://developer.zendesk.com/rest_api/docs/core/attachments#redact-comment-attachment. You can permanently delete uploads via there information provided here: https://developer.zendesk.com/rest_api/docs/core/attachments#delete-upload.

”

And their next response after I replied to the above with amazement to their answer and asking if this check box is disabled by default:

”

The administrative setting of “Require authentication to download” is disabled by default. Many of our customers specifically ask for the ability to host and share non-sensitive documents with their customers so we give them the ability to configure their account to best fit their needs. Additionally, many of our customers’ customers utilize Zendesk strictly through e-mail and not the actual Zendesk UI, therefore they wouldn’t have a registered account to begin with which could cause a lot of confusion if the e-mail correspondence contains attachments. That being said, I’ve escalated this to my manager to start the discussion with our Product teams regarding the default nature of that setting. I can’t promise a change as this may be an accepted risk using the shared responsibility model.

I’ve already mentioned the API endpoints available which Zendesk accounts can use to redact/delete all non-inline attachments. If you are worried about any specific attachments I would reach out to that specific account and address the issue with them. If they are unsure how to proceed with that type of request Zendesk is more than happy to walk them through that process.

”

I think ZD is making a mistake by disabling this check box by default, loading on itself the legal responsibility for data exposure, when some of it may be private.

If they enabled it by default – they would have been covered themselves better, making the default more secure and if customers would try to change it – they would be displayed with a flashing bold warning about the consequences of such change, and if they do change it – they will be the ones responsible for any relevant data exposure.

So, there goes my imaginary pile of bug bounty money, but as least I came across a good story and a chance to let you know about this risk and possibly mitigate it.

A next day addition I forgot to add – I found only one place on the web that already related to this issue – and it is from a poker forum, where a customer complaints about his personal data being freely exposed on the web, in a zdusercontent.com sub-domain. And he is furious… – https://forumserver.twoplustwo.com/252/global-poker/security-issue-personal-documents-posted-open-web-1715425/

(4-May-2020 – I added here the above forum discussion as a PDF file, for archiving – zd-angry-customer)

Addition at 22-Nov-18: Hi Zendesk folks, I see you reacted quickly and cleared the search results from Google. That’s very good. Just remember there are more search engines you need to handle, some main ones:

Bing – https://www.bing.com/search?q=site%3Azdusercontent.com

Yahoo – https://search.yahoo.com/search;?fr2=sb-top-search&p=site%3Azdusercontent.com

DuckDuckGo – https://duckduckgo.com/?q=site%3Azdusercontent.com&t=h_&ia=web

And I’m sure you will find more.