SSH Threat Advisory: GoScanSSH

Executive Summary

GoScanSSH, a new strain of malware that has been targeting Linux-based SSH servers exposed to the Internet since June 2017. The malware attempts to obtain a valid SSH credential through a wordlist attack and attempts to infect the host. Upon successful login new malware is delivered infecting the host and the process is repeated.

“GoScanSSH is another example of bad actors looking to exploit SSH keys which provide the keys to the kingdom, said Andrew Hammond, VP of Business Development, customers need to proactively manage important credentials like SSH keys with a policy framework that rotates crypto and sets time expiration.”

Threat Summary for GoScanSSH

This advisory is based on research and written reports from Edmund Brumaghin, Andrew Williams, and Alain Zidouemba of Cisco’s Tallos Intelligence Group. Brumaghin, Williams, and Zidouemba performed unique and important research on this topic. SSH is highlighting their research as we feel this is potentially a serious threat vector which the community should be aware of. Please refer to their blog of March 26th: “Discovered by Forgot About Default Accounts? No Worries, GoScanSSH Didn’t” https://blog.talosintelligence.com/2018/03/goscanssh-analysis.html

GoScanSSH Specifics

• targeting Linux-based SSH servers exposed to the internet

• active since June 2017

• has at least 250 domains

• targets the following usernames to attempt to authenticate to SSH servers:

  • admin

  • guest

  • oracle

  • osmc pi

  • root

  • test

  • ubnt

  • ubuntu

  • user

• determines how powerful the infected system is and obtains a unique identifier

• attempts to obtain valid SSH credential through wordlist attack

• upon successful login new malware is delivered infecting the host and process is repeated

• results are sent to a C2 server accessed via the Tor2Web proxy

• avoids military or government systems

• researchers intend to continue monitoring and tracking the attack and have provided blacklists, IOCs, and domains associated with the malware

Remediation

Specifically, SSH recommends the following best practices:

1. Define a controlled provisioning and termination process for SSH keys

2. Discover existing legacy keys

3. Monitor key usage and eliminating the 90% of keys that are never used

4. Eliminating policy-violating keys, such as access from DEV/TEST to production or access from personal accounts to service accounts

5. Utilize monitoring, controlling and auditing of encrypted privileged access and data transfers

SSH recommends customers read the research blog of March 26th from Edmund Brumaghin, Andrew Williams, and Alain Zidouemba of Cisco’s Tallos Intelligence Group: “Discovered by Forgot About Default Accounts? No Worries, GoScanSSH Didn’t” https://blog.talosintelligence.com/2018/03/goscanssh-analysis.html

SSH Background and Macro Threats

The SSH protocol is the de facto standard for remote system administration and secure file transfers. One of the features behind the adoption of the protocol is the strong authentication using SSH Keys.

SSH keys provide the same access as user names and passwords. They often grant access to privileged accounts on the operating system level, giving a command line. SSH keys have been overlooked in identity and access management planning, implementation, and audits. Users have been able to create and install keys without oversight and controls. These keys are like passwords and grant access to resources - production servers, databases, routers, firewalls, disaster recovery systems, financial data, payment systems, intellectual property, and patient information. This has led to violations of corporate access policies and dangerous backdoors. Most large organizations have accumulated large numbers of SSH keys in their environment.

Organizations are finding enterprise wide deployment issues in Secure Shell (SSH) authentication management, which has suffered from lack of governance for years. Many organizations report:

• Large numbers of SSH keys - even several million - and their use is underestimated

• Have no provisioning and termination processes in place for key based access

• Have no records of who provisioned each key and for what purpose

• Allow their system administrators to self-provision permanent key-based access - without policies, processes, or oversight.

Figure 1: External and Unauthorized SSH Access to Root as determined by SSH Risk Assessment

Case Study: Large Multinational Bank

They had five million daily logins using SSH, most of them using SSH keys for automation. We analyzed 500 business applications, 15,000 servers, and found three million SSH keys that granted access to live production servers.

• Of those, 90% were no longer used.

• Root access was granted by 10% of the keys.

• A compromise of a root account allows the attacker to modify the operating system, steal or subvert any data, or install malicious software on the system.

Business Risk Factors

• Business continuity

• Reputation loss

• Risk of major financial losses

• Criminal and civil liability for CEO&CFO under Sarbanes-Oxley

• No control of who can access what

• Hackers and malware utilizing SSH

• Backdoors into intranet

• Data leaks under encryption

Remediation Specifics

NIST IR 7966 is a good starting point for understanding how to manage access using SSH. SSH Communications Security also have our own guidelines that build on the NIST guidance. We wrote most of the NIST guidelines, together with the NIST staff, and have the best subject matter experts in the field. SSH Communications recommends utilization of our onsite workshop including the he SSH Risk Assessment. SSH Risk Assessment is a security assessment service that delivers a detailed analysis of how SSH (Secure Shell) is deployed and used in your network and provides an estimate of your SSH key management problem. Long term, SSH Communications recommends a best practice that discovers, monitors, remediates, and manages SSH keys for interactive and automated connections both in on premise and cloud-based environments.