FULLTEXT01

DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING,
SECOND CYCLE, 30 CREDITS

STOCKHOLM, SWEDEN 2021
Ethical Hacking of an IoT

camera
NICOLAI HELLESNES
KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
2|
Ethical Hacking of an IoT
camera
NICOLAI HELLESNES
Degree Programme in Computer Science and Engineering

Date: August 18, 2021
Supervisor: Pontus Johnson

Examiner: Mathias Ekstedt
School of Electrical Engineering and Computer Science
Swedish title: Etisk hackning av en IoT-kamera
© 2021 NICOLAI HELLESNES
Abstract | i
Abstract
With the fast growing popularity of IoT devices, a new entry point for cyber
attacks is emerging. As IoT devices such as security cameras become more
widely used in settings where security and privacy can be considered a key
concern, more research about these devices must be done to ensure that the
security requirements are met.
In this thesis the home security camera Reolink E1 Zoom has been evalu-
ated. The security of the device was evaluated with a 7 step method which
consisted of pre-engagement, information gathering, threat modeling, vulner-
ability analysis, exploitation, post exploitation, and reporting. The threat mod-
eling and penetration testing was conducted on the IoT device with a focus on
the web application. The result of the penetration testing was that one vul-
nerability was discovered, an XSS attack, with many other security issues not
directly leading to an exploit also being discovered. The vulnerability discov-
ered was reported to the manufacturer as detailed in the thesis. The conclusion
is that the security of the IoT device was lacking in certain areas.
Keywords
security, IoT camera, IoT, penetration testing, threat modeling
ii | Sammanfattning
Sammanfattning
IoT har med en snabbt växande popularitet öppnat för nya potentiella problem
med cyberattacker. Då IoT-enheter som säkerhetskameror börjar användas i en
större utsträckning i sammanhang där säkerhet och integritet har högsta prio-
ritet, måste mer forskning kring säkerheten av dessa enheter utföras. Detta för
att kunna säkerställa att säkerhetskraven är uppnådda.
I denna avhandlingen har säkerheten av IoT-enheten Reolink E1 Zoom ana-

lyserats. Säkerheten av enheten hara analyserats med hjälp av en 7-stegsmetod
som bestod av förberedning, informationssökning, hotmodellering, säkerhets-
analys, efter-exploatering, samt rapportering. hotmodelleringen samt penetra-
tionstestningen som genomfördes på enheten fokuserade på webbapplikatio-
nen. Resultatet av penetrationstestningen var att en sårbarhet hittades, en XSS-
attack, ett flertal andra säkerhetsproblem som inte direkt ledde till en sårbarhet
identifierades också. Sårbarheten som identifierades blev rapporterad till före-
taget enligt beskrivelsen i rapporten. Slutsaten är att säkerheten av IoT-enheten
har brister inom vissa områden.
Nyckelord
säkerhet, IoT-kamera, IoT, penetrationstestning, hotmodellering
Acknowledgments | iii
Acknowledgments
I would like to express my gratitude to my supervisor, Pontus Johnson, for
helping me with this thesis.
Stockholm, August 2021

NICOLAI HELLESNES
iv | Acknowledgments
Acknowledgments | v
List of Acronyms and Abbreviations

POC: Proof of Concept
IoT: Internet of Things
FTP: File Transfer Protocol
NVR: Network Video Recorder
PC: Personal Computer
IP: Internet Protocol
OSINT: Open Source Intelligence
TCP: Transmission Control Protocol
HTTP: Hypertext Transfer Protocol
HTTPS: Hypertext transfer Protocol Secure
ICMP: Internet Control Message Protocol
SYN: Synchronize
DOM: Document Object Model
API: Application Programming Interface
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Research Question . . . . . . . . . . . . . . . . . . . 2
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Research Methodology . . . . . . . . . . . . . . . . . . . . . 3
1.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 6
3 Method 10
3.1 Pre-Engagement . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Information Gathering . . . . . . . . . . . . . . . . . . . . . 11
3.3 Threat Modeling . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . 14
3.5 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Post Exploitation . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Threat Model 19
4.1 Understanding the System . . . . . . . . . . . . . . . . . . . 19
4.1.1 Technologies . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Functionality . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3 System . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Modeling the attack possibilities . . . . . . . . . . . . . . . . 23
4.2.1 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 Security controls . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Threat agents . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Interpreting the threat model . . . . . . . . . . . . . . . . . . 25
vi
CONTENTS | vii
4.3.1 Identified threats . . . . . . . . . . . . . . . . . . . . 25

4.4 Create a traceability matrix to record missing or weak controls 26
4.4.1 Threat traceability matrix . . . . . . . . . . . . . . . . 26
4.4.2 Selecting threats . . . . . . . . . . . . . . . . . . . . 28
5 Penetration Testing 30
5.1 Cross-site Scripting (XSS) . . . . . . . . . . . . . . . . . . . 30
5.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2 Background . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Broken Access Control . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Background . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Broken Authentication . . . . . . . . . . . . . . . . . . . . . 36
5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.2 Background . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Sensitve Data Exposure . . . . . . . . . . . . . . . . . . . . . 38
5.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.2 Background . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 40
5.5 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 40
5.5.2 Background . . . . . . . . . . . . . . . . . . . . . . . 40
5.5.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Security Misconfiguration . . . . . . . . . . . . . . . . . . . 42
5.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.2 Background . . . . . . . . . . . . . . . . . . . . . . . 42
viii | CONTENTS
5.6.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 43
5.7 XML External Entities (XXE) . . . . . . . . . . . . . . . . . 43
5.7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 43
5.7.2 Background . . . . . . . . . . . . . . . . . . . . . . . 44
5.7.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Insecure Deserialization . . . . . . . . . . . . . . . . . . . . 46
5.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.2 Background . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 48
5.9 Using Components with Known Vulnerabilities . . . . . . . . 48
5.9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 48
5.9.2 Background . . . . . . . . . . . . . . . . . . . . . . . 48
5.9.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 49
5.10 Insufficient Logging & Monitoring . . . . . . . . . . . . . . . 49
5.10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 49
5.10.2 Background . . . . . . . . . . . . . . . . . . . . . . . 49
5.10.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 50
5.11 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . 50
5.11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 50
5.11.2 Background . . . . . . . . . . . . . . . . . . . . . . . 50
5.11.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . 52
6 Discussion 54
6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 54
CONTENTS | ix
7 Conclusions and Future work 57

7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
References 59
List of Figures
4.1 External information flow of system . . . . . . . . . . . . . . 22

4.2 Internal information flow of system . . . . . . . . . . . . . . . 23
5.1 XSS attack on system . . . . . . . . . . . . . . . . . . . . . . 32
x
List of Tables
4.1 Identified Technologies for the IoT system. . . . . . . . . . . . 20

4.2 Identified possible actions on the web interface of the IoT system. 21
4.3 Identified assets of the IoT system. . . . . . . . . . . . . . . . 24
4.4 Identified security controls of the IoT system. . . . . . . . . . 24
4.5 Identified threat agents of the IoT system. . . . . . . . . . . . 25
4.6 Identified threats of the IoT system. . . . . . . . . . . . . . . . 25
4.7 Threat traceability matrix for the identified threats with the
STRIDE model of the IoT system. . . . . . . . . . . . . . . . 27
4.8 Threat traceability matrix for the identified threats with the
STRIDE model of the IoT system. . . . . . . . . . . . . . . . 28
xi
xii | LIST OF TABLES
Chapter 1
Introduction
The number of connected internet of things (IoT) devices in the world is rapidly
increasing, with an expected number of 43 billion connected IoT devices by
2023[1]. With this explosive growth and with the nature of IoT, IoT devices
can be found connected to critical infrastructure. Thus security of these de-
vices becomes a large concern.
This project will research how IoT devices can be analyzed with regards to
their security. This project will do this by focusing on a particular device, the
Reolink E1 Zoom, which is a connected security camera for indoor use. The
camera has 3x optical zoom, pan/tilt functionality, and also supports two-way
audio. The device has support for Reolink applications on Android, Iphone,
Ipad, Windows, Mac, Internet explorer, Chrome, Edge, Safari, and Firefox.
The device also supports the saving of recordings to a Micro SD Card, a FTP
server, Reolink Cloud, and with a NVR. It could be a serious violation of pri-
vacy if an attacker could gain access to the device’s camera or its data.
1.1 Background
Internet of things is a broad term that has been described in many ways. One
common way to describe IoT devices are "network connected computing de-
vices that use the internet and unique identifiers to communicate with each
other"[2]. The term is primarily used for devices that traditionally have not
been connected devices, such as locks, watches, and light switches, while ex-
cluding devices that have traditionally have been connected such as PCs.[2]
There are many industries that have adopted IoT devices and introduced them
1
2 | Introduction
into the workflow, such as healthcare where cancer care wearables have been
used and tested in clinical practice[3].
The design of IoT makes it susceptible to attacks, and the security issues might
hinder the development and adoption of these devices. There are many cases
of hacked IoT devices, such as the case with the St. Jude Medical implantable
cardiac devices.[4] These devices are network connected devices that are used
to control the rhythm of the heart. The vulnerability made it possible for an
attacker to control the device and could thus deplete the battery at an rapid
pace, change the pacing, or even administer shocks.
With IoT devices being used in contexts where security is important, it be-
comes important to show how vulnerable these devices are and to make the
consumers and the device makers aware of this. If security of IoT devices be-
comes valued, additional resources will be put into making the devices more
secure.
The intention is that this project will help to make IoT devices more secure.
This will be done by showing how an IoT device can be analyzed with regards
to its security.
1.2 Problem
IoT devices are becoming more and more popular, they will be present in con-
texts where security is an important matter, and thus the security of these de-
vices should be questioned and analyzed.
1.2.1 Research Question

