Thesis Archive

Download as pdf or txt
Download as pdf or txt
You are on page 1of 71

MASARYK

UNIVERSITY
FACULTY OF INFORMATICS

MCUXpresso Web Application


Security

Bachelor's Thesis

PETR SELINGER

Brno, Spring 2023


MASARYK
UNIVERSITY
FACULTY OF INFORMATICS

MCUXpresso Web Application


Security

Bachelor's Thesis

PETR SELINGER

Advisor: RNDr. Zdeněk Matěj, Ph.D.

Degree Program: Cybersecurity

Brno, Spring 2023


Declaration

Hereby I declare that this paper is my original authorial work, which


I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed i n complete reference to the due source.

Petr Selinger

Advisor: R N D r . Zdeněk Matěj, Ph.D.

iii
Acknowledgements

I w o u l d like to thank my advisor, R N D r . Zdenek Matej, Ph.D., for


supervising me throughout the creation of this thesis, and thank my
family for supporting me during my studies.
I would also like to express my gratitude to Mgr. Denisa Bodeckova
for her endless patience and for providing me with splendid food and
a superb study environment.
Special thanks go to my classmates in the Cybersecurity program. I
have enjoyed the academic journey and was able to complete it thanks
to them.

iv
Abstract

In today's highly digital world, web applications are capable of per-


forming a variety of sophisticated tasks, which also makes them more
complex. This complexity opens a space for new vulnerabilities, and
attackers are more motivated and active than ever. O n the other hand,
there are tools, techniques, and comprehensive knowledge sources
that help to find and prevent such vulnerabilities.
This thesis aims to provide a basic overview of web applications
and security, explain each category of the OWASP Top 10 list of vulner-
abilities, and demonstrate the hacking environment, techniques, and
tools. I utilize all the acquired knowledge in the last part of the thesis
to provide a proper security analysis of the real-world M C U X p r e s s o
S D K Builder web application. Furthermore, I present an automated
test and further security recommendations to improve the security of
the MCUXpresso web application.

Keywords

cybersecurity web application security, vulnerabilities, OWASP, OWASP


Top 10, hacking, MCUXpresso, N X P

v
Contents

Introduction 1

1 Web Application Security 3


1.1 Web Applications 3
1.2 Security and Terminology 6
1.2.1 CIA 7
1.2.2 NISTNVD 7
1.2.3 Mitre 8
1.2.4 CWEandCVE 8
1.2.5 CVSS 8
1.2.6 PortSwigger 9

2 OWASP Top 10:2021 10


2.1 A01 Broken Access Control 11
2.2 A02 Cryptographic Failures 12
2.3 A03 Injection 13
2.4 A04 Insecure Design 14
2.5 A05 Security Misconfiguration 15
2.6 A06 Vulnerable and Outdated Components 16
2.7 A07 Identification and Authentication Failures 17
2.8 A08 Software and Data Integrity Failures 18
2.9 A09 Security Logging and Monitoring Failures 19
2.10 A10 Server-Side Request Forgery (SSRF) 20

3 Hacking Skills, Techniques, and Tools 22


3.1 Hacking Environment and Skills 22
3.1.1 Note Keeping 22
3.1.2 Information Searching 23
3.1.3 Virtual Machines and Private Networks 23
3.1.4 K a l i Linux 23
3.1.5 Unix 24
3.1.6 Bash and Python Scripting 24
3.1.7 Browser Developer Tools 24
3.2 Passive Reconnaissance 25
3.2.1 Website Reconnaissance 25

vi
3.2.2 Social Media Reconnaissance 25
3.2.3 Advanced Google Search 26
3.2.4 Dark Web 26
3.3 Active Reconnaissance 26
3.3.1 Website Analysis 27
3.3.2 Finding Sub domains 27
3.3.3 E-mail Address Gathering 27
3.4 Scanning and Enumeration 28
3.4.1 Httprobe 28
3.4.2 Nmap 28
3.4.3 Nikto 29
3.4.4 Dirb 29
3.4.5 Wapiti 29
3.5 Exploitation 30
3.5.1 Sqlmap 30
3.5.2 Metasploit 30
3.5.3 O W A S P Zed Attack Proxy 30
3.5.4 Burp Suite 31

4 MCUXpresso Analysis and Recommendations 32


4.1 MCUXpresso Reconnaissance 33
4.2 MCUXpresso Scanning and Enumeration 39
4.3 M C U X p r e s s o Exploitation 43
4.4 Automated Test Implementation 47

4.5 Summary and Recommendations 49

Conclusion 51

Bibliography 52

A List of Abbreviations 61

B Attached Archive 62

vii
List of Figures

1.1 Standard web application architecture 5


1.2 Uber's microservices web application architecture . . . . 5
1.3 Percentage of at least one successful attack on organizations 6
1.4 CVSS v2.0 and CVSS v3.0 comparison 9
2.1 OWASP Top 10 2017 and 2021 comparison 10
4.1 MCUXpresso home page 33
4.2 M C U X p r e s s o / N X P login page 34
4.3 Account creation first part 35
4.4 Verification e-mail 36
4.5 Account creation second part 37
4.6 Home page (Dashboard) after login 38
4.7 Landing page for developer.nxp.com (left) and dev-my.nxp.com
(right) 40
4.8 Landing page for amec-ssl-test.nxp.com (left) and community-
staging.nxp.com (right) 40
4.9 Nikto scan output 42
4.10 Part of Wapiti scan summary 42
4.11 Part of sqlmap output 43
4.12 OWASP Z A P automated scan result 44
4.13 S Q L injection attempt via Burp Suite 45
4.14 XSS attempt 46
4.15 Two screenshots of password resetting 47
4.16 Testing script for basic analysis of M C U X p r e s s o and re-
lated nxp.com domains 48

viii
Introduction

Web applications are faster, more versatile, and more intelligent than
ever before. They have all the unique features and outstanding ani-
mations and effects. O n the other hand, these benefits come at a cost.
Web applications are becoming more complicated. Every year, new
technologies and methodologies emerge and evolve at a rapid pace.
Understanding the whole complex is certainly challenging, and it
takes many years to master it. In addition, more complexity brings us
potential room for mistakes, creating vulnerabilities and, thus, less
secure web applications. Nowadays, almost all web applications are
publicly accessible and tend to have various vulnerabilities they need
to defend against. A s a result, they need to be secure and resilient to
various types of attacks.
In the beginning, i n Chapter 1, the thesis briefly describes how
old websites and web applications were developed, how modern web
applications are developed now, and the trend i n their architecture.
Then the general view on current cybersecurity and web application
security is described. Some essential terminologies are explained for a
more comfortable orientation throughout the web application security
and the thesis.
Chapter 2 illustrates the established global standard i n web appli-
cation security—OWASP Top 10 list of vulnerabilities. A l l ten vulnera-
bilities are explained, and further recommendations for developers
are given, represented w i t h actual vulnerability examples.
A l l amateur and professional security engineers, penetration testers,
and hackers need a set of tools and principles to succeed i n finding
vulnerabilities. They also need broad informational technology knowl-
edge and must master specific skills. These topics are covered in Chap-
ter 3.
The acquired knowledge and experience are then utilized in Chap-
ter 4 i n the real-world web application called M C U X p r e s s o S D K
Builder for complex security analysis w i t h extensive reports. The au-
thor of the thesis provides the analysis and comments on the whole
process from his point of view. Furthermore, the author introduces an
automated test w i t h a step-by-step explanation. Based on the results,

1
INTRODUCTION

further recommendations are given to achieve more pleasing security


results.
The outcomes are then summarized i n the last part of the the-
sis—Conclusion. There are also additional remarks and thoughts of
the author on web application security i n general and a broader per-
spective on the whole cybersecurity industry.

2
1 Web Application Security

In this chapter, the thesis briefly describes how websites and old web
applications were built, how modern web applications are built nowa-
days, and related newly designated web application architectures.
The next subject of this chapter focuses on the general security
of web applications and a few security terms for a more comfortable
orientation i n the security field and the thesis.

1.1 Web Applications

Only simple websites existed at the beginning of the World Wide Web.
They were built with the Hypertext Markup Language ( H T M L ) to show
basic content, mostly text, and images, to users i n their browsers. The
users could read the loaded content and click on some other links i n
the text or click on buttons i n some forms. This action created a request
via Hypertext Transfer Protocol (HTTP) from the user's browser {front
end) to a related server (back end) that was responsible for handling
these requests and sending the new H T M L page back to the front
end. A l l the H T M L pages were already written d o w n i n separate
files, meaning the back end merely looked for the correct file with the
H T M L content and sent it back to the front end.
This bland experience was then improved by using Cascading Style
Sheets (CSS) as a "designing" language to enhance the website's ap-
pearance. Furthermore, JavaScript language was invented to integrate
dynamic features into the website.
The dynamic JavaScript innovation was crucial for both developers
and users. Developers could be more creative and flexible i n the con-
tent they display to the users. Regarding the users' real-time actions,
the website could dynamically react and generate other content.
Clearly, the users were facing a m u c h better experience, and es-
pecially personalization was n o w achievable. This was the moment
when web applications started to exist. It was not anymore only about
static H T M L websites, but the dynamic elements and varied features
started being developed.
Despite the progress expressed i n previous paragraphs, the overall
web application architecture was still relatively straightforward. The

3
i . W E B A P P L I C A T I O N SECURITY

most common occurrence used to be a front end developed w i t h the


mentioned trio of H T M L , CSS, and JavaScript. It was connected to a
back end via H T T P requests. A few languages were used to create the
back end, for example, Hypertext Preprocessor ( P H P ) , Perl, and Java,
and they contained the main business logic of the web application.
Finally, cookies or a database were used to store data, such as MySQL,
PostgreSQL, or simple comma-separated values (CSV) files databases
written i n those back end languages. Clear three divided parts of a
web application have been established i n the past—front end, back
end, and database.
Current web application technological and methodological bun-
dles are m u c h more complicated. The front-end design (the look,
animations, feedback to users) has gotten more pleasing; moreover,
the comprehensive logic in the front end is now possible too. The noted
trio remained the same ( H T M L , CSS, JavaScript) but has developed
rapidly. Especially the usage of JavaScript frameworks, such as React,
Angular, Vue, and Svelte, is a must-have these days. O n the other hand,
the back end is written in many languages and their frameworks. The
popular example frameworks are Laravel in PHP, Spring in Java, Django
and Flask i n Python, and Express, NestfS, and Strapi i n JavaScript. Be-
sides, the back end and front end communicate v i a a new mediator
called Application Programming Interface (API). A l s o , there are new
ways to store data, like Web Storage, IndexedDB, or Service Workers. [1,
2]
The traditional architecture is called monolithic, where the applica-
tion parts are interdependent and interconnected, and to change anything,
the whole application must be compiled and deployed again. Nev-
ertheless, new web application architectures have been designated
with the elevation of previously mentioned technologies. Many serve
the need for better speed, scalability, modularity, and flexibility across
many end-user devices. One of the hottest principles is a microservices
architecture, where developers split the heavy application into slim
and independent services that can be deployed and maintained effi-
ciently. They communicate between themself through APIs. Another
impressive and breakthrough architecture is serverless architecture.
The back end is written into independently executable functions, stored in
cloud services (Amazon Web Services [3] (AWS) is a great cloud service
example), and used only when needed after an event is triggered. This

4
i . W E B A P P L I C A T I O N SECURITY

way, the costs and maintenance are reduced, and developers can focus
more on web application design and functionality. [4]
The architectural complexity difference can be seen immediately
in the following two figures. Figure 1.1 shows the standard traditional
web application architecture, and Figure 1.2 shows an example of the
microservices web application architecture from Uber.

L|j| Presentation Layer

