Most devices connected to the Internet these days arent 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 " />
Other passwords also increased significantly. For example look at7ujMko0admin . This password doesnt 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 DVRs 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 wouldnt be used to attack other systems.
The sad part is, that I didn" />
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 isnt 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 isnt 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.
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 /bin/busybox rm /.nippon
This sends the string kami to the file /.nippon. This test is then repeated on all partitions found in mount rm /.human
I have also seen .s being used, but it looks like this attacker wasnt 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 /bin/busybox ECCHI /bin/busybox ECCHI
Finally, since neither tftpor wget worked, the attacker used the good old echo trick to build a binary:
echo -ne \x7f\x45\x4c\x46\x01\x01 ... /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 didnt 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 didnt 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 Hollisterwho 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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.