Category Archives: Tips

SSL VPN security enhancement idea – Reduce the gateway attack surface by allowing access only to pre-approved DDNS clients

Cryptography, Encryption, Decryption, Hardening and Mitigations, Thoughts and Ideas, Tips, What have I discovered?Eitan Caspi

(Hi there readers – If you know anyone who works for an SSL VPN vendor – in development, product management and so on, please send them a link to this post, hoping this idea will gain attention, acceptance, and eventually will come to life, hence enhance security for all of us)

The Hebrew version of this post can be found here.

TL;DR / Summary

This is an idea I came up with, to enhance the security of SSL VPN, by reducing the SSL VPN server attack surface, by adding Dynamic DNS (DDNS) client to the SSL VPN client endpoint, hence configuring the server side to allow only networking-pre-approved sources to even communicate with the SSL VPN server component of the gateway in the first place, based on FQDN values of the DDNS clients, hence blocking, up front, most of the internet from even communicating with the SSL VPN server, hence greatly reducing its attack surface.

Thinking about it further – the above principle is good for any server element who needs to accept incoming traffic non-fixed source IP(s) – be it a web server, an SSH server and so on

I tried so find solutions that use the above principle, but I didn’t find any.

From what I have found – all uses of a DDNS client are for the benefit of systems that operate in as a server, meaning they listen for client-initiated incoming traffic, in order to provide service to clients, so that clients can find them and reach them, even if the IP address of these systems changes.

There are security gateway products who support using FQDN as an object in their Firewall rules, which means the above idea can be technically realized already now, but I think it will be hard to manage it all this way, and it will not scale. I think this needs a more systematic solution, to also handle the client side and DDNS server side, so I think vendors should incorporate it as part of their relevant products and services, to be able to be managed properly by customers.


Background

I noticed that in the recent time there are many incidents in which SSL VPN components of security gateways are breached successfully, due to various reasons, mostly due to software vulnerabilities of the gateway’s software.

Vulnerabilities are inevitable, it will always happen, as we cannot guarantee bulletproof, 100 percent secure, software.

Also, SSL VPN, as a concept, is mostly used to grant secure access from the Internet in to local, private, internal networks, so it has to be open to the whole (or most) of the internet, as the organization cannot know in advance from which source IP addresses the clients will initiate communicate to the gateway, and as also some of the client endpoints change their source  IP from time to time, for various reasons (Their ISP changed their allocated IP, they travel in train and change cellular networks when they cross to another country, and so on).

So, I thought, we have here an enormous attack surface at the gateway side, constantly open to all of the Internet, so no wonder it is successfully breached so much.
I though to myself: There should be a better, more secure, way to do it.

Here are several news articles about mostly recent SSL VPN vulnerabilities and breaches (sorted from newest to older):

2025, August
Fortinet SSL VPNs Hit by Global Brute-Force Wave Before Attackers Shift to FortiManager
https://thehackernews.com/2025/08/fortinet-ssl-vpns-hit-by-global-brute.html

2025, August
SonicWall Investigating Potential SSL VPN Zero-Day After 20+ Targeted Attacks Reported
https://thehackernews.com/2025/08/sonicwall-investigating-potential-ssl.html

2025, April
Ivanti has recently patched a critical severity vulnerability found in its Connect Secure (ICS) VPN appliances which was allegedly being abused in the wild by Chinese state-sponsored actors
https://www.techradar.com/pro/security/ivanti-patches-serious-connect-secure-flaw

2025, March
VPN Vulnerabilities Become a Primary Weapon for Threat Actors Targeting Organizations
https://gbhackers.com/vpn-vulnerabilities-become-a-primary-weapon/

2025, January
Ivanti Connect Secure VPN Targeted in New Zero-Day Exploitation
https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day

2024, February
Exploitation Observed: Ivanti Connect Secure — CVE-2023-46805 and CVE-2024-21887
https://www.akamai.com/blog/security-research/ivanti-january-rce-cve-zero-day-exploitation-observed

2023, July
Researchers Develop Exploit Code for Critical Fortinet VPN Bug
Some 340,000 FortiGate SSL VPN appliances remain exposed to the threat more than three weeks after Fortinet released firmware updates to address the issue
https://www.darkreading.com/vulnerabilities-threats/researchers-develop-exploit-code-for-critical-fortinet-bug

2022, December
Fortinet Warns of Active Exploitation of New SSL-VPN Pre-auth RCE Vulnerability
https://thehackernews.com/2022/12/fortinet-warns-of-active-exploitation.html


The suggested solution (High level)

