in , , , , , , , , , ,

Usage of TLS in DDNS Services leads to Information Disclosure in Multiple Vendors

Usage of TLS in DDNS Services leads to Information Disclosure in Multiple Vendors

The use of Dynamic DNS (DDNS) services embedded in appliances can potentially expose data and devices to attacks.

The use of Dynamic DNS (DDNS) services embedded in appliances, such as those provided by vendors like Fortinet or QNAP, carries cybersecurity implications. It increases the discoverability of customer devices by attackers.

Advisory on security impacts related to the use of TLS in proprietary vendor Dynamic DNS (DDNS) services.

The use of Dynamic DNS (DDNS[1]) services embedded in appliances, such as those provided by vendors like Fortinet or QNAP, carries cybersecurity implications. It increases the discoverability of customer devices by attackers.

Imagine a perfect world for an attacker, where they can precisely identify devices belonging to customers of a specific vendor, all using a product potentially riddled with known vulnerabilities or zero-day exploits.

In this advisory, I aim to explore how implementing a specific security technological combination (TLS and DDNS) negatively influences the overall security, inadvertently creating opportunities for attackers to exploit weaknesses on a massive scale.

Securing Internet communications is crucial for maintaining the confidentiality and integrity of information in transit. This is typically achieved through a combination of Public Key Infrastructure (using X.509[2] certificates) and encrypted, authenticated connections (TLS[3] and its precursor, SSL[4]).

Certificate Transparency (CT)[5] is a mechanism designed to ensure transparency in the issuance of certificates, with the main aim of spotting rogue Certification Authorities (CAs) and the issuance of fraudulent certificates[6]. The Certificate Transparency Log is a public and immutable record of all issued certificates.

The process of the Certificate Transparency Registry can be summarized in the following steps:

  1. Request for SSL Certificate: A website requests an SSL certificate from a Certification Authority (CA).
  2. Issuance of SSL Certificate: The CA issues an SSL certificate.
  3. Logging in Certificate Transparency Log: The issued certificate is recorded in the Certificate Transparency Log along with other relevant information, such as domain name, date and time of issuance, and other details.

Although the Certificate Transparency Log is designed to improve security and transparency, its public nature leads to known Information Disclosure risks. Attackers abuse the Certificate Transparency Log to identify subdomains (FQDNs) in order to map a target’s attack surface and, consequently, exploit vulnerabilities[7].

Dynamic Domain Name System (also known as Dynamic DNS or DDNS) is a technology that allows users to link a Fully Qualified Domain Name (FQDN) with an IP address that may change over time.

This system consists of two main components: a DDNS client installed on the device that needs to be accessible and a DDNS server managed by a service provider.

Although this type of technology is not recommended for use in SMB (Small and Medium Business) or Enterprise environments (spoiler: it often is), it is highly popular in SOHO (Small Office/Home Office) settings. In fact, an increasing number of vendors are now integrating this service into their appliances to meet this demand.

The combined use of these two technologies – requiring a certificate for an FQDN associated with a DDNS domain owned by a specific vendor – can lead to widespread exploitation of vulnerabilities.

For instance, suppose firewall manufacturer ACME Inc. offers its DDNS service under the domain “acme-firewall.com”.

If a vulnerability were discovered in this firewall, a malicious user could abuse the Certificate Transparency Log to identify vulnerable targets by querying all subdomains of “acme-firewall.com”. This would allow them to massively compromise thousands of exposed devices.

Fortinet

Fortinet has introduced the “FortiGuard DDNS” service in its FortiGate firewall products. While this service facilitates the setup of VPN systems in the absence of a static IP, it inadvertently encourages the exposure of the appliance’s administrative interface to the Internet.

This DDNS service uses three Fortinet-owned domains: fortiddns.comfortidyndns.com, and float-zone.com. It also integrates an ACME client for automatic certificate generation via Let’s Encrypt[8].

By querying a Certificate Transparency Log service[9] for the fortiddns.com domain, an attacker can uncover over 2300 potential targets that have recently been issued TLS certificates for fortiddns.com (filtering for certificates that have not yet expired). The service used for this sample truncated the results due to an excessive number of matching entries, indicating that there are actually many more potential targets.

However, Shodan[10] indexed up to 7968 targets for the same domain. Almost all of these hosts were indexed using the “Common Name” field of the SSL certificate.

QNAP

QNAP offers the “myQNAPcloud” service to simplify remote access to its NAS products.

However, this service inadvertently encourages the exposure of these appliances to the Internet by using the proprietary DDNS myqnapcloud.com.

The Certificate Transparency Registry service reveals over 4400 potential targets, with search results truncated due to the large number of entries.

Shodan returns 39027 targets, all indexed through the “Common Name” field of the certificate.

Mikrotik

The router and switch manufacturer Mikrotik also offers a DDNS service on the sn.mynetname.net and integrates an ACME client into their appliances. The subdomain generated by this service consists of the appliance’s serial number (which corresponds to the MAC address of the first network interface), for example: serialnumber.sn.mynetname.net.

The Certificate Transparency Log service reveals over 1300 potential targets, with the search results truncated due to the high number of entries.

Shodan, on the other hand, returns 3885 targets indexed by the Common Name field.

While the easy availability (in some cases a checkbox) of DDNS in technological appliances does not automatically expose administrative interfaces and services to the Internet, it does encourage this practice. When combined with an ACME client that automatically generates an X.509 certificate for the DDNS domain, it inherently creates an information disclosure risk.

Therefore, it is crucial for manufacturers to clearly communicate these potential security hazards to users, emphasizing the importance of cautious configuration.

References and additional info are included in the original analysis available here:

https://www.ush.it/2024/05/23/tls-ddns-multiple-vendor-information-disclosure/

About the author: Pasquale ‘sid’ Fiorillo: Senior Security Researcher | CEH



What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

Visual keyboard tool Keyviz v2.0.0-Alpha2 update

Analysis of Solana's SVM Infinite Loop Instruction Consumption Vulnerability