SSH Security Notification Tool

We are researchers from the Security, Usability, Society (SECUSO) research group at the Karlsruhe Institute of Technology and the Security in Telecommunications (SecT) department at the Technical University of Berlin. Both groups conduct research in the field of IT security and are cooperating on the topic of vulnerability notification as part of this study.

If you have any further questions or complaints, please do not hesitate to contact us. You will find our contact details below in the FAQ question "Further questions?".

We looked for a technical contact in the legal notice of your website or wrote to you because you are named in the legal notice as the person responsible for the content. However, you are welcome to forward our message to the person who takes care of your IT infrastructure.

The SECUSO research group conducts research in human factors in IT security, including the topic of vulnerability notifications. The SecT group conducts research into the detection of web, network and software vulnerabilities.

Together, we want to find out how we can effectively inform those affected about vulnerabilities.

No. Our test tool is designed to help you identify and remediate misconfigurations yourself. If you have any further questions, please do not hesitate to contact us. You can find our contact details below in the FAQ question "Further questions?". However, we cannot offer you IT support.

Our aim is to find out how we can best inform those affected about vulnerabilities.

Depending on which scenarios your domain falls into, you can take the following measures:

1) Update the SSHFP entries so that they match the HostKey fingerprints of the servers. Generate new SSHFP entries using "ssh-keyscan -D <hostname>" and set these with your DNS provider.

2) If DNSSEC is not active for your domain, you can activate it with your DNS provider. Some DNS providers have provided information on this on their websites (e.g. INWX, Namecheap, United Domains, or Strato).

The old DNS entries can be cached in the DNS system for up to 24 hours, so the self-test tool cannot check this change immediately. The duration depends, among other things, on the configured TTL (time-to-live) of the DNS entries.

In such a case, you must wait until the new entries have been propagated by the DNS system (usually 1 hour). You can then use the self-test tool to check your domain again.

For this study, the focus was on the notification of German-language websites.

To do this, we first collected domains with a German top-level domain (".de") from various public sources. We were able to identify a total of 8.3 M actively used German domains. Including the associated subdomains, this resulted in a data set of over 27.5 M domains.

Each domain was then examined for the presence and correct configuration of SSHFP according to the methodology of Neef et. al..

If you were notified by us, your domain was in one of the initial data sets and was classified as incorrectly configured by the analysis.

As described in the publication by Neef et. al., the domains were checked for the existence and correct configuration of SSHFP and the use of DNSSEC.

The first step was to check whether SSHFP entries exist in the DNS for a domain. These entries were then checked for syntactical correctness. In the next step, the IPv4 addresses for the domain were determined and these servers were checked for an open port 22 (SSH). The HostKey fingerprints were determined for all SSH servers. Now it was possible to check whether the server-side HostKey fingerprints matched the fingerprints from the SSHFP entries.

Finally, an SSHFP DNS query with active DNSSEC validation was performed again for each domain for which this comparison was carried out in order to determine whether DNSSEC is being used.

We have notified you because your domain falls into these scenarios:

1) The SSHFP entries do not match the server-side HostKey fingerprints.

2) The SSHFP entries are transmitted unsecured without DNSSEC protection.

SSH stands for "Secure Shell" and is a popular protocol for establishing secure connections for the administration of a remote computer system. For example, the OpenSSH server and OpenSSH client are very well-known implementations of the protocol.

To ensure that a user connects to the correct system, the fingerprints of the HostKeys are compared each time a connection is established. When connecting to a new system for the first time, the user must confirm in a dialog whether the HostKey from the server is correct.

With SSHFP DNS records, this confirmation process can be simplified by the OpenSSH client checking the correctness of the fingerprints automatically without user interaction. However, this requires that the SSHFP entries in the DNS are transmitted protected against manipulation, e.g. via DNSSEC.

DNS (Domain Name System) was originally designed as a plain text protocol without security guarantees. DNSSEC was created as an extension to the DNS standard. With the help of cryptography (PKI, signatures), the authenticity of DNS entries is to be guaranteed.

Security-related DNS record types, which include SSHFP, require forgery-free transmission. If the entries are transmitted without DNSSEC protection, attackers could manipulate the SSHFP entries transmitted in plain text.

If the HostKey fingerprints from the SSHFP DNS entries do not match the actual fingerprints of the system, no automated validation can be carried out by the SSH program or the automated validation fails. In the case of OpenSSH, the user is prompted to manually verify the HostKey fingerprint. To perform this verification, the user must first receive the valid server-side HostKey fingerprints from the administrator. The user must then ensure that the two random character strings match without error. Human error can occur here, meaning that a potentially manipulated HostKey fingerprint could be accepted.

The vulnerability is primarily a misconfiguration. It has no immediate and direct impact on the security of your infrastructure. However, this misconfiguration favors attacks against people who log in to your systems via SSH. In the worst case, this can lead to an attacker gaining access to your SSH credentials.

If HostKey fingerprints are not automatically checked and incorrectly verified by the user, a network-based attacker could use a manipulated connection and a manipulated HostKey fingerprint to trick the user into connecting to an attacker-controlled system. Depending on the authentication method, the SSH credentials could be passed to the attacker.

In the event that the SSHFP records match but are not transmitted DNSSEC-secured, a network-based attacker can manipulate the SSHFP records and the transmitted IP address of the server at the DNS level.

As we understand it (i.e. without legal examination or advice), there are no legal consequences to be expected. The vulnerability described is a misconfiguration in your infrastructure that can facilitate an attack. This means that without a targeted attack against people who administer the server via SSH, there is no data leak that would require a report to the data protection authorities. However, we cannot make any legally binding statements without a legal examination. If in doubt, please contact your legal department or other relevant entities.

To protect our own and third-party systems, some restrictions have been implemented in the self-test tool. For example, you may only check the domains that we included in the notification email. Additionally, certain IP ranges cannot be checked and we have implemented a rate limit of 360/tests per hour. You should not notice these restrictions during normal use of the self-test tool. However, if you notice incorrect behavior or are unable to use the tool as described, please contact us.

If you have any further questions, please do not hesitate to contact us. The best way to contact us is by email to:
- for technical questions: neef@sect.tu-berlin.de or +493031477151
- for methodological questions: anne.hennig@kit.edu or +49 721 608-46038