The question that this project intends to answer is: does the smart camera have
security flaws, and if it does, how severe are they? This research question can
be divided into two sub-questions:
1. Does the Reolink E1 Zoom have security vulnerabilities?
2. If the Reolink E1 Zoom has security vulnerabilities, how severe are the
vulnerabilities found, and how can they be exploited?
Introduction | 3
1.3 Purpose
In this project, an IoT device was analyzed with regard to its security. The
purpose of this is to gain an understanding of security in IoT devices and the
common vulnerabilities that can be found in such devices. This will help with
acquiring knowledge about the state of security in IoT devices.
This project helps expand the knowledge of the state of security in IoT de-
vices and the state of cyber security knowledge at large. This helps with the
continuation of the research in the field of cyber security.
1.4 Research Methodology

The method used to answer the research question consisted of three parts.
1. The first part was a literature study, which was used to research threat
modeling, common security vulnerabilities for IoT devices, and how to
exploit these common vulnerabilities.
2. The second part consisted of threat modeling, which was used done to
explore and describe the system. This was done to find potential weak-
nesses in the system.
3. The third part consisted of penetration testing, which was the part where
potential weaknesses found with the threat modeling were tested in order
to find vulnerabilities.
1.5 Delimitations
The cloud features were excluded from the scope of the project for legal rea-
sons, as no agreement with the manufacturer regarding penetration testing had
been made. The applications for the different systems were excluded from the
scope of the project because of time limitations. Instead this project focused
on the web application located on the device. The parts that were excluded in
the project were:
• Windows application
• Mac application
• Iphone application
4 | Introduction
• Android application
• Cloud features
1.6 Structure of the thesis

The thesis is divided into 8 chapters. This chapter, chapter 1 introduces the
project. The rest of the chapters are divided in this way:
• Chapter 2 presents relevant related work about penetration testing and

security of IoT devices.
• Chapter 3 presents the methodology and method used to create a threat

model for the system and the penetration tests.
• Chapter 4 presents the threat modeling conducted for the project.
• Chapter 5 presents the penetration testing conducted for the project to-
gether with the results and discussion for the penetration tests conducted.
• Chapter 6 presents the discussion.
• Chapter 7 presents the conclusion and future work.

Introduction | 5
Chapter 2
Related Work
In 2013 during a Black Hat conference, Craig Heffner presented his findings
after having analyzed the security of multiple IP security cameras.[5] He found
the vulnerabilities of the cameras by only studying the firmware of the cameras.
In the case study of a web camera[6] for the International Conference on Ad-
vanced Communications Technology the authors show how one can search
for vulnerabilities in web cameras. The authors found that the camera used
for the study used unencrypted communication and thus sensitive information
could be gathered. This information could then be used to take control over
the device. The authors also showed that the account details for the camera
were stored in plaintext within the mobile application. This showed the se-
rious flaws of having unencrypted communication and storing credentials in
plaintext.
Not using default credentials is crucial. Default credentials will often be found
and makes it easy for an attacker to compromise a system. One example
where this was put to use is the Mirai botnet, which was first found by a secu-
rity research group called MalwareMustDie[7]. Mira targeted devices which
used default credentials or misconfigurations to easily take control over these
devices[8].
In June 2019, a security researcher named mcw0 on Github posted a PoC for
a command injection that worked on several Reolink cameras.[9] The Vulner-
ability later known as CVE-2019-11001, let an authenticated admin use the
"TestEmail" functionality to inject and run OS commands as root.[10]
6
Related Work | 7
In a blogpost named Trendnet Cameras - I always feel like somebody’s watch-

ing me, the author, named someLuser, showed how one could get access to the
video feed of Trendnet cameras without being authenticated.[11] The author
found this while looking through the firmware for the Trendnet TV-IP110w
camera. Apparently there existed functionality for watching the video feed
anonymously, which anyone could access. Not only was this feature turned on
by default, but it was not possible to turn it off.
In a blogpost named Hacking Reolink cameras for fun and profit[12], the au-
thor, George Hilliard showed how to gain root access on the Reolink B800
IP camera. This was done by modifying the firmware of the camera. The
firmware was modified so that the camera would start telnet on boot. This
could be prevented by having a secure boot scheme.
In a document published in May 2014, the Trustwave SpiderLabs team pub-

lished the security vulnerabilities found while investigating multiple Y-cam
cameras with regard to their security.[13] Multiple denial of service vulnera-
bilities were found, the team successfully attacked the device with a specially
crafted HTTP get request that forced the device to reboot.[13] The Trustwave
SpiderLabs team also found multiple persistent cross site scripting vulnerabil-
ity was found, and with basic authorization a successful persistent XSS attack
could be achieved.[13]
A smart toy bear from Fisher-Price was found to have a security vulnerability,
the API allowed malicious agents to remotely gain access to sensitive infor-
mation and to modify data.[14] The API calls was not verifying the sender of
the messages correctly which resulted in the possibility of attackers acquiring
sensitive information such as customer and profile information.[15]
A vulnerability was found in the Samsung SmartCam where a bug allowed

for the possibility of changing the password of the administrator without the
current password for the account.[16] The security vulnerability occurred be-
cause the script which was used to create an administrator account could be
called even though an administrator account already existed.[16] This made
it possible for an attacker to assume the identity of the administrator and gain
control over the device.
Researchers for the Kaspersky lab studied the security of surveillance cameras.[17]
The research team found that the data packets was not encrypted, and could
8 | Related Work
view the data in plain text.[17] With surveillance cameras being deployed in
cities and with the packets not being encrypted, it could be used to spy on peo-
ple throughout cities.
A XML external entity vulnerability (XXE) was found in the Cisco Firepower
device manager on-box software.[18] The vulnerability happened due to the
handling of XML external entities, and the XXE attack could be used to gain
access to sensitive information as access to files on the local file system could
be acquired.[18]
In April 2019 Citrix mentioned in a blogpost named "Citrix investigating unau-

thorized access to internal network"[19] that they were investigating unautho-
rized access to the internal network of the company after being contacted by
the FBI regarding the subject. In a later blogpost from Citrix named "Citrix
concludes investigation of unauthorized internal network access"[20] which
regards the conclusion on the investigation, the company concluded that the
attackers had access to the internal network between October 13, 2018, and
March 8, 2019. To protect against future attacks Citrix improved the logging
at the firewall.
A vulnerability was found in Moxa ThingsPro IIoT Gateway and Device Man-
agement Software, the vulnerability was a broken access control vulnerability
which lead to privilege escalation.[21] The attack could be performed remotely
and without any user interaction.[22]
Related Work | 9
Chapter 3
Method
This chapter describes the method used in this thesis. The method used for this
thesis is based on the Georgia Weidman method.[23] Georgia Weidman[23]
divides penetration testing into 7 steps. The steps are:
1. Pre-Engagement
2. Information Gathering
3. Threat Modeling
4. Vulnerability Analysis
5. Explotation
6. Post Explotation
7. Reporting
3.1 Pre-Engagement
The pre-engagement phase consists of deciding the goals and rules for the pen-
etration testing, this includes scope and testing window.[23] The scope is used
to decide what is allowed and what is off limits. This can be IP addresses,
services, and types of attacks. The testing window decides when penetration
testing is allowed. A testing window is common with penetration tests against
live services, and is usually used to avoid peak hours. This is done so that if
the penetration test creates downtime for the live service, it will happen at a
time with as few users as possible.
10
Method | 11
With this project not having a client, a large part of the pre-engagement phase
could be disregarded. The main focus of this phase became to decide the scope
of the penetration testing.
3.2 Information Gathering

The second phase is the information gathering phase. This phase consists of
gathering as much information as possible about the target of the penetration
testing.[23] This is usually done with open source intelligence gathering and
port scanning. The open source intelligence gathering consists of searching
through freely available resources to gather as much information as possible.
The information gathered can be about the system, the company, or the em-
ployees. Port scanning is used to scan ports of a system, this will give informa-
tion about which ports are open, and which services are running on the ports.
For this project fccid.io[24] and the website of the manufacturer of the system[25]
were used for OSINT. For port scanning the tool nmap[26] was used. This
identified the open ports of the system and the services running on the open
ports.
3.3 Threat Modeling

The third phase is the threat modeling phase. In this phase the information
gathered in the information gathering phase is used to create a plan for how to
penetrate the system.[23]
There exists many different models for threat modeling, the chosen threat
model for this project is a threat model created by Synopsys.[27] This model
is based around five steps:
1. Define scope and depth of analysis
2. Gain an understanding of what is being threat modeled
3. Model the attack possibilities
4. Interpret the threat model
5. Create a traceability matrix to record missing or weak controls

12 | Method
Define scope and depth of analysis

In the first step the scope and depth of the analysis is determined.[27] By de-
ciding on scope and depth at an early stage of the threat modeling a lager focus
can be directed towards modeling the relevant parts of the system, and can also
help simplify the threat modeling phase.
This step was omitted from the threat modeling in this project as the scope
had already been decided in chapter 1.6.
Gain an understanding of what is being threat modeled

In the second step the system is modeled. This is done by analyzing the system
and is often supplemented by creating a diagram of the structure of the system.
By creating a diagram of the system, the system becomes easier to understand
both as a whole and by seeing how the components interact with each other.
Model the attack possibilities

In the third step the attack possibilities are modeled. This is done by identify-
ing assets, security control, and threat agents.[27] To help identify the threats
of the system the STRIDE threat model[28] was used. The STRIDE threat
model is made up of six different threat categories:
1. Spoofing identity
2. Tampering with data
3. Repudiation
4. Information disclosure
5. Denial of service
6. Elevation of privilege
Spoofing identity
Spoofing an identity is the act of using the information you have gathered to
pretend to be someone else. This is a method often used to access information
that otherwise would be inaccessible.
Method | 13
Tampering with data

Tampering with data is the act of maliciously modifying data. This can be
used to modify important data or even to inject malicious code.
Repudiation
Repudiation is the act of denying to have performed an action with the other
actors not being able to prove otherwise.
Information disclosure
Information disclosure is the act of exposing information to people that should
not have access to that information.
Denial of service
Denial of service is the act of denying the availability of a resource, for exam-
ple by making a web server unavailable.
Elevation of privilege
Elevation of privilege is the act of an unprivileged user gaining privileged
access. The threat of elevation of privilege is that an attacker can use the
heightened levels of privilege to get access to information they should not have
or take control over the system.
Interpret the threat model

