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

[Eitan Caspi via Fulldisclosure <fulldisclosure () seclists org>]

Original, as HTML with images, was posted at LinkedIn - 
https://www.linkedin.com/pulse/vulnerability-feature-zendesk-customer-act-now-eitan-caspi/And also at my security blog 
- https://fudie.net/it-is-not-a-vulnerability-it-is-a-feature-a-zendesk-customer-act-now/

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/
 
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.

Eitan CaspiIsrael
LinkedIn: https://www.linkedin.com/in/eitancaspiDefault is a FAULT! - The end of default passwords starts here and now! 
- https://defaultisafault.comSecurity Blog (English): http://fudie.netSecurity Blog (Hebrew): 
http://security.caspi.org.il (with a matching Facebook page at https://www.facebook.com/notsurenorsafe/)

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/