The core concept for using DDNS is that if we wish to grant secure access to clients that we cannot know in advance what is their source IP and even if we know it at some point – it can change at any time, because it is not a fixed VPN connection, with fixed client IP, so we use the DDNS system to have a trusted fixation layer (made of the FQDN’s domain and DDNS server), which we trust to authenticate the client device – hence we are willing to allow the first networking level access to an unknown-in-advance client IPs, but ones that have a preliminary required software (the DDNS client) and was authenticated (even if just a device was verified, not a human) at a system we trust (The DDNS server system).

The idea is to limit who has access to the SSL VPN server side, based on the following high-level concept:

  • SSL VPN Client side
    • The clients who wish to access and use the SSL VPN server – will have, as part of their SSL VPN client software (and possibly as part of their EDR client software), a Dynamic DNS (DDNS) client component
    • The DDNS client will communicate securely with its DDNS server (I guess over HTTPS), authenticate to it, and send to the DDNS server its client identity and public IP address (which the DDNS server can also fetch by itself, from the network session). This should be done every time the public IP of the client changes, to verify the DDNS server and the gateway always get the current IP of the client
      • The DDNS client software must of course be secured – The client’s DDNS server credentials should be encrypted locally; communication to the DDNS server needs to be encrypted and authenticated, DNS queries better be encrypted using DoH (DNS over HTTPS); protected from tampering and so on

 

  • SSL VPN server side (the organizational security gateway)
    • The gateway will, constantly and ad-hoc when needed, run reverse (PTR) DNS queries against the same DDNS server/system as the SSL VPN client use, to fetch the current IP addresses of relevant SSL VPN clients
    • The gateway will have a firewall rule, related to the SSL VPN activity, who allows access to it from the internet, based not on numeric source IPs, but rather on FQDN names that the DDNS server controls and manages, the ones attached to its clients (desired with wildcard support, for better configuration flexibility)
      • For example, the Firewall rule’s allowed source object will be *.vpn-allowed.firm.com, and any IP that is resolved to matching FQDN, will be allowed (e.g., johndoe.vpn.firm.com or serioussam.vpn.firm.com)

 

  • Session
    • The client will initiate an https-based SSL VPN session to the gateway
    • The gateway will receive the first packet of the TCP handshake session (with the SYN flag) and will check the value of the incoming source IP, based on the above SSL VPN access firewall rule
    • This source IP will be evaluated (best using a DNS PTR resolving (hence IP to FQDN) against the DDNS server or, less desired, as its data may not be up-to-date, locally against a pre-fetched cache)
      • Timeouts and invalidation of non-active DDNS client’s is highly desired, to prevent granting access to unauthorized clients who accepted the original IP if the real client is not using that IP anymore, for any reason
    • If there is a match – the client will be allowed to continue with the session – to complete the TCP handshake, set the TLS session, authenticate and then establish the SSL VPN connection
    • If there is no match – the firewall rule evaluation process will continue to the rest of the firewall’s rules, ideally eventually reaching the last rule, the cleanup / deny-all rule, which will drop the communication, hence blocking any further communication from the client side to the SSL VPN server, which actually means blocking any source IP that does not currently has a currently active allowed DDNS client ID, which is probably most of the Internet, which means most of the opportunistic attackers

 

Added possible points:

  • The DDNS server system
    • I think it is desired not to use a DDNS server system that is part of the gateway, the SSL VPN server device – as it is exposing the device to the whole Internet using an extra web/DNS server interface, which is against what we try to achieve here in the first place
    • Also, I think it is less desired to use 3rd party DDNS system/service, unless it is a very secure one
    • Ideally the DDNS system will be a cloud service by the same vendor of the security gateway’s vendor, to hopefully achieve more compatibility, interoperability, and security
  • Of course, this concept adds to the current way of things – more complexity, management, and the need for hardening, but I think the added security worth it

Zero trust features that can be added as well:

  • Applying IP reputation – to either block access up front, or instead adding more security checks or limitations to the session
  • Dropping the session if the public IP of the client changed during an active session, forcing the client to start a new session from the beginning
  • Blocking clients if their public IP is changing too fast/often or their public IP is not reported within a timely manner (if there is a technical demand from the DDNS logic for recuring scheduled updates from the DDNS client to its server)
  • Checking local settings like if the client is set as router (IP Forwarding), the use of a proxy, the use of another VPN in parallel, and so on (although this slides more towards an EDR functionality)

That’s all, folks. I hope you liked it, and if you did – please spread the word, and the link to this post, to relevant people who can bring this concept to life.

Allegory for Information Security

Employees Awareness, Idioms, Allegories, The Information Security Profession, Thoughts and Ideas, TipsEitan Caspi

Allegory is a powerful tool to explain a complex topic or summarize it, so many times I  explain that Information Security should be like the atmosphere – it should be transparent (not felt, not bothering), it should prevent bad things (asteroids = malware/other attacks) from coming in, and prevent good things (like oxygen = sensitive/confidential data) from getting out.

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.