This book was originally written

for the first version of Kali and

was ready to be released last
month. But as the new Kali 2.0
was released I held the book
back and completely updated
the entire book from beginning
to end to cover the new OS and
any tool changes. So in essence
as it took about a year and a half
to write this book, all the
information in it has been
updated as of this month!
If you are still using the original
Kali, not a problem the tools
work the same in both versions,
though I do recommend
updating to the new Kali 2.0 as it
has a much better interface and menu system. If you are still using
Backtrack, please update to Kali 2 you will thank yourself!
Kind Regards,

Dan W. Dieterle and Hack Insight Team

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

Chapter 34
The Internet of Things

Online enabled devices or the Internet of Things as it is now being called is all the rage. Take that fancy
hardware gizmo, add an embedded web server and you can view and control it from anywhere in the
world What a great idea! But sadly with the mad rush to make things more user friendly and
convenient, security is being put aside, even in devices that are being used to protect important
facilities.
Physical security devices are used to help secure important buildings, rooms, data or material. These
hardware devices along with security personnel help defend a company from thieves & trespassers.
They also protect employees, equipment and data.
These items include:

Motion detectors
Window & door alarms
Smoke & fire detectors
Security cameras
Electronic locks

With the convenience of the internet and mobile devices, it just makes sense to give these devices an
online interface so that they can be more easily monitored by reduced security staff, small business
owners that are out of the office or home owners that are away on vacation.
But what if these devices themselves were not secure? Worse, what if these devices themselves were a
security threat to your network? That is a good question, and there seems to be no good answer. Here
are a few thoughts:
1. The manufacturers dont know how to secure the system.
2. Security is not a priority to the manufacturer.
3. They dont have the staff to keep up on security issues.
Or even more concerning,
4. The manufacturers might be doing it on purpose!
I recently ran into a very feature rich DVR security camera system that a small to medium size business
would use. And as a bonus it was internet enabled so it could be monitored from anywhere or from any

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

smart device. Just having this thing at your facility gave you the warm fuzzies. But with a little research I
found that the device wasnt secure at all.
The device was being run on a Local Area Network (LAN), but the manufacturer recommended that the
device be allowed outside your firewall so it could be monitored from anywhere via smart devices. And
why not, it had all the surface hallmarks of security. Layers of passwords were needed to access the
device, and you could even set up account access allowing some users guest viewing privileges and
various levels of configuration access to manager or admin level employees.
This item seemed very secure, and why wouldnt it be? It was a physical security device; it must also
have very strong online protection. But a quick security test of the device (took about 15 minutes)
painted a totally different picture. This chapter will be more of a read through than a step-by-step
tutorial. Also, as this device is still being sold to the public, and I am not sure if they fixed the issues yet, I
will not reveal the brand name and its digital identity will be altered.

Basic Security Test

To test the video system, I first ran a standard nmap probe against the device and found that it had
several open ports. A couple regular ports and several high level ports were open. This made sense as it
would need some open ports to be able to be monitored and configured over the web. But the large
number of open ports just didnt seem right:

I then ran a more in-depth nmap scan to determine what software and version numbers were running
on the open ports:
nmap -v -A 192.168.1.130
From the returns, I could see that the device was running some pretty standard services. I picked the
Telnet server software name and version that nmap displayed and did a quick Google search for
exploits. Low and behold the Telnet server on this manufacturers device seemed to have used the same
default password on all devices at one time. The post even listed the default password. But this article
was from several years ago. There is no way that brand new devices would still use this password, or
would they?

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

To be sure, I tried to connect to the Telnet service on the device using Netcat and the default password
that I found. From a Kali Linux terminal prompt I started Netcat (or I could have just used Telnet) with
the IP address and port of the device:
nc 192.168.1.130 23
It then prompted me for the username and password. I entered the ones that I found from the web:
host login: root
Password: ******
I then received this response:

BusyBox is somewhat common on embedded devices and is called, The Swiss Army Knife of Embedded
Linux. It has a very small footprint and includes only the commands that the device manufacturer
wants to include at compile time.
Typing help returned this screen:

Not too many options for commands, though I did find more in the sbin directory. But surfing around
the directory structure re-affirmed that many commands and directories that you would expect are just
not there making it a bit harder to do things we would normally do.

IoT Network Interfaces

When I ran an ifconfig command to list the network interfaces I saw that eth0 is on our 192.168.1.0
network, but there is also an ether0:poe interface that belongs to the 10.1.1.0 network, very
interesting:

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

PoE stands for Power over Ethernet. These devices communicate and get the power to work over the
Ethernet cable. These must be the cameras. If we run PS we see there is a micro-DHCP (udhcpd) service
running:

The command above mentions a mount directory, if we go there, we can view the config file:

The cameras should be in the 10.1.1.128-255 range. And sure enough when I pinged them from the
device I got a response. What is interesting is that the client control software for this system tends to
just show the last view recorded as a still image if the feed is interrupted. So I wonder what would
happen if we just remotely turned off the eth0:poe network interface (ifconfig down) for the cameras
from the command line? Think about that for a moment.

Passwords Galore
I did find several configuration files and poking through them revealed some interesting information,
like this:
INI_GROUP_NAME_ADMIN
INI_GROUP_NAME_USER
INI_SYS_USER_ADMIN
INI_SYS_USER_ADMIN_PWD
INI_SYS_USER_LOCAL
INI_SYS_USER_LOCAL_PWD
INI_USER_USER_LOCAL
INI_USER_USER_LOCAL_PWD
INI_DEFAULT_USER_NAME
INI_DEFAULT_USER_PWD

= "admin";
= "user";
= "admin",
= "admin",
= "user",
= "user",
= "user",
= "user",
= "default",
= "tluafed"

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