In the fourth step the model should be Interpreted, this is done by looking at
the model while asking questions about how a potential attack could look.[27]
This step is done to help the creation of a threat traceability matrix in the next
step.
Create a traceability matrix to record missing or weak

controls
In the fifth and final step a threat traceability matrix is created. A threat trace-
ability matrix is created to investigate and examine what a threat agent can do.
This is done by looking at how a threat agent can use an asset, what kind of
14 | Method
attacks are possible and what the attack surface is.[27] The potential impact
and mitigation techniques are also looked at.
3.4 Vulnerability Analysis

The fourth phase is the vulnerability analysis phase. In this phase vulnerabil-
ities are discovered and strategies for exploiting the vulnerabilities are devel-
oped. The vulnerabilities are discovered by using vulnerability scanners and
by doing manual analysis.
For this project the manual analysis consisted of trying to find vulnerabili-
ties based on the information gathered during the information gathering phase
together with threats identified in the threat model. The vulnerability scan-
ner used for this project was Nikto.[29]. Aside from threats identified in the
threat modeling, the OWASP top 10 list[30] was also used in order to discover
vulnerabilities. The OWASP top 10 ranks the top 10 security risks for web
applications:
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfigurations
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known vulnerabilities
10. Insufficient Logging & Monitoring
Injection
An injection attack is when untrusted data is sent to a program and gets in-
terpreted. This can be used to run commands or access information as an
unauthorized user.
Method | 15
Broken Authentication
The aim of attacking the broken authentication of a system is to exploit the
implementation of an authentication system. This can be used to compromise
credentials, using the system to find valid usernames, or to hijack a session.
Sensitive Data Exposure

The exposure of sensitive data in a system can lead to attackers accessing in-
formation they should not have access to.
XML External Entities (XXE)

An XXE attack is when external entities in XML are used as the attack vector
in an attack. This can be used to gain access to internal files, gain ability to
execute code remotely, or even to do a denial of service attack.
Broken Access Control

Broken access control is when restrictions on what a user can do can be by-
passed. This can be a normal user being able to access an admin panel or an
attacker being able to take over other users accounts.
Security Misconfigurations
Security misconfigurations when a service, such as a web server, is configured
wrong. This can lead to many problems.
Cross-Site Scripting (XSS)

XSS is an attack where untrusted user data that is not correctly handled by the
application can be used to attack the users of the application. XSS can be used
to hijack sessions from users.
Insecure Deserialization
Deserialization is the process of converting a byte stream into the original
object. Insecure deserialization provides attackers with an attack vector and
can often lead to remote code execution.
16 | Method
Using Components with Known vulnerabilities

Using software or hardware components with known vulnerabilities provides
attackers with an attack vector.
Insufficient Logging & Monitoring

Insufficient logging and monitoring can result in an attacker breaching a sys-
tem and maintain persistence without being noticed.
3.5 Exploitation
The fifth phase is the exploitation phase. During this phase potential vulnera-
bilities found in previous phases are tested and exploited. The explotation step
is conducted in order to verify that possible vulnerabilities can be exploited.
The explotation conducted for this project can be seen in chapter 5. If a poten-
tial vulnerability proved possible to exploit it was reported to the manufacturer
of the device following the rules of section 3.7.
3.6 Post Exploitation

The sixth phase is the post exploitation phase. During this phase the successful
exploits are assessed. This is done by analyzing the successful exploits with a
focus on impact and mitigation tactics. This step is conducted in order to find
the possible approaches to patch the found vulnerability. The post exploitation
conducted for this project can be seen in chapter 5.
3.7 Reporting
The last phase of a penetration test is the reporting. The report should consist
of the findings of the penetration testing. According to Weidman’s method[23]
the report should be divided into two parts, an executive summary, and a tech-
nical report. The executive summary should contain the goals of the penetra-
tion testing together with an overview of the findings. The technical report
should contain an in-depth technical analysis of the penetration testing and the
findings.
Method | 17
As this project did not have a project owner, the reporting phase consisted
of contacting the manufacturer of the device and coming to an agreement on
the rules of the reporting of the found vulnerability. The first contact was made
via a submission form on the manufacturers website. This mail consisted of
informing the manufacturer that a potential security issue had been found and
asking to be put in contact with someone responsible for the product secu-
rity. The manufacturer responded to the mail by asking for information about
the security issue, and stating that they would forward the information to their
R&D team. A report of the vulnerability was then sent to the manufacturer.
The report given to the manufacturer consisted of information about the found
vulnerability and a PoC for the vulnerability together with the guidelines that
would be used regarding the disclosure of the vulnerability unless otherwise
agreed upon. The reporting followed the guidelines of Coordinated Vulner-
ability Disclosure: the Guideline[31] by NCSC. The response to the report
of the vulnerability consisted of information about the fixes the manufacturer
would implement in their firmware in order to patch the vulnerability and make
the device and system more secure.
18 | Method
Chapter 4
Threat Model
This chapter focuses on the threat modeling of the system. The method used
for the threat modeling is described in chapter chapter 3.3.
4.1 Understanding the System

In order to gain an understanding of the system, the technologies and func-
tionalities of the system were identified. A visualization of the data flow for
the system in the form of diagrams was also created.
4.1.1 Technologies
The IoT device utilizes applications on multiple systems for the possibility to
control the device. The device has applications for Android, iOS, Windows,
Mac, and the web. The IoT device uses a self hosted server for the web appli-
cation. This server also sends data to a relay server in order for a user to be able
to connect to the device outside of the network. Port forwarding can also be
used to access the device outside of the local network. The web server on the
device uses nginx version 1.14.2. Settings and controlling of the device can
be done from all the different applications. This includes zoom, tilt, and pan
functionality. The web application has an administrator panel where settings
can be changed. Table 4.1 shows the technologies identified for the device.
19
20 | Threat Model
Technologies
Technology Description
Camera The OS of the camera is not known. The camera uses a nginx
web server.
iOS application, Applications used to interact with the camera and to view
Android application, the video feed.
Mac application,
Windows applica-
tion
Communication pro- User Datagram Protocol (UDP) is a connectionless protocol
tocol: UDP for web communication.
Communication pro- Hypertext Transfer Protocol (HTTP) is a communication
tocol: HTTP protocol for the web.
Communication pro- Hypertext Transfer Protocol Secure (HTTPS) is a variant of
tocol: HTTPS HTTP that uses encryption.
Communication pro- Real-time streaming protocol (RTSP) is a protocol for
tocol: RTSP streaming media via the web.
Communication pro- Real Time Messaging Protocol (RTMP) is a protocol used
tocol: RTMP for streaming data.
Communication pro- Simple Mail Transfer Protocol (SMTP) is a protocol for
tocol: SMTP sending email.
Communication pro- File Transfer Protocol (FTP) is a protocol for transfering files
tocol: FTP via the web.
Communication pro- Universal Plug and Play (UPnP) is a protocol used for auto-
tocol: UPnP matic discovery of devices.
Communication pro- Network Time Protocol (NTP) is a protocol for clock syn-
tocol: NTP chronization.
Communication Protocol for wireless communication.
protocol: IEEE
802.11a/b/g/n
Communication pro- Simple Object Access Protocol (SOAP) is a protocol for
tocol: SOAP transfering XML data.
Table 4.1: Identified Technologies for the IoT system.
4.1.2 Functionality
The rights for using certain functionality on the IoT device can be divided into
three categories. The categories are user, administrator, and super administra-
Threat Model | 21
tor. The rights different users have to the actions of the web interface can be
seen in table 4.2.
Functionality
Action Description
Create user account Any administrator can create another user account
Create administrator Only super administrator can create another administrator
account account
Create super admin- Super administrator is a pre-created account and a new one
istrator account can not be created
Delete user account An administrator can delete a user account
Delete administrator Only super administrator and the administrator itself can
account delete an administrator account
Delete super admin- Super administrator account can not be deleted
istrator account
View camera feed Any user or administrator can view the camera feed
Take picture Any administrator can take picture with the camera
Pan, tilt, and zoom Any administrator can use the pan, tilt, and zoom function-
ality
Change settings Any administrator can change the settings of the camera
Modify user account Any administrator can modify a user
Modify administra- Only super administration and the administration itself can
tor account modify a administrator account
Modify super ad- Only super administrator can modify the super administrator
ministration account account
Table 4.2: Identified possible actions on the web interface of the IoT system.
4.1.3 System
In order to gain an understanding of how the system works, diagrams for the
external and internal information flow for the IoT device were created. Which
can be seen in figures 4.1 and 4.2.
22 | Threat Model
Figure 4.1: Diagram over external information flow for the IoT device.
Threat Model | 23
Figure 4.2: Diagram over internal information flow for the IoT device.
4.2 Modeling the attack possibilities

In order to model the attack possibilities, tables containing the security con-
trols, and threat agents were created. Which can be seen in table 4.3, 4.4, and
4.5 respectively. Together with the figures 4.1 and 4.2 this created a model for
the attack possibilities.
4.2.1 Assets
As a part of the threat modeling the assets of the system were identified as seen
in table 4.3. The assets were identified by inspecting the web interface of the
IoT device. While the logging data asset was not identified on the system as
no access to the operating system was acquired, it was seen as a possible asset
during the modeling the attack possibilities phase.
24 | Threat Model
Assets
ID Description Location
A0 Video feed Web server
A1 Firmware IoT device
A2 Configuration files System data
A3 User credentials System data
A4 Local storage data System data
A5 logging data System data
A6 Session token Browser
Table 4.3: Identified assets of the IoT system.
4.2.2 Security controls

As a part of the threat modeling the security controls of the system was iden-
tified as seen in table 4.4. The security controls were identified by inspecting
the web interface of the IoT device.
Controls
ID Description Location
SC0 User authentication system Web server
SC1 SSL Browser/Web
server
SC2 Session token Browser
SC3 User input filter Browser
SC4 User input escaping Web server
SC5 Password policy Web server
SC6 Privilege level control Browser/Web
server
Table 4.4: Identified security controls of the IoT system.
4.2.3 Threat agents

