Category Archives: Vulnerabilities

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 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 –

Some of this data is indexed by Google, sample searches: 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

And then you can search by their names, Say, Uber 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 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 –

It didn’t mention that the domain of 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 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: 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: You can permanently delete uploads via there information provided here:

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 sub-domain. And he is furious… –

(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 –

Yahoo –;?fr2=sb-top-search&

DuckDuckGo –

And I’m sure you will find more.

Possible vulnerability in F5 BIG-IP LTM

About a year ago, while I was performing a web site penetration test for a customer, I run a manual fuzzing phase, where I like to “question” even the most basic networking and application conventions, and this time it paid off more than the usual…

The site was behind a “F5 Networks” BIG-IP device, running the modules of LTM (load-balancer) and ASM (WAF (Web Application Firewall)).

Generally, each HTTP request made by the client towards a web site (normally using a web browser) should have its first line in the following format:
<Method> <URL> <HTTP Version>

– The <Method> part is replaced with one of a fixed set of words that describe the action the client wish to perform on the target site (usually GET for viewing a web page)
– The <URL> is the site address the client wishes to access
– The <HTTP Version> must be in the format of HTTP/<version number> (usually 0.9 or 1.0 or 1.1 which is the most common these days, e.g. HTTP/1.1)

For example:

I decided to attempt and disregard this format, so first I carefully tried messing with the HTTP version number – first I tried 0.1 (a non-existing HTTP version number) and sent something like:

To my surprise, instead of getting a reply of either an error message from the back-end web server or a security blocking message from ASM, for trying to be naughty – simply NOTHING came back, no reply arrived from the server side and the HTTP session ended only when its underlying TCP session timed out.

So, I dug dipper, to try and find what caused this phenomena, to see if there is some logic for this glitch – so…
– I tried different numbers (e.g. 1000, 0.5, -4, etc.) and the result was the same.
– I tried without any number (e.g. HTTP/ ) – the result was the same.
– I tried omitting the forward slash – the result was the same.
– I changed HTTP to be helloworld (GET helloworld) – the result was still the same.

So, it looked like there is no format verification and enforcement being made at the BIG-IP end regarding the HTTP version part of the request, a situation that looked risky to me, as the content/payload being pushed from the client to the server is not sanitized properly, possibly being accumulated at some memory, either on any relevant F5 BIG-IP module or at the back-end application server, which may lead to server resources being exhausted or possibly overflowing the memory, which can be much more dangerous, as it may allow the attacker to run there his/her own malicious code at the remote server side.

I tried to run some basic low-power DoS (Denial-of-Service) attacks using this issue, to see at what level, if at all, this issue can harm the target system – but since I didn’t have the sufficient resources to perform a decent large scale DoS attack, I wasn’t able to spot anything more than a minor traffic delay, but not something that I can be sure that this issue was the cause of it.
So, I had to stop my research at this point and turn to the vendor, “F5 Networks”.


First of all, I found the web page in which F5 states about its security vulnerability response policy (“sol4602: Overview of the F5 security vulnerability response policy“). Unfortunately this page did not include any public key (using PGP) or S/MIME certificate to encrypt the email exchange between me and F5 nor any SSL based web form.
So, since I wanted to report my finding securely, I sent on the 8-Feb-2015 the following email to the email address mentioned at the above web page as the one for reporting security issues – [email protected]. I signed this email with my S/MIME certificate, so F5 will have a way to securely reply to me.
1. I wrote:


I wish to report something to F5, but at there is no mention of any way to security encrypt the email sent to F5, either PGP or s/mime – do you have something in place for this goal? (s/mime is preferred)


2. The next day, 9-Feb-2015, I was replied by F5 Support Reply <[email protected]>:

Hello Eitan,

I have forwarded your request to our IT department, as I spoke with one of the security people and he does know what you are asking for, someone will be back in contact with you soon in regards to your request.


<employee-name> | Technical Support Coordinator II

3. I promptly replied on the same day:

Cool, thanks.

I will be waiting for your move.

4. As no one approached me by the 14-Feb-2015, I sent the following email to the support email address I was replied from initially:

Hello F5,

Any news on this?

5. I was replied on the same day with:

Hello, Eitan:

I spoke with our Duty Manager about your security concerns.  He followed up with our IT Security Department.  I was told that they do not have an answer at this moment, but they are working on the problem.

Meanwhile, I am leaving a note for <employee-name>, the woman with whom you communicated last week.  She will be in tomorrow, and can get in touch with the team originally tasked with this.

I apologize for the length of time it is taking to resolve this, but I assure you that we are taking measures.



F5 Networks Support |

As no one replied to me by the 21-Feb-2015 I sent the following email (which included all of the above correspondence) to Mr. Manny Rivelo, who at the time was the company’s senior vice president in charge of security (and now he is the CEO former-CEO), and I was in touch with him a few times during the time I worked at F5:

Guys, are you serious?! How long does it take?

You don’t treat security seriously.

On the same day he replied from his phone:

Eitan, I will reach out to our CIO to see what the issue is.

I replied on the same day:

Cool, it will help my will to securely hand F5 via email a possible security issue and also for others in the future.
Consider also adding a secured web form for this purpose, as a parallel and quick way to submit security issues.

In security response time is crucial.

Two days later, on the 23-Feb-2015 I was replied by M., a senior security supporter, who from now on will be my point of contact, and this was the first time I received an official support case number, to track this case:


First, apologies for the delay in responding to you.  I wasn’t involved, but I’ve been told there was some confusion with our first tier of support which caused a delay in getting this into the proper channels.

I’ll email you directly in a moment.  I don’t have S/MIME, but we do have two options for secure communication.  The first, and easiest, is <a service F5 uses. I will omit it as it is not relevant here and it is a quite long text. Eitan>

The second method we can use is PGP.  My public key is listed on MIT’s keyserver: <link>

I’ll email you directly twice – once with each method – to make things easier for you.  Then you can respond using your preferred method.

Thank you.


I replied to M. on the same day:

Hello M.,

Thank you for jumping in to save the day… 😉

Got your key and added to my keyring (btw, consider giving it an expiration date).
I don’t publish my PK on the net, but I added it here for you.

I will re-verify the issue, write my report about it and send it your way in the coming days, now that I am sure we have a secure (relatively, these days…) communication channel.

Will be in touch soon.


I sent M. the report using an encrypted email and on the 2-March-2015 he emailed me:

I received and successfully decrypted your email from Saturday.  I’ll attempt to produce the issue in our lab and I will let you know the status.
Thank you

On 8-May-2015 M. wrote to me:


We worked on this with our product development group and we’ve opened ID518020 for this issue.  We are classifying it as a Vulnerability, with a Severity of High under our policy – covered in SOL4602.  We will be fixing this in our next major release, 12.0.0, due out later this year.  We’re also planning on pulling the fix back to future Hotfix Rollups on our current supported releases.  That work is already underway.

From our testing, overall it appears that the behavior is basically similar to what we do if we get a connection that doesn’t send a complete request; we’ll eventually disconnect the client via the TCP profile timeout.  The reason these requests aren’t rejected outright is that the profile currently looks for a valid HTTP/1.0 or 1.1 request format – basically <method> <uri> HTTP1.[0|1] – but if it isn’t one of those it presumes it must be HTTP/0.9, which was much more forgiving with respect to the headers.  (HTTP/2 is experimental in the latest 11.6.0 releases, but that’s a different beast entirely.)  So the current profile errs on the side of trying to service the request and falls back to 0.9; a server which strictly enforces 1.0 or 1.1 is likely to reject them outright.

We try to process this HTTP/0.9 request and look for a response from the server, but things break down when we try to proxy the bad request.  The short version is that we send a request to a pool member, but it sees it as HTTP/1.0 and since it isn’t a complete 1.0 header it is waiting for more.  We end up sitting in the middle until our timer fires and we close the connection or one of the endpoints times out and closes it, whichever comes first.  So this all stems from trying to be too accommodating with support for HTTP/0.9 and the fix is to get stricter about what we’ll accept.

The good news is that we’ve conducted volumetric automated testing and we haven’t been able to produce any noticeable issue with the BIG-IP; it has absorbed the queries as intended.  In theory a very high number of requests, from a larger number of attacking systems, could create a DoS situation, but the behavior appears to be the same as other known DoS methods in being related to the TCP profile timeout.  Even with 65,000 simultaneous connections (using all available source ports, in other words) from one host it barely moved the needle on the BIG-IPs resource utilization, so it would need to be a DDoS type of attack from a large number of attack hosts.  The actual cost per connection to the BIG-IP is negligible, it isn’t consuming much in the way of resources.

Overall we do see a few ways we could enhance the BIG-IP’s internal filters to more strictly enforce the request format and reject this kind of exploit in general more readily, and we’re looking into what improvements can be made in future releases.   Based on our testing, this attack has about the same impact on the BIG-IP as opening the TCP connection and sending nothing, until the TCP profile closes the connection.  It isn’t as resource intensive as Slowloris for example, though that’s obviously true on the client side as well, making this attack lower cost.  We tested a number of variations with different types of malformed headers, looking for any different characteristics.

We do appreciate your bringing this to our attention as it has given us a few ideas on ways we can further improve the product.  I’ll be working with our AskF5 team to prepare a Solution article for our site, and we can coordinate the publication with your timing as well.

I hope this explanation addresses the concerns you’ve raised.  Do you have any questions I might address?

Thank you.

Following this email we had some more emails exchange regarding various possible risk and mitigations about this issue, and I was asked to supply the title I wished to be presented in the acknowledgment part of the vulnerability support post.

At the 27-May-2015 I received an email from M. that eventually they published the issue at the support site, titled “SOL16672: An improperly formatted HTTP request-line may cause connections to hang and eventually timeout“.

According to this KB this issue is affecting versions ranging from version 10.1.0 (from December 2009) until a very recent version – 11.6.0 (August 2015) (Click the “Show Version” part on the upper right side of the KB post).

To my surprise the issue was not marked as a vulnerability but as a “Known Issue”, although during my discussions with “F5 Networks” they classified it as a “High” grade vulnerability (see above), and no one updated me, before publishing the support post – that they decided to demote it from a vulnerability.
Even the “Acknowledgments” section was deviated from the normal text pattern they use for vulnerabilities posts (see here an example here)

I asked M. why, after they admitted it is a “High” grade vulnerability by their own policy – they eventually  played it down to a “Known Issue”?

He replied:


There was a lot of discussion about this internally, but in the end the developers and management decided this is not a vulnerability in BIG-IP, but a defect.  The ID was re-categorized as Defect and is being addressed as such.  Hence there will be no CVE requested and the SOL format used was the Known Issue template used for product defects.

Through the testing that was done they were never able to produce a real DoS/DDoS effect on the BIG-IP and they didn’t feel that it rose to the level to be classified as a vulnerability.  But they did feel that it was not the proper handling of these requests, so it is considered a defect to be resolved in upcoming HF releases.  It was a very involved debate, with a lot of arguments made for both sides.  In the end the ‘Defect’ arguments carried the day.

The central point was really trying to rectify the test results, wherein little impact was observed on the BIG-IP, with calling it a Vulnerability and then trying to explain the minimal impact in a SOL.  There was concern that labeling it as such would cause undue concern for customers in light of the negligible impact observed, as there is something of a strong reaction to any Vulnerability SOL independent of the content.  It was agreed however that customers should be made aware of the issue in any case, and the Known Issue SOL was expedited for that purpose.

I had initially argued to handle it as a Vulnerability, but in the end I agreed with the consensus to handle it as a Defect after all of the arguments had been presented.

I publish this post because I guess most people are not aware of this issue as it was not flagged as a vulnerability hence folks who collect and react to vulnerabilities report could not possibly know about it.

I hope that with this post more “F5 Networks” customers will be aware of this issue and patch their systems with the fixes mentioned at the KB post (or instead use the suggested mitigation steps offered there as well); and that the security researchers community will learn about this issue, thus researchers with better tools, knowledge and experience than I have – will look deeper into this issue and give this issue a “second opinion”, whether it can be exploited as a vulnerability or not.

You can find my prior Information Security advisory and all the ones before it at SecurityFocus.

How to protect yourself from the Samsung keyboard vulnerability in Android devices

A few weeks ago, on June 2015, the mobile devices security company “NowSecure”, has published a post about a vulnerability they have found, titled “Remote Code Execution as System User on Samsung Phones Summary”, discovered by its researcher, Mr. Ryan Welton.
This research was also marked using two official vulnerability identifications of CVE-2015-4640 and CVE-2015-4641.

On the above blog post the company wrote “Unfortunately, the flawed keyboard app can’t be uninstalled or disabled”.
I believe this is not fully correct as the relevant Android service of the this keyboard can be disabled if the device is rooted.

In the rest of this post I will show you how to do just that.

Following are the steps of how to work-around the vulnerabilities mentioned in the post blog of “NowSecure” – but the fact it worked for me does not necessarily means it will work for you or that it won’t harm your device and/or data.
I will have NO responsibility NOR liability for the following steps, if you will perform the following steps – it will be on your own personal responsibility and liability.

There is a workaround, which means it is not fixing the problem and the relevant software is still vulnerable, it is just that we will make sure the relevant software will not load into the device memory, so attackers will not be able to exploit this vulnerability.

The following procedure requires a root access for the device.

The concept outline is:
1. Installing another Android keyboard software
2. Making the new keyboard app the device active keyboard
3. Disabling the Samsung keyboard (including across device reboots)

This replaces the vulnerable keyboard with a (probably…) non-vulnerable keyboard and blocking the vulnerable keyboard from loading into memory, so it cannot be exploited.

First of all – make a full backup of the target Android device! And save the backup output OUTSIDE the device itself!

1. Make sure you have a root access on your Android device.
The free app of “Root Checker” may help you verify this.
If you do not have root access – the decision if and how to get root access is up to you to decide as it has many and serious implication on your device operation, maybe even its warranty – further beyond this workaround.
See the following two articles discussing the advantages and disadvantage of rooting and Android device:
a. Rooted vs. Unrooted Android: Your Best Arguments
b. To Root or Not to Root

2. Install an alternate free keyboard, like the “Google Keyboard”.
Here are some recommendations (not by me) for other alternate keyboards apps.

3. Make the non-Samsung keyboard the active system keyboard
The steps to do this may change from Android version to another, but you can get a hint in the following articles:
a. How to replace your Android or iOS keyboard
b. Type in style: How to change your Android keyboard

4. Reboot the device and make sure that the new keyboard app is the active keyboard and that it is working properly (say, do a Google search)

5. Install the free app of “Disable Service”. I installed and used it and it worked fine for me.

6. Disable the “Samsung Keyboard” app using the following steps:
a. Open the “Disable Service” app and choose the “System” tab on the right side of the app interface
b. Find the app named “Samsung Keyboard” (the actual name (partial or complete) of the app may be different as it may be written using the interface language of your phone) and choose it
(you can easily find the “Samsung Keyboard” app using the “Disable Service” app search option (the magnifier icon at the top-left side of its interface) – just type there “samsung”)
c. Un-check all the check boxes of the sub-items listed, the ones which the “Samsung Keyboard” is attached to. Once you un-check an item it will be disabled and its text color will turn from white to red.
You will probably be prompted, using a pop-up window, to grant the “Disable Service” app a root access – you HAVE to approve this request for this procedure to succeed (the pop-up window will enable you to limit this access for only 15 minutes. You can do this as well, as you suppose to complete the whole procedure within a few minutes)
d. That’s it – exit the app
e. To verify that the “Samsung Keyboard” is disabled – return to the Android keyboard selection section, as mentioned in step number 3 above and make sure that there is no item of “Samsung Keyboard” listed

In case you wish to re-enable the Samsung keyboard, use the following steps:

a. Open the “Disable Service” app and choose the “System” tab on the right side of the app interface
b. Find the app named “Samsung Keyboard” (the actual name (partial or complete) of the app may be different as it may be written using the interface language of your phone) and choose it
(you can easily find the “Samsung Keyboard” app using the “Disable Service” app search option (the magnifier icon at the top-left side of its interface) – just type there “samsung”)
c. Check/Select all the check boxes at the list you will be presented with. Once you check/select an item it will be enabled and its text color will turn from red to white.
You will probably be prompted, using a pop-up window, to grant the “Disable Service” app a root access – you HAVE to approve this request for this procedure to succeed (the pop-up window will enable you to limit this access for only 15 minutes. You can do this as well, as you suppose to complete this procedure within a few minutes)
d. Exit the app
e. To verify that the “Samsung Keyboard” is enabled – return to the Android keyboard selection section, as mentioned in step number 3 above and make sure that an item of “Samsung Keyboard” is listed there

The above procedure is meant for most folks as it easy and less prone to cause any harm – most folks should use it.

The following procedure will give the same result but it is intended for more technically experienced folks as it is more prone for possible mistakes and damage, as it is using low-level operating system commands. Use it only if are very technically knowledgeable about the low-system-levels of Android.

Perform steps 1 to 4 the same as mentioned above.
From step 5 and forward use the following steps:

5. Install a shell/terminal emulator like the free app of “Terminal Emulator for Android”, which I tested and found it to work fine and easy.

a. Open the “Terminal Emulator for Android” app and at the command line type the text “su” (without the quotes. su means “super user”, which is what we call “root” mode) and hit the “Enter” key, found on the edge of the lower-right corner of the app’s online keyboard. It looks like a thin line with large arrow-head that is pointing to the left
b. You will probably be prompted, using a pop-up window, to grant the “Terminal Emulator for Android” app a root access – you HAVE to approve this request for this procedure to succeed (the pop-up window will enable you to limit this access for only 15 minutes, you can do this as well, as you suppose to complete this procedure within a few minutes)
c. You will be returned to the command line. Notice that the sign at the right side of the line’s initials is changed from the dollar sign, “$”, to be the sign of “#”, which symbols you are now in “root” mode.

***Be very careful here as you can make real damage using the root mode***

d. Type the following line exactly, and once you completed writing it – press the “Enter” key:
pm disable

If all is fine you will be replied with a message of:
Package new state: disabled

e. Exit the app by clicking on the “X” sign on the app’s upper-right corner

To enable back the Samsung keyboard using the same app:

Do most of the same steps as mentioned above using the “Terminal Emulator for Android” app, but for step “d” change the command to be:
d. Type the following line exactly, and once you completed writing it – press the “Enter” key:
pm enable

If all is fine you will be replied with a message of:
Package new state: enabled

e. Exit the app by clicking on the “X” sign on the app’s upper-right corner


That is all. I hope this post will assist you in protecting yourselves from this vulnerability.


Eitan Caspi