Opinions expressed are solely my own and do not express the views or opinions of my employer. Information is provided for educational purposes only.

What is vendor-exclusive DDNS?

This is the name I am using for any dynamic DNS service provided exclusively by a hardware vendor for use only by its own hardware products. This blog post will focus on a service I am familiar with, fortiddns.com, which is offered by Fortinet for use on its FortiGate firewalls. However, many others exist.

What’s the problem?

I’m not saying it can’t be used safely, but my argument is that using vendor-exclusive DDNS is a form of information disclosure and adds an additional level of risk to your network. Please consider the following example.

The Following Example

Step 1: A wild vulnerability appears!

A known vulnerability is published (or a zero-day discovered) that pertains to a particular hardware vendor. In this example, I have chosen CVE-2016–1909, which is an SSH backdoor vulnerability existing in old versions of FortiOS.

Step 2: DDNS becomes your landing crew

We now have a Fortinet-specific vulnerability, but we don’t have any FortiGates to test it on. Let’s find some. Knowing that only FortiGate firewalls can be owners of fortiddns.com subdomains, we can use a subdomain enumeration tool (aka subdomain bruteforcing) to find some potential test subjects.

Sublist3r is popular, so let’s give that a shot using the following command, where I’ve added the port flag so that sublist3r will only return the subdomains where port 22 is open.

python sublist3r.py -d fortiddns.com -p 22

Step 3: Who’s a silly admin?

360 subdomains found (more time could be spent on this step, as 360 subdomains is quite lower than my expectation), and 45 are open on port 22. Although the port for SSH access can be changed, I expect that if the admin left SSH enabled on the WAN port, and they left it on the standard port of 22, then there is a good chance they are still running the old firmware necessary for the SSH backdoor to work.

Since there are only 45, each subdomain can be manually tested with the publicly-available python script.

And with a little luck, we’re in.

TLDR (Summary)

Using vendor-exclusive DDNS increases your risk of network attack because it literally provides attackers a list of targets using that specific hardware platform. The increased risk percentage drops significantly depending on if the admin (and the vendor) follows best practices, but if the hardware is something important, why not pay the money and just use a vendor-agnostic DDNS service?