As a part of the threat modeling the possible threat agents to the system was
identified as seen in table 4.5. The possible threat agents were identified by
finding the possible generic user types that could exist.
Threat Model | 25
Threat agents
ID Description
TA0 Unauthorized user
TA1 Authorized administrator
TA2 Authorized user
Table 4.5: Identified threat agents of the IoT system.
4.3 Interpreting the threat model

Based on the information gathered in the previous phases of the threat model-
ing, possible threats to the system were identified with the help of the STRIDE
model. The threats identified with the STRIDE model can be seen in table 4.6.
4.3.1 Identified threats

Based on the threat modeling and the STRIDE model possible threats to the
system were identified.
Identified threats (Stride model)

Threat type Threat
Spoofing identity - Spoof an access point
Tampering with - Delete or modify local storage data
data - Delete or modify logs
Repudiation - Delete or modify logs
- Disable logging & monitoring
Information - Intercept network communication
disclosure - Leak credentials
- Leak configuration details
Denial of service - Crash the server
- Change passwords of the users
Elevation of priv- - Brute force login
ilege - Bypass authentication system
Table 4.6: Identified threats of the IoT system.

26 | Threat Model
4.4 Create a traceability matrix to record miss-

ing or weak controls
In order to further investigate the possible threats to the system found with the
STRIDE model, a threat traceability matrix was created. A threat traceability
matrix aims to identify the threat agent, the asset an attacker wants, the attack
the attacker could perform, the attack surface the attacker could use, the po-
tential impact of a successful attack, and the control of the system that could
stop an attack.
4.4.1 Threat traceability matrix

A threat traceability matrix over the potential vulnerabilities found with the
STRIDE model was created as can be seen in table 4.7 and table 4.8.
Threat Model | 27
Threat traceability matrix (part 1)

Threat Asset Attack Attack Attack Impact Control
agent surface goal
TA0 A3: Brute Web in- Become an High: A succesful A password
User force terface authorized brute force attack policy is
creden- user would give an at- the only
tials tacker access to the control
web application and
its data
TA0 A0: Bypass Web in- Accesing High: an attacker by- SC0: User
Video authen- terface the web passing the authenti- authen-
feed tication interface cation system would tication
system and the give the attacker ac- system
video feed cess to the video feed
and the rest of the
web application
TA0, A0: Denial Web in- denying High: Denying ac- SC6: Only
TA1 Video of terface access to cess to the video feed Authorized
feed service the device could be used by an adminis-
and its attacker in order to trators can
video feed not be seen while restart the
committing a crime device
TA0 A2: user Intercept Web Gain infor- High: Sesssion to- SC1: SSL
creden- network commu- mation ken or user creden-
tials, communication tials would make it
A6: nication possible for an at-
Session tacker to gain autho-
token rized access to the
web application
TA0 A2: Leaking Web in- Gain in- Medium: Gaining SC0: User
Config- config- terface, formation information about authen-
uration uration Firmware about the the system might tication
files details system make it easier to system
exploit
TA0, A4: Lo- Deleting Web Tamper Low: Deleting or SC0: User
TA1 cal stor- or mod- inter- with data modyfing local stor- authen-
age data ifying face & age data would not tication
local physical have a big impact system
storage device
data
TA0 A5: Delete Web in- Delete or Low: While deleting No direct
Logging or mod- terface modifying or modifying logs access
data ify logs can hide an attack, to logs
logs having logs does not via web
directly stop attacks interface
Table 4.7: Threat traceability matrix for the identified threats with the STRIDE
model of the IoT system.
28 | Threat Model
Threat traceability matrix (part 2)

Threat Asset Attack Attack sur- Attack Impact Control
agent face goal
TA0 A5: Disable Web inter- Disable Low: While dis- No direct
Logging logging face logging abling logging & access to
data & moni- & moni- monitoring can logging &
toring toring hide an attack, hav- monitoring
ing logs does not functional-
directly stop attacks ity via web
interface
TA0 A3: Spoof an Web com- Gain High: Sesssion to- No control
User access munication informa- ken or user creden- identified
creden- point tion tials would make it
tials, possible for an at-
A6: tacker to gain autho-
session rized access to the
token web application
Table 4.8: Threat traceability matrix for the identified threats with the STRIDE
model of the IoT system.
4.4.2 Selecting threats

After identifying possible threats with regards to security to the web interface
of the device, a selection of which to investigate further had to be made. All
the security threats on the OWASP top 10 list were chosen for further investi-
gation as they hold large significance for web security while also being com-
monly occurring vulnerabilities in web applications. From the possible threats
found with the STRIDE model the threat of denial of service was selected for
further investigation as it is an attack that could render the IoT device useless.
While it would be preferable to further investigate all the possible threats, time
limitations made it necessary to focus on a smaller number of possible threats.
As this would make it possible for a more thorough penetration testing on the
selected security threats.
Threat Model | 29
Chapter 5
Penetration Testing
This chapter describes the penetration testing that was performed for this the-
sis together with the method, results, and discussion for each penetration test
performed.
5.1 Cross-site Scripting (XSS)

5.1.1 Introduction
Cross-site scripting, also known as XSS, is an attack vector with the goal of
executing malicious scripts on the client-side of a web application. Cross-site
scripting can occur in any web application that uses untrusted user data in the
application.[32]
5.1.2 Background
There exist three kinds of XSS attack types, stored XSS, reflected XSS, and
DOM based XSS.[33]
Reflected XSS
Reflected XSS can occur when an application receives data from an untrusted
source in a HTTP request, which promptly is included within the application.[34]
For example this could be that user controllable data in the url will be displayed
within the application, as this would make it possible for a malicious user to
include malicious scripts in the application via the url.[34]
30
Penetration Testing | 31
Stored XSS
Stored XSS can occur when an application receives and stores data from an
untrusted source, which later is included as data in an HTTP response.[33]
One example of this could be an application which asks for the users name
which later will be displayed every time the user log in to the application. If
the name is displayed in the application with <h1>name</h1> an attacker
can inject a script when entering their name with <script>/*malicious pay-
load*/</script>[33].
DOM-based XSS
DOM-based XSS attacks can occur when user controllable data is passed to
a sink in a application.[35] A sink is a JavaScript function or DOM object
that might be dangerous for the application if user controlled data is handled
by them.[36] The most common way for a DOM-based XSS to be introduced
into an application is via the URL.[35]
5.1.3 Method
The penetration testing conducted for XSS attacks was conducted as a two step
process. The first step consisted of identifying the parts of the web applica-
tion that accepted user controlled inputs. The second part of the penetration
testing consisted of testing the parts of the web application that accepted user
controlled data with the intent of identifying if any parts were vulnerable to
XSS attacks. The script used as input for testing was
<svg/onload=alert(’XSS’)>
If the attack was successful an alert box with the word "XSS" would appear.
During the testing the inspect element tool in Firefox was used to inspect how
the application handled the script as an input.
5.1.4 Results
Four stored XSS vulnerabilities were found as four api endpoints were vulner-
able to stored XSS attacks. Depending on the endpoint different inputs could
be used to store the XSS scripts. These endpoints were vulnerable because of
the content type used. The endpoints used the content-type text/html instead
of application/json which meant that the malicious script got executed.
32 | Penetration Testing
Figure 5.1: A successful XSS attack against the GetUser api endpoint.
The four affected api endpoints were:
1. http://<ip>/cgi-bin/api.cgi?cmd=ScanWifi&token=<token>
2. http://<ip>/cgi-bin/api.cgi?cmd=GetUser&token=<token>
3. http://<ip>/cgi-bin/api.cgi?cmd=GetEmail&token=<token>
4. http://<ip>/cgi-bin/api.cgi?cmd=GetFtp&token=<token>
In order to test reliability and to improve reproducibility a POC for a stored

XSS attack against the GetUser api endpoint was created. After executing the
Python script and getting a successful response code, visiting the GetUser api
endpoint would result in an successful XSS attack.
# XSS POC
import requests
ip = <ip>
token = <token>
url = "http://" + ip +
"/cgi-bin/api.cgi?token=" + token
data =
[{"cmd":"AddUser","action":0,"param":{"User":{"userName":
"<svg/onload=alert(’XSS’)>","password":"test1234","level":
"admin"}}}]
response = requests.post(url, json=data)

print(response.text)
5.1.5 Discussion
Both the victim and the malicious actor of this attack has to be authorized users
for the attack to be successful. It is unlikely that a users visits an api endpoint
and thus the most probable way of using this vulnerability for an successful
attack is for an malicious actor to send a link to one on the affected endpoints
containing a stored XSS to the victim.
The attack works because the stored script is being included as data in the
api call and is being interpreted as HTML and thus executes. To defend the
application against stored XSS attacks the api endpoints should have used the
content-type application/json instead of the content-type text/html that was
used. Another way to protect against this attack would have been to use proper
escaping to avoid the malicious script being interpreted as code, which is done
correctly in the whole application aside from the api endpoints.
5.2 Broken Access Control

5.2.1 Introduction
Access control is used in order to regulate what different types of users are
allowed to do. Access control not being enforced correctly can lead to unau-
thorized users having access to functionality and data they should not have
access to.
5.2.2 Background
Access control is used in applications in order to decide what kind of actions
an authorized user has access to, and what a user can access in terms of re-
sources. For example, an administrator might have the right of performing the
action of deleting a user, while a user does not have that right. When access
control is broken or flawed an attacker can use this to exploit the application.
This can result in an attacker gaining access to data or functionality the at-
tacker should not have access to.
There are three types of access control. These are vertical access control,
horizontal access control, and context-dependent access control.[37]
Vertical access control

Vertical access controls are access controls that aim to limit the access to
functionality[37], usually vertical access controls are based on user types. For
example, a normal user might not be able to change user name while an ad-
ministrator has access to that functionality.
Horizontal access control