L[fj Business Layer

[_fT?J Data Layer

Figure 1.1: Standard web application architecture [4]

Figure 1.2: Uber's microservices web application architecture [5]


i . W E B A P P L I C A T I O N SECURITY

1.2 Security and Terminology

As the previous chapter shows, the overall complexity and number of


different technologies and principles have grown extensionally. This
growth undoubtedly opens up a significant space for developers to
create new innovative, more efficient products, solving other people's
needs. However, this results in people being more dependent on those
applications.
In addition, more people worldwide are connected to the Inter-
net, the world is becoming more digitalized, and people spend more
time using various applications daily. According to the 2022 report by
DataReportal, the average person spends almost 7 hours daily using the
Internet, and 192 million people are newly connected to the Internet.
[6]
A s a consequence of this situation, attackers are more motivated
for further attacks to gain various sensitive information about all these
users that can be sold on black markets (mostly on dark web ) or 1

utilized for further fraudulent actions.


The growth of at least one successful attack on organizations can
be seen i n Figure 1.3.

86.2%

2014 2015 2016 2017 2018 2019 2020 2021

Figure 1.3: Percentage of at least one successful attack on organizations


[8]

1. Dark web is a part of the deep web (hidden web, not indexed by standard search
engines for various reasons). Accessible through special configurations and software,
primarily used for illegal goods trading and fraudulent online activities. [7]

6
i . W E B A P P L I C A T I O N SECURITY

For these reasons, there is tremendous pressure on web application


security too. Companies and national institutions must have appro-
priate internal security policies and focus more on defending their
applications. A s a result, there is already a significant job interest
in cybersecurity experts, and it w i l l be even more significant i n the
following years. [9]
Fortunately, a few companies and foundations have been estab-
lished that are excellent sources of knowledge for overall cybersecurity
and web application security. They are determining the industry stan-
dards. The subsequent paragraphs briefly mention some of those
security companies, foundations, and other terms. They w i l l be re-
ferred to i n the other parts of the thesis and serves as an entrance to
cybersecurity i n general. Nevertheless, the primary source of infor-
mation about web application security for this thesis is used from the
OWASP Foundation, described i n Chapter 2.

1.2.1 CIA

Confidentiality, Integrity, and Availability, or the CIA triad, is the most


k n o w n established guide used across the entire cybersecurity field.
It consists of three principles: Confidentiality is about privacy and
protection of sensitive information from unauthorized access. Integrity
refers to accurate and reliable information to protect the data against
attacker modification. Availability relates to dependable access of
authorized users to related information anytime there is a need. [10]

1.2.2 NISTNVD

The National Institute of Standards and Technology (NIST) is a U.S. govern-


ment organization determining global standards for industry, science,
and technology. [11] One of their projects is the National Vulnerability
Database ( N V D ) , the primary source of information about all known
vulnerabilities—providing a description, categorizing, scoring, and
other expertise measurements. [11]

7
i . W E B A P P L I C A T I O N SECURITY

1.2.3 Mitre

Mitre is a nonprofit corporation based in the U.S. with experts research-


ing, innovating, and publicly delivering solutions to complicated
worldwide problems ranging from cybersecurity and 5G through
aviation safety to healthcare and numerous other specializations. [12]
Their cybersecurity-related project is called Adversarial Tactics, Tech-
niques, and Common Knowledge ( A T T & C K ) . Particularly the ATT&CK
Matrix for Enterprise, a comprehensive knowledge base of methods,
techniques, and other security recommendations w i t h real-world ex-
amples. [13]

1.2.4 CWEandCVE

C W E stands for Common Weakness Enumeration, and CVE stands for


Common Vulnerabilities and Exposures. Both are openly developed by
a community and maintained by Mitre. The goal of these projects is
to appoint a cybersecurity dictionary. They together create a globally
organized catalog of all publicly known vulnerabilities w i t h detailed
descriptions, a scoring system, and other features to unify the proce-
dures to defend software. [14,15]
When a new vulnerability or exposure is discovered, it is assigned
to a C W E category. A new C V E identifier is given to track the related
issues more adequately on the developers' side. For instance, a vulner-
ability labeled as CVE-2020-6969 [16] and categorized into CWE-522:
Insufficiently Protected Credentials. [14,15]

1.2.5 CVSS

CVSS refers to Common Vulnerability Scoring System and is created and


maintained by the FIRST organization. It provides a unified method-
ology for the severity measurement of vulnerabilities. This scoring
system aims to provide a standardized way of vulnerability severity
for organizations to prioritize their resources sufficiently. There are
more versions of this scoring system.
The system assigns a value, ranging from 0 to 10 (10 is the most
severe), to each vulnerability based on its attributes, such as its impact
and exploitability. Currently, CVSS Version 3.x is used, and not all CVEs
have the score attached; however, there is always at least a CVSS

8
i . W E B A P P L I C A T I O N SECURITY

Version 2.0 score if the 3.x score does not exist. For example, the C V E
from the previous paragraph has a critical score of 9.8. [16,17]
Figure 1.4 shows the comparison in severity naming and base score
ratings for CVSS v2.0 and v3.0.

CVSS v2,0 Ratings CVSS v3.0 Ratings

Severity Base Score Range Severity Base Score Range

None 0.0
LOW 0.0-3.9 Low 0.1-3.9
Medium 4,0-6.9 Medium 4.0-6.9
High 7.0-10.0 High 7.0-8.9
Critical 9.0-10,0

Figure 1.4: CVSS v2.0 and CVSS v3.0 comparison [17]

1.2.6 PortSwigger

Like the O W A S P Foundation, the PortSwigger company significantly


impacts web application security. Even though their main focus is
doing business, mainly by selling their web application security tool
Burp Suite (described i n Section 3.5.4), they produce tremendous
research, educational news, and security recommendations on their
website. Companies like Google, Microsoft, A m a z o n , and Samsung
rely on PortSwigger's work. [18]

9
2 OWASP Top 10:2021

The Open Worldwide Application Security Project (OWASP) is an open-


source non-profitable foundation heavily supported by a broad com­
munity. Throughout the years, the OWASP Foundation has established
itself as an informational, educational, and innovative global authority
in the software security field, primarily focused on web application
security. They have produced numerous flourishing projects, such as
OWASP Top 10, OWASP Zed Attack Proxy (described i n Section 3.5.3),
and OWASP Web Security Testing Guide. [19]
Nonetheless, the main focus of this chapter is on the OWASP Top
10 list of vulnerabilities. This project is undoubtedly the must-have
learning material for all web application developers. The recent list of
vulnerabilities was created in 2021; the previous version is from 2017.
The comparison and changes between these two versions can be seen
in Figure 2.1 below. Detailed information about the methodology can
be found o n the OWASP Top 10 home page. [20]
The following sections explain every single category from the
O W A S P Top 10:2021 list. A section is split into three parts. A t first,
there is a short description of the category, including an exact number
of total occurrences ("total number of applications found to have the CWEs
mapped to a category" [20]). The second part contains mitigation, how
to prevent these vulnerabilities, with recommendations for developers.
The third part is about mentioning a few real-world examples.

2Q17 2021
A01:2017-lnjection jr A01:2021-Broken Access Control
A02:2017-Broken Authentication —— f^Ĺ—^r A02:2021-CrvptograDhic Failures
A03:2017 Sensitive Data Exposure A03:2021-hjection
Arj4:2017-XML External Entities (XXE) —-ř-OSs. ^ ( N é w ) A04;2021 Insecure Design
A05:2017-Broken Access Control -H. — A 0 5 : 2 0 2 1 - S e c u r i t y Misconfiguration
A06:2O17-Securíty M ^configuration ^x^? A06:2021-Vulnerable and Outdated Components
A07:2017-Cross-Site Scripting (XSS) A07:2021-ldentification and Authentication Failures
A0S:2017-lnsecure Deserialization I'!. .-. A08:2021-Software and Data Integrity Failures
A09:2017-Using Components with Known Vulnerabilities ^ A09:2021-Security Loggingand Monitoring Failures*
A10:2017-lnsufficient Logging 6c Monitoring (New) A10:2021-Server-5ide Request Forgery (SSRF)*
• From the Survey

Figure 2.1: OWASP Top 10 2017 and 2021 comparison [20]

10
2. OWASP T O P 1 0 : 2 0 2 1

2.1 A01 Broken Access Control

Broken Access Control is an essential component of web application


security, containing the most occurrences—318,487. It helps ensure
that users only have access to the resources and functionality they
are authorized to access. Users cannot access sensitive information or
perform actions that they should not. Attackers can exploit this v u l -
nerability to gain access to sensitive information, manipulate data, or
perform actions that should be restricted if access control mechanisms
are not adequately implemented. [21]

Mitigation

To prevent Broken Access Control vulnerabilities, developers should


implement strong access controls that restrict users to only the re-
sources and functionality they are authorized to use. This can be
achieved by using role-based access control, w h i c h assigns roles to
users based on their permission level. Another method is to use ac-
cess control lists, w h i c h define the resources each role is allowed to
access. In addition, developers should ensure that access controls are
correctly implemented and tested throughout development and that
security controls are periodically reviewed and updated to address
new threats. [21]

Examples

One of the most known CWEs from this category is CWE-200: Exposure
of Sensitive Information to an Unauthorized Actor. N V D published the
first available attack from CWE-200 on 9th January 2001. The attack
is labeled CVE-2000-1117 [22] and illustrates a feature b u g i n Java
Virtual Machine. [21]

11
2. OWASP T O P 1 0 : 2 0 2 1

2.2 A02 Cryptographic Failures

The Cryptographic Failures contain 233,788 occurrences, w h i c h refer to


vulnerabilities driven by the inappropriate use or implementation
of cryptographic functions. These vulnerabilities can appear i n var-
ious contexts, including mobile and web applications and network
protocols. Software systems typically use cryptographic functions to
provide data CIA. Nonetheless, if cryptographic functions are not i m -
plemented accurately, applications can be vulnerable to key cracking,
data forgery, and man-in-the-middle attacks. [24]
1

Mitigation

Developers should use established and tested cryptographic algo-


rithms and functions to mitigate Cryptographic Failures vulnerabili-
ties. Moreover, adequately implement them based on industry bench-
marks and best practices. Cryptographic keys should be stored se-
curely, and input and output validation should be performed to ensure
the integrity and authenticity of the data. Besides, developers should
follow secure coding practices, regularly review code for vulnerabili-
ties, and perform regular vulnerability assessments and penetration
testing to identify and mitigate potential weaknesses. [24]

Examples

CWE-327: Use of a Broken or Risky Cryptographic Algorithm contains good


examples of w h y developers should, without a doubt, spend extra
time learning and using more complex cryptographic algorithms. Even
Microsoft made a mistake and created a cryptographic vulnerability.
It was labeled CVE-2007-5460 [25] and published by N V D on 15th
October 2007. Windows Mobile 5.0 used only X O R obfuscation w i t h
a fixed key w h e n data flowed from one device to another via a USB
connection. The attacker could easily deobfuscate users' passwords.
[24]

1. A man-in-the-middle is a common attack where the attacker hacks stealthily be-


tween two communicating machines and listens to or moderates the communication
without the machines noticing.[23]

12
2. OWASP T O P 1 0 : 2 0 2 1

2.3 A03 Injection

In 2017 list the Injection vulnerabilities positioned in the first place. In


the 2021 list, it has been merged w i t h Cross-Site Scripting (XSS) v u l -
nerabilities and moved d o w n to third place, w i t h 274,228 occurrences.
The cause of the Injection is inappropriate input validation or saniti-
zation. These varieties of vulnerabilities can appear i n a wide variety
of environments, such as mobile applications, web applications, and
databases. Injection vulnerabilities arise when untrusted user input is
not correctly validated or sanitized. Furthermore, if it is used i n SQL
queries or commands to back-end systems, this can allow attackers to
inject malicious code into the back-end systems. A s a result, it leads to
unauthorized access to sensitive data, corruption, or theft. [26]

Mitigation

To prevent Injection vulnerabilities, developers should always per-


form validation and sanitization of untrusted users' input data before
using it in a back-end system command or query. This includes using
parameterized queries, preparing functional statements to prevent
SQL injection, and verifying user input to prevent command injection.
Developers should implement proper input validation and output
encoding to prevent any other type of injection. Additionally, secure
coding techniques and periodic code auditing should be utilized. In
general, these types of vulnerabilities could be efficiently tested both
manually and automatically by many security tools or custom pene-
tration scripts. [26]

Examples

There are two C W E s , w h i c h represent two of the most k n o w n at-


tack types. The first is CWE-79: Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting'). This enumeration includes
a CVE-2021-1879 [27], where the software i n A p p l e devices (iOS,
iPadOS, watchOS) was able to process malicious code. The second
enumeration is CWE-89: Improper Neutralization of Special Elements used
in an SQL Command ('SQL Injection'), containing a vulnerability la-

13
2. O W A S P T O P 1 0 : 2 0 2 1

beled CVE-2007-6602 [28], where attackers could execute any SQL


command through the username field. [26]

2.4 A04 Insecure Design

W i t h the general rise of design and architectural complexity, this


O W A S P category is newly introduced i n the 2021 list, containing
262,407 occurrences. Insecure Design directs to vulnerabilities caused
by insecure or flawed design decisions i n software. Software systems
are designed with security drawbacks that attackers can control. Such
design decisions make it more straightforward for attackers to bypass
security measures, steal sensitive data, or gain unauthorized access to
systems. Network protocols and mobile and web applications are the
main targets of these vulnerabilities. [29]

Mitigation

Developers should use established secure software design principles


to mitigate Insecure Design vulnerabilities. Namely, using appropriate
error handling and logging, deploying proper consumption moni-
toring, and setting up comprehensive boundaries for resources used
by services and users. DevOps, more usually DevSecOps engineers,
should be responsible for designing secure models. Developers should
do routine testing and validate that all critical flows resist the threat
model by writing integration and unit tests. [29]

Examples

Insecure Design has got the most extended list of C W E s . M a n y of


these C W E s have a familiar topic: using or storing critical sensitive
information without insufficient protection. Proof of this is a C W E -
312: Cleartext Storage of Sensitive Information. Specifically, a vulnerability
known as CVE-2005-2160 [30], where an application called IMail kept
usernames and passwords in a cookie. Moreover, they stored them in
plaintext. Another notable enumeration is CWE-209: Generation of Error
Message Containing Sensitive Information. For instance, in a vulnerability
labeled CVE-2018-1999036 [31] where Jenkins SSH Agent Plugin was

14
2. OWASP T O P 1 0 : 2 0 2 1

used, users w i t h correct permission could get an S S H private key


password from build logs. [29]

2.5 A05 Security Misconfiguration

Security Misconfiguration vulnerabilities, including 208,387 occurrences,


occur in various applications. The typical Security Misconfiguration is
using default accounts w i t h default or significantly weak passwords.
Furthermore, the applications could lack any security configuration, or
the configuration could be set up improperly across all the application
services w h e n giving permissions or upgrading some parts of the
system. There is also a need for reasonable error handling; applications
cannot show or send sensitive information to users w h e n an error
occurs during the production run. [32]

Mitigation

To prevent Security Misconfiguration vulnerabilities, developers should


follow well-established security practices. Part of them is never to use
default accounts and passwords. Moreover, developers should intro-
duce strong password policies and configure two-factor authentication.
Internal IT specialists and security engineers should be responsible
for correctly establishing and supervising all environments' accesses
and permissions. Additionally, developers should remove all disabled
and unused frameworks, features, and other services to remain the
technological bundle as compact as possible. Lastly, periodic security
audits ought to prevent those security vulnerabilities. [32]

Examples

There are a lot of various enumerations. One of them, CWE-756: Miss-


ing Custom Error Page, does not seem particularly dangerous i n the
first place; however, w h e n a custom error page is missing, the appli-
cation shows the complete log to the user, and developers cannot be
sure what the page content is going to be. Unfortunately, there is no
related C V E example. Other admirable enumerations are CWE-547:
Use of Hard-coded, Security-relevant Constants, and CWE-526: Cleartext
Storage of Sensitive Information in an Environment Variable. For instance,

15
2. OWASP T O P 1 0 : 2 0 2 1

JetBrains TeamCity software had password environment variables


visible i n their logs—CVE-2022-25264 [33]. [32]

2.6 A06 Vulnerable and Outdated Components

In sixth place is a category called Vulnerable and Outdated Components,


with 30,457 occurrences. These vulnerabilities happen when an applica-
tion use outdated, unsupported, or vulnerable components. With the
rising technological complexity, these vulnerabilities can appear i n
any application layer, such as servers, databases, APIs, and the front
end. These layers utilize various frameworks, third-party libraries,
and environments. It is a difficult task to surveil every component
of the application entirely. Attackers usually target old and unmain-
tained applications to gain unauthorized access to internal systems or
sensitive data. [34]

Mitigation

Mitigation of Vulnerable and Outdated Components is quite sim-


ple. Developers should use only trusted and reputable software from
known sources and keep the software up to date. Furthermore, devel-
opers should regularly check documentation and news about all the
used components and delete any disabled and unused code, dependen-
cies, and files. Also, implementing an accurate Continuous Integration
and Continuous Delivery (CI/CD) pipeline is necessary because it w i l l
block developers from merging or deploying a code w i t h a k n o w n
vulnerability unless they fix it. [34]

Examples

Vulnerable and Outdated Components has got only 3 CWEs. Namely,


it is CWE-937: OWASP Top Ten 2013 Category A9 - Using Components
with Known Vulnerabilities, CWE-1035: OWASP Top Ten 2017 Category
A9 - Using Components with Known Vulnerabilities, and CWE-1104: Use
of Unmaintained Third Party Components. Unfortunately, it is the only
O W A S P category w i t h no mapped C V E . O n the other hand, a typ-
ical attack is relatively straightforward. Attackers explore and scan
networks and applications, searching for any vulnerable component.

16
2. OWASP T O P 1 0 : 2 0 2 1

After successful findings, they utilize hacking tools w i t h already pre-


pared exploits since the vulnerability is publicly comprehended. [34]

2.7 A07 Identification and Authentication Failures

The seventh place is occupied by Identification and Authentication Fail-


ures, with 132,196 occurrences. In the 2017 list, it was known as Broken
Authentication. It is the most major decline i n the 2021 list; it has
moved from second place to seventh. This category refers to vulner-
abilities that originate from software that incorrectly identifies and
authenticates users. Commonly, the software lacks two-factor authen-
tication and adequate password policies and processes or has a weak
defense against automated attacks, such as basic brute force attacks.
Apart from this, another weakness might arise i n user sessions when
session identifiers are not properly used. [35]

Mitigation

To prevent Identification and Authentication, developers should change


all default credentials as soon as possible and must establish a suffi-
cient password policy and implement it into the software. Hence, i m -
plementing multi-factor authentication has a notable positive impact.
Other recommendations are to force users to use strong passwords,
do regular password checks against known or newly leaked password
lists, and set up boundary mechanisms for failed login attempts. Corre-
spondingly, developers should use well-established session managers,
preferably on a back-end side of a program, w i t h a valid random ses-
sion generator. Besides, developers should reliably store the session
identifiers and delete them after the user logout or after some idle
time. The final advice is not to use session identifiers i n observable
places (for example, i n U R L addresses). [35]

Examples

The list of all related CWEs is extended; on the other hand, one C W E
is the most noteworthy, the CWE-259: Use of Hard-coded Password. It is
impressive that this category of vulnerabilities is still relevant these
days. In this case, vulnerability CVE-2021-37555 [36] is about a TX9

17
2. OWASP T O P 1 0 : 2 0 2 1

Automatic Food Dispenser device, where users were allowed to access


the system as a superuser because a default password was used for
the root account. This C V E is a highly severe vulnerability; thus, the
N V D has ranked it w i t h a CVSS 9.8 critical. [35]

2.8 A08 Software and Data Integrity Failures

Software and Data Integrity Failures is a newly formed category for the
2021 list and counts 47,972 occurrences. It relates to vulnerabilities that
result from the failure of a system or an application to provide ade-
quate protection for the integrity of its data and software. Most of the
time, applications have got a lot of external dependencies. Attackers
could set up these dependencies to be automatically updated and
upload malicious code into these updates, which w i l l be distributed
and executed on all machines. Furthermore, the lack of data backup
and recovery instruments might result i n an integrity disaster. [37]

Mitigation

There is one focus on preventing Software and Data Integrity Failures.


Developers should implement effective ways into C I / C D pipelines
to automatically check all software used dependencies to ensure no
code is used from untrusted and potentially malicious sources. They
should always do proper code reviews to minimize the chances and,
admittedly, use secure communication protocols such as Hypertext
Transfer Protocol Secure (HTTPS). Lastly, reliable software backups
and recovery mechanisms ensure that data can be restored during a
compromise. [37]

Examples

A n interesting C W E is CWE-829: Inclusion of Functionality from Un-


trusted Control Sphere because it maps 20 C V E s , 17 of w h i c h were
published between 2004 and 2005. Another notable C W E is CWE-494:
Download of Code Without Integrity Check, including two vulnerabilities
regarding well-known software: PartyPoker and A p p l e M a c O S X .
Both were not correctly verifying the authenticity of updates; thus,
man-in-the-middle attackers could remotely execute any malicious

18
2. OWASP T O P 1 0 : 2 0 2 1

code over Trojan horse update. Namely, CVE-2008-3324 [38], and


CVE-2008-3438 [39]. [37]

2.9 A09 Security Logging and Monitoring Failures

A s the name suggests, Security Logging and Monitoring Failures v u l -


nerabilities—53,615 occurrences—are about accurate monitoring, i n -
formative logs from the monitoring, and following alerts and actions
triggered by correctly set-up rules. Failures happen w h e n it is not
possible to find important system events i n the logs, like transactions
and logins, and if the crucial alerts from monitoring are not clear or
not triggered at all. A l s o , it might be an issue if logs are stored on
local machines only. Additionally, insufficient response time to active
attacks might cause serious security incidents resulting i n massive
losses. [40]

Mitigation

The first step to mitigating Software and Data Integrity Failures vulner-
abilities developers should focus on what data is essential to inspect
and save i n their systems (e.g., logins, accesses, requests) and imple-
ment reliable logs instruments of these parts of the systems. These
logs must be saved securely, encrypted, and preferably formatted to
be easily read and quickly understood. Developers have to make sure
it is saved and efficiently accessible both locally and in a trusted cloud
service. Secondly, developers should design efficient system monitor-
ing and, i n addition to this, set up some limits and alerts to quickly
react where time is the most critical entity. A swift response could
save a lot of trouble and costs. Lastly, developers should ensure an i n -
cident response and recovery plan to further faster reactions and cost
savings. This plan might also help other internal departments, users,
customers, or other companies to prevent more harmful casualties.
[40]

Examples

Security Logging and Monitoring Failures contain only 4 CWEs. Namely


CWE-117: Improper Output Neutralization for Logs, CWE-223: Omission

19
2. OWASP T O P 1 0 : 2 0 2 1

of Security-relevant Information, CWE-532: Insertion of Sensitive Infor-


mation into Log File, and CWE-778: Insufficient Logging. From the last-
mentioned enumeration, a vulnerability occurred where attackers
were making brute-force attacks on passwords w i t h a m u c h higher
chance of not being detected because the systems were not monitoring
nor logging failed authentication attempts. It happened in OpenGroup
Pegasus 2.7.0 on Red Hat Enterprise Linux 5, Fedora 9, and Fedora 10.
The vulnerability is labeled CVE-2008-4315 [41]. [40]

2.10 A10 Server-Side Request Forgery (SSRF)

Server-Side Request Forgery is a newly shaped category on the 2021 list


w i t h the least occurrences—9,503. Security risks occur w h e n a web
application can send arbitrary requests to other systems that read or
utilize the responses without any validation. A s a consequence of the
higher usage of cloud services and the growth of modern and more
architectural complex web applications, this category is expected to
be more considerable i n future OWASP Top 10 editions. [42]

Mitigation

To mitigate Server-Side Request Forgery vulnerabilities, developers


should implement appropriate user input validation and sanitization
to discourage attackers from injecting malicious code. It is recom-
mended to apply "deny by default" network rules. Besides, developers
should use a positive allow list for requests instead of a deny list be-
cause attackers have all kinds of tools and abilities to sidestep the
denied requests. Finally, developers should disable H T T P redirections,
use H T T P S instead, and not allow sending raw responses to users.
[42]

Examples

This category contains only a single C WE—CWE-918: Server-Side Re-


quest Forgery (SSRF), which is the identical name to this vulnerabilities
category. The separation and growth of this enumeration are expected
in the future. There are two C V E s related to immensely k n o w n com-
panies. The first one is CVE-2016-4029 [43], where WordPress made

20
2. OWASP T O P 1 0 : 2 0 2 1

a simple mistake. They were not expecting octal and hexadecimal IP


addresses; hence attackers could bypass intentional SSRF policies. It
has gained a CVSS Base Score of high 8.6. The second one is CVE-2021-
26855 [44], w i t h only the following description: "Microsoft Exchange
Server Remote Code Execution Vulnerability." [44] Nevertheless, the CVSS
Base Score is exceptional—9.8 critical. [42]

21
3 Hacking Skills, Techniques, and Tools

This chapter uses the term hackers as a description—for the purpose of


simplification—for all hackers w i t h good intentions only (also called
ethical hackers).
Exactly like professional developers, hackers must have a broad sci-
ence overview and comprehensive informational technologies knowl-
edge. However, they need to know a specific set of helpful tools, tech-
niques, and different skills to reach their goal successfully and effi-
ciently.
The first section illustrates the different skills and tools hackers
should learn. Then the thesis describes a step-by-step hacking process,
split into four sections—active reconnaissance, passive reconnaissance,
scanning and enumeration, and exploitation. Every section describes only
a portion of chosen techniques and tools because there are many more
of them. It all depends on the hackers' experience, preference, and
other circumstances of their hacking target.
It is also necessary to mention that there is no solid line between
the four sections; some tools and techniques might be considered
in multiple sections. Moreover, the described hacking process can
be done differently, and other steps might be included, like gaining
access, maintaining access, and clearing traces. Nevertheless, this chapter
focuses on how to find security issues.

3.1 Hacking Environment and Skills

There is no doubt that hackers should generally know how web appli-
cations are built, what the web application architecture looks like, and
what languages and technologies are being used. However, following
skills and tools might not be so crucial for developers, but hackers
should master these to be successful.

3.1.1 Note Keeping

Making and keeping great notes is the first skill hackers should focus
on. This skill is essential and not as straightforward as it might seem
in the first place. Hackers w i l l go through many learnings and unordi-

22
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

nary experiences throughout their careers. Besides, the hackers w i l l


be searching for and gathering an extensive amount of distinctive data
and information. Therefore, correctly making and sorting out all notes
is crucial for further actions because the hackers must be genuinely
precise to avoid being detected and blocked. It is also a good idea to
store the notes only offline because the notes w i l l contain sensitive
information, and i n order to reduce any evidence traces.

3.1.2 Information Searching

Similar to keeping notes, the skill to efficiently search for information


is also more complicated. M a n y tools and techniques have yet to be
publicly k n o w n and comprehensibly described. It is also essential to
regularly check adequate security news sources and be aware of all
newly found vulnerabilities. Great publishers and databases are, for
instance, Mitre, OWASP, NIST N V D , PortSwigger, and other sources.
Furthermore, knowing how to navigate inside the deep web (especially
the dark web part) might help find any extra secret, leaked, or stolen
information.

3.1.3 Virtual Machines and Private Networks

Virtual Machines (VMs) are often used as an isolated safe place (sand-
box) where hackers can train and test all techniques and tools and
run any scripts without m o d i f y i n g or harming their machines. To-
gether w i t h Virtual Private Network ( V P N ) , they can accomplish total
anonymity and non-traceability. O n the other hand, the combination
of V M s and V P N s is also utilized to simulate various users' devices
and locations to test out their view and access to web applications.
Hackers usually operate on V M s , where the K a l i Linux operating
system is installed.

3.1.4 Kali Linux

Kali Linux is probably the most essential complex platform to master.


It is an open-source operating system specialized for hackers. There
are already predefined and configured network-related elements, and
it comes with a tremendous bundle of applications and tools used for

23
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

all hacking and security-related activities. Knowing which tool to use


and how to utilize it adequately takes a lot of time and practice. [45]

3.1.5 Unix

Since K a l i L i n u x and almost every server uses a Unix-like operating


system, hackers should have a deep knowledge of the principles of
Unix-like systems. Accordingly, hackers should know how to modify
the Unix environment and access rights, how to navigate through
the Unix file system, where to find configurations and other discreet
information, how to create and edit files, and how to use the U n i x
shell command line interface (CLI) to achieve all the goals.

3.1.6 Bash and Python Scripting

Bash is used as a default U n i x shell C L I inside Unix-like systems.


W i t h the help of Bash, hackers can write multiple Bash commands
to do more complex tasks and combine all the tools and their results.
Additionally, Python is very popular among developers for its easy
learning curve, superb readability, and rich ecosystem of libraries, and
it is also preinstalled on many Unix-like systems. Those are the reasons
why also hackers should learn Python more. Writing a Python script
for all kinds of tasks, such as third-party API usage, data scraping and
manipulation, and many other functions, is relatively quick.

3.1.7 Browser Developer Tools

Browser developer tools are the most practical tools for all web appli-
cation developers and hackers. Every browser has its o w n bundle of
developer tools. Nonetheless, the bundles are similar, and all contain
essential tools like a browser console, networking tool, performance
tool, page inspector, filesystem manager, and security overview. Most
tools are straightforward, with pleasant user interfaces and many prac-
tical functions. The complete tools bundle is accessible via a keyboard
shortcut (for example, after pressing the F12 key on Chromium-based

24
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

browsers ). Hackers should master these tools because web application


analysis, testing, and attacks can be made exclusively via the tools.

3.2 Passive Reconnaissance

The first part of the hackers' methodology is passive reconnaissance,


where hackers try to determine the whole context of their target. Identi-
fying the company and its persons behind the web application, looking
for any public contacts, searching through social media websites, and
doing other general information-gathering actions. It is the first step,
where hackers should look for publicly accessible information without
making any "noise" and leaving no traces behind them. [47]

3.2.1 Website Reconnaissance

This technique involves a manual reconnaissance of the targeted web


application. Hackers click through the links, trying to figure out how
the web pages work, who is the web's targeted audience, and looking
for any useful information. There might be employees' details (name,
e-mail, job positions), what technologies the company is operating
with, and who are their partners, suppliers, and customers. Therefore,
making a general overview of the web application from the users'
perspective is always reasonable.

3.2.2 Social Media Reconnaissance

Social media is one of the best sources of sensitive information for hack-
ers and in general. People are publicly sharing a tremendous amount
of personal information about them. If hackers know the names of
employees, they can find their Facebook or Instagram profiles filled
up w i t h lots of photos. For example, people are sharing the names of
their kids and pets, w h i c h can be used for password attacks. More-
over, they show their cars w i t h license plates or even their place of
residence or recent location, which can be used for further reconnais-
sance. The employees or the company usually share photos from work,

1. Chromium-based browser is a browser built on C h r o m i u m engine—Edge, Opera,


Brave, V i v a l d i , and others [46]

25
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

where sensitive information might be leaked. Also, photos of devices


the company use might be valuable. O n Linkedln, people share their
certificates and level of skills, what they are working on, and what
technologies they operate w i t h . A s a result, social media reconnais-
sance has plenty of potential for useful information; therefore, finding
even login credentials is not excluded.

3.2.3 Advanced Google Search

Using Google search as a typical user does not lead hackers to gather
any noteworthy information. However, certain techniques exist to
find poorly configurated or leftover web pages and files. One of the
most known techniques is to use quotation marks around phrases that
have to match exactly the findings i n the same w o r d order ("match
t h i s phrase"). Using unique strings like i n t e x t : , i n t i t l e : , i n u r l : ,
inbody: allows hackers to search i n specific areas of the web pages.
There is also a unique string f i l e t y p e : used to find files. Many other
remarkable techniques and examples can be seen i n Google Hacking
Database. [47,48]

3.2.4 Dark Web

This technique lies on the line between Passive and Active Reconnais-
sance. As mentioned before, search engines do not display everything
on the Internet. The Dark Web part could also be an excellent source
for finding sensitive information and login credentials. Various fraud-
sters offer credit cards, personal information, photos, and other leaked
data for money (mostly in cryptocurrencies). There are many ways to
enter Dark Web websites, but it is worth mentioning that most Dark
Web users use the Tor Browser for additional security and complete
anonymity. [7,49]

3.3 Active Reconnaissance

Active reconnaissance is the second part of the hackers' methodol-


ogy. The main goal is to gather more targeted information, w h i c h is
more technologically oriented. In this part, the hackers typically use
third-party tools, trying not to touch the target directly. The thesis

26
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

describes a few techniques of active reconnaissance actions with suited


tool examples. There are many more tools available that produce sim-
ilar results. The selection depends on the hackers' experience and
preference and the current availability status of the tool. [47]

3.3.1 Website Analysis

This technique parallels Website Reconnaissance, but it goes one step


deeper into the proper technical analysis w i t h the help of K a l i Linux
or other third-party tools. The goal is to identify what technologies,
libraries, and packages the web application is built with, besides if the
web application uses any additional systems or third-party services.
Also, identifying the servers and devices the web application is run-
ning on. A good tool for this technique is WhatWeb [50], available on
K a l i Linux. Other advanced standalone web applications offer only
limited results for free, such as Wappatyzer [51] and BuiltWith [52].
[47]

3.3.2 Finding Subdomains

The next technique describes subdomain findings. Usually, web ap-


plications contain many subdomains that serve as a place for another
app service or testing. These secondary subdomains might not be ap-
propriately secured as the main domain or subdomains. Furthermore,
if the web application or the company itself is large, it is included
that there are live services on subdomains that are forgotten i n the
company; this can lead to severe exposures. Simple and quick tools
available on Kali Linux are Sublist3r [53] and assetfinder [54]. Another
much more capable and complex tool is, for example, Amass [55]. [56]

3.3.3 E-mail Address Gathering

Lastly, some tools help with gathering e-mail addresses. One of them
is called Hunter [57], w h i c h is an easy-to-use online application. It
allows users to search for e-mail addresses for free 25 times monthly
Furthermore, the pattern of how the e-mail addresses are created can
be seen i n the app. Otherwise, the app is paid, offering extra features

27
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

like C S V exports. The gathered e-mail addresses can be combined


with the most often used or leaked passwords. [56,57]

3.4 Scanning and Enumeration

Another part of the hackers' methodology is the further process of


collecting information, but this time w i t h the data and information
from previous passive and active gathering. The following tools and
techniques are directly interacting w i t h targeted machines. The goal
is to prepare the final worthy targets and find as many vulnerabilities
as possible. Hackers should be extraordinarily cautious and patient
with techniques and tools because targeted systems could have some
defensive mechanisms to prevent such actions. [47]

3.4.1 Httprobe

This tool is lightweight, available on Kali Linux, and has only a single
but practical utility. Httprobe takes a list of domains and probes them
to see if the H T T P and H T T P S servers are alive. It is an incredible
tool for filtering the previously gathered domains and subdomains.
Configurations are also available; hackers can set up custom timeout,
concurrency level, and other settings. [58]

3.4.2 Nmap

Nmap—full name is Network Mapper—is the most legendary secu-


rity tool. It has w o n several awards, and every hacker should utilize
this superb free and open-source tool. It has been created to deeply
explore the targeted network to discover all the network hosts w i t h
their active services, operating systems, firewall settings, and other
elements. The information gained includes all the names and versions.
Since its popularity, the Nmap has been reasonably documented, and
it has many available tutorials and an active community. Other specific
analytic tools based on Nmap exist, for instance, Neat, Ndiff, and Nping.
Moreover, an official multi-platform application w i t h an advanced
graphical user interface (GUI) version of N m a p is named Zenmap. [59]

28
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

3.4.3 Nikto

Another great scanning tool available on K a l i L i n u x is Nikto. It is an


open-source web server scanner designed to discover vulnerabilities
in web servers and applications. The tool scans the services for poten-
tially dangerous misconfigurations, options, files, programs, and other
possible security weaknesses. It can identify the installed software and
check if the versions are outdated. Nikto is very configurable, includ-
ing extra functions such as reports saving into different file formats
and auto-pausing at a specified time. Because the scanning is done as
quickly as possible, the tool w i l l leave clear traces. [60]

3.4.4 Dirb

Dirb is a web content scanner to find public or hidden web content. It


performs a wordlist attack on a web server and analyzes the responses
to determine if a hidden directory or file exists. There is an already
predefined wordlist, but any wordlist can be used. It is mainly used
as an additional scan, different from other scanners, because it is not
searching for vulnerabilities specifically but gathers extra information
that can be utilized i n further actions. The Dirb tool is also available
on K a l i Linux. [61]

3.4.5 Wapiti

Wapiti focuses on websites and web applications. It is an open-source


security C L I tool that performs black-box scanning and is written i n
2

Python. Wapiti covers a wide range of vulnerabilities, such as XSS,


SQL injections, file inclusion, and many others. The tool analyzes the
target for all injection places and then fuzzes data into such places
3

to test if a vulnerability exists. Wapiti generates a detailed report that


includes the vulnerabilities found and the recommended remediation
steps. The tool is available on K a l i Linux for free use. [62]

2. Black-box scanning means that the tool scans the target from outside, not reading
the source code. It simulates the user's/attacker's view. [56]
3. Fuzzing is a technique where somebody or something is intentionally sending
invalid and unexpected data into an application. [56]

29
3- H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

3.5 Exploitation

The hackers should now have all information about the target com-
pany, people, used domains and subdomains, and what technologies
and services the web server and web application uses. Moreover, the
scanners might have found a specifically k n o w n severe vulnerability.
N o w is the time for exploitation, the last part of the hackers' method-
ology.

3.5.1 Sqlmap

Sqlmap is a complete open-source tool for detecting and exploiting


databases via SQL injection vulnerabilities. It supports over 30 database
management systems, including the best-known Oracle, Microsoft SQL
Server, PostgreSQL, MariaDB, SQLite, and MySQL. The tool is available
on Kali Linux, offers many more features, and the data can be dumped
into different formats. [63]

3.5.2 Metasploit

One of the most elaborate, powerful, but hard-to-learn exploitation


tools for hackers is the Metasploit. The tool is open-source, available on
Kali Linux, and has many security features and modifications. O n the
other hand, the tool is best known for its C L I called msfconsole. Thanks
to the msfconsole, the hackers can access most of the tool features
and execute external commands inside the interface. Once the hackers
master the Metasploit and find the vulnerabilities, further exploitation
is relatively fast and effortless. [64]

3.5.3 OWASP Zed Attack Proxy

OWASP Zed Attack Proxy (ZAP) is one of the two professional, robust,
and industry-standard tools used by many companies, developers,
and both beginner and expert hackers for web application security.
Z A P is an open-source and free tool with GUI, available on Kali Linux
and widely supported by a large community of security professionals.
The tool provides complete web application security scanning and
exploitation. Comprehensive documentation and many video tutorials

30
3. H A C K I N G SKILLS, T E C H N I Q U E S , A N D TOOLS

are available, thanks to O W A S P and the community. Moreover, it


is an ideal tool for complete automation because it delivers docker
containers, GitHub Actions ", API, and an Automation Framework. [66]
4

3.5.4 Burp Suite

The second professional, robust, and industry-standard tool is Burp


Suite. It is also used by many companies, developers, and both begin-
ner and expert hackers for web application security scanning and ex-
ploitation. However, the tool is not open-source, it is developed by the
PortSwigger company, and it comes in 4 different versions—Enterprise
Edition (paid, for companies), Professional (paid, for hackers), Dastardly
(free, for lightweight automation) and Community Edition (free, for
personal use only). O n the other hand, there are also reasonable docu-
mentation and extensive learning materials. Additionally, PortSwigger
offers a great online and free Web Security Academy [67] from the cre-
ators of Burp Suite. [68]

4. G i t H u b Actions are a feature created by G i t H u b to provide better and simpler


automation for projects on GitHub.[65]

31
4 MCUXpresso Analysis and Recommendations

The final chapter of the thesis is about the real-world web appli-
cation—MCUXpresso SDK Builder ( M C U X p r e s s o ) . M C U X p r e s s o is
owned and developed by the NXP Semiconductors company [69] that
designs and produces microcontrollers, microprocessors, and other
solutions used i n various technological industries. The MCUXpresso
servers the need for further software development on those processors.
Users can customize and download their specific processor's software
development kit (SDK). [70]
The author of the thesis utilizes all the acquired knowledge and
experience from previous chapters. MCUXpresso is being investigated
and manually and automatically tested by the author. Then the results
are shown, commented on, and further recommendations are given.
The author describes the whole process from his point of view i n the
following sections.

32
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

4.1 MCUXpresso Reconnaissance

A s I have learned from previous chapters, the first step was to do a


proper passive and active reconnaissance of the target. MCUXpresso is
a web application available at h t t p s : //mcuxpresso. nxp. com/. Figure
4.1 shows the MCUXpresso home page.

Figure 4.1: MCUXpresso home page

33
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

After clicking on the "Select Development Board" or the "Access My


SDK Dashboard" buttons, it redirects users to a login page—https: //
www. nxp. com/security/login?service=https°/o3A°/o2F°/ 2Fmcuxpresso0

nxp. com°/„2Flogin°/„2F. There is little much to investigate on the home


page because the application is hidden behind a login, where users
need an NXP account. A s can be seen i n Figure 4.2, the login page
immediately asks for location permission and cookies acceptance. I
accepted both.

Figure 4.2: M C U X p r e s s o / N X P login page

34
4- M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

After clicking the "CREATE AN ACCOUNT" button, it redirected


me to an account creation page—https : //www.nxp. com/webapp-signup/
r e g i s t e r ? r e f errerUrl=https : //mcuxpresso. nxp. com/. A s can be seen
in Figure 4.3, the creation form consists of an e-mail, Terms of Use and
Privacy Policy acceptance, and reCAPTCHA check.

N P

Create your NXP account


=nh = nr=ri features increased access are part of fhe premium-
expariente on NXP.ium. Discover Ilia benefits uf Lied lint an NXP

Already liavear account?

Figure 4.3: Account creation first part

35
4. M C U X P R E S S O A N A L Y S I S A N D R E C O M M E N D A T I O N S

After doing all the required steps and clicking on the "CONTINUE"
button, the website needed a verification code sent to the used e-mail
from the previous step. The code expires after ten minutes which is a
great policy. Figure 4.4 shows the verification e-mail.

MC3
H&llo and welcome to NXP. com :

You began the process of creating an NXP account. Your account security is important to us. To
continue, please verity your email address ^ ^ ^ M l ^ ^ ^ ^ ^ ^ K using this six-digit verification
code

965026
This verification code is valid for 10 minutes. Please do not share this code. If you didn't make this
request, please contact NXP Support.

Thank you,
NXP Semiconductors

This is an automated email, please do not reply. To ensure the delivery of future emails from NXP. we
recommend thai you add helper mail@nxrj.com lo your address book. If you have any questions, please conlacl
NXP Support.

32006-2023 NXP Semiconductors. All righls reserved.

Figure 4.4: Verification e-mail

36
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

The final step of account creation is to fill i n other information,


including a password. A s shown i n Figure 4.5, the users' password
requirements are visible. According to NIST Digital Identity Guidelines
[71], password length is the most important rule. The requirement for a
password 8 characters long needs to be higher. Bitwarden recommends
using a password of at least 14 characters long [72].

Figure 4.5: Account creation second part

37
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

I created an account, logged in, and the web application was ready
to explore. The home page inside the app (Dashboard) has a U R L ad-
dress https : //mcuxpresso .nxp. com/en/dashboard, and the content
can be seen i n Figure 4.6.

O H DjJibcird | MCU«p-so MJR [ X 1


<• 0 d Cl irap^™^™™™
N X P MCUXpresso SDK Builder
= i • •

MCUXpresso SDK Dashboard


A:cess, jj'.v-lcac, and Sriaeytur "ac.eslcc. SDK 3i.il;s

Additional Links
MCUXpresso SLiflwura arid
-MCUXpressn IF
-MCUXpresso SJK
Getting started with MCUXpresso SDK is simple -MCUXpresso Config Tools
MCUXpresso Sc-uure Pro.
MCUXpresari Supported D*
Do you have s development board? MCUXpresso Clonflg ools
MCUXpresso FAQ

Are you returning and seeking previously downloaded SDKs?

Figure 4.6: Home page (Dashboard) after login

I have analyzed the app and noted some places for forthcoming
testing. The app includes many user input fields, numerous user inter-
actions are possible, and much downloadable content exists. W i t h a
longer loading time, the app felt heavily packed w i t h much potential
for vulnerabilities.
M o v i n g on to Social Media Reconnaissance, the company is enor-
mous, and there were plenty of people and photos everywhere. I have
tried to find something valuable but was not successful. I established
a list of employees' names, quit social media, and focused more on
the application.
Besides, I skipped the Dark Web research since the orientation
inside the Dark Web is for more experienced hackers.
I tried the Advanced Google Search technique to find any leftover
files. Searching the whole N X P company with the help of the f i l e t y p e :
command, I found one .xml, one .xls, one .xlsx, and tons of.pdf files. When

38
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

focusing only on MCUXpresso, I d i d find only three .pdf files. From all
of these findings, I could not gather anything valuable.
Next step, I tried the Hunter service to gather names, e-mail ad-
dresses, and the company's pattern for e-mail addresses. The result
is 769 e-mail addresses w i t h all related names. Besides, the pattern is
evident—{firstname}.{lastname}@nxp.com.
I used Wappalyzer, BuiltWith, and WhatWeb to analyze the tech-
nologies and techniques M C U X p r e s s o utilizes. To s u m up, I found
that MCUXpresso is running on an Apache server, it is operating with
Google Analytics and Google Tag Manager, has some security measures
like X-XSS-Protection and HTTP Strict-Transport-Security, and utilizes
other services like Akamai content delivery network. The whole output
from WhatWeb is i n the attached archive.
The final step in this section was to collect subdomains. I tried the
assetfinder tool; the complete list of all related domains and subdo-
mains can be found i n the attached archive. It contains 2,647 results.

4.2 MCUXpresso Scanning and Enumeration

In this section, I utilized the gathered information from previous


actions and d i d more aggressive and complex scanning of the target
to find vulnerabilities.
A t first, I took the list of found domains and subdomains and
probed them via the Httprobe tool to enumerate only alive and work-
ing servers. Then I filtered the result to contain unique domains with
the following command:

$ cat a s s e t f i n d e r _ o u t p u t . t x t I s o r t - u I httprobe
I sed 's/https\?:\/\///' I sort - u I » a l i v e _ d o m a i n s . t x t

The final list of only alive unique domains contains 110 results and
is available i n the attached archive.
The list was still too immense; it would take ages to scan all the re-
sults thoroughly. I focused only on domains containing the following
words: dev, test, stag, and admin. I found four interesting domains that
might be forgotten or less secure: developer.nxp.com, dev-my.nxp.com,
amec-ssl-test.nxp.com, and community-staging.nxp.com. However, the

39
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

main target is mcuxpresso.nxp.com, and I d i d not find any alive sub-


domain containing the mcuxpresso keyword. The following Figure 4.7
and Figure 4.8 show the home page of the four interesting domains.

Welcome to the NXP developer program!

1
Figure 4.7: L a n d i n g page for developer.nxp.com (left) and dev-
my.nxp.com (right)

Figure 4.8: L a n d i n g page for amec-ssl-test.nxp.com (left) and


community-staging.nxp.com (right)

40
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

M y reconnaissance and enumeration were done; the scanning was


on the line. I started the vulnerability scanning with two known nmap
scripts (vuln and vulners) w i t h the following commands:

$ nmap -sV -Pn — s c r i p t vuln


—script-args http.useragent="Pentesting BP"
mcuxpresso.nxp.com

and

$ nmap -sV -Pn — s c r i p t vulners


—script-args http.useragent="Pentesting BP"
mcuxpresso.nxp.com

N e w information was observable, the server is running on Apache


2.4.6 (CentOS), but no vulnerability was found. According to NIST
N V D search results [73], 69 CVEs are discovered for Apache 2.4.6. Full
scan outputs can be seen i n the attached archive.
For another scan, I choose Nikto and the following command:

$ nikto -useragent "Pentesting BP"


-followredirects -usecookies -host mcuxpresso.nxp.com

A s can be seen i n Figure 4.9 below, a few issues were found. Espe-
cially, OpenSSL seems to be seriously outdated and w i l l be supported
only until 11 November 2023. Also, X-Frame-Options and X-Content-Type-
Options are missing, which could lead to click-jacking attacks and A05 1

Security Misconfiguration (see Section 2.5) vulnerabilities, respec-


tively.

1. Click-jacking attack happens when users click on page elements that an attacker
sets up without the user noticing. [7]

41
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

+ T a r g e t Hostname: mcuxpresso. nxp.com


+ Target Port: 80

+ S t a r t Time: 2623-85-13 14:47:46 (GMT-*)

+ S e r v e r : Apache/2.4.6 (CentOS) D p e n S S L / 1 . 0 . 2 k - f i p s
+ /: The a n t i - c l i c k j a c k i n g X - F r a m e - D p t i o n s header i s n o t p r e s e n t . See: h t t p s : / / d e v e l o p e r . m o z i l l a . o r g / e n - U S / d o c s / W e b
/HTTP/Headers/X-Frame-Opt i o n s
+ /: Uncommon header ' s e r v e r - t i m i n g " f o u n d , w i t h m u l t i p l e v a l u e s : ( c d n - c a c h e ; desc=MTS5,edge; d u r = l l l , o r i g i n ; dur=6
l a k _ p ; desc="467778_399797823_103616621_17866_4477_18_-";dur=l,).
F

+ /: The K - C o n t e n t - T y p e - O p t i o n s header i s n o t s e t . T h i s c o u l d a l l o w t h e u s e r agent t o r e n d e r t h e c o n t e n t o f t h e s i t


e i n a d i f f e r e n t f a s h i o n t o t h e MIME t y p e . See: h t t p s : / / i w w f . n e t s p a r k e r . c o m / w e b - v u l n e r a b i l i t y - s c a n n e r / v u l n e r a b i l i t i e
s/missing-content-type-header/
+ Root page / r e d i r e c t s t o : h t t p s : / / m c u x p r e s s o . n x p . c o m /
+ : S e r v e r banner changed f r o m "Apache/2.4.6 (CentOS} O p e n S S L / 1 . 6 . 2 k - f i p s ' t o 'AkamaiGHost'.
+ No CGI D i r e c t o r i e s found ( u s e -C a l l " t o f o r c e check a l l p o s s i b l e d i r s )
1

+ Apache/2.4.6 a p p e a r s t o be o u t d a t e d ( c u r r e n t i s a t l e a s t Apache/2.4.54). Apache 2.2.34 i s t h e EOL f o r t h e 2.x b r a


nch.
+ O p e n S S L / l . 0 . 2 k - f i p s a p p e a r s t o be o u t d a t e d ( c u r r e n t i s a t l e a s t 3.0.7). DpenSSL 1.1.1s i s c u r r e n t f o r t h e 1.x b r a
nch and w i l l be s u p p o r t e d u n t i l Nov 11 2823.

Figure 4.9: Nikto scan output

I chose the Wapiti as the last scan; a vital part of the summary result
is visible below i n Figure 4.10 below. The complete scan is accessible
in the attached archive. The scan confirms that X-Frame-Options and
X-Content-Type-Options are missing. However, it also shows that X -
XSS-Protection and Strict-Transport-Security still need to be included.
This should be a false finding since all the previous analyzing tools
showed that these two headers are set up correctly. Besides, there are
Content Security Policy Configuration issues, w h i c h could lead to XSS
and click-jacking attacks.

Content Security Policy Configuration 2

C r o s s Site Request Forgery 0

Potentially dangerous file 0

C o m m a n d execution S19 k

Path Traversal

Htaccess Bypass

H T T P Secure Headers

Figure 4.10: Part of Wapiti scan summary

I skipped the Dirb tool because it provides a wordlist attack, which


cannot be easily controlled. The brute force attacks were prohibited
by the MCUXpresso authors.

42
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

4.3 MCUXpresso Exploitation

Exploitation is another step i n the whole MCUXpresso analysis. Since


no specific C V E s were found, I d i d not use the Metasploit tool. The
focus was more on other tools and techniques. The first part is about
automated testing, and the second is about manual testing w i t h the
help of the Burp Suite tool.
A t first, I used sqlmap trying to exploit any SQL injection vulnera-
bility. The following command was executed:

$ sqlmap -u mcuxpresso.nxp.com —batch —banner


—delay=l -A "Pentesting BP" —level=5

The command execution was slow (the delay option was the main
reason) and unsuccessful. Moreover, as seen i n Figure 4.11, "the target
is protected by some kind ofWAF/IPS ", which is an excellent defensive
2

signal. From my experience with this tool, it is unsuitable for automa-


tion; thus, it should be used more manually for specific targets by
more experienced hackers.

[16:57:49] [INFO] t e s t i n g connection t o the target URL


got a 302 r e d i r e c t t o 'https://mcuxpresso.nxp.com/'. Do you want t o follow? [Y/n] Y
[16:57:53] [INFO] checking i f the target i s protected by some kind of WAF/IPS
[16:57:54] [CRITICAL] h e u r i s t i c s detected that the target i s protected by some kind of WAF/IPS
are you sure that you want t o continue with f u r t h e r target t e s t i n g ? [Y/n] Y
[16:57:54] [WARNING] please consider usage of tamper s c r i p t s (option ' - - t a m p e r ' )
[16:57:54] [INFO] t e s t i n g i f the target URL content i s stable

Figure 4.11: Part of sqlmap output

W h e n it comes to the best overall security tool, it is rather Burp


Suite or Z A P . Most of the time, it depends on the user's preference.
The Burp Suite might be a better option for more professional work,
while the Z A P is entirely free compared to Burp Suite, where the free
Comunity Edition has some limitations. I tried both; the Z A P was
used for an automated scan, and the Burp Suite was used for further
manual testing.
Starting w i t h the Z A P , I adjusted the user-agent, configured a
one-second delay between requests, and tried to provide my login

2. Web Application Firewall (WAF) and Intrusion Prevention System (IPS)

43
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

credentials to scan the app from behind the login. It took me a few
hours to set up the scan correctly, but the automated scan was success-
ful. The full report is available i n the attached archive as a .html file,
and part of the result can be seen i n Figure 4.12. The report contains
0 high, 8 medium, 11 low, and 7 informational alerts. Z A P categorizes
all the m e d i u m alerts as A05 Security Misconfiguration (see Section
2.5) vulnerabilities, which correlate with other previous scanning and
testing. Therefore, the overall Z A P scan result is acceptable. I d i d not
find any significant vulnerabilities.

Figure 4.12: OWASP Z A P automated scan result

The second part of the M C U X p r e s s o analysis is the manual hack-


ing w i t h Burp Suite Community Edition. Initially, I had to configure
the Burp Suite to catch and intercept requests from a browser. The
configuration was successful, and now was the time to attack the
MCUXpresso login page and other behind-the-login contents.
A t first, I tried S Q L injection attacks, putting various potentially
malicious strings into inputs to see how the app responded. For ex-
ample, I used strings like t e s t ' , t e s t " " and t e s t ' OR 1=1; —. I was
not successful w i t h any attack, w h i c h confirms the previous scans.
N o SQL injection vulnerability was found by automated and manual
scanning and testing. Figure 4.13 below contains an example of an
SQL injection attempt from Burp Suite.

44
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

Figure 4.13: S Q L injection attempt v i a Burp Suite

Another type of attack I was focusing on was XSS attacks, where I


tried to insert various pieces of code into random input elements to
see if any XSS vulnerabilities existed. A great source for XSS attacks is
PortSwigger's XSS cheat sheet [74]. I used strings like:

<script /**/>/**/alert(l)/**/</script /**/

felt;IMG SRC=&quot;livescript:[code]&quot;&gt;

<iframe %00 src="&Tab;javascript:prompt(1)&Tab;"%00>

<dialog onafterscriptexecute=alert (1) ><script>K/script>

45
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

I could not find any vulnerabilities; an example X S S attempt can


be seen i n Figure 4.14.

Figure 4.14: X S S attempt

While looking for some authentication vulnerabilities, I found none


and was surprised at how well the reset password action is delivered.
Figure 4.15 below shows two reset password screenshots together. O n
the left in the figure, when I tried to reset a nxp.com account, it told me
that I could not reset an employee account and should contact internal
support with password issues. O n the right in the figure, when I tried
to reset a random non-employee account, it d i d not show if the account
existed. These two approaches are significant authentication policies.

46
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

Figure 4.15: Two screenshots of password resetting

In the end, I also tested X M L External Entities (XXE) attacks, where


I tried to upload a custom X M L file and was unsuccessful in uploading
it anywhere.

4.4 Automated Test Implementation

Throughout the process of M C U X p r e s s o analysis, I was b u i l d i n g a


simple automated testing shell script that is visible i n Figure 4.16
below and accessible i n the attached archive as a t e s t . sh file. The
script should be run on Kali Linux, and it might need a small amount
of configuration and preinstall some packages and tools, depending
on the system used.

47
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

#!/bin/bash
echo "* * * S c r i p t has s t a r t e d * * *"
urll=nxp.con
url2=ncu;cpressG.nxp.can

f o l d e r nane v u l n e r a b i l i t i e s _ s c a n i n g _ $ ( d a t e -u +"i6V-Sn-SdTSH-SW-S5Z")
mkdir $folder_name
echo " J f o l d e r n a n e has beer c r e a t e d (UTC d a t e ) "

echo "[1/6] Gathering r e l a t e d domains and subdomains f o r $ u r l l "


assetfinder J u r l l Jfoldername/domains.txt

echo "[2/6] Probing f o r a l i v e and unique domains f o r $ u r l l . . . "

cat $folder_name7domains.tirt: | s o r t -j | httprobe | sed 's/https\?:\/\H}' | s o r t -u >> $folder_name/alive_domains.t)ct

echo "[3/6] F i l t e r i n g o n l y test., dev, s t a g , and admin domains..."

cat $folder_name/alive_donain5 .txt grep " t e s t \ | admin\ | s t a g \ | dev" $folder_name/filtered_domains.txt

echo "[4/6] Nmap scanning $ u r l 2 f o r v u l n e r a b i l i t i e s . . . "


nmap
echo -sV -Pn N i-k ts oc r iscanning
"[5/6] p t v u l n $-u-rslc 2r i fp to-ra rvgusl n http.user-agent="testing"
erabilities..." $ u r l 2 -oN $folder_name/scan_nmap.tj<t
n i k t o -useragent " t e s t i n g " - f o l l o w r e d i r e c t s -usecookies host ( u r l 2 >> $folder__name/scan_nikto.txt

echo "[6/6] w a p i t i scanning $ u r l 2 f o r v u l n e r a b i l i t i e s . . . "


w a p i t i -u $ u r l 2 -A " t e s t i n g " - - c o l o r - f t x t -o $ f o l d e r _ n a n i e / s c a n _ w a p i t i . t x t

echo "* * * S c r i p t s u c e s f u i l l y f i n i s h e d * * *"

Figure 4.16: Testing script for basic analysis of MCUXpresso and related
nxp.com domains

The script creates a folder labeled w i t h the U T C date (for ex-


ample, vulnerabilities_scanning_2023-05-14T20-01-09Z). The as-
setfinder finds all related domains and subdomains for nxp.com (domains . t x t ) .
The list of domains is then probed via Httprobe to operate only w i t h
alive domains, and the list is filtered to contain unique domains
(alive_domains . t x t ) . Then the script filters domains that contain key-
words: test, dev, stag, and admin because these domains are usually less
secure (f iltered_domains .txt).Besides,thealive_domains . t x t could
be filtered w i t h the keyword mcuxpresso to find domains related to
MCUXpresso.
The second part of the script runs three scanning tools on mcux-
presso. nxp.com and outputs the result into text files: Nmap (s can_nmap. t x t ) ,
N i k t o ( s c a n _ n i k t o . t x t ) , and Wapiti ( s c a n _ w a p i t i . t x t ) . The tools
are set up without zero delays (breaks between requests) and w i t h
a user-agent set to " t e s t i n g " . These tools are highly modifiable, de-
pending on testing requirements. Currently, they are configured to
provide medium scanning and take a few minutes to finish.

48
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

The script provides a basic scan of related domains and possible


vulnerabilities. I recommend modifying and using the script with the
official K a l i Linux Docker images [75].

4.5 Summary and Recommendations

The overall security status of the MCUXpresso web application is pos-


itive. I did not find any specific C V E or any major vulnerability. A few
minor shortcomings have been found; however, they all belong to a
single OWASP category of vulnerabilities—A05 Security Misconfigu-
ration (see Section 2.5). I recommend focusing on the category and
trying to fix the issues. Likewise, I suggest increasing the m i n i m u m
password length policy from 8 to 14 characters because the length is
the most crucial parameter and inspecting if the OpenSSL cannot be
updated.
Regarding security testing automation, there are better choices
than working on custom testing scripts. If the developers are not expe-
rienced in hacking and all the Kali Linux tools, it w i l l take much time
to provide a high-quality and reliable testing script.
I recommend using one of the two well-established industry-standard
security tools: Z A P and Burp Suite. They already offer high-quality
GU I applications that can be used for manual and automated testing.
Furthermore, the tools provide comprehensive and well-documented
APIs [76, 77], straightforward integrations into CI/CD pipelines [78,
79], and are available i n GitHub Actions [80, 81].
I also suggest focusing more on code quality and prevention. De-
velopers should create complete tests, do proper code reviews, and
use available tools to produce quality code to prevent vulnerabilities
and increase maintainability. U s i n g code linters like eslint [82] for
JavaScript or ruff [83] for Python helps notably. Moreover, integrating
dependencies audits like npm audit [84] for JavaScript or pip-audit [85]
for Python into CI/CD pipelines w i l l prevent using code with known
vulnerabilities. A l l the theses linters and audits are free and easy to
utilize.
If I were to recommend a more complex and paid tool, it w o u l d
be Snyk. They offer several solutions and products to improve code
quality and prevent vulnerabilities. Snyk supports a w i d e range of

49
4. M C U X P R E S S O A N A L Y S I S A N D RECOMMENDATIONS

languages and can be integrated into multiple other tools, C I / C D


pipelines, or used as a standalone G U I web application. [86]
When it comes to learning about hacking and web application secu-
rity, I suggest learning from the OWASP Foundation [19] or PortSwig-
ger's Web Security Academy [67]. Besides, many security training
projects exist where anyone can legally try to hack and learn how
vulnerabilities work. OWASP Juice Shop [87] and Damn Vulnerable Web
Application [88] (DVWA) are outstanding examples. They are free and
offer an excellent environment for training and learning with extensive
tutorials.

50
Conclusion

The main goal of the thesis was to learn about web application se-
curity, utilize the learnings to perform a proper security analysis of
the M C U X p r e s s o S D K Builder web application, and introduce an
automated test.
I started w i t h a general view on web applications and security.
Then I introduced the most vital source for web application secu-
rity—OWASP Top 10—with explanations, recommendations, and ex-
amples, followed by a description of hackers and their skills, tech-
niques, and tools. Finally, I have used all the acquired knowledge to
provide the MCUXpresso security analysis.
According to the accomplished analysis, the all-around security
status of M C U X p r e s s o is adequate. I d i d not find any C V E or major
vulnerability. Besides, all the minor vulnerabilities encountered are
associated w i t h a single O W A S P category—A05 Security Misconfig-
uration. I also suggested increasing the m i n i m u m password length
policy from 8 to 14 characters since the length is the most crucial
parameter and inspecting if the OpenSSL cannot be updated.
I provided an automated testing shell script for basic web v u l -
nerabilities targeting the M C U X p r e s s o . I also suggested using well-
established tools like Z A P and Burp Suite that can be integrated into
CI/CD pipelines. Furthermore, I recommended to developers how to
mitigate the OWASP Top 10 vulnerabilities and additional suggestions
to deliver better code quality.
A n important note is that building a non-exploitable web appli-
cation is impossible. O n the other hand, adequate security measures
w i l l reduce the probability of exploitation and further losses. It also
depends on how skilled and experienced the attackers are.
Eventually, cybersecurity is not just about mitigating and fixing
application vulnerabilities. The other vital part is having appropriate
security policies across the organization and remembering that h u -
mans are the worst part of security (social engineering). In addition,
artificial intelligence w i l l completely change the cybersecurity game
in the future.

51
Bibliography

1. Learn web development [online]. Mozilla Foundation, 2023 [visited


on 2023-05-10]. Available from: https : //developer . m o z i l l a .
org/en-US/docs/Leam.
2. Stack Overflow Developer Survey 2022 [online]. Stack Overflow,
2022 [visited on 2023-05-10]. Available from: https : //survey.
stackoverflow.co/2022/#most-popular-technologies-webframe.
3. Amazon Web Services [online]. A m a z o n Web Services, Inc, 2023
[visited on 2023-05-10]. Available from: https : //aws . amazon.
com/.
4. W I L L I A M . Web Application Architecture: The Latest Guide 2022.
ClickIT DevOps & Software Development [online]. 2022 [visited on
2023-05-10]. Available from: https : //www. c l i c k i t t e c h . com/
devops/web-application-architecture/.
5. V A L D E S , Alfonso. Microservices vs Monolith: The Ultimate Com-
parison 2022. ClickIT DevOps & Software Development [online].
2021 [visited on 2023-05-10]. Available from: https : / /www .
clickittech.com/devops/microservices-vs-monolith/.
6. K E M P , Simon. D I G I T A L 2022: G L O B A L O V E R V I E W R E P O R T .
DataReportal [online]. 2022 [visited on 2023-05-10]. Available
from: https : / / d a t a r e p o r t a l . c o m / r e p o r t s / d i g i t a l - 2 0 2 2 -
global-overview-report.
7. M C D O N A L D , Malcolm. Web Security for Developers: Real Threats,
Practical Defense. Illustrated Edition. N o Starch Press, 2020. ISBN
1593279949.
8. 2023 Cyberthreat Defense Report [online]. CyberEdge, 2023 [visited
on 2023-05-10]. Available from: https : //cyber-edge. com/cdr/.
9. M O R G A N , Steve. Top 10 Cybersecurity Predictions A n d Statistics
For 2023. CYBERCRIME MAGAZINE [online]. 2022 [visited on
2023-05-10]. Available from: h t t p s : //cybersecurityventures.
com/top-5-cybersecurity-facts-figures-predictions-and-
statistics-for-2021-to-2025/.

52
BIBLIOGRAPHY

10. C H A I , Wesley. What is the C I A triad (confidentiality, integrity


and availability)? TechTarget [online]. 2023 [visited on 2023-05-
10]. Available from: https : / /www . techtarget . com/whatis/
definition/Confidentiality-integrity-and-availability-
CIA.
11. NATIONAL VULNERABILITY DATABASE [online]. Gaithers-
burg, M D : National Institute of Standards and Technology [vis-
ited on 2023-05-10]. Available from: https : //nvd. n i s t . gov/.
12. Who We Are [online]. The M I T R E Corporation [visited on 2023-
05-10]. Available from: https : //www.mitre. org/who-we-are.
13. Enterprise Matrix [online]. The MITRE Corporation, 2023 [visited
on 2023-05-10]. Available from: https : / /attack . mitre . org/
matrices/enterprise/.
14. Common Vulnerabilities and Exposures [online]. The M I T R E Cor-
poration, 2023 [visited on 2023-05-10]. Available from: https :
//eve.org/.
15. Common Weakness Enumeration [online]. The M I T R E Corpora-
tion, 2023 [visited o n 2023-05-10]. Available from: https : //ewe.
mitre.org/.
16. CVE-2020-6969 [online]. Gaithersburg, M D : National Institute
of Standards and Technology, 2020-02-14 [visited on 2023-05-10].
Available from: https : / /nvd . n i s t . gov/vuln/detail/CVE-
2020-6969.
17. Vulnerability Metrics [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology [visited on 2023-05-10]. Avail-
able from: h t t p s : / / n v d . n i s t . g o v / v u l n - m e t r i c s / c v s s .
18. About us [online]. Knutsford: PortSwigger [visited on 2023-05-
10]. Available from: https ://portswigger.net/about.
19. OWASP Foundation [online]. Wakefield, M A : O W A S P Founda-
tion, 2023 [visited on 2023-05-11]. Available from: https : //
owasp.org/.
20. OWASP Top 10:2021 [online]. Wakefield, M A : O W A S P Founda-
tion, 2021 [visited on 2023-05-11]. Available from: https : //
owasp.org/ToplO/.

53
BIBLIOGRAPHY

21. A01-.2021 - Broken Access Control [online]. O W A S P Foundation,


2021 [visited on 2023-05-11]. Available from: https : //owasp .
org/ToplO/A01_2021-Broken_Access_Control/.
22. CVE-2020-6969 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2008-09-10 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2000-1117.
23. man-in-ihe-middle attack (MUM) [online]. Gaithersburg, M D : N a -
tional Institute of Standards and Technology [visited on 2023-05-
11]. Available from: h t t p s : / / c s r c . n i s t . g o v / g l o s s a r y / t e r m /
man_in_the_middle_attack.
24. A02:2021 - Cryptographic Failures [online]. O W A S P Foundation,
2021 [visited on 2023-05-11]. Available from: https : / /owasp .
org/ToplO/A02_2021-Cryptographic_Failures/.
25. CVE-2007-5460 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2018-10-15 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2007-5460.
26. A03:2021 - Injection [online]. OWASP Foundation, 2021 [visited
on 2023-05-11]. Available from: https : / /owasp . org/Top 10/
A03_2021-Injection/.
27. CVE-2021-1879 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2023-01-09 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2021-1879.
28. CVE-2007-6602 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2017-09-28 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2007-6602.
29. A04:2021 - Insecure Design [online]. O W A S P Foundation, 2021
[visited on 2023-05-11]. Available from: https : / /owasp . org/
ToplO/A04_2021-Insecure_Design/.

54
BIBLIOGRAPHY

30. CVE-2005-2160 Detail [online]. Gaithersburg, M D : National Insti-


tute of Standards and Technology, 2016-10-17 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2005-2160.
31. CVE-2018-1999036 Detail [online]. Gaithersburg, M D : National
Institute of Standards and Technology, 2019-10-02 [visited on
2023-05-11]. Available from: https : //nvd . n i s t . g o v / v u l n /
detail/CVE-2018-1999036.
32. A05:2021 - Security Misconfiguration [online]. O W A S P Founda-
tion, 2021 [visited on 2023-05-11]. Available from: https : //
owasp.org/ToplO/A05_2021-Security_Misconfiguration/.
33. CVE-2022-25264 Detail [online]. Gaithersburg, M D : National In-
stitute of Standards and Technology, 2012-03-08 [visited on 2023-
05-11]. Available from: https : / / n v d . n i s t . g o v / v u l n / d e t a i l /
CVE-2022-25264.
34. A06:2021 - Vulnerable and Outdated Components [online]. OWASP
Foundation, 2021 [visited on 2023-05-11]. Available from: h t t p s :
//owasp . org/ToplO/A06_2021-Vulnerable_and_Outdated_
Components/.
35. A07:2021 - Identification and Authentication Failures [online]. OWASP
Foundation, 2021 [visited on 2023-05-11]. Available from: h t t p s :
//owasp.org/ToplO/A07_2021-Identification_and_Authentication
Failures/.
36. CVE-2021-37555 Detail [online]. Gaithersburg, M D : National In-
stitute of Standards and Technology, 2021-08-09 [visited on 2023-
05-11]. Available from: https : / / n v d . n i s t . g o v / v u l n / d e t a i l /
CVE-2021-37555.
37. A08:2021 - Software and Data Integrity Failures [online]. O W A S P
Foundation, 2021 [visited on 2023-05-11]. Available from: h t t p s :
//owasp.org/ToplO/A08_2021-Software_and_Data_Integrity_
Failures/.
38. CVE-2008-3324 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2018-10-11 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2008-3324.

55
BIBLIOGRAPHY

39. CVE-2008-3438 Detail [online]. Gaithersburg, M D : National Insti-


tute of Standards and Technology, 2008-09-05 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2008-3438.
40. A09:2021 - Security Logging and Monitoring Failures [online]. OWASP
Foundation, 2021 [visited on 2023-05-11]. Available from: h t t p s :
/ / owasp . org / ToplO / A09 _ 2021 - S e c u r i t y _ Logging _ and _
Monitoring_Failures/.
41. CVE-2008-4315 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2017-09-28 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2008-4315.
42. A10:2021 - Server-Side Request Forgery (SSRF) [online]. O W A S P
Foundation, 2021 [visited on 2023-05-11]. Available from: h t t p s :
//owasp.org/ToplO/A10_2021-Server-Side_Request_Forgery_
°/„5C°/„28SSRF°/„5C°/„29/.
43. CVE-2016-4029 Detail [online]. Gaithersburg, M D : National Insti-
tute of Standards and Technology, 2017-11-03 [visited on 2023-05-
11]. Available from: https : //nvd.nist .gov/vuln/detail/CVE-
2016-4029.
44. CVE-2021-26855 Detail [online]. Gaithersburg, M D : National In-
stitute of Standards and Technology, 2022-07-12 [visited on 2023-
05-11]. Available from: https : / / n v d . n i s t . g o v / v u l n / d e t a i l /
CVE-2021-26855.
45. Kali Linux [online]. Offensive Security, 2023 [visited on 2023-05-
12]. Available from: https ://www.kali .org/.
46. WEISS, Yoav. Intent to Explain: Demystifying the Blink Shipping
Process. Chromium Blog [online]. 2019 [visited on 2023-05-15].
Available from: h t t p s : //blog.chromium.org/2019/ll/intent-
to-explain-demystifying-blink.html.
47. H O F F M A N , A n d r e w . Web Application Security: Exploitation and
Countermeasures for Modern Web Applications. 1st edition. O'Reilly
Media, 2020. ISBN 1492053112.

56
BIBLIOGRAPHY

48. Google Hacking Database [online]. Offensive Security, 2023 [visited


on 2023-05-14]. Available from: h t t p s : //www. e x p l o i t - d o . com/
google-hacking-database.
49. Tor Project [online]. The Tor Project [visited on 2023-05-14]. Avail-
able from: h t t p s : //www. t o r p r o j e c t . org/.
50. WhatWeb [online]. A n d r e w Horton, Brendan Coles, 2021-01-16
[visited on 2023-05-15]. Available from: https : //github. com/
urbanadventurer/whatweb.
51. Wappalyzer [online]. Elbert Alias [visited on 2023-05-15]. Avail-
able from: h t t p s : //www. wappalyzer. com/.
52. Built With [online]. Sydney: BuiltWith Pty [visited on 2023-05-15].
Available from: h t t p s : / / b u i l t w i t h . com/.
53. Sublist3r [online]. A h m e d Aboul-Ela, 2020-04-06 [visited on 2023-
05-15]. Available from: https : //github. com/aboul31a/Sublist3r.
54. assetfinder [online]. Tom Hudson, 2020-04-15 [visited on 2023-05-
15]. Available from: https : //github. com/tomnomnom/assetf inder.
55. OWASP Amass [online]. O W A S P Foundation, 2022 [visited on
2023-05-15]. Available from: https : //owasp. org/www-project-
amass/.
56. LI, Vickie. Bug Bounty Bootcamp: The Guide to Finding and Reporting
Web Vulnerabilities. N o Starch Press, 2021. ISBN 1593279949.
57. Hunter [online]. Hunter Web Services, 2023 [visited on 2023-05-
15]. Available from: https : //hunter. io/.
58. httprobe [online]. Tom H u d s o n , 2022-06-09 [visited on 2023-05-
12]. Available from: h t t p s : //github. com/tomnomnom/httprobe.
59. Nmap [online]. Gordon Lyon [visited o n 2023-05-12]. Available
from: h t t p s : //nmap. org/.
60. Niktol [online]. Chris Sullo, 2023 [visited on 2023-05-12]. Avail-
able from: h t t p s : / / c i r t .net/Nikto2.
61. DIRB [online], [visited on 2023-05-12]. Available from: https :
//dirb.sourceforge.net/about.html.
62. Wapiti [online]. Nicolas Surribas, 2023-01-16 [visited on 2023-05-
12]. Available from: h t t p s : / / w a p i t i - s c a n n e r . g i t h u b . i o / .

57
BIBLIOGRAPHY

63. sqlmap [online]. Bernardo Damele A . G . , Miroslav Stampar, 2023


[visited on 2023-05-13]. Available from: h t t p s : //sqlmap. org/.
64. METASPLOIT UNLEASHED [online]. Offensive Security, 2023
[visited on 2023-05-13]. Available from: https : //www. of f sec .
com/metasploit-unleashed/.
65. GitHub Actions [online]. G i t H u b , 2023 [visited on 2023-05-15].
Available from: h t t p s : //github. com/f eatures/actions.
66. OWASP Zed Attack Proxy (ZAP) [online]. O W A S P Foundation,
2023 [visited on 2023-05-13]. Available from: https : / /www .
zaproxy.org/.
67. Web Security Academy [online]. PortSwigger [visited on 2023-05-
15]. Available from: https ://portswigger.net/web-security.
68. Burp Suite [online]. PortSwigger, 2023 [visited on 2023-05-13].
Available from: h t t p s : //portswigger. net/burp.
69. NXP [online]. N X P Semiconductors, 2023 [visited on 2023-05-15].
Available from: h t t p s : //www. nxp. com/.
70. MCUXpresso SDK Builder [online]. N X P Semiconductors, 2023
[visited on 2023-05-14]. Available from: https : //mcuxpresso .
nxp.com/en/welcome.
71. PAUL A . GRASSI Michael E. Garcia, James L. Fenton. NIST Special
Publication 800-63-3: Digital Identity Guidelines [online]. Gaithers-
burg, M D : National Institute of Standards and Technology, 2022-
03-02 [visited on 2023-05-14]. Available from: https : //nvlpubs.
n i s t . gov/nistpubs/SpecialPublications/NIST . SP . 800-63-
3.pdf.
72. O R E N S T E I N , Gary. 3 tips from NIST to keep your passwords
secure. Bitwarden [online]. 2022 [visitedon2023-05-14]. Available
from: https : //bitwarden. c o m / b l o g / 3 - t i p s - f r o m - n i s t - t o -
keep-passwords-secure/.
73. Search Results [online]. Gaithersburg, M D : National Institute of
Standards and Technology, 2023 [visited on 2023-05-14]. Avail-
able from: https : / /nvd . n i s t . gov/ v u l n / search/ r e s u l t s ?
cves=on&cpe_version=cpe:/a:apache:http_server:2.4.6.

58
BIBLIOGRAPHY

74. Cross-site scripting (XSS) cheat sheet [online]. PortSwigger, 2023-


03-30 [visited on 2023-05-15]. Available from: https : //portswigger.
net/web-security/cross-site-scripting/cheat-sheet.
75. Official Kali Linux Docker Images [online]. Offensive Security, 2022-
12-19 [visited on 2023-05-15]. Available from: https : //www. k a l i .
org/docs/containers/official-kalilinux-docker-images/.
76. API Reference [online]. OWASP Foundation [visited on 2023-05-
15]. Available from: https : / /www . zaproxy . o r g / d o c s / a p i /
#introduction.
77. API documentation [online]. PortSwigger, 2023-04-24 [visited on
2023-05-15]. Available from: https : //portswigger .net/burp/
documentation/enterprise/api-documentation.
78. L U K A N O V , Dimitar. H o w to integrate O W A S P Z A P i n Gitlab
C I / C D pipeline. Codific [online]. 2022 [visited on 2023-05-15].
Available from: https : / / c o d i f i c . com/integrate-owasp-zap-
and-gitlab/.
79. Integrating Burp Suite Enterprise Edition with your CI/CD platform
[online]. PortSwigger, 2023-04-24 [visited on 2023-05-15]. Avail-
able from: https : //portswigger . net/burp/documentation/
enterprise/integrate-ci-cd-platforms.
80. GitHub Action: OWASP ZAP Full Scan [online]. G i t H u b , 2023
[visited on 2023-05-15]. Available from: https : //github. com/
marketplace/actions/owasp-zap-f u l l - s c a n ? v e r s i o n = v 0 .4 .
0.
81. GitHub Action: Dastardly Scan Action [online]. GitHub, 2023 [vis-
ited on 2023-05-15]. Available from: https : / /github . com/
marketplace/actions/dastardly-scan-action.
82. ESLint [online]. OpenJS Foundation, 2023-05-05 [visited on 2023-
05-15]. Available from: https : / / e s l i n t . org/.
83. Ruff [online]. Astral [visited on 2023-05-15]. Available from:
https://beta.ruff.rs/docs/.
84. npm-audit [online]. G i t H u b [visited on 2023-05-15]. Available
from: https://docs.npmjs.com/cli/v9/commands/npm-audit.

59
BIBLIOGRAPHY

85. pip-audit [online]. Python Software Foundation, 2023-05-04 [vis-


ited on 2023-05-15]. Available from: https : //docs. npmj s . com/
cli/v9/commands/npm-audit.
86. Snyk [online]. England and Wales: Snyk, 2023 [visited on 2023-
05-14]. Available from: https : //snyk. io/.
87. OWASP Juice Shop [online]. OWASP Foundation, 2023 [visited on
2023-05-15]. Available from: https : //owasp. org/www-project-
juice-shop/.
88. DVWA [online]. Robin Wood, 2023-03-22 [visited on 2023-05-15].
Available from: h t t p s : //github. com/digininja/DVWA.

60
A List of Abbreviations

API Application Programming Interface


ATT&CK Adversarial Tactics, Techniques, and C o m m o n Knowledge
AWS A m a z o n Web Services
CI/CD Continuous Integration and Continuous Delivery
CIA Confidentiality, Integrity, and Availability
CLI Command Line Interface
CSS Cascading Style Sheets
CSV Comma-Separated Values
CVE C o m m o n Vulnerabilities and Exposures
CVSS C o m m o n Vulnerability Scoring System
CWE C o m m o n Weakness Enumeration
DVWA D a m n Vulnerable Web Application
GUI Graphical User Interface
HTML Hypertext M a r k u p Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IPS Intrusion Prevention System
NIST The National Institute of Standards and Technology
NVD National Vulnerability Database
OWASP Open Worldwide Application Security Project
PHP Hypertext Preprocessor
SDK Software Development Kit
SSRF Server-Side Request Forgery
VMs Virtual Machines
VPN Virtual Private Network
WAF Web Application Firewall
XSS Cross-Site Scripting
XXE X M L External Entities
ZAP O W A S P Zed Attack Proxy

61
B Attached Archive

This thesis attached archive contains outputs from tools and an auto-
mated testing shell script, all used for MCUXpresso security analysis
in Chapter 4.

• alive_domains.txt: output from Httprobe used i n Section 4.2

• assetfinder_output.txt: output from assetfinder used i n Section


4.1

• owasp_zap_report: inside this folder, open the 2023-05-14-ZAP-Report-. html


file to see the complete report from Z A P used i n Section 4.3,

• scan_nikto.txt: output from Nikto used i n Section 4.2

• scan_nmap.txt: output from N m a p used i n Section 4.2

• scan_wapiti.txt: output from Wapiti used i n Section 4.2

• sqlmap_output.txt: output from sqlmap used i n Section 4.3

• test.sh: an automated testing shell script explained in Section 4.4

• whatweb_output.txt: output from WhatWeb used i n Section 4.1

62

You might also like