Compromised SSH Host Special Report

Description

The Shadowserver Foundation released a Compromised SSH Host Special Report on the 29th Jan 2024, in respect of the jurisdiction. The report contains information of hosts running SSH services that are known to be compromised. The public malicious SSH keys installed, are known and they facilitate remote access.

The Shadowserver Foundation state in their documentation that the information contained in the special report is based upon data obtained through collaboration with an external third party.

The Default Security Level of the Report is: 'Critical'

Problem

The report identified hosts, within the jurisdiction, that are running SSH services that are known to be compromised. The public malicious SSH keys installed, are known and they facilitate remote access.

An Attacker collects SSH keys for the following resons:

SSH Keys
No. Description
1. SSH keys provide a long-term backdoor allowing an attacker to gain access to the operating system of a network. Once accessed, it is highly probable that an attacker will find one or more private keys from the initial breached server which can then be used to login to other servers allowing the attacker to expand his foothold, moving from one server to another across the entire network, enabling him to reach his primary target which may include disaster recovery data centers and backup data centers.
2. SSH keys may grant access to privileged accounts such as 'root' and 'administrator'. An attacker with access to these accounts with their elevated privileges can move from one server to another across the entire network, to compromise network software, install malware or exfiltrate data.
3. SSH keys often grant access to financial data held in public companies such as credit card details together with their payments.

In November 2014, Sony Pictures Entertainment was hacked by a group calling themselves the Guardians of Peace. The hackers claim to have exfiltrated over 100 terabytes of data from Sony Pictures Entertainment, a claim never confirmed. The group released over 217MB of compressed archives, they claimed, contain data from Sony. Those that were able to access the data reported that dozens of SSH private keys were included in the reported exfiltrated data.


Recommendations

Hosts identified in the report, for running SSH services that are known to be compromised, are advised to implement the following recommendations.

Recommendations
No. Action Description
1. Disable Root User Login. Disable root user logins, instead created root privilege users accounts. These are easier to track and audit. An SSH root access or superuser access is considered to be extremely dangerous because it allows full access to and control over the entire system. Turning off server access for the root user is a defense strategy that prevents attackers from achieving their goal of intruding into the system.
2. Disable Default SSH Port. Disable the default SSH Port and change it to a non-standard port number. The main advantage of switching to a non-standard port number is to limit brute force attacks and port scanner access to the server. The default SSH port is 22/TCP.
3. Disable X11/TCP port forwarding. Disable X11 and TCP port forwarding. X11 refers to the 11th edition of the X Window System. The X Window System is a windowing system for bitmap displays, common on Unix-like operating systems. X11 was an open source graphics protocol first released in September 1987. It provides a basic framework for creating custom GUIs that can display graphics on both local and remote display devices. X11 support multiple forms of communication between client and a server. X11 forwarding, enables users to run graphical applications on a remote server and interact with them using their local display and I/O devices. In X11 Forwarding, the client to server connection gets tunneled through an SSH Channel.
4. Block Access for Users With Blank Passwords. Block users with blank passwords, preventing them from gaining access to the network.
5. Restrict SSH logins to specific IP Addresses & Hosts. Restrict SSH logins to specific IP Addresses and hosts. Publicly known IP Addresses & host are liable to brute force and dictionary attacks.
6. Impliment SSH Public Authentication. Public key authentication improves security by providing cryptographic strength that even long complicated passwords can not offer. Users do not have to remember or commit complicated passwords to paper. It also allows for the implementation of single sign-on to SSH servers. Public SSH key authentication allows for the automated, passwordless login that is a key enabler for the secure automation processes that execute within enterprise networks worldwide.
7. SSH Key Management Policy. SSH keys provide the same access to a network as user names and passwords. The number of SSH keys in circulation have grown exponential since the system was first introduced in 1995 leading to keys being stolen, misused or used as part of an attack. A SSH Key Management system for the validatation, replacement and the updating of authorised list of users must be implemented, the automation of such a system may help to eliminate mistakes due to human error. Constituents are advised to try and prevent the proliferation of SSH keys, where possible, in their respective organisation.
8. Public SSH keys can leak information. Public SSH keys can leak information in relation of a private infrastructure. Constituents are advised to read the following article which describes a minor security flaw in the SSH authentication protocol that can lead to the disclosure of information in relation to private infrastructures. See attached link:- Public SSH keys can leak your private infrastructure
9. Replace SSH Keys known to be Compromised. Constituents are advised to replace SSH Keys that are reported, or are known to be compromised, with immediate effect. In the event of a reported compromised SSH Key, constituents are advised to initiate a thorough search of their servers and network in case an undetected breach of their network occured during period the compromised SSH key was in use, after which, monitoring of the network should be maintained, for signs or indications of unusual or suspicious activity.