Horizontal access controls are access controls that aim to limit access to a
resource[37], usually horizontal access controls are based on user types. For
example, an administrator might be able to view the total number of users of
an application while a normal user does not have access to that information.
Context-dependent access control

Context-dependent access controls are access controls that limit the access to
functionality and resources based on the current state of the application or how
a user interacts with said application.[37] For example, a user might only be
able to get information about shipping after placing items in their shopping
cart.
5.2.3 Method
For the penetration testing of access control, the mechanics of the different
access controls of the web application was inspected. The application uses
a token for access control. The token, which is stored in localstorage, was
accessed and inspected with the firefox developer tools. How the application
handles access control for different user types was also inspected.
5.2.4 Results
Discovery 1
Access control for the application can be circumvented by manipulating the
user token. The token contains the fields /player/default-stream, /player/play-
back/volume, /player/preview/volume, token, and userName. While being an
authorized user, changing the name in the userName field to a name of an
admin grants the user access to the admin dashboard. This is because the
name of the super admin account is admin and for access to the administrator
dashboard only the name of the token is checked. While settings can not be
changed, the user can view the settings and gain access to information such as
model, UID, Build No, hardware No, config version, and firmware version. As
an authorized administrator changing the name in the userName field of the
token to admin, grants the admin the rights to remove other accounts, which
is an action only the super admin should be able to perform.
Discovery 2
Access control for the admin dashboard can be circumvented by manipulating
the client-side JavaScript code. An authorized user can access the administra-
tor dashboard with the code "ControllerMain.trigger(’gotoRemoteConfig’);"
as it is only intended for the piece of code to be executed if the user is an
administrator. This code can be found in the client-side JavaScript Controller-
Main.js
$("#navigation_bar_remoteconfig").on(’click’,
function() {
if (ControllerLogin.level !== ’admin’) {
return;
}
ControllerMain.trigger(’gotoRemoteConfig’);
});
While no settings can be changed in the administrator dashboard by utilizing
this attack, all the settings can be viewed, and thus provide valuable informa-
tion to an attacker.
5.2.5 Discussion
For discovery 1, for an attack to be successful the attacker has to be an autho-
rized user. To protect against this attack, the application should not use the
userName field of the token for access control purposes. This is because the
userName field of the token is easily manipulated and thus makes the access
control ineffective.
For discovery 2, an attacker needs to be an authorized user for the attack to

be successful. To protect against this vulnerability, the application logic for
dashboard access should not be present in the client-side code for the applica-
tion. Placing access control logic for the administrator dashboard client-side
of the application makes it simple to manipulate, and thus simple to exploit.
5.3 Broken Authentication

5.3.1 Introduction
Broken authentication is an attack vector where how an application handles
authentication and sessions are being exploited. Broken authentication is a
large problem in web security and it resides on the OWASP top 10 list.
5.3.2 Background
Authentication is used to control who can access an account. When authen-
tication is poorly implemented it can suffer from numerous issues. These is-
sues include default credentials, permitting brute-force attacks, weak password
recovery systems, handling of session IDs and tokens, poorly implemented
multi-factor authentication, or exposing credentials.[38]
Default Credentials
Default credentials are a big security risk and many cases of broken authentica-
tion are because of it. Default credentials often occur because the credentials
are never changed on a new or default account. Default credentials for sys-
tems are usually known or easy to guess which makes it easy for an attacker
to exploit.
Brute Force Attacks

A brute force attack is when an attacker is using plain guessing in order to gain
information about a system. In the case of authentication systems the guesses
are for credentials and different character sets might be used.
Dictionary Attacks
Dictionary attack is a type of brute force attack where an attacker tries to be-
come an authorized user via the authentication system by supplying the au-
thentication system with login credentials from a dictionary list.[39] The dic-
tionary lists are usually specialized in some way, with some specializing in
certain languages and other specializing in certain systems.
Credential Stuffing
Credential stuffing is a type of brute force attack where leaked credentials are
used in order to gain access to a system.[40] This type of attack prays on com-
mon credentials and people that reuse the same credentials for multiple sys-
tems.
Password Spraying
Password spraying is a special type of brute force attack. The method consists
of trying to brute force login with a list of multiple different usernames and
with one default password, this is done in an attempt to avoid the protection
some sites has that only allow a certain amount of tries to login.[41]
Session Hijacking
A session hijacking attack is a method for acquiring unauthorized access to
an account or system by exploiting how the session management works.[42]
This is usually done by acquiring a valid session token, this can be done in
many different ways for example with an XSS attack or by capturing network
traffic.[42]
5.3.3 Method
The penetration testing of broken authentication consisted of identifying how
the system handled brute force attacks and default credentials. The default
credentials used were discovered in the manual for the device and Burp was
used in order to gain an understanding of how the web application handles
brute force attacks.
5.3.4 Results
Discovery 1
The application uses default credentials. The system comes preconfigured
with the superadmin account, which uses the credentials admin/blank. While
the system tries to get the user to change the password during the setup phase,
it is not a must. This leaves the possibility for the system to continue using
default credentials thus making it an easy target for an malicious actor.
Discovery 2
The web application is susceptible to brute force attacks as no limit on the
amount of tries exists. With no limit on the amount of tries for logging into an
account, an attacker can try as many times as they want.
5.3.5 Discussion
An attacker can gain access to the web application by using the default creden-
tials to login and does not need to be an authorized user in order to utilize this
type of attack. To protect against this the system should not have an account
with default credentials or enforce the change of credentials during the setup
phase for the device.
An attacker can gain access to the web application by utilizing a brute force
attack on the authentication system. An attacker does not need to be an autho-
rized user in order to utilize the brute force attack. If the attack is successful
the attacker would become an authorized user and thus have access to the web
application and the video feed of the camera.
5.4 Sensitve Data Exposure

5.4.1 Introduction
The attack vector sensitive data exposure can be used when sensitive data is
not properly protected by an application.
5.4.2 Background
Sensitive data exposure is a common vulnerability. Both data in transit and
data at rest need to be protected so that only the right people can access it.
Unauthorized users gaining access to such data can be devastating for the se-
curity and integrity of the application and the privacy of its users.
There are many different ways sensitive data can be exposed, it can be through
an api that does not protect the data, it can be that data is being sent in plain-
text, bad configurations and settings, and it can be a weak crypto scheme that
is being used.
A common flaw web applications have is that it does not enforce HTTPS in-
stead of HTTP. This results in login credentials being in plaintext during trans-
portation, which means that an attacker that intercepts the traffic can easily get
ahold of the login credentials. Another common mistake is to not properly
store passwords at rest. This could be not hashing or salting the passwords, or
simply using a broken hashing scheme.
5.4.3 Method
For discovery 1 the firmware of the device was inspected in order to find the
files located in the www directory. After identifying the files, testing to see
if the files were accessible was done. For directory 2 the tool Wireshark was
used to identify the protocol used. Wireshark was also used to identify what
data was being sent with the packets.
5.4.4 Results
Discovery 1
All the files in the www directory are accessible, a malicious actor could use
this to get ahold of important information about the system and its configura-
tion by accessing configuration files placed in the www directory.
Discovery 2
The use of the HTTPS protocol is not enforced for the web application which
results in a risk that a user is using the HTTP protocol. The use of the HTTP
protocol can result in insecure transportation of important data such as login
credentials. An malicious actor intercepting those packages would then be able
to use the credentials which are presented in plaintext to login and become an
authorized user.
Discovey 3
The application exposes the user token in HTTP get request. A malicious actor
listening on the traffic can acquire the token and use it to become an authorized
user.
5.4.5 Discussion
For discovery 1, an attacker does not need to be authenticated to access the file
in the www directory. The server should be configured in such a way that an
attacker cannot access configuration files from the server. An attacker having
access to configuration files may potentially lead to an attacker being able to
exploit the web server.
For discovery 2, while the web application supports the HTTPS protocol, it
is not enforced and thus there is a risk for a user to use the insecure HTTP
protocol instead. While using the HTTP protocol packets with important in-
formation such as login credentials could be intercepted and used by a mali-
cious actor to gain authorized access. Enforcing the use of the HTTPS protocol
would defend against such attacks.
For discovery 3, an attacker does not need to be an authorized user to ex-

ploit these security flaws as only access to the network traffic is needed. With
the token being exposed in the url an attacker can use the token to become an
authorized user. In order to prevent this type of attack, the token should not
be exposed via the url.
5.5 Injections
5.5.1 Introduction
With the attack vector injections a malicious actor can exploit injection flaws
where data sent from an attacker is interpreted as a command. While there
exists many different possible injections, this section will focus on SQL injec-
tions.
5.5.2 Background
SQL
SQL, or structured query language, is a programming language used for both
creating and interacting with relational databases.[43] With SQL being the
most popular language for interacting with databases[44] it sees a widespread
use for applications throughout the web.
SQL Injections
SQL injection is a common attack vector utilized by malicious actors trying
to steal data from companies and organizations. While many desktop appli-
cations utilizes SQL databases, the SQL injection attack is used the most for
web related attacks.[45] An SQL injection consists of injecting data into a SQL
query through the client of an application.[46] A successful exploit can result
in access to information in the database, access to the database, and access
to the operating system.[46] While there are known ways to protect against
SQL injections, there are still many vulnerable applications in existence and
the attack still resides on the OWASP top 10 list.
SQL Injection Example