Of course they are all simple passwords, you were expecting something else on a building security
device? I looked around the file system for a bit, seeing that I could modify the system services, all due
to the fact that the manufacturer used a simple (and publicly known) password. I could spend more time
trying to figure out what else I could do, but in reality the whoami command told me all I really
needed to know:

We do in fact have root or god level access rights to the device. Nice
Good thing this device isnt made to sit outside your firewall, because anyone could easily get root
access to it. Oh, wait a minute, this IoT device is meant to be outside your firewall! The password the
manufacturer used to protect the root level account was not only publicly available; it was also a short
simple password comprised of less than six lowercase letters! Even if I didnt get the password off the
internet, I could have brute forced it in a fairly short amount of time.
If a password like this is run through Kasperskys secure password checker,
(https://blog.kaspersky.com/password-check/) it responds with a possible crack time of:

Forty Six seconds! Enough time, it says, for a snail to crawl nine inches.
A quick view of the device user passwd file (cat /etc/passwd) showed that the developer created over
40 usernames on this small device. What is the chance that they used simple passwords for all of the

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

other users too? Worse yet, the manufacturer was seemingly notified about the root password being
publicly displayed over two years ago and still havent corrected the issue.

Mass Exploiting the IoT Device

Instead of this just being a single test device. What if our target was a large corporation and used
multiple devices like this. How could we find and access all of them? Lets try the telnet login scanner
that is built in to Metasploit. The Telnet Login scanner allows you to put in a username password combo,
or use username/ password file lists and scan a network range looking for successful Telnet logins.
As you can see below, it easily scanned our network and found our camera system. It then created a
telnet session with the credentials that we provided (Password is redacted):

Set the options and run the scanner. We want it to scan the entire 192.168.1.0/24 range and try the
credentials on every system in this range. This would simulate searching a large network for similar
devices:

You will see a lot of failed connections, but after a short while (be sure to set the threads to 254 or you
will wait a long time!) you will see the successful login:

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

If we show and connect to the session it found:

And we are in!

The End Game

With just a quick security test we saw that this out of the box building security device was not very
secure at all. As I have mentioned several times, if this device was placed outside the corporate firewall
as it was intended to be, it would have been an easy target for hackers.
If they wanted to disable the cameras, they could have stopped the individual services controlling the
camera systems, or if they wanted to they could just run one of these commands:

Or this?

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

But would something that simple really work? I mean could you really remotely power off a building
security device? Sure does, here is a view of the DVRs control screen after running the command above:

Instead of just turning the device off, I wonder what would happen if they formatted the drive? Of
course you would lose all the stored video from the device, but I wonder if it would brick the device
making it unusable all together? Again something to think about.

But it is inside my Firewall so it is Okay

You would think that this type of attack would only be possible if the attacker was on the same LAN as
the device. If there is a firewall between the device and the outside world, then no one from the outside
should be able to mess with the security device. Or so you would think.
The system I used in this chapter was from an American based company that used a re-branded Chinese
device. One day the system just stopped working. I could see it, but the DVR software just no longer
worked. I re-installed the software and tried it from several computers to no avail. I went round and

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

round with their technical support. Then one day, it just started working. I again called their tech
support and was told that the issue was fixed - They updated the software on THEIR WEBSERVER and
this fixed the issue. I revealed to them that leaving themselves in the communication loop between the
client software and the physical device was a serious concern, especially for a security device that sat
behind a firewall!
I brought it to their attention multiple times that it did not make sense that a building security device
would be down just because they were doing maintenance on a remote webserver. And I repeatedly
asked why their needed to be constant contact between this device and their web server, instead of it
being a standalone fully functional unit. I kept getting passed to other company employees and
managers. This whole ordeal lasted about two weeks, but at each step I kept getting reassured by
company reps that as long as the system was functioning, everything was okay complete insanity!

Conclusion
I know that this section was very short, but hopefully I demonstrated that you cannot just blindly trust
that internet enabled physical security devices or any IoT device, are properly secured by the
manufacturer. It is scary too to think that this device in particular offered no way to change the default
passwords to the underlying services that were exposed to the web, and that after more than two years
from being publicly exposed, new devices were still being made with the same simple root password.
Also it is trivial to find IoT devices of all kinds using the internet search engine Shodan. This is why it is
imperative to test these devices for security just as you would for any network device that you attach to
your network, or worse, put outside your firewall.

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle

Book Overview
Intermediate Security Testing with Kali Linux 2 is a hands-on learn by doing book will help take you
beyond the basic features of Kali into a more advanced understanding of the tools and techniques used
in security testing.
Kali Linux is an Ethical Hacking platform that allows good guys to use the same tools and techniques that
a hacker would use so they can find and correct security issues before the bad guys detect them. If you
have a basic understanding of Kali and want to learn more, or if you want to learn more advanced
techniques, then this book is for you. As a follow up to the popular Basic Security Testing with Kali
Linux book, this work picks up where the first left off.

Topics Include
Creating Shells with Msfvenom
Post Modules & Railgun
PowerShell for Post Exploitation
Web Application Pentesting
Security Testing Android Devices
Forensics Tools for Security Testing
And much more!

About the Author

Daniel W. Dieterle has worked in the IT field for over 20 years. During this time he worked for a
computer support company where he provided system and network support for hundreds of companies
across Upstate New York and throughout Northern Pennsylvania.
For about the last 6 years Daniel has been completely focused on security as a computer security
researcher and author. His articles have been published in international security magazines, and
referenced by both technical entities and the media.
Daniel has assisted with numerous security training classes and technical training books mainly based on
Backtrack and Kali Linux.
Daniel W. Dieterle

Website: cyberarms.wordpress.com
Twitter: @cyberarms

Intermediate Security Testing with Kali Linux 2 - Copyright 2015 by Daniel W. Dieterle