The Secure Shell (SSH)

The Secure Shell Protocol was developed in July 1995 in response to a hacking incident in the Finnish University Network. SSH provides secure login, file transfer, X11, and TCP/IP connections over an untrusted network. It uses cryptographic authentication, automatic session encryption, and integrity protection for transferred data. RSA is used for key exchange and authentication, and symmetric algorithms (e.g., IDEA or three-key triple-DES) for encrypting transferred data.

SSH is intended as a replacement for the existing rsh, rlogin, rcp, rdist, and telnet protocols. SSH is currently (March 1996) being used at thousands of sites in at least 50 countries. Its users include top universities, research laboratories, many major corporations, and numerous smaller companies and individuals.

The SSH protocol can also be used as a generic transport layer encryption mechanism, providing both host authentication and user authentication, together with privacy and integrity protection.


Additional Information

Compromised SSH Host Special Report.
The Mitre Corporation - CVE-2016-20012.
Public SSH keys can leak your private infrastructure.
RFC4252 - The Secure Shell (SSH) Authentication Protocol.
RFC4253 - The Secure Shell (SSH) Transport Layer Protocol.
SSH.Com - What is SSH(Secure Shell).
SSH - Secure Login Connections over the Internet.
Makeuseof - 13 Ways to Secure SSH Server Connections on Linux.
SSH.com - Malware & Hackers Collect SSH Keys to Spread Attack.
TechRepublic - 5 tips for securing SSH on your Linux servers.
Venafi - Attack on Trust Threat Bulletin: APT Operators Exploit Heartbleed.
CSIRT-IE: Special Reports released by the Shadowserver Foundation

CSIRT-IE: Special Reports released by the Shadowserver Foundation

Objective

CSIRT-IE primary focus, in regard to the following Special Reports released by the Shadowserver Foundation, is to inform responsible network operators and constituents,  based upon the IP address of the host(s) identified in the reports, for the reason stated in the reports, by email and to provide advice and recommendations on how to mitigate the reported vulnerabilities or possible malicious activity for which the reports were released.  The Special Reports, while having a timestamp for a given date & time, do not cover a specific daily twenty four (24) hour time period,  instead they are based upon a high value dataset.

Source of Information

The Shadowserver Foundation is a Non-Governmental Organisation and one of the world's leading resources for internet security reporting and malicious activity investigation.  The Shadowserver Foundation works with national governments, network providers, enterprises, financial and academic institutions, law enforcement agencies, and others, to reveal security vulnerabilities, expose malicious activity and help remediate victims.  The Shadowserver Foundation performs a scan of the entire IPv4 address range every day for Internet accessible servers & services and reports the security vulnerabilities found.  In 2022,  Shadowserver began to systematically rolling out IPv6 scanning of services.   Information on Shadowserver Reports and the data contain therein can be found at the follow link:- Shadowserver Reports

Event Severity Levels

On the 12th Oct 2023, the Shadowserver Foundation introduced a new system of categorising events in their reports called Event Severity Levels, making it possible for recipients of their reports to filter events based upon the severity of the actual event reported.  The Shadowserver Foundation have also commenced applying a default severity level to their reports.

Event Severity Levels
No. Level Description
1. Critical. Highly critical vulnerabilities that are being actively exploited, where failure to remediate poses a very high likelihood of compromise.   For example, a pre-authorisation Remote Code Execution (RCE) or modification or leakage of sensitive data.
2. High. End of life systems, systems that you can log into with authentication that are meant to be internal (SMB, RDP), some data can be leaked.   Sinkhole events end up in this category.
3. Medium. Risk that does not pose an immediate threat to the system but can over time escalate to a higher severity.  For example, risk of participating in DDoS, unencrypted services requiring login, vulnerabilities requiring visibility into network traffic (Man-in-the-Middle (MITM) attack without being able to manipulate the traffic) to exploit, an attacker will need to know internal systems/infrastructure in order to exploit it.
4. Low. Deviation from best practice - little to no practical way to exploit, but setup is not ideal.  Vulnerabilities requiring MITM (including manipulating the traffic) to exploit.
5. Info. Informational only.  Typically no concerns.   However, this category includes the Device Identification report, which may include information on device types that should not be accessible on the public Internet, in which case the individual events in the report may be assigned higher severity levels.  Review in accordance with the organisation security policy.

Secure Information Sharing Sensor Delivery Event Network

The Secure Information Sharing Sensor Delivery Event Network  seeks to improve the cyber security posture of EU organisations and citizens through the development of increased situational awareness and the effective sharing of actionable information.

Special Reports released by the Shadowserver Foundation

Additional Information

CVE Beta website