If an application uses a login form containing the fields username and pass-
word, the SQL query might look something like the following.
SELECT * FROM users WHERE username=’$user’
AND password=’$pass’;
A malicious actor can take advantage of the unprotected SQL query. The sin-
gle quote closes the quotes belonging to the username, OR 1=1 will make
the query always true as 1 is indeed equal to 1. Semicolon is used to close the
query and –- is used to comment out everything after it.
’ OR 1=1;--
In the final query that will be executed the $user and $pass will be replaced
with the user input in the corresponding fields of the input form. With the
input in the password field being blank and the input in the user field being as
mentioned below, the query will look like the following.
SELECT * FROM users WHERE username=’’
OR 1=1;--’ AND password=’’;
The malicious actor will then have gained access to the application.
5.5.3 Method
The penetration testing performed to find possible injection attacks was per-
formed as black box testing, meaning that no knowledge of how the system
handles the database interactions. The tool sqlmap was used to fuzz for SQL
injections within the application.
5.5.4 Results
The application does not appear vulnerable to SQL injections as no attack
during the penetration testing was successful. This does not however eliminate
the possibility of injection flaws being present in the application.
5.5.5 Discussion
No injection vulnerabilities were found in the application. An attacker does
not have to be an authorized user to search for possible injection flaws in the
application. Injection vulnerabilities is a type of vulnerability that can have
large ramifications. Had an injection exploit been found, it could possibly be
used to gain root access on the device and thus gain control over it.
To protect against SQL injections an application can use prepared statements

for the SQL queries. This is to prevent untrusted data dangerously being in-
cluded in an SQL query. Another option would be to escape or filter all the
untrusted data supplied by users.
5.6 Security Misconfiguration

5.6.1 Introduction
Security misconfiguration is an attack vector that relies on misconfigurations
of an application. Security misconfiguration is a common issue, with the attack
vector residing on the OWASP top ten list.
5.6.2 Background
Security misconfiguration vulnerabilities occur in applications that are not
properly and correctly configured. This can be because default credentials
are still in use, that the system uses software that is vulnerable or out of date,
security settings are incorrectly configured, error handling revealing too much
information, or that unnecessary features are active.[47]
5.6.3 Method
The firmware of the device was inspected in order to gain an understanding
of how the system was configured and to potentially find misconfigurations.
Security scanning software was also used to find misconfiguration in the live
application.
5.6.4 Results
Discovery 1
All the files in the www directory are accessible, a malicious actor could use
this to get ahold of important information about the system and its configura-
tion by accessing configuration files placed in the www directory.
Discovery 2
The application uses default credentials. The system comes preconfigured
with the superadmin account, which uses the credentials admin/blank. While
the system tries to get the user to change the password during the setup phase,
it is not a must. This leaves the possibility for the system to be easy to access
for a malicious actor.
5.6.5 Discussion
For discovery 1, with all the files in the www directory being accessible, an at-
tacker could use this security flaw to gain information about the system, which
could help with a potential attack. An attacker does not need to be authorized
to use this security flaw. This security issue could be resolved by changing the
configuration so that only the necessary files are accessible.
For discovery 2, an attacker can gain access to the system by using the de-
fault credentials to log in and does not need to be an authorized user in order
to utilize this type of attack. To protect against this the system should not have
an account with default credentials or enforce the change of credentials during
the setup phase for the device.
5.7 XML External Entities (XXE)

5.7.1 Introduction
XML external entities, also known as XXE, is an attack vector that relies on
XML processors that are poorly configured. XXE is a common vulnerability
and it resides on the OWASP top 10 list.
5.7.2 Background
XML
XML, or extensible markup language, is a protocol created to solve the prob-
lem om handling and maintaining information.[48] XML can be used to do
anything from formatting to filtering information[48] and is often used for
transporting and storing data.
Document Type Definition

The document type definition, or DTD, is the specification inside the XML
document that detail how elements of the XML documents should relate to
each other.[49] If a document conforms to the specification of the DTD, the
XML document is said to be valid.[49]
XML Entities
Entities in XML work like variables in other languages, it’s used to refer to a
piece of data within the XML document. An entity is declared in the document
type definition and is later referred to by reference in the XML document.[50]
For example, XML that looks like the following.
<?xml version="1.0"?>
<Car>
<Brand>Trabant</Brand>
</Car>
Could instead with XML entities be written as the following.
<!DOCTYPE Car [
<!ENTITY brand "Trabant">
]>
<Car>
<Brand>&brand;</Brand>
</Car>
This makes a piece of data reusable without the need of explicitly writing it
everywhere it is needed. A common use for entities are the characters < and >,
as they are used for tags in the XML language entities must be used instead.[51]
The kind of entities used for less-than and greater-than is known as predefined
entities.
XML External Entities

XML external entities are like entities but with the definition of the entity being
located outside of the XML document.[51] An XML document for describing
cars can with entities be written as the following.
<!DOCTYPE Car [
<!ENTITY brand "Trabant">
]>
<Car>
</Car>
With the use of external entities the XML document can instead be written as
the following.
<!DOCTYPE Car [
<!ENTITY brand SYSTEM "trabant.txt">
]>
<Car>
</Car>
Where the information for the entities is taken from the local file trabant.txt
instead of defining the value of the entity directly in the XML document. The
source which the external entity takes its information from does not have to be
a local file, it will accept any type of valid uri, for example HTTP.
XML External Entities vulnerabilities

If an application accepts user supplied data to an XML document, or accepts
XML files in file uploads an malicious actor can use it to their advantage and
possibly exploit the application. For example an malicious actor could supply
the following XML with a post request.
<!DOCTYPE exploit [
<!ENTITY test SYSTEM "file:///etc/passwd">
]>
<Exploit>
<Test>&test;</Test>
</Exploit>
If the application runs this XML and returns the result to the user, the actor
will have access to the etc/passwd file.
5.7.3 Method
For the testing of XML external entities vulnerabilities black box testing was
used. First the parts of the application that used XML had to be identified,
after that the testing for vulnerabilities could commence.
5.7.4 Results
While the parts of the application that uses XML could be identified, no XXE
exploit was found in the application as it did not accept user supplied data.
5.7.5 Discussion
No XML external entities exploit was found in the application. XXE vulner-
abilities are vulnerabilities that can have a large impact for the security of the
application. If a vulnerability had been found, depending on the exploit, it
could be used to extract data or even run remote commands. There are many
different solutions to prevent XXE vulnerabilities in an application.
5.8 Insecure Deserialization

5.8.1 Introduction
Insecure Deserialization is an attack vector where an attacker tries to use how
an application deserializes data to exploit said application. Insecure Deserial-
ization resides on the OWASP top 10 list.
5.8.2 Background
Serialization & Deserialization
Serialization is the process of taking an object and converting it to a byte-
stream.[52] This is done in order to make the data easier to transport. When the
data has been transported to the desired location it can be deserialized. Dese-
rialization is the inverse of serialization, and is the act of taking a byte-stream
and converting it back into the original object. For example the array ["I",
"like", "cats"] can look like a:3:{i:0;s:1:"I";i:1;s:4:"like";i:2;s:4:"cats";} in
serialized form, and will transformed back to ["I", "like", "cats"] when it is
deserialized.
Insecure Deserialization
Insecure deserialization can result in multiple different attacks including re-
mote code execution, replay attacks, injection attacks, and privilege escalation
attacks.[52] Insecure deserialization occurs when data that is controllable by
a user is deserialized server-side of an application.[53] That the data is user
controllable enables an malicious actor to send malicious data that will be in-
terpreted by the application.[53]
One way it can be exploited is if a website uses an serialized object as a cookie

to store important information about the user. The cookie could for example
hold the information username and user role. The cookie could then look
something like this.
a:2:{i:0;s:7:"Nicolai";i:1;s:4:"user";}
A malicious actor could then change the data of the serialized object by for
example changing the user role from user to admin.
a:2:{i:0;s:7:"Nicolai";i:1;s:5:"admin";}
This could end with the malicious actor gaining administrator privileges and
thus gaining control over the application.
5.8.3 Method
The testing for insecure deserialization vulnerabilities was divided into two
parts. In the first part of the application that used deserialization had to be
identified. In the second part the testing for vulnerabilities for the Deserializa-
tion had to be done.
5.8.4 Results
No part of the application that used deserialization could be identified, and
thus no insecure deserialization vulnerabilities were found.
5.8.5 Discussion
Whether an attacker needs to be authorized or not to exploit insecure vulnera-
bilities depends on where in the application the deserialization is used. While
no vulnerabilities with regards to insecure deserialization could be found, in-
secure deserialization vulnerabilities can lead to big security problems for an
application. There are multiple ways of preventing insecure deserialization
vulnerabilities in application. One solution is to not use serialization on un-
trusted data. If that is not an option, different types of filter and checks can be
done to the data.
5.9 Using Components with Known Vulner-

abilities
5.9.1 Introduction
Using components with known vulnerabilities is a security concern as it affects
the security of the application or device.
5.9.2 Background
An application tends to be built with multiple different components such as
frameworks and libraries. If any of these have known vulnerabilities it can
have big security ramifications for the application. To protect against these
kinds of scenarios the developers should regularly use checkers that verify
that the components are not vulnerable.
5.9.3 Method
The method used for the testing of components with known vulnerabilities
was to research the components used in the device and try to identify possible
known vulnerabilities.
5.9.4 Results
Discovery 1
The application is using Bootstrap v3.2.0 which is vulnerable to XSS attacks
which can be seen in CVE-2018-14041, CVE-2018-14040, and CVE-2018-
14042.
Discovery 2
The application is using jQuery UI - v1.11.4 which is vulnerable to XSS at-
tacks, which can be seen in CVE-2016-7103. The application uses a version
of jQuery that has a known cross site scripting exploit. While no successful
attack could be done with the vulnerability the application should still not use
a library with a known vulnerability.
Discovery 3
The application uses jQuery v2.2.0 that has a known cross site scripting ex-
ploit, which can be seen in the CWE:s CVE-2020-11023, CVE-2020-11022,
and CVE-2015-9251. While no successful attack could be done with the vul-
nerability the application should still not use a library with a known vulnera-
bility.
5.9.5 Discussion
An attacker does not need to be an authorized user to search for components
with known vulnerabilities in the device. Using components with known vul-
nerabilities can be a big security issue for an IoT device. Depending on the
vulnerability in the component an attacker can do everything from gaining ac-
cess information they should not have access to to gaining root Privilege on
the device. To protect against this the developers need to update out of date
parts of the system and avoid using components with known vulnerabilities.
5.10 Insufficient Logging & Monitoring

5.10.1 Introduction
Insufficient logging and & monitoring allows an attacker to go unnoticed for a
longer period, or even forever. Insufficient logging & monitoring is a common
security problem with applications and it resides on the OWASP top 10 list.
5.10.2 Background
Logging & monitoring is an important aspect of live applications. Having
insufficient logging & monitoring is something a malicious actor can use to
their advantage. It will give them more time to try to find weaknesses in the
system before someone finds out. In some cases a malicious actor can work in
total peace as no logging or monitoring is done.
5.10.3 Method
The testing was performed by inspecting the firmware and the live application
while trying to identify occurrences of logging and monitoring. If any occur-
rences of logging or monitoring could be found, it could be used to determine
if the logging or monitoring was insufficient.
5.10.4 Results
No instances of logging or monitoring could be found during the penetration
testing. However this does not necessarily prove that the application lacks log-
ging & monitoring as without access to the server side of the live application
the task of finding any cases of logging or monitoring was not successful.
5.10.5 Discussion
An attacker does not necessarily have to be an authorized user in order to
search for vulnerabilities regarding insufficient logging & monitoring as it de-
pends on how it is implemented on the system. Insufficient logging & mon-
itoring can be a security issue as it can make it harder to identify attacks on
the system. In order to prevent an attack being undetected, sufficient logging
& monitoring should be used for the necessary parts of the application.
5.11 Denial of Service

5.11.1 Introduction
Denial of service is the act of making a resource or system inaccessible for a
period of time.
5.11.2 Background
Denial of service is a type of attack where a malicious actor tries to make
a device or its content unavailable.[54] There are different ways this can be
done. The most common way is to overload the system with so much traffic
that someone that tries to access the system won’t get access.
Buffer overflow
There exists a possibility of using buffer overflow attacks to achieve denial of
service. This is done by causing the system to consume all its resources, be it
disk space, memory, or its CPU.[54] There also exists less common denial of
service attacks such as physically destroying equipment.
Flooding
There exist many different denial-of-service flooding attacks. Two common
flooding attacks are ICMP flooding and SYN flooding. SYN flooding attacks
work on servers that utilize TCP. If a port is in the LISTEN state TCP will
perform state retention after accepting a SYN segment.[55] SYN flooding uses
this to its advantage. SYN flooding exploits this by keeping the server busy by
creating many connections to the server, but never completes the handshake,
which takes up all the resources from the server and leaves legitimate users
unable to connect.[55] In a ICMP flooding attack, ICMP packets which have
the source spoofed as the target machine are sent out to a large group of hosts,
these host will then respond to the target machine and it will be flooded with
responses.[56]
5.11.3 Method
The method that was used in order to test if the system was vulnerable to denial
of service attacks was fuzzing. Fuzzing is a technique in which random data
is supplied as input to a program in order to find bugs or unexpected behavior.
5.11.4 Results
A denial of service attack was successfully executed against the system. A
specially crafted post request was used in order to perform the denial of service
attack. The body of a post request where a user is added normally looks like
this.
[{"cmd":"AddUser","action":0,"param":
{"User":{"userName":"test","password":"test1234",
"level":"admin"}}}]
Changing the value for the param key to something else, such as "DosTest",
will result in the system shutting off and restarting, rendering the system inac-
cessible.
[{"cmd":"AddUser","action":0,"param":"DosTest"}]
PoC for denial of service attack:
import requests
ip = <ip>
token = <token>
url = "http://" + ip +
"/cgi-bin/api.cgi?token=" + token
data =
[{"cmd":"AddUser","action":0,"param":"DosTest"}]
response = requests.post(url, json=data)
print(response.text)
The server will answer with "502 Bad Gateway" and the system will restart,
rendering the device inaccessible for a period of time. This attack can be per-
formed continuously in order to render the device inaccessible for the desired
amount of time.
5.11.5 Discussion
An attacker needs to be an authorized user in order to execute the denial of
service attack. A denial of service attack can lead to big security problems for
an application.
Chapter 6
Discussion
This chapter presents a discussion about the results and the methodology of
this thesis.
6.1 Results
The device tested in this thesis can not be considered secure as a vulnerability
was discovered during the penetration testing, as can be seen in section 5.1.
The vulnerability discovered was an XSS vulnerability, in which a malicious
actor needs to be authorized in order to successfully execute the attack and
user interaction is required. However as user tokens are exposed via the url,
as long as a malicious actor has access to the traffic, the attack can be executed.
The results in this thesis are reliable as potential vulnerabilities were tested
during the penetration testing and a PoC was created in order to verify the
validity of the vulnerability.
6.2 Methodology
The method used for this project was a penetration method with 7 steps, which
was created by Georgia Weidman.[23] The method was good as the 7 steps
ensured thorough testing of the system with regards to its security. With the
method being a broad method for penetration testing rather than a method spe-
cially designed for the thesis, more time than necessary might have been spent
on less important parts for the thesis. This came with the downside of being
time consuming as many steps had to be done before the actual penetration
testing. As a result more time was spent on threat modeling and information
54
Discussion | 55
gathering than penetration testing. Little time could be afforded to the pen-
etration testing part of the thesis, which resulted in many attack types being
excluded from the penetration testing. This also affected the depth of which
the chosen vulnerabilities could be tested.
56 | Discussion
Chapter 7
Conclusions and Future work
This chapter presents the conclusions drawn from this thesis and thoughts on
future work.
7.1 Conclusions
The goal of this thesis was to analyze and evaluate the security of the IoT de-
vice. One vulnerability was found and reported to the manufacturer. Multiple
other security issues were Identified and discussed in the thesis. Thus it can
be concluded that the web application of the device with its current firmware
does suffer from security issues.
The penetration testing conducted for this project is only a small part of the
possible vulnerabilities a system can contain. Thus there are possibilities for
future work regarding the security of the system.
It’s important to keep developing the firmware and keeping the system up to
date. Even though the security of the system has been tested, the system is con-
tinuously developed and thus the security of the system must also continuously
be tested.
7.2 Limitations
The largest limiting factor of this project was time. With more time one would
be able to do more thorough investigation of the system and test for more secu-
rity vulnerabilities, as only a small number of potential vulnerabilities could
be tested.
57
58 | Conclusions and Future work
The scope of the testing was limited to the web application as stated in section
1.6. The result of which is that there are many other parts of the system that
were not tested for security vulnerabilities in this thesis. Thus there could exist
security vulnerabilities that were not discovered because of the scope.
7.3 Future Work

As software for IoT devices in general and this system in particular are contin-
uously developed, the testing of the security of the system has to be an ongoing
process. As the penetration testing in this thesis was only conducted on one
firmware version, there exists future work in testing older and newer firmware
versions for the device as these might suffer from security vulnerabilities.
The penetration testing in this thesis had a focus on the web application of
the system. Thus there are other parts of the system that still should be se-
curity tested. Due to time limitations of the project many vulnerability types
were not included in the penetration testing. Thus there exists future work in
a more thorough testing of the system with regards to its security.
Due to cost and time, a similar device from the same manufacturer was not
investigated. It would however be interesting to investigate if the security vul-
nerabilities found in this system also exist in other devices from the same man-
ufacturer.
7.4 Ethics
Hacking can be costly in terms of violation of privacy, economical cost, and
disruption. It is thus important that hacking is done ethically.
It is important that reporting of discovered security vulnerabilities are dis-

closed in a responsible manner as it regards sensitive information. In this the-
sis, after a discovery of a security vulnerability had been made, the manufac-
turer was contacted and an agreement regarding the terms of the disclosure was
made. The terms used followed the guidelines of Coordinated Vulnerability
Disclosure: the Guideline[31] by NCSC, which meant that the manufacturer
of the device had a 90-day period to fix the found vulnerability before it would
be publicly known.
Conclusions and Future work | 59
It is important that laws and ethical considerations are thought of before per-
forming penetration testing as it can be both a sensitive and legal matter. If
penetration testing is performed in a live environment and on a system which
one does not have legal control over it is important that agreement regarding
the penetration testing is agreed on before any testing can commence. In this
project the penetration testing was done on a self-hosted IoT device which
meant that an agreement did not have to be made with the manufacturer of the
device.
References
[1] F. Dahlqvist, M. Patel, A. Rajko, and J. Shulman, “Growing op-

portunities in the internet of things,” https://www.mckinsey.com/
industries/private-equity-and-principal-investors/our-insights/growing-
opportunities-in-the-internet-of-things, Jul. 22 2019.
[2] M. Ramgir, Internet of Things, 1st ed., 2019. ISBN 93-5394-152-0
[3] R. A. Rayan, C. Tsagkaris, and R. B. Iryna, The Internet of

Things for Healthcare: Applications, Selected Cases and Challenges.
Singapore: Springer Singapore, 2021, pp. 1–15. ISBN 978-981-15-
9897-5. [Online]. Available: https://doi.org/10.1007/978-981-15-9897-
5_1
[4] “Cybersecurity vulnerabilities identified in st. jude medical’s im-

plantable cardiac devices and merlin@home transmitter: Fda
safety communication,” https://www.fda.gov/medical-devices/safety-
communications/cybersecurity-vulnerabilities-identified-st-jude-
medicals-implantable-cardiac-devices-and-merlinhome, Jan. 2017.
[5] C. Heffner, “Exploiting network surveillance cameras like a hollywood

hacker,” Black Hat conferance, Feb. 2013.
[6] Y. Seralathan, T. T. Oh, S. Jadhav, J. Myers, J. P. Jeong, Y. H. Kim, and

J. N. Kim, “Iot security vulnerability: A case study of a web camera,” in
2018 20th International Conference on Advanced Communication Tech-
nology (ICACT), 2018. doi: 10.23919/ICACT.2018.8323686 pp. 172–
177.
[7] unixfreaxjp, “Mmd-0056-2016 - linux/mirai, how an old elf malcode is

recycled..” https://blog.malwaremustdie.org/2016/08/mmd-0056-2016-
linuxmirai-just.html, Sep. 2016.
60
REFERENCES | 61
[8] G. Author, “Inside the infamous mirai iot botnet: A retrospective analy-
sis,” https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-
a-retrospective-analysis/, Dec. 2018.
[9] mcw0, “Reolink-ipc-rce,” https://github.com/mcw0/PoC/blob/master/

Reolink-IPC-RCE.py, Jun. 2018.
[10] “Cve-2019-11001 detail,” https://nvd.nist.gov/vuln/detail/CVE-2019-

11001, Apr. 2019.
[11] someLuser, “Trendnet cameras - i always feel like somebody’s watching

me.” https://console-cowboys.blogspot.com/2012/01/trendnet-cameras-
i-always-feel-like.html, Jan. 2012.
[12] G. Hilliard, “Hacking reolink cameras for fun and profit,”

https://www.thirtythreeforty.net/posts/2020/05/hacking-reolink-
cameras-for-fun-and-profit/, May 2020.
[13] Trustwave, “Trustwave spiderlabs security advisory twsl2014-007: Mul-

tiple vulnerabilities in y-cam ip cameras,” https://www.trustwave.com/
en-us/resources/security-resources/security-advisories/?fid=18912.
[14] NIST, “Cve-2015-8269 detail,” https://nvd.nist.gov/vuln/detail/CVE-

2015-8269.
[15] M. Stanislav, “R7-2015-27 and r7-2015-24: Fisher-price

smart toy® hereo gps platform vulnerabilities (fixed),” https:
//www.rapid7.com/blog/post/2016/02/02/security-vulnerabilities-
within-fisher-price-smart-toy-hereo-gps-platform/.
[16] exploitee, “Samsung smartcam,” https://www.exploitee.rs/index.php/

Samsung_SmartCam%E2%80%8B.
[17] B. Donohue, “Urban surveillance camera systems lacking security,”

https://www.kaspersky.com/blog/urban-surveillance-not-secure/8901/.
[18] Cisco, “Cisco firepower device manager on-box software xml external
entity vulnerability,” https://www.cisco.com/c/en/us/support/docs/csa/
cisco-sa-fdm-xxe-zR7sxPfs.html.
[19] S. Black, “Citrix investigating unauthorized access to internal net-

work,” https://www.citrix.com/blogs/2019/03/08/citrix-investigating-
unauthorized-access-to-internal-network/.
62 | REFERENCES
[20] D. Henshall, “Citrix concludes investigation of unauthorized inter-

nal network access,” https://www.citrix.com/blogs/2019/07/19/citrix-
concludes-investigation-of-unauthorized-internal-network-access/.
[21] NIST, “Cve-2018-18392 detail,” https://nvd.nist.gov/vuln/detail/CVE-

2018-18392.
[22] Kaspersky, “Klcert-18-020: Moxa thingspro iiot gateway and device

management software solutions: Broken access control,” https://ics-
cert.kaspersky.com/advisories/klcert-advisories/2018/10/18/klcert-18-
020-moxa-thingspro-iiot-gateway-and-device-management-software-
solutions-broken-access-control/.
[23] G. Weidman, Penetration Testing: A Hands-On Introduction to Hack-

ing. San Francisco: No Starch Press, Incorporated, 2014. ISBN
9781593275648
[24] “Searchable fcc id database,” https://fccid.io/.
[25] “Reolink,” https://reolink.com/.
[26] “Nmap,” https://nmap.org/.
[27] S. E. Team, “The 5 pillars of a successful threat model,”

https://www.synopsys.com/blogs/software-security/5-pillars-
successful-threat-model/, Jul. 2016.
[28] Microsoft, “The stride threat model,” https://docs.microsoft.com/en-us/

previous-versions/commerce-server/ee823878(v=cs.20), Nov. 2009.
[29] “Nikto,” https://cirt.net/Nikto2.
[30] “Owasp top ten,” https://owasp.org/www-project-top-ten/.
[31] NCSC, “Coordinated vulnerability disclosure: the guideline,”

https://english.ncsc.nl/binaries/ncsc-en/documents/publications/2019/
juni/01/coordinated-vulnerability-disclosure-the-guideline/WEB_
Brochure-NCSC_EN.pdf.
[32] OWASP, “Cross site scripting (xss),” https://owasp.org/www-

community/attacks/xss/.
[33] “Cross-site scripting,” https://portswigger.net/web-security/cross-site-

scripting.
REFERENCES | 63
[34] “Reflected xss,” https://portswigger.net/web-security/cross-site-

scripting/reflected.
[35] “Dom-based xss,” https://portswigger.net/web-security/cross-site-

scripting/dom-based.
[36] PortSwigger, “Dom-based vulnerabilities,” https://portswigger.net/web-

security/dom-based/.
[37] “Access control vulnerabilities and privilege escalation,” https://

portswigger.net/web-security/access-control.
[38] “A2:2017-broken authentication,” https://owasp.org/www-project-top-

ten/2017/A2_2017-Broken_Authentication.
[39] RAPID7, “What are brute-force and dictionary attacks?” https://www.

rapid7.com/fundamentals/brute-force-and-dictionary-attacks/.
[40] OWASP, “Credential stuffing,” https://owasp.org/www-community/

attacks/Credential_stuffing.
[41] ——, “Password spraying attack,” https://owasp.org/www-community/

attacks/Password_Spraying_Attack.
[42] ——, “Session hijacking attack,” https://owasp.org/www-community/

attacks/Session_hijacking_attack.
[43] C. Fehily, SQL, 3rd ed., ser. Visual quickstart guide. Berkeley, [Calif.]:
Peachpit Press, 2008.
[44] “Tiobe index for may 2021,” https://www.tiobe.com/tiobe-index/.
[45] “How to protect against sql injection attacks,” https://security.berkeley.

edu/education-awareness/how-protect-against-sql-injection-attacks.
[46] “How to protect against sql injection attacks,” https://owasp.org/www-

community/attacks/SQL_Injection.
[47] “A6:2017-security misconfiguration,” https://owasp.org/www-project-

top-ten/2017/A6_2017-Security_Misconfiguration.
[48] E. T. Ray, Learning XML. Cambridge, Mass.: O’Reilly, 2001. ISBN

0-596-00046-4
[49] R. Eckstein, XML pocket reference, 1st ed., 1999. ISBN 0-596-15226-4
64 | REFERENCES
[50] S. Holzner, Inside XML, 1st ed. Indianapolis, Ind.: New Riders, 2001.
ISBN 0-7357-1020-1
[51] “Xml entities,” https://portswigger.net/web-security/xxe/xml-entities.
[52] S. Borso, The Penetration Tester’s Guide to Web Applications, ser. Artech
House information security and privacy series. Norwood: Artech
House, 2019. ISBN 9781630816223
[53] “Insecure deserialization,” https://portswigger.net/web-security/

deserialization.
[54] “What is a denial-of-service attack?” https://www.cloudflare.com/

learning/ddos/glossary/denial-of-service/.
[55] W. Eddy, “TCP SYN Flooding Attacks and Common Mitigations,” RFC
4987, Aug. 2007. [Online]. Available: https://rfc-editor.org/rfc/rfc4987.
txt
[56] CISA, “Understanding denial-of-service attacks,” https://us-cert.cisa.

gov/ncas/tips/ST04-015.
REFERENCES | 65
TRITA-EECS-EX-2021:843
www.kth.se

FULLTEXT01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FULLTEXT01

Uploaded by

Copyright:

Available Formats

DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING,

SECOND CYCLE, 30 CREDITS

Ethical Hacking of an IoT

KTH ROYAL INSTITUTE OF TECHNOLOGY

Degree Programme in Computer Science and Engineering

Supervisor: Pontus Johnson

I denna avhandlingen har säkerheten av IoT-enheten Reolink E1 Zoom ana-

Stockholm, August 2021

List of Acronyms and Abbreviations

4.3.1 Identified threats . . . . . . . . . . . . . . . . . . . . 25

7 Conclusions and Future work 57

4.1 External information flow of system . . . . . . . . . . . . . . 22

5.1 XSS attack on system . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Identified Technologies for the IoT system. . . . . . . . . . . . 20

1.2.1 Research Question

1. Does the Reolink E1 Zoom have security vulnerabilities?

1.4 Research Methodology

1.6 Structure of the thesis

• Chapter 2 presents relevant related work about penetration testing and

• Chapter 3 presents the methodology and method used to create a threat

• Chapter 4 presents the threat modeling conducted for the project.

• Chapter 6 presents the discussion.

• Chapter 7 presents the conclusion and future work.

In a blogpost named Trendnet Cameras - I always feel like somebody’s watch-

In a document published in May 2014, the Trustwave SpiderLabs team pub-

A vulnerability was found in the Samsung SmartCam where a bug allowed

In April 2019 Citrix mentioned in a blogpost named "Citrix investigating unau-

3.2 Information Gathering

3.3 Threat Modeling

1. Define scope and depth of analysis

2. Gain an understanding of what is being threat modeled

3. Model the attack possibilities

4. Interpret the threat model

5. Create a traceability matrix to record missing or weak controls

Define scope and depth of analysis

Gain an understanding of what is being threat modeled

Model the attack possibilities

2. Tampering with data

Tampering with data

Interpret the threat model

Create a traceability matrix to record missing or weak

3.4 Vulnerability Analysis

3. Sensitive Data Exposure

4. XML External Entities (XXE)

5. Broken Access Control

7. Cross-Site Scripting (XSS)

9. Using Components with Known vulnerabilities

10. Insufficient Logging & Monitoring

Sensitive Data Exposure

XML External Entities (XXE)

Broken Access Control

Cross-Site Scripting (XSS)

Using Components with Known vulnerabilities

Insufficient Logging & Monitoring

3.6 Post Exploitation

4.1 Understanding the System

Table 4.1: Identified Technologies for the IoT system.

4.2 Modeling the attack possibilities

Table 4.3: Identified assets of the IoT system.

4.2.2 Security controls

Table 4.4: Identified security controls of the IoT system.

4.2.3 Threat agents

Table 4.5: Identified threat agents of the IoT system.