![The source code of Morris worm. source: [Intel-Newsroom, 2013]](https://www.researchgate.net/profile/Shahid-Alam-3/publication/361765615/figure/fig1/AS:1174459276886019@1657024320632/The-source-code-of-Morris-worm-source-Intel-Newsroom-2013_Q320.jpg)
![The WannaCry ransomware. source: [Naked-Security, 2019]](https://www.researchgate.net/profile/Shahid-Alam-3/publication/361765615/figure/fig2/AS:1174459276890115@1657024320649/The-WannaCry-ransomware-source-Naked-Security-2019_Q320.jpg)
![Main processes of fuzzing: source [Li et al., 2018]](https://www.researchgate.net/profile/Shahid-Alam-3/publication/361765615/figure/fig3/AS:1174459276894209@1657024320673/Main-processes-of-fuzzing-source-Li-et-al-2018_Q320.jpg)
![Overview of a reverse engineering process: source [Botero et al., 2020]](https://www.researchgate.net/profile/Shahid-Alam-3/publication/361765615/figure/fig4/AS:1174459276898309@1657024320686/Overview-of-a-reverse-engineering-process-source-Botero-et-al-2020_Q320.jpg)
Content uploaded by Shahid Alam
Author content
All content in this area was uploaded by Shahid Alam on Mar 12, 2024
Content may be subject to copyright.
Available via license: CC BY 4.0
Content may be subject to copyright.
Contents
1
Introduction 2
1.1
Why Cybersecurity ............................................................................................... 2
1.2
A Short History of Cybersecurity ......................................................................... 3
1.3
A Glance into Challenges and Solutions .............................................................. 7
1.4
Organization of the Book...................................................................................... 8
2
Software Security 10
2.1
What is the Problem ........................................................................................... 10
2.2
Impact of Software Vulnerabilities ..................................................................... 12
2.3
Software Vulnerabilities and Mitigation ............................................................. 13
2.3.1
Buffer Overflow ..................................................................................... 13
2.3.2
Never Trust Input ................................................................................... 15
2.3.3
Access Control ....................................................................................... 17
2.3.4
Denial of Service ................................................................................... 20
2.3.5
Poor Error Handling .............................................................................. 22
2.4
Software Protection ............................................................................................ 25
2.4.1
Why and How ........................................................................................ 26
2.4.2
Anti-Reverse Engineering Techniques ................................................... 26
2.5
Designing Secure Software ................................................................................ 28
2.6
Secure Programming .......................................................................................... 29
2.7
Security Testing and Assurance .......................................................................... 30
2.8
Future Work ....................................................................................................... 31
2.8.1
Code Obfuscation .................................................................................. 31
2.8.2
Smart Fuzzing ........................................................................................ 32
2.8.3
Secure Programming Languages ........................................................... 32
3
Hardware Security 35
3.1
What is the Problem ........................................................................................... 35
3.2
Impact of Hardware Vulnerabilities.................................................................... 36
3.3
Hardware Vulnerabilities and Mitigation ............................................................ 36
3.3.1
Hardware Trojans .................................................................................. 37
3.3.2
Side-Channel Attacks ............................................................................ 38
i
3.3.3
Physical Attacks .................................................................................... 40
3.4
Security/Kill Switch ........................................................................................... 42
3.5
Security Testing and Assurance .......................................................................... 43
3.6
Future Work ....................................................................................................... 44
3.6.1
Machine Learning .................................................................................. 44
3.6.2
IoT Devices ........................................................................................... 45
4
Evolution of Malware 46
4.1
Malware ............................................................................................................. 46
4.1.1
Classification ......................................................................................... 47
4.2
Analysis and Detection ....................................................................................... 48
4.3
Reverse Engineering ........................................................................................... 50
4.4
Cyberattacks ....................................................................................................... 51
4.5
Evolution ............................................................................................................ 51
4.5.1
Hidden Malware .................................................................................... 53
4.5.2
Obfuscations .......................................................................................... 54
4.6
Issues and Challenges ......................................................................................... 56
4.7
Solutions ............................................................................................................. 58
4.7.1
Static Malware Analysis ........................................................................ 58
4.7.2
Dynamic Malware Analysis ................................................................... 62
4.8
Future Work ....................................................................................................... 63
4.8.1
Automation ............................................................................................ 63
4.8.2
Embedded Systems Malware ................................................................. 64
4.8.3
Adversarial Machine Learning and Malware Analysis .......................... 64
4.8.4
In-Cloud Malware Analysis ................................................................... 64
5
Biometrics 66
5.1
Basics ................................................................................................................. 66
5.1.1
Classification ......................................................................................... 68
5.1.2
Phases .................................................................................................... 68
5.1.3
Testing ................................................................................................... 69
5.1.4
Spoofing ................................................................................................ 70
5.2
Methods .............................................................................................................. 70
5.2.1
Fingerprinting ........................................................................................ 70
5.2.2
Face Recognition ................................................................................... 71
5.2.3
Iris Scanning .......................................................................................... 71
5.2.4
Keystroke Dynamics .............................................................................. 72
5.2.5
Voice Recognition .................................................................................. 72
5.2.6
Comparison ............................................................................................ 73
5.3
Multi-Biometric Systems ................................................................................... 73
5.3.1
Normalization ........................................................................................ 74
5.3.2
Fusion .................................................................................................... 74
5.4
Soft Biometrics ................................................................................................... 75
CONTENTS
iii
5.4.1
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.4.2
Application to Cybersecurity . . . . . . . . . . . . . . . . . . . . .
75
5.4.3
Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5
Privacy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5.1
Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.6 Biometric Attacks ............................................................................................... 77
5.6.1
Types
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.6.2
Protections
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.7
Future
Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.7.1
Wearable Biometrics . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.7.2
DeepFakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.7.3
Usability Testing
. . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.7.4
Personal Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
6
Cyber Intelligence
83
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.2 Cyber Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.2.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.2.2 Collecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.2.3 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.2.4 Performing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.3 Challenges and how AI can help
. . . . . . . . . . . . . . . . . . . . . . .
87
6.3.1 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.3.2 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.3.3 Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.4 Practical Applications of AI to Cybersecurity . . . . . . . . . . . . . . . .
89
6.4.1 Adversarial Machine Learning . . . . . . . . . . . . . . . . . . . .
89
6.4.2 Game Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6.4.3 Improving Cybersecurity Using Generative Adversarial Networks .
91
6.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
6.5.1 Hybrid Augmented Intelligence . . . . . . . . . . . . . . . . . . .
92
6.5.2 Explainable Artificial Intelligence
. . . . . . . . . . . . . . . . . .
92
7
Cyber Forensics
94
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.1.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.2 Collecting Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
7.2.1 Chains of Custody . . . . . . . . . . . . . . . . . . . . . . . . . .
99
7.2.2 Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
7.2.3 Risks and Challenges . . . . . . . . . . . . . . . . . . . . . . . . .
100
7.2.4 Digital Fingerprints . . . . . . . . . . . . . . . . . . . . . . . . . .
100
7.2.5 Final Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
7.3 Antiforensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
CONTENTS
1
7.3.1
Hiding Data.......................................................................................... 102
7.3.2
Erasing Data ........................................................................................ 103
7.4
Future Work ..................................................................................................... 104
7.4.1
Tools .................................................................................................... 104
7.4.2
IoT Forensics ....................................................................................... 104
7.4.3
Cloud Forensics ................................................................................... 105
Chapter 1
Introduction
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
(Sun Tzu, The Art of War, 500 BC)
1.1
Why Cybersecurity
With the rising of the Internet and the technology that runs and controls it we are transform-
ing into a new Digital Age, This transformation is different than any of the previous such
transformations. Advancements in the technical areas, such as natural language processing,
machine and deep learning, have tremendously improved the processing and use of social
media, Internet of things (IoTs), and cloud computing, etc. These advancements have
certainly improved the workings of businesses, organizations, governments, the society
as a whole, and day to day life of an individual. These improvements have also created
some new challenges, and one of the main challenge is security. The security of the new
digital age, also known as Cyberspace, is called Cybersecurity. A formal definition of
Cybersecurity provided by Merriam-Webster dictionary [Merriam-Webster, 2021b] is:
Measures taken to protect a computer or computer system (as on the Internet) against
unauthorized access or attack.
Another formal but a more comprehensive definition given in [Schatz et al., 2017] is:
The approach and actions associated with security risk management processes followed by
organizations and states to protect confidentiality, integrity and availability of data and
assets used in cyberspace. The concept includes guidelines, policies and collections of
safeguards, technologies, tools and training to provide the best protection for the state of
the cyber environment and its users.
2
1.2. A SHORT HISTORY OF CYBERSECURITY
3
100
80
60
40
20
0
2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
Figure 1.1: Google search trends [Google, 2021] by month, from January 2004 to January
2021, for the terms Cyber Security, Computer Security, and Information Security. The y-
axis depicts the relative search frequency for the term. A value of 100 is the peak popularity
for the term. A value of 50 means that the term is half as popular. A score of 0 means there
was not enough data for this term.
Different terms are being used in the context of security. Some of the popular terms
are Computer Security, or Information Security. Now a days, to include all kind of com-
puter systems and cover everything that is part of the cyberspace, such as smart devices
(e.g., smartphones and televisions), cloud computing, IoTs and several others, the new term
Cyber Security has become increasingly popular. The graphs shown in Figure 1.1 depict
the popularity by month of these three terms (mentioned above) when used during Google
searches performed from January 2004 to January 2021. This development in the use of ter-
minology based on the current most popular search engine is useful and of value to identify
trends. The term Cyber Security starts gaining popularity from the year 2017 and achieves
peak popularity in the years 2019 and 2020. Whereas, the other two terms show a steady
decline in popularity.
To keep pace with the advancements in the new digital technologies like IoTs and cloud,
there is a need to expand research and develop novel cybersecurity methods and tools to
secure these domains and environments. We need to highlight some of the challenges facing
cybersecurity and discuss some innovative solutions to resolve or mitigate these challenges.
To know these challenges and provide solutions we have to examine the past, scrutinize the
present and ameliorate the future.
1.2
A Short History of Cybersecurity
The first comprehensive published work Security Controls for Computer Systems
[Ware, 1970] which became the foundation in the field of cybersecurity was a technical
report commonly called the Ware Report. This report, published in 1970, was the result of
Cyber Security
Computer Security
Information Security
1.2. A SHORT HISTORY OF CYBERSECURITY
4
Figure 1.2: An example of the message produced by the Creeper: source
[corewar.co.uk, 2021]
a study carried out by a task force on computer security organized by the department of de-
fense of United States of America. The report concluded, that a comprehensive security of a
computer system requires a combination of hardware, software, communications, physical,
personnel and administrative controls.
The first computer program (also the first non-self-replicating benign virus in history)
that could move across a network was written in 1971, leaving a message trail (I am the
creeper, catch me if you can) behind wherever it went. The program was called the Creeper.
An example of the message produced by the Creeper is shown in Figure 1.2. The first exam-
ple of an antivirus program (it performed the same functions that an antivirus does today)
was written in the year 1973 called the Reaper, which chased and deleted the Creeper.
Reaper was also the first self-replicating program and hence making it the first benign com-
puter worm (a self-replicating computer program that moves across the network).
In 1977 the CIA triad, of Confidentiality, Integrity, and Availability shown in Figure
1.3, was introduced [Ruthberg and McKenzie, 1977]. These are the three basic principles
for cybersecurity and are still widely used benchmarks to evaluate the effectiveness of a
cybersecurity system.
Confidentiality — The confidential information and data should be prevented from reach-
ing the wrong hands. Confidentiality deals with the access, operation, and disclosure of
system elements.
Integrity — The information and data should not be corrupted or edited by a third party
without authorization. Integrity deals with the modification, manipulation, and destruction
of system elements.
Availability — The information and data should be available all the time and adaptive
recovery mechanisms should be established to restore the system and the services provided
by the system. Availability deals with the presence, accessibility, readiness, and continuity
of service of system elements.
The CIA triad gives the appearance of a holistic security model, but is not in any way
1.2. A SHORT HISTORY OF CYBERSECURITY
5
Figure 1.3: The CIA Triad
a checklist for security systems. It is rather a limited security model and acts as a starting
point for many elaborative security systems engineering frameworks, processes and policies
[Ross et al., 2016].
During the 1980s, the ARPANET (the first wide-area network) became the Internet.
As computers started to become more connected computer viruses became more advanced.
The Morris Worm (Figure 1.4) developed in 1988 became the starting point of the creation
of more effective worms and viruses. This rise led to the development of antivirus solutions
as a means for countering the worm and virus attacks.
Figure 1.4: The source code of Morris worm. source: [Intel-Newsroom, 2013]
In the 1990s viruses such as Melissa (Figure 1.5) causes the failure of the email systems
by infecting tens of millions of computers. These attacks have mostly financial and strate-
gic objectives. 1990s also saw a sudden growth of antivirus companies. These antivirus
products suffered with using a large amount of available resources and producing a large
number of false positives. Some of the cybersecurity solutions today also suffered similar
problems.
As the computers started gaining computing power, the 2000s saw sophisticated ma-
licious software, such as polymorphic and metamorphic malicious programs. These two
Confidentiality
Cybersecurity
Availability
1.2. A SHORT HISTORY OF CYBERSECURITY
6
Figure 1.5: The Melissa virus sent through an email. source: [Panda-Security, 2013]
types can change there shape and structure with a variety of complex modules to execute
malicious activities. These and other stealthy malicious programs have also infiltrated the
new platforms, such as smartphones and IoTs (Internet of things), etc. Stuxnet (Figure 1.6)
found in the year 2010 was the first weaponized malware program, and one of the first
instances where cyberattacks were used in espionage. Stuxnet spread using an infected
removable drive such as a USB flash drive. This drive contain Windows shortcut files to
initiate the malicious executable code.
Figure 1.6: The Stuxnet virus spreading through a USB drive. It first injects a malicious
module into Windows autorun.inf file. After this, the malicious module executes automat-
ically and loads the Stuxnet main body (∼XTRVWp.dat) from the USB drive and injects it
into the system process. source: [Gostev, 2012]
Recently, ransomware (malicious software that threatens the victim to publish or block
access to victim’s data unless a ransom is paid) attacks are on the rise, e.g., WannaCry (Fig-
ure 1.7), Clop Ransomware, and Mount Locker. Because of the ongoing digitization and
hardware acceleration, attackers also started targeting hardware, with Backdoors, Trojans
and side-channel attacks.
With the rise of new technologies, such as artificial intelligence (AI), researchers and
1.3.
A GLANCE INTO CHALLENGES AND SOLUTIONS
7
Figure 1.7: The WannaCry ransomware. source: [Naked-Security, 2019]
industry have also started applying these new technologies to analyse and understand the
cyberattacks and improve defense against them. At the same time, attackers and adversaries
are using similar techniques to advance their cyberattacks.
The best cybersecurity defense for a system is to know and reduce the current and future
cybersecurity risks to the system. For example, a novel technique, Generative Adversarial
Networks (GANs) [Goodfellow et al., 2014], is being applied to give insights into specific
behaviors of adversaries and also provide guidance and direction to reduce the cybersecurity
risks to a system. GANs can also be used by adversaries to learn specific behaviors of the
defenders, and improve their attack strategies to defeat the defense against their attacks.
This is the modern warfare (a.k.a Cyberwarfare), where friends and foes improve upon
their defending and attacking cyber technologies and tools, respectively, to defeat each
other.
1.3
A Glance into Challenges and Solutions
There are several challenges facing cybersecurity. Some of them are:
1.
The increased model complexity of AI makes it difficult for its application and adop-
tion in cybersecurity.
2.
Successful development and implementation of human-AI collaboration to improve
cybersecurity.
3.
Development and improvement of simple user authentication mechanisms suitable
for the resource constrained devices, also called wearable and IoT biometrics.
4.
Personal privacy is still a big concern when it comes to the design, development, and
deployment of biometrics.
5.
Cyber forensics of IoT devices and Cloud computing is still immature and faces lot of
challenges, such as complexity and diversity of IoT devices, and evidence collection
1.4. ORGANIZATION OF THE BOOK
8
in Cloud environment because the data is distributed between countries and within
datacenters.
6.
For the successful analysis and detection of the shear number of malicious programs
we need to completely automate this process.
7.
Design, development, and implementation of in-cloud analysis of malicious pro-
grams .
8.
Applying machine learning to hardware security faces several challenges. One of the
major limitations of the application of machine learning to hardware reverse engi-
neering is the lack of extracted features that can be generalized to other chips.
9.
Code obfuscation, smart fuzzing, and secure programming languages are some of the
challenges faced by software security.
Next generation cybersecurity started using innovative technologies to improve detec-
tion and prevention of new threats and building a safe and secure society. Some of the
examples of these technologies are:
1.
Multi-factor authentication, e.g., using a combination of personal identification num-
ber (PIN), biometrics (fingerprints, and face, etc.) or passwords.
2.
Behavioral analysis of malicious programs to detect anomalies.
3.
Sandboxing, i.e., creating an isolated and safe environment for testing malicious pro-
grams or links.
4.
Forensics, the use of scientific methods and expertise to gather and analyze evidences
that can be used in criminal or other investigations in a court of law.
5.
Applying artificial intelligence (AI) to improve and solve challenging problems in
cybersecurity.
Here we have just enumerated some of the challenges and solutions. In rest of the
chapters, we are going to discuss in detail these and some other challenges and also some
new innovations and solutions. We also present some future directions to resolve or mitigate
the challenges faced by cybersecurity.
1.4
Organization of the Book
This chapter has provided a peek into the past, present and future of cybersecurity. Rest of
the chapters provide detail discussion about the past, present, and future of different major
sub-domains and specializations of cybersecurity: including software, hardware, malware,
biometrics, artificial intelligence, and forensics.
1.4. ORGANIZATION OF THE BOOK
9
The rest of the book is organized as follows:
Chapter 2 first defines what is Software Security, and then discusses some of the major
software vulnerabilities and techniques to mitigate these vulnerabilities. How to protect
and design secure software. It also discusses about software security testing. At the end, it
points out some future works and directions in the field of software security.
Chapter 3 first defines what is Hardware Security, and then discusses some of the
major hardware vulnerabilities and techniques to mitigate these vulnerabilities. It also dis-
cusses about hardware security testing. At the end, it points out some future works and
directions in the field of hardware security.
Malware is a major threat to cybersecurity, therefore we have dedicated a separate
Chapter 4 that discusses the Evolution of Malware, including classification, analysis, re-
verse engineering, cyberattacks. It also discusses some of the issues in malware analysis
and detection, such as obfuscation, automation, and morphing, and their solutions. At the
end, it points out some future works and directions in the field of malware analysis and
detection.
Chapter 5 first covers the basics of Biometrics, such as properties, classification,
phases, testing, and methods used. It also discussed about multi and soft biometrics, and
different biometric attacks and how to protect against them. At the end, it points out some
future works and directions in the field of biometrics.
Chapter 6 first covers the basics of AI, including the definition, different approaches
to AI, and explains the processes involved in Cyber Intelligence. Some of the challenges
plaguing cybersecurity where AI can help are also discussed. It also discusses some practi-
cal applications of AI to cybersecurity, such as adversarial machine learning, game theory,
and generative adversarial networks. At the end, it points out some future works and direc-
tions in the field of cyber intelligence.
Chapter 7 first introduces the field of Cyber Forensics, including basic terminologies
used and the general process of cyber forensics. Then it talks about some anti-forensics
technique used to make forensic analysis difficult. At the end, it points out some future
works and directions in the field of cyber forensics.
Chapter 2
Software Security
Force the enemy to reveal himself, so as to find out his vulnerable spots.
(Sun Tzu, The Art of War, 500 BC)
2.1
What is the Problem
NASA Mars Polar Lander, a 165 million US dollars machine, crashed on December 3, 1999
into Mars due to software errors, generating false signals that led the onboard computer to
shut off the engine too soon [Leary, 2000]. This disaster could have been avoided and fixed
by a software change in the onboard computer. The investigating reports concluded that
due to the pressure of the NASA’s credo of faster, cheaper, better on project managers and
engineers working on the NASA Mars Polar Lander ended up compromising the project.
To meet the new constraints, the project managers neglected and sacrificed needed testing
and realistic assessments of the risks of failure.
Northeast blackout of 2003 was caused due to a software bug, known as a race con-
dition, in the alarm system at the control room. This blackout was a widespread power
outage of upto two days of the Northeastern and Midwestern United States, and the Cana-
dian province Ontario. Almost 55 million people were affected by this power outage. The
blackout’s cause was stalling of the alarm system at the control room, causing the failure of
both audio and video alerts of the system state.
Buggy smart meters open door to power grid botnet (interconnected devices each run-
ning one or more malicious programs) [Goodin, 2009]. An experimental worm developed
at IOActive (a cybersecurity company) self-propagated across these meters, and was able to
take over large number of them. The vulnerabilities present in the software on these smart
meters, because of the use of insecure C functions memcpy() and strcpy(), were ex-
ploited for this attack.
The above three real life examples demonstrate and reveal that software bugs are re-
sponsible for producing security vulnerabilities in a program that can be exploited by at-
tackers to fail the software system. Complexity is the enemy of security, i.e., a complex
10
2.1.
WHAT IS THE PROBLEM
11
program will contain more bugs. Not all the bugs lead to security vulnerabilities. A secu-
rity analyst is only interested in bugs that have security implications and are called security
bugs/flaws. If we eliminate all the bugs from a software system that will also eliminate all
the security bugs from the system. This proposition becomes a premise of the relationship
between software engineering and software security. Improving the quality of a software
system would result in an increase in security of the system. However, many security bugs
go undetected, because traditional software development processes does not cater for se-
curity. For example, during quality assurance of a software system only reasonable range
of user inputs are tested, whereas the attackers are rarely reasonable and will devise inputs
that break the system.
DEFINITION: A software vulnerability is a set of conditions, bugs, flaws, or weak-
nesses in the software that can be exploited by an attacker. A software exploit is a piece
of malicious program that takes advantage of a vulnerability in a software system to cause
damage to the system. A mitigation is a method, technique, or process that prevents or
limits exploits. Software Security is a process/practice to either mitigate or design and
develop software without vulnerabilities to escape exploitations.
Figure 2.1 shows the growth in the number of software vulnerabilities from 1988 – 2020
in the National Vulnerability Database maintained by NIST (National Institute of Standards
and Technology) USA. The number of vulnerabilities grew from just 2 in the year 1988 to
16958 in the year 2020. In the last four years there is a significant increase in these numbers.
Following are some of the rationals for this sudden increase in software vulnerabilities over
the last four years. There are several, but we only list some of the major causes.
1730516958
1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
Figure 2.1: Statistics on software vulnerabilities reported from 1988 – 2020 Source: Na-
tional Vulnerability Database maintained by NIST, USA [NIST, 2020]
1.
The competition and pressure from businesses and organizations demand a shorter
time to market of the software products from the vendors. This in turn forces the ven-
dors to release products faster and reduce the resources and time for quality assurance
and testing.
2.
With the continuous evolving technology, mobile devices and their applications,
2.2.
IMPACT OF SOFTWARE VULNERABILITIES
12
cloud computing, social media, and Internet of things (IoT) have become ubiquitous.
This has enabled the deployment of new products and services and have opened op-
portunities for innovative businesses, though with relatively low maturity in software
development and lacking skills in secure coding.
3.
Complexity is the enemy of security. Software applications’ are increasingly becom-
ing complex because of the new wave of technology. Modern applications are often
built using open source components which become a source of major vulnerabili-
ties in these applications. The complexity problem is worsen by the use of unsafe
programming languages (e.g., C and C++).
4.
Legacy systems, that for different reasons are still in use, are also a major source of
vulnerabilities.
5.
Cybersecurity is now on top of the agenda on every nation state. Therefore, they are
actively engaged in vulnerability research to support lawful interventions in software
systems. With cyberattack becoming a profitable activity and business, cybercrimi-
nals are also heavily involved in vulnerability research to support their attacks.
6.
A vulnerability is introduced by design, such as back doors, for various purposes
(software updates, security patches, and hidden commercial agendas, etc) by the soft-
ware vendors.
2.2
Impact of Software Vulnerabilities
The impact of software vulnerabilities on consumers and businesses is in the form of, loss
of data, privacy, other resources, such as time and money, etc. Following are some of the
key impacts because of a vulnerability in a software system/application.
Denial of Service: An attacker partially or completely disrupts the normal function of
a computer service (e.g., an online service such as a website) and prevents other users from
accessing the service. This can cost a business or an organization both time and money
while their resources are unavailable.
Information Leakage: An attacker gets access to confidential information present in a
software system/application, such as technical and proprietary details about the application,
developer comments, or user specific data. This data can be used by the attacker to further
exploit the target application, its hosting network/cloud, or its users. Depending on the type
of software, this attack can cause serious financial damages to the business, or sabotage the
company or organization, owning the software.
Privilege Elevation: An attacker attempts to gain more permissions or access with an
existing account that the attacker has compromised. The result of this is that the attacker
with more privileges can perform unauthorized and malicious actions, such as deleting
important accounts, files or other such resources on a system. In addition to other damages,
these actions can compromise the trust and privacy of users and cause a loss of assets of the
system.
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
13
Software is everywhere. It runs your car, controls your cell phone and household items.
It is the backbone of banks and nations’ power grids. As businesses, organizations, indi-
viduals and nations depend heavily on software, we have to make it better and more secure.
Software security is no longer a luxury but a necessity.
2.3
Software Vulnerabilities and Mitigation
Here we discuss some of the major software vulnerabilities that can be exploited by an
attacker (a person or program) to inflict damage on the system. We also present and discuss
some of the strategies/techniques to mitigate them.
2.3.1
Buffer Overflow
A buffer overflow occurs when a program writes data outside the buffer, i.e., the allocated
memory. Buffer overflow vulnerabilities are usually exploited by an attacker to overwrite
values in memory to the advantage of the attacker. The first exploit of buffer overflow was
carried out in 1988 by Morris Worm (a malicious program). The worm exploited a buffer
overflow vulnerability in some of the UNIX applications, sendmail, finger, etc., infecting
10% of the Internet at that time. After over 3 decades we would expect that buffer overflow
would no longer pose a significant threat. But, recently in 2019 a buffer overflow vulner-
ability in WhatsApp VOIP on smartphones was exploited that allows a remote attacker to
execute arbitrary code on the target system. WhatsApp was broken with just a phone call,
the user did not even have to pick the phone [Newman, 2019]. This indicates how dangerous
is this vulnerability and justify the importance of preventing buffer overflow.
Here is a simple buggy program overflow() that is susceptible to buffer overflow attack.
void overflow() {
char buff[32];
gets(buff);
}
gets() continues to read input until the end of line character, an attacker can overflow
the buffer, buff, with malicious data. In the current environment the above code would
be quickly labeled as unsafe, because gets() is almost universally understood to be an
unsafe function. The presence of the above code in legacy applications still makes this a real
threat today, especially on older platforms. For a better understanding of a classic buffer
overflow exploit, consider Figure 2.2
There are three different versions of execution of function overflow(). In the first
version, before execution, space is reserved for the buffer and then the return address of
the caller. In the normal execution, the string "Hello World" is read from the input
and stored in the buffer. Then the function jumps to the return address, i.e., returns to the
caller. In the third execution, during the buffer overflow attack the attacker has already
filled the stack with a series of nop instructions, the exploit code, and the address of the
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
14
Figure 2.2: Three different varieties of a simplified stack frame for the function
overflow(): the top one before execution, the middle one after normal execution, and
the bottom one after a buffer overflow attack
beginning of the buffer, hence the function instead of returning to the caller executes the
exploit code. There are also other types of buffer overflow, such as heap-based, integer
overflow, etc. Interested readers are referred to [Hoglund and McGraw, 2004] for more
details and in-depth coverage of buffer overflow exploits.
Mitigation
□ Tracking Buffer Size: The most common mistake that leads to buffer overflow exploit
is not keeping track of the buffer size. Memory safe languages, such as Java and
Python, keep track of the buffer size and use this size during different operations
performed on the buffer. But, a very large number including the legacy programs
are written in the two most popular languages C and C++, which are memory unsafe
languages. A general solution to explicitly track size of the buffer is to keep/store
length of the buffer as a separate value and update whenever the buffer size changes.
In C, this can be accomplished with the following data structure.
typedef struct {
char* ptr;
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
15
int length;
} buff;
□
Use of Safe Functions and Languages: As shown above in the code snippet for buffer
overflow example, the function gets() is an unsafe (dangerous to use) function.
There are several other such functions that are also dangerous, such as scanf(),
strcpy(), strcat(), and so on. All of them can be replaced by the safe func-
tions, that check the array bonds, such as gets s(), scanf s(), strcpy s(),
strcat s(), and so on. There is a safe dialect of C and C++ programming lan-
guages and contain all the safer functions. The best way to avoid buffer overflow is to
either use safe programming languages, such as Java and C#, or use safe dialect of a
programming language. The problem is not yet solved, because there already exists a
large number of legacy programs that contain these unsafe functions. Many of these
legacy programs are in native code, i.e., the source code is not present. That means it
is difficult/impossible to replace the unsafe functions in these programs. What to do
about these programs. There are different solutions to get around this problem, and
here we discuss two of them.
□
Address Space Layout Randomization: During a buffer overflow attack the main pur-
pose of the attacker is to execute its own malicious code. The first solution, address
space layout randomization (ASLR) randomly arranges the address space of data ar-
eas of a process, including the stack, heap and libraries. In this case the attacker
has to first successfully guess the address of the injected malicious code which is a
non-trivial process. Recently researchers have shown that ASLR can be bypassed by
using a type of side-channel attack [Evtyushkin et al., 2016]. A side-channel attack
is any attack based on the information gained from the internal knowledge, such as
timing information, power consumption, etc., of a computer system, rather than the
weaknesses, such as software bugs, etc.
□
Data Execution Prevention: The second solution, data execution prevention (DEP)
attempts to ensure that the contents of only those memory locations can be executed
that are pre-defined for such purpose, and data/code in all other memory locations
become non-executable. DEP helps prevent buffer overflow attacks that inject and
execute code and rely on some part of the memory, usually the stack, both being
writable and executable. DEP can be implemented in either hardware or software. A
combination of DEP and ASLR becomes a successful defense against buffer overflow
and other such attacks. All the major operating systems, including Linux, Android,
iOS, Windows, and Solaris implement both ASLR and DEP technique to avoid buffer
overflow and other such attacks.
2.3.2
Never Trust Input
One of the most talked about mantra of security professionals/gurus is to Never Trust Input.
But, when you ask a group of programmers about this mantra, you will notice a mystified
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
16
1003 OR 'a'='a'
look on their faces. If you can not trust input, how can your program do anything useful?
Example 2.3.1 illustrates the gravity of this mantra.
Example 2.3.1. How a hacker might get access to all the usernames and passwords in a
database. If the input is not checked and a user is allowed to enter anything, then a malicious
user can enter the following input in the user id field of a web database application:
UserID:
The SQL statement generated is:
SELECT * FROM Users WHERE UserID = 1003 OR 'a'='a';
This is a valid SQL statement, since 'a'='a' is always true. If the Users table also
contains names and passwords then the above SQL statement becomes:
SELECT UserID, Name, Password FROM Users WHERE UserID = 1003
OR 'a'='a';
This returns all the ids, usernames and passwords from the Users table in the database.
The above example elucidates a SQL injection attack because of the poor/no input val-
idation. This example also shows how metacharacters are used to exploit a vulnerability
in the SQL. Metacharacters are characters that have special meaning in the input language,
such as single quote (') in SQL, double period (..) in file system paths, and semicolon (;)
and double ampersand (&&) in command shells. Using these metacharacters, several other
such attacks are possible because of inadequate input validation. A program have to accept
input, but it must not trust it, then what it should do? A program must implement adequate
input validation, such as performing sanity check, corroborating the input, and controlling
and limiting only the acceptable values, etc.
Mitigation
□
Validate All Input: This is the basic mitigation, to check all the inputs from all the
sources. For example, if your application consists of more than one process, vali-
date the input for each of the process. Validate input even if it comes from a secure
or trusted connection. Every validation done denies the attacker an opportunity and
provides an added degree of assurance. There are two types of validation: Syntax Val-
idation – checks the format of the input, and Semantic Validation – checks the input
based on the logic and function of the application. Perform input validation not only
on user input, but also on data from any source outside the program/application, such
as command line parameters, configuration files, data from database, and network
services, etc.
□
Parameterized Requests: Example 2.3.1 shows a metacharacter vulnerability exploit.
Many such and other metacharacter vulnerabilities can be eliminated by keeping data
and code information separate. The main cause of SQL injection is the mixing of
data and code. Trusted code is sent via a code channel and untrusted data provided
by user is sent via a data channel. The database clearly knows the boundary between
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
17
code and data. The code hidden in data by an attacker manipulating metacharacters
(example 2.3.1) will never be treated as code, so it will never be executed.
□
Whitelist Validation: In this type of validation only known good inputs are accepted.
The known good inputs are based on the expected type, length or size, numeric range,
or other format standards. For example a credit card number should only contain
numbers between 16 digits long and passes the business logic check (validity of a
number based on the last digit of the card). Regular expressions are generally used
to implement whitelist validation. Example 2.3.2 lists a Java program using regular
expressions to validate US phone numbers.
□
Blacklist Validation: In this type of validation known bad inputs are rejected. The
known bad inputs are based on the presence of the number of known bad characters,
strings, or patterns in the contents of the input. Because, in general the list of poten-
tially bad characters is extremely large, this validation is weaker than the whitelist
validation. Like whitelisting, a common way of implementing a balcklist is also to
use regular expressions.
In practice, whitelist validation is first used and then if needed it is supplemented with
blacklist validation. There are certain validations where it becomes difficult to get a full list
of possible inputs and use the whitelist validation. For example, applications with certain
inputs that are localized in languages with large character sets, e.g., Chinese and Japanese.
In these cases to validate the application inputs whitelist is supplemented with blacklist
validation.
Example 2.3.2. Example, taken from [Chess and West, 2007], of a Java program using
regular expressions to validate US phone numbers.
// A separator is some whitespace surrounding a . or -.
String sep = "\\s*[.-]?\\s*";
// A US phone number is an optional 1 followed by
// a three digit area code, a three digit prefix,
// and a four digit number.
String regex = "(1"+sep+")?\\d{3}"+sep+"\\d{3}"+sep+"\\d{4}";
2.3.3
Access Control
Access control is one of the most important security features when designing and develop-
ing an application. It sets permissions and protects the application’s resources from unau-
thorized access. Applications may manage their own resources or use the services provided
by the operating system (OS). Different OSs have their own access control model. Here we
briefly discuss the traditional access control model of the UNIX OS (Android OS is based
on Linux, which is a variant of UNIX).
Users of a UNIX system have a user name, which is identified by a user ID (UID).
Every user belongs to a group and consequently has a group ID (GID). The information
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
18
Symbolic
Link
/home/foo
attacker can
read/write
/etc/passwd
attacker cannot
read/write
Symbolic
Link
/home/foo
attacker can
read/write
/etc/passwd
attacker cannot
read/write
required to map a user name to a UID is maintained in the file /etc/passwd. The login
program authenticates a user by examining the /etc/passwd file to validate the UID
and password of the user. Each file in a UNIX system has an owner (UID) and a group
(GID). Only the owner and root can change permissions for a file. The permissions are
read, write, and execute. These permissions can be granted or revoked for each of
the following types of users: Owner, group, and others.
Figure 2.3 shows an example of an access control exploit. In this attack, an attacker
exploits the race condition bug in the program to gain access to a file which the attacker
could not otherwise access. The problem occurs when the access to a file is checked and
then the file is opened if access is granted. There are two operations performed here, one is
checking access, and the other is opening the file. In the time between these two operations
(window of vulnerability) an attacker can change the link of the file that is being operated
upon. In this way the attacker can gain access to a file that otherwise is not accessible to
the attacker. A shown in Figure 2.3 the attacker changed the link of the file /home/foo
to point to /etc/passwd. Now the program is tricked into opening a file on behalf of the
attacker that it should not have.
a. Checking access to the file.
b. Opening the file. Before opening the file the attacker has changed the
link to point to a file that is otherwise not accessible to the attacker.
Figure 2.3: Example of an access control exploit by utilizing race condition software vul-
nerability
The race condition vulnerability is more common in multithreaded programs because
of the uncontrolled concurrency found in these programs. These type of vulnerabilities are
difficult to detect, reproduce, and eliminate. In these cases, similar to the above example, to
eliminate the race condition a race window is to be identified. A race window is a piece of
code that accesses the race object in a way that opens a window of opportunity for the other
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
19
processes/threads (e.g., an attacker) can access and alter the race object. A race window is
not protected by a lock or any other mechanism.
Generally a web application provides a web interface to manage user accounts and
other resources. An administrator logins using this web interface to manage the resources.
Example 2.3.3 shows an access control exploit at the application level. In which an attacker
gains privileges of an administrator.
Example 2.3.3. Some applications determine the user’s access rights or role at login de-
pending on the parameters passed. For example the following URL:
https://insecure.com/login/home.jsp?admin=false
when changed (admin=false means an unsuccessful login) by an attacker (unauthorized per-
son – not an admin) to:
https://insecure.com/login/home.jsp?admin=true
gives the attacker access to carry out administrative functions.
Mitigation
□
Closing the Window of Vulnerability: The race condition vulnerabilities exist only
during the (race) window of vulnerability. The obvious solution is to eliminate this
window. We discuss here some of the techniques to eliminate these windows. (1)
Checking for symbolic links and only give access to a file if it is not a symbolic link.
This way even if the attacker changes the symbolic link will not be able to gain access
to the file. (2) Using synchronization primitives available in OSs (locks, semaphores,
etc) these windows of vulnerability can be protected as mutually exclusive critical
sections. Care must be taken to minimize the size of the critical sections. (3) In a
multithreaded application it is not enough to only avoid race conditions within the
application’s own instructions. The invoked functions could be responsible for race
conditions. In this case, use of thread-safe functions avoid race conditions. Thread-
safe functions can be called by concurrent threads with the function being responsible
for any race condition. (4) Use of atomic operations. These operations can not be in-
terrupted until run to completion. It is this atomic property that makes these functions
useful for synchronization and helps eliminate race conditions.
□
Principle of Least Privilege: A process, user, or program must only access the
resources that are necessary for their legitimate purpose to complete the job
[Saltzer, 1974]. This mechanism mitigates race conditions as well as other vulner-
abilities. For example, if a program is running with elevated privileges and accessing
files in shared or user directories, there is a chance that the program might be ex-
ploited and perform an operation for which the user of the program does not have
the appropriate privileges. One of the methods used to implement this mechanism is
in the microprocessor hardware. For example, in the Intel x8 architecture there are
four modes (ring 0 – ring 3) of running with graduated degrees of access. The most
privileged is ring 0. The OS kernel runs in ring 0, device drivers may run in rings 1
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
20
or 2 and applications in ring 3. It can also be implemented in software. As in OSs the
elevated privileges are dropped, as soon as the process is finished with the required
job, before accessing the shared resources.
□
Managing Permissions: Managing privileges is a good strategy for controlling the
access, but it will not control the initial permissions given to a process, user, or pro-
gram. This is the responsibility of the administrator and the programmer. We discuss
here some of the techniques that can be used to manage permissions. (1) Securing
Directories – A secure directory is a directory where no one other than the user, or the
administrator, has the ability to manipulate (create, rename, and delete, etc) files. All
the directories above a secure directory are owned by either the user or the superuser
(administrator), and can not be manipulated by other users. Other users may only
read or search the directory. This eliminates the possibility of an attacker masquerad-
ing as an other user will not be able to exploit a file system vulnerability in a program.
(2) Restrict Initial Access Permissions – A process inherits the permissions from its
parent process. A parent process gets the default permissions set by the OS, that can
be adjusted by the administrator when installing the OS. These permissions should
be set appropriately keeping the principle of least privilege as discussed above. There
are certain rules (mostly based on common sense) to follow when managing the ini-
tial access permissions. Here we will just list couple of them. For executable files,
only permit the file owner to execute the file. For sensitive files, only permit the file
owner to read and write.
□
Multi-Factor Authentication: Multi-factor authentication (MFA) is a process of grant-
ing access to a user or application after successfully presenting two or more factors
of authentication. These factors may include: something you have – e.g., a bank card
or a key; something you know – e.g., a password or a PIN; and something you are
– e.g., fingerprints or eye iris. A typical example of two-factor authentication is the
correct combination of a bank card and a PIN to withdraw from an ATM. This kind
of authentication reduces identity thefts and online frauds as the victim’s password
would not be enough to access the information.
2.3.4
Denial of Service
Denial of service (DOS) attack is one of the easiest and most popular attacks, that it needs a
separate mention here. We have already discussed some of the vulnerabilities that can cause
DOS, such as buffer overflow and access control vulnerabilities. Here we explain DOS with
an example and then discuss some of the mitigation techniques. Resource starvation attacks
consumes all the available resources to prevent normal clients from obtaining access to the
system. In a service-based system, if your application is single threaded, it may not be
able to process the requests as quickly as they are received, i.e., your application will only
support a simple service with one thread. To support more number of clients, a pool of
threads is used. If the size of the pool is fixed, an attacker can simply send requests faster
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
21
than an application can serve. If the pool of thread is not fixed, then the application can
absorb lot of DOS attacks without dropping the service entirely. But, then at some point
the application is going to consume system resources without bound. Therefore, instead of
just breaking the service provided by an application a DOS attack can bring down the entire
system. An extension of DOS attack is a DDOS (Distributed DOS) attack. A DDOS attack
is carried out from multiple machines to starve the resources of the target system. Figure
2.4 shows a DDOS attack carried out by an IoT (Internet of things) botnet. Several Internet
devices (including computers, smartphones, and IoTs) connected and running one or more
bots is called a botnet (the network of bots). A botnet is controlled through a command and
control (C&C) software. A bot is a software application that rns automated tasks, such as
web crawling, etc., over the Internet.
IoT device (Bot)
IoT device (Bot)
IoT device (Bot)
IoT device (Bot)
1
Figure 2.4: A DDOS attack carried out by an IoT botnet
Mitigation
□
Managing Clients: A common mistake in writing multithreaded application is to
create a new thread every time a new task is initiated, such as a new connection from
a client. An attacker can quickly flood (leading to a DOS attack) the server with
false or incomplete connections. To avoid this attack, place limits on the number
of connections from each client. If a client tries to consume more than the allowed
number, then these additional requests from the client are simply refused. Also, make
Botmaster
(Attacker)
C&C server
Victim
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
22
the limit of connections configurable. This will save the server from DOS attack,
and the attacker has to launch a DDOS attack to deny service to anyone other than
themselves. To mitigate DDOS attack is to implement timeouts. If a client does not
send requests in a timely manner, the connection with the client can be closed, making
the worker thread available for a new connection. This response can also be based on
the utilization of the worker threads. If an attack is perceived, the connections can be
dropped more quickly. Do not right away allocate memory/resources just to respond
to a client who wants to connect to your application. First validate and authenticate
a client before starting any complicated process or allocating much memory for the
client. If each client sends 10MB of data, then it will not take many clients to run
your machine out of memory. Set limits on the amount of data the application will
accept. Make this limit configurable, and drop clients that exceeds this limit.
□
System Resource Management: System resources, such as memory, CPU time, disk
space, and open files, etc., are best managed by system quotas. A running application
does not have knowledge if these quotas are enabled or not. Therefore, it is better to
be defensive and write code that is more aware of the system resource management.
This is also part of good programming practice. Some of these good programming
practice rules are listed as follows. (1) Minimize the number of file reads and writes.
(2) Try to avoid CPU intensive code or loops. (3) Do not use stack for allocating
large size of buffers. (4) When possible, avoid using system calls.
□
Intrusion Prevention System: Intrusion prevention system (IPS) is a relatively recent
development in cybersecurity. The main purpose of such systems is to monitor net-
work or system activities for malicious activity. Whenever a DOS attack takes place
these systems can log information about the attack, report and attempt to block or
stop the attack. There are two methods that these systems use to detect attacks. (1)
Signature-Based – This method monitors packets in the network traffic with known
attack patterns as signatures. (9) Anomaly-Based – This method monitors network
traffic and compare it against an established baseline. The baseline determines what
is normal and what is anomaly.
2.3.5
Poor Error Handling
In general programmers pay less attention to abnormal situations in the code than they do
to the normal cases. This makes errors (abnormal cases) a natural path for the attackers
to follow. These abnormal cases can be, the network is down, database connection failed,
page not found on the server, or memory not allocated, etc. Example 2.3.4 shows that on
Error 404 (HTTP standard error for the requested resource not found) sensitive information
is revealed/leaked by a server that can be used by an adversary (opponent – e.g., an attacker)
to design and launch an attack.
Example 2.3.4. Generation of error message containing sensitive information
Following is the message returned by a server for a non-existent page:
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
23
Error 404 - Page not found.
The requested page /page.html was not fond on this server.
Apache/2.2.3 (Unix) mod ssl/2.2.3 OpenSSL/0.9.7g DAV/2
PHP/5.1.2 Server at Port 80
The server reveals valuable information, web server version, OS, modules, and code used,
that can be used by an attacker to design and launch an attack.
Mitigation
□
Managing Exceptions: Exceptions allows code to separate between normal and ab-
normal cases. There are two types of exceptions, checked and unchecked. Checked
exceptions can not be ignored, whereas unchecked exceptions do not have to be de-
clared or handled. To force the programmer to properly take care of the abnormal
case catch all exceptions whether checked or unchecked. To accomplish this, handle
exception at the top level of the exceptions’ hierarchy. In Java the base (top) class is
Throwable. Example 2.3.5 shows a snippet of Java code for handling exception at
the top level.
Example 2.3.5. All the top-level Java methods should catch Throwable:
protected void getHost(HttpServletRequest req) {
try {
String ip = req.getRemoteAdddr();
InetAddress addr = InetAddress.getByName(ip);
out.pritnln("Hostname: " + addr.getHostName());
}
catch (Throwable e) {
out.println("Caught at the top level: " + e);
}
}
Certain other rules to follow for managing exceptions are: (1) To avoid duplicated
try/catch blocks handle exceptions in a centralized place, and ensure that all abnormal
behaviors are correctly handled. (2) Error messages should be verbose enough to
enable proper user response, but must not display or leak critical data. (3) Careful
testing and verification of error handling code should be performed.
□
Return Values: Functions or methods return a value to convey their success or failure.
In case of a failure, this value is used by the calling code to handle the error. The
problem with this is that function that returns the value depends on the caller to
check the error. Further, this prevents returning something more interesting, like the
function result. Moreover, there is no universal convention for communicating error
information, so error returned from each function call is handled differently. Uncheck
return values become problems and can lead to buffer overflows, information leakage
and other software vulnerabilities. To avoid these problems, the designers of C++ and
2.3. SOFTWARE VULNERABILITIES AND MITIGATION
24
Java included exceptions as part of the language feature. Use exceptions wherever
possible but handle/manage them properly as discussed above.
□
Managing Resources: Resources including database objects, file handles, sockets,
and allocated memory etc., should be released properly, otherwise they can cause
serious performance and information/data leakage problems. There is a special con-
nection between error handling and resource leaks, that error handling should address
resource management properly. There are basically three steps to eliminate a resource
leak: (1) Detect the leak. (2) Find the source of the leak. (3) Release the resource at
the proper location in the code to avoid the leak. For example, if a call to reading a
file fails the buffer allocated for the read operation should be freed. If this is not done
properly a resource/memory leak will occur, as shown in example 2.3.6. Example
2.3.7 shows a proper way of performing the error handling and hence avoiding the
resource leak.
Example 2.3.6. A memory leak takes place if the call to reading the file fails:
char *readFile(int handle) {
char *buffer = (char *) malloc(SIZE);
if (buffer == NULL); {
return NULL;
}
else if (read(handle, buffer, SIZE) != SIZE) {
return NULL;
}
return buffer;
}
Example 2.3.7. Handling the error (reading the file fails) properly to avoid the
memory leak shown in example 2.3.6:
char *readFile(int handle) {
char *buffer = (char *) malloc(SIZE);
if (buffer == NULL); {
return NULL;
}
else if (read(handle, buffer, SIZE) != SIZE) {
free(buffer);
return NULL;
}
return buffer;
}
□
Debugging: Debugging is one of the best practices to catch any error/bug in the
software. This practice gives insight into a running program and assists in finding
errors or abnormal behaviors in the program. Logging is another technique that saves
2.4. SOFTWARE PROTECTION
25
hours of manually debugging a program. The problem is to log or not to log. Here
are some of the good practices to follow taken from [Chess and West, 2007]: (1)
Log every important action, including authentication attempts, attempt to modify the
ownership of an object, account creation, password reset requests, purchases, sales,
or anything of value, etc. (2) Use centralize logging, to provide one consistent and
uniform view, and to facilitate changes. (3) Time stamp log entries to form a timeline
of events that greatly helps in forensic investigations. (4) Protect the logs, i.e., prevent
attackers from gaining access to the log entries.
Keep debugging aids and back-door access code out of production. Isolate the de-
bugging code within the program so that it does not show up in the production code.
Back-door code is a form of debugging code that is written to test different com-
ponents of the software system and allows the test engineers to access the software
in a way that are not intended for the end users/customers. If back-door code ends
up in the production code then an attacker can use it to bypass security mechanisms
and gain access to sensitive parts of the system. There are different methods, such
as using version control tools, preprocessors, etc, to keep the debugging code out of
production. Example 2.3.8 shows how to isolate debugging code from the production
code using C/C++ preprocessors.
Example 2.3.8. Keeping debugging code out of production.
#define DEBUG
...
#if defined( DEBUG )
// debugging code
...
#endif
2.4
Software Protection
Brain, the first IBM PC virus was written (for benign purpose) in 1986 by the authors to
protect their software from illegal use and copying. Brain effects the PC by replacing the
boot sector of a floppy disk with a copy of the virus, making the disk unusable. The virus
came complete with the address and phone numbers of the authors and a message asking
the users to call them for inoculation. Similar techniques or concept is used now to protect
against software piracy and tampering (reverse engineering). Malware writers often use re-
verse engineering techniques to find vulnerabilities in a software (usually binary programs)
system and write malware to exploit the system. Protecting software from reverse engineer-
ing is an often overlooked software engineering topic, and has no easy answers. Section 4.3
in Chapter 4 discusses and explains several reverse engineering techniques. Here before
discussing some of the anti-reverse engineering techniques, we first elaborate upon why
and how of software protection.
2.4. SOFTWARE PROTECTION
26
2.4.1
Why and How
The first thing an attacker is going to ask before cracking a software is, if the software
is popular and in high demand. For example, there are more malware programs written
for Android than iOS. The reason is the popularity and demand of Android. This way
the exploit written has a greater impact and produces more benefits (financial and others)
for the attacker. On the other hand the software company will try to make cracking the
software a difficult or impossible task. The second question an attacker is going to ask is,
if the software is highly and genuinely valuable, such as special algorithms, or applications
controlling and managing sensitive facilities/resources of a state or a company, etc. This
way also, the exploit written has a greater impact, and more professional actors, including
states, get involved in researching and developing the exploit. In such cases, it is worth
spending large amounts of time and money to protect the software.
When writing and developing a software protection mechanism, it should be assumed
that the attacker has absolute control over the physical and software components of the
system on which the application is running. The basic goal of software protection is to
increase the level of competence and time required to breach the software. The achieve this
goal stealthy techniques are used to protect the software. For example a strong encryption
only serve to lead the attacker directly to the location of protection. Then it is a just a matter
of time before the software is breached. The location and effects of protection should be
hidden, so that the attacker finds it difficult to trigger the protection.
There is always some kind of cost involved when protecting software. The cost to
breach the software is always much less than the cost to develop the protection. There are
certain type of costs that one should keep in mind when developing software protection. (1)
Developing Time – This is the time to develop effective software protection. Skilled and
experienced programmers are required to write good software protection. Moreover, the
time spent on writing software protection is the time away from the application develop-
ment. Sometimes, a third-party software protection is used. Well known and commercial
software protections are known to the attackers and can be bypassed. So, it is always wise
to supplement it with in-house protection mechanisms. (2) Debugging Time – While devel-
oping software protection new bugs may be induced into an otherwise working application.
Moreover, protected software itself is difficult to debug. With more new bugs the time to
debug the application is significantly increased. (3) Maintaining Time – Software protection
makes it difficult to understand the code, which in turn makes it difficult to maintain. After
months or years of the protection being implemented, the maintenance engineers may no
longer be able to understand the protection or the code it protects.
2.4.2
Anti-Reverse Engineering Techniques
Checksums
Checksum is a datum (a single piece of information usually numerical) used as a signa-
ture of a program to check for any modifications done to the program. A good checksum
2.4. SOFTWARE PROTECTION
27
algorithm will generate a significantly different value even for small changes made to the
input. That is why usually a cryptographic hash function (CHF) is used for generating the
checksum. CHF is a special hash function with the following properties: (1) Compression –
Output of a CHF, i.e., the hash value, is fixed size. (2) Deterministic – A CHF produces the
same hash for the same input, no matter how many times it is used. (3) One Way – There is
no practical or feasible way to invert the hash. (4) Collision Resistant – It is impossible to
find any two inputs that hash to the same value.
Obfuscations
Obfuscation is a technique in which a program is transformed into another program that
keeps the behavior of the original program but is hard to understand. This makes it non-
trivial to reverse engineer the obfuscated program. The quality of obfuscation depends on
these four metrics [Collberg et al., 1998]: (1) Potency – How much more obscure an obfus-
cated program becomes. (2) Resilience – How much an obfuscated program holds up to an
automatic reverse engineering tool. (3) Stealth – How well an obfuscated program blends
in with the rest of the program. (4) Cost – How much time and space is required to obfus-
cate a program. Section 4.5.2 in Chapter 4 presents and discusses some of the obfuscations,
including some basic and advance techniques, used by malware (malicious program) to
escape detection, and can also be used for software protection. A more complete list of
different obfuscation techniques can be found in [Nagra and Collberg, 2009].
Watermarking
Software watermarking is a defense technique whereby a signature is embedded inside
a software application to reliably representing and identifying the owner. The embed-
ded signature should be resilient to code transformations, optimizations and obfuscations,,
i.e., the signature should be stealthy and hard to tamper with. Moreover, the signature
should be retrievable. There are two types of software watermarking, static and dynamic
[Nagra et al., 2002]. Static watermark is defined as one which is stored in the applica-
tion executable itself. Dynamic watermark is defined as one which is stored in a pro-
gram’s execution state, rather than in the program code itself. Some important metrics
[Nagra et al., 2002] to measure the effectiveness of a software watermarking technique are:
(1) The computational cost of developing, embedding, and recognizing the watermark. (2)
The running time and memory consumption of embedding a watermark into a program.
Hardware
There are different methods that the hardware can be used to protect the software. Here we
discuss few of these methods. (1) A typical hardware based protection is to use a trusted pro-
cessor to execute the software. The trusted processor uses specific cryptographic techniques
to check and verify a software application before executing the application. This makes it
strenuous to execute the application on any other processor, and becomes enigmatic for
2.5.
DESIGNING SECURE SOFTWARE
28
the pirates to produce the same hardware. (2) Another approach used is to associate the
software with a particular machine by secretly sending the serial number associated with
the hardware to the software company. (3) A smart card or a dongle – trusted hardware
– is used to protect the software, by preventing the software from executing unless some
specific information from the trusted hardware is retrieved.
2.5
Designing Secure Software
Different software systems have different security requirements depending on type of the
system and environments where the system is deployed. For example, software system for
a bank requires a higher level of security than for a university. Despite the presence of these
differences among systems, there are some general guidelines that are universally applied
when designing system security solutions. Here we discuss some of these guidelines. For a
full list and discussion readers are referred to [Sommerville, 2016].
□
Base Security Decisions on an Explicit Security Policy — A security policy of an
organization explicitly lays out fundamental security conditions for the organization.
Software and system designers should use the security policy as a framework for
making and evaluating design decisions. For example, a hospital security policy may
state that only the authorized clinical staff may modify the patient records. Design
of the access control for the hospital should be based on such security policies. If an
organization do not have an explicit security policy, which is generally the case, then
the designers may have work this out from examples and confirm with the managers
of the organization.
□
Defense in Depth — In any critical software system, it is a good design practice to
avoid a single point of failure. For software security this means, instead of relying
on a single mechanism to ensure security employ several different techniques. This
approach is sometimes called defense in depth. For example, using multifactor au-
thentication to recognize and authenticate users to a system.
□
Fail Securely — Failing securely means, when a system fails use fallback procedures
that are as secure as the system or more secure than the system itself. So that when
the system fails an attacker should nt access data that would not normally be allowed.
For example, if a server in a hospital fails before deleting certain patient data from
the database, that data can be accessed by an attacker. The patient data should be
encrypted before storing on the client, so that an unauthorized user cannot read the
data.
□
Compartmentalize Assets — Compartmentalizing means organizing the information
in a system into compartments. A user should have access to the information that
they need for their work, rather than to all of the information in a system. An attack
compromising a user account can be contained. This means some information may
2.6.
SECURE PROGRAMMING
29
get damaged or lost, but not all of the information in the system. For example, clinical
staff should not be given access to all the patient records, but only to those patient
records who have an appointment with them. If an intruder steal their credentials,
then the intruder cannot damage all patient records.
□
Design for Recovery — A system should always be designed for recovery. That
means the designer should always assume that a security failure could occur, and a
recovery mechanism should always be designed so that the system can be restored to
a secure operational state. For example, if the password authentication subsystem is
compromised, then there should be a backup authentication sbsystem that can replace
the compromised subsystem.
2.6
Secure Programming
Most successful attacks on software rely on software vulnerabilities that were introduced
during the program development. We have already discussed some of these vulnerabili-
ties and their mitigation in section 2.3. There are some universally accepted programming
practices and principles that reduces the chance of introducing software vulnerabilities into
programs. Here we discuss some of these basic principles of secure programming. For a
full list and discussion readers are referred to [Sommerville, 2016].
□
Control the Visibility of Information in a Program — A principle that is adopted by
military organizations is the need to know security principle. Individuals (users) are
given access to only a particular piece of information that they need to carry out their
duties. When programming control access to the variables and data structures that
you use. Hide these from the components that do not use them. For example, abstract
data types, in which the structure and attributes are not externally visible, and all
access to the data is through operations.
□
Minimize the Use of Error Prone Constructs — There are some programming ap-
proaches/constructs that are more likely to cause and introduce errors in programs
than others. These constructs should be avoided as much as possible. Some of these
approaches/constructs are: goto statements, dynamic memory allocation, aliasing,
and unbounded arrays, etc. For example, dynamic memory allocation where storage
is explicitly managed. it is very easy to forget to release the storage in the program,
that can lead to a memroy leakage and eventually can become a security hazard.
□
Check Array Bounds — Not all programming languages automatically check array
bounds. For example the two most popular languages C and C++ does not provide
any standard construct or library for checking array bounds. For example in C/C++,
array[123456] would access the word that is 123456 locations from the beginning
of the array, irrespective of whether or not this was part of the array. This lack of
bound checking leads to security vulnerabilities, such as buffer overflow discussed in
2.7.
SECURITY TESTING AND ASSURANCE
30
section 2.3. For these and other such languages there is a need to include checks that
the array index is within bounds.
□
Check all Inputs for Validity — We have already discussed some general techniques
about checking and validating inputs in section 2.3. Wrong input values may lead
to produce wrong results and may cause system failure. Here we discuss different
type of checks specifically used during software coding and programming. (1) Range
Checks: Check if the input is within the range. For example, a sensor value should be
within a particular range, e.g., temperature value between 0 and 100 degrees Celsius.
(2) Size Checks: Size of the input could be important for various financial transac-
tions, such as 8 characters to represent a bank account, and less than 40 characters to
represent name of a person, etc. (3) Representation Checks: There are specific for-
mats to represent different inputs, such as name of a person does not include numeric
values, and the two parts of an email address are always separated by a @ sign, etc.
(4) Reasonableness Checks: If the input belongs to a series and there is a relationship
between members of the series, then we can check if the input is reasonable or not.
For example checking for outliers in the readings of a household electricity smart
meter. The current amount of electricity used should be approximately the same as
in the previous years. If there is a huge difference (from 3000 kWh → 10 kWh) then
that means something has gone wrong, e.g., the reading of the smart meter has been
manipulated by violating the software.
2.7
Security Testing and Assurance
To assure the security of a software system, security testing [Potter and McGraw, 2004,
Sommerville, 2016] of the system is carried out. The verification and validation of software
system should not only look for the correctness of the system and that the system is fit for
purpose, but also focus on security assessment. During security assessment, the ability of
the system to resist against different types of attack is tested. One of the other goals of
security assessment is to find vulnerabilities that can be used by the attackers to gain access
to the system or cause damage to the system or its data. To carry out security assessment
of a software system different types of testing is carried out, some of them are discussed
below.
□
Experience-Based Testing — This testing is based on the experience of the validation
team. The team analyses a system against the types of attacks and vulnerabilities that
are known to them. For example, testing for buffer overflow errors, validating all
inputs, and so on. They also check if the design and programming guidelines have
been followed.
□
Penetration Testing — This testing is based on the experience of the validation team
and as well as experiences drawn from outside the validation team. The main goal of
this testing is to break into the system. For this purpose they simulate different type
2.8. FUTURE WORK
31
of known attacks, and also develop new (unknown) attacks based on their ingenuity.
One of the main advantages of penetration testing is that it simulates the behavior
of a real cybercriminal to uncover the critical security issues in a system. This also
uncovers the steps carried out to exploit a vulnerability and the steps required to fix
the vulnerability, before it is exploited for real.
□
Tool-Based Testing — This testing is based on the use of security tools such as static
and dynamic analysis tools to find errors and vulnerabilities in a software program.
Anomalies revealed during this analysis can be directly fixed or help identify part of a
system that requires more testing to find the real possibility of a risk to the system. In
this approach experience of security flaws is embedded into the tools used for testing.
The main problem with security testing is the time available for testing. The validation
team has a limited time to test the software, because of reasons beyond their control, such
as the pressure from the customers to release the software as soon as possible, and other
financial constraints. The time available to attackers is almost unlimited. They can spend
more time discovering vulnerabilities than the system test engineers. They are also willing
to experiment and try things that are outside the normal activities. A better approach to
testing is a risk-based [Potter and McGraw, 2004] analysis of a system, that focuses on the
most significant risks faced by the system.
2.8
Future Work
The number of attacks and threats posed to software are increasing rapidly. Therefore,
research in software protection is growing at a fast pace. To encourage further research in
this fast-growing area, this section discusses some future research directions including the
problems and challenges faced.
2.8.1
Code Obfuscation
To protect software we want to make exploitation of vulnerabilities harder. One of the
basic techniques used for this purpose is code obfuscation. This makes the code more
complicated and harder to comprehend, and hence difficult to find vulnerabilities. Even if
adversaries get hold of the code it takes more time and energy, and in turn makes reverse
engineering of the code harder and costlier. Some of the future research opportunities or
gaps in this area are [Hosseinzadeh et al., 2018]: (1) Lack of a standard metric for reporting
the overhead and effectiveness of the obfuscation techniques. More empirical studies are
needed to measure and present the performance and space requirements of the different
obfuscation techniques. (2) There is a need to do more research on applying the obfuscation
techniques to other domains/environments, such as mobile platforms, cloud computing, and
IoT. For example Android applications are vulnerable to reverse engineering. Most of the
studies on obfuscation in mobile environments only discuss techniques used by malware
to evade detection.
There is a need to develop new obfuscation techniques for mobile
2.8. FUTURE WORK
32
platforms to increase their software security. There is a limited number of studies on the
obfuscation techniques for securing cloud computing and IoT environments.
2.8.2
Smart Fuzzing
Fuzzing is the most widely used technique in practice for finding vulnerabilities in software
[Li et al., 2018, Godefroid, 2020]. It generates and executes tests automatically with the
goal of finding vulnerabilities. Compared to static analysis fuzzing produces less number
of false positives, but is more compute intensive. Any application that processes untrusted
data and input must be fuzzed. The main processes of fuzzing are shown in Figure 2.5.
Fuzzing starts with the generation of a set of program inputs (testcases). The input should
meet the requirements of the target program input format as far as possible. The generated
inputs are fed to the target programs. One of the main challenges of fuzzing is that the
inputs should be broken enough to fail the program. Therefore, one of the future works
in fuzzing is to automate the generation of input grammars for complex formats, possibly
using machine learning or some other techniques. Another future work is the effective
fuzzing of large distributed applications such as the entire cloud services. Smart fuzzing is
another area to improve, such as collecting as much information about the target program
as possible to improve fuzzing.
Figure 2.5: Main processes of fuzzing: source [Li et al., 2018]
2.8.3
Secure Programming Languages
Programming languages are used to communicate ideas between humans and machines,
and design and write computer programs that perform some kind of computation. Recently,
because of the importance of designing secure information systems, programming language
researchers have made security a prime concern in language design and implementation.
2.8. FUTURE WORK
33
Safe Languages
Many attacks exploiting software vulnerabilities in language design and implementations.
The most well known example of such an attack is the buffer overflow attack (Section 2.3.1,
such as the strcpy function in C and C++, in which the overflowing data overwrites un-
allocated memory e.g., for malicious purposes. Therefore, a safe language is crucial for
designing secure systems and avoiding software vulnerabilities, and provides more princi-
pled defense against buffer overflow and other exploits [Salka, 2005]. For example, Java
employs dynamic checks to enforce safety. Safe languages like PLT, a safe dialect of Lisp,
is used to write an advanced web server that, unlike web servers written in C like Apache,
is not subject to buffer overflow exploits [Graunke et al., 2001].
Language-Based Access Control
A programming language provides access to local resources such as CPU, memory, and
files, which can be exploited by the attackers. Sandboxing is a technique that is used to
access control to resources. Java and other such language platforms can achieve sandboxing
by combining lower level safety and security controls. For example, Java prevents untrusted
platforms such as Applets to load classes with the same name as the existing library names
to protect against spoofing attacks (a program identifying as another).
Language-Based Information Flow
We explain the importance of secure information flow with the following example. If H is
a variable and has a higher security level than the variable L, then we would allow flows
from L → L, L → H, H → H, but not H → L. That means:
the following explicit flows
H = L; and L = 1234; are legal
whereas, the following explicit flow
L = H; is illegal
and also illegal is the following implicit flow
if ((H % 2) == 0)
L = 0;
else
L = 1;
This copies (the information leaks) the last bit of H to L
If we do not check the flow of information from H → L then some information can
be leaked. To check and catch these insecure and illegal information flows, information
flow analysis analyzes a software program before its execution to inspect and propel the
security of data that flows through the program. In this, program variables and statements
2.8. FUTURE WORK
34
are augmented with labels to specify data use policies. For example, Jif (Java + information
flow) [Myers, 2021, Sabelfeld and Myers, 2003], an extension to the Java language, has
labels that express security policies to restrict the information flow in a Jif program. A Jif
compiler will flag the above implicit flow (the if statement) as illegal, because the label
associated with it is high (H) while there is assignment to the low label variable (L).
Unsafe Languages
How to make unsafe languages, such as C and C++ safer? The researchers have extended to
create safe variants, CCured [Necula et al., 2002], Cyclone [Hicks et al., 2003] and others,
of these languages. All of these extensions bear some form of weaknesses, such as an unac-
ceptable runtime overhead, and incomplete detection of memory bound violations etc., and
as such these extensions are not widely accepted or used in practice. Because of their pop-
ularity, these languages are still in use, and moreover, lot of legacy code is written in these
languages. Therefore, there is a need to develop methods and techniques to automatically
secure a program written in these languages.
Research in these topics (discussed above) is ongoing, but the current most important
task at hand is the successful integration of modern language security technologies. Why
developers repeat the same mistake? Instead of relying on programmers we should develop
tools that systematize the known security vulnerabilities and integrate them directly into the
development process [Evans and Larochelle, 2002].
Chapter 3
Hardware Security
To know your Enemy, you must become your Enemy.
(Sun Tzu, The Art of War, 500 BC)
3.1
What is the Problem
Hardware security is a new and compounded research area. The purpose of this chapter is
to introduce briefly the topic of hardware security. We have kept the discussion simple and
to the point, and referred further readings to get a thorough understanding of this subject
area.
Computer hardware consists of all the physical parts of a computer, including central
processing unit (CPU), motherboard, monitor, case, mouse, keyboard, data storage, etc.
Most of the time, hardware is directed by the software to execute instructions to perform
certain tasks, but sometimes it is just the hardware that accomplishes a task.
Software functions and primitives either running or implemented on a hardware plat-
form assume that the hardware is resilient to attacks. This is not always true, as shown by
recent vulnerabilities found and attacks on some of the hardware platforms. The first real
world backdoor in a military FPGA (field programmable gate array – a chip that can be
reprogrammed, also called dynamically programmable chip) was detected in the year 2012
by [Skorobogatov and Woods, 2012]. Backdoor is a covert method to gain remote access
to a computer by bypassing normal authentication processes. Using this vulnerability an
attacker is able to perform malicious actions, such as reprogramming crypto and access
keys, modifying low level silicon features, reverse engineering the design or permanently
damaging the device. The most damaging possibility in this case was that it was not possi-
ble to patch the backdoor in the FPGAs already deployed. Organizations using this FPGA
either have to live with the fact that they can be compromised or physically replaced after
a redesign of the silicon itself. There are other examples [Rostami et al., 2014] of finding
such vulnerabilities in smart cards and microcontrollers (small computers embedded inside
devices). Counterfeit (imitation of something authentic for malicious purposes) electronics
35
3.2.
IMPACT OF HARDWARE VULNERABILITIES
36
is prevalent in computers, automobile, control, and defense systems [Rostami et al., 2014].
DEFINITION: A hardware vulnerability is a set of conditions, bugs, flaws, or weak-
nesses in the hardware that can be exploited by an attacker. A hardware exploit is any
malicious action that takes advantage of a vulnerability in a hardware system to cause dam-
age to the system. A mitigation is a method, technique, or process that prevents or limits
exploits. Hardware Security is a process/practice to either mitigate or design and develop
hardware without vulnerabilities to escape exploitations.
3.2
Impact of Hardware Vulnerabilities
The impact of hardware vulnerabilities on consumers and businesses is in the form of, loss
of data, privacy, other resources, such as time and money, destruction of hardware, etc.
Following are some of the key impacts because of a vulnerability in a hardware device.
Denial of Service: In this attack a chip is rendered partially or fully unusable. The
performance of the chip degrades and the functional units of the chip, such as registers,
data path, logic units, remain in an intentionally induced state of overload or deadlock.
Eventually, either the chip is reset or replaced.
Information Leakage: An attacker gains access to a chip and leaks sensitive infor-
mation, such as the design of the chip, technical and proprietary details about the chip,
encryption keys, trade secrets, etc. This sensitive information can lead to further exploits
and attacks on the chip or on the overall system, including the hardware and software. This
can lead to serious financial damages to the companies, and organizations owning or using
the chip. The sensitive information leaked can be used to espionage and finally lead to
sabotaging the critical infrastructures of states and organizations.
Reduce Reliability: Reliability is the quality of a hardware for being trustworthy or
performing consistently well without failures. If the reliability of a chip is reduced, the
software running on it suffers and may fail. This is one of the root causes of software fail-
ures. Moreover, reliability of data storage is paramount for modern hardware and software
systems. Unreliable chips can not be installed in a mission critical system, such as nuclear
power plants, medical devices, and intelligent transport systems, etc.
Hardware is everywhere, even where there is no software. It runs your car, controls your
cell phone, household items, mission critical systems, and saves lives in the form of medical
devices. It is the backbone of banks and nations’ power grids. As businesses, organizations,
individuals and nations depend heavily on hardware, we have to make it better and more
secure. Hardware security is no longer a luxury but a necessity. Cybersecurity starts with
first securing the hardware.
3.3
Hardware Vulnerabilities and Mitigation
Some of the main goals of the adversaries attacking hardware are, leakage of sensitive
information, reducing reliability, denial of service, stealing the design, and identifying trade
3.3. HARDWARE VULNERABILITIES AND MITIGATION
37
secrets. Following type of attacks [Rostami et al., 2014, Prinetto and Roascio, 2020] on the
hardware are possible to achieve these goals.
3.3.1
Hardware Trojans
Any malicious modifications introduced during the design and manufacturing of a chip
is referred to as Hardware Trojans [Chakraborty et al., 2009]. Due to the stealthy nature
(precondition for activation is a very rare event) of Hardware Trojans, it is difficult to detect
them. Activation of a Trojan depends on a condition, such as certain values from sensors,
a particular input pattern, or value of an internal counter. The possibility of vast spectrum
and large number of Trojan instances, and large variety of structure and operation mode an
adversary can employ also make Trojans difficult to detect.
Mitigation
Unlike Software viruses/Trojans Hardware Trojans are difficult to detect and eliminate, and
therefore, are more harmful to computer systems. Lot of research have been done on detect-
ing Hardware Trojans, and different detection and mitigation methods have been proposed.
These methods can be divided into three main categories [Jin, 2015, Becker et al., 2017].
Here we provide a brief discussion of these three categories. For a more complete list
and detail discussion of detection and mitigation methods of Hardware Trojans readers are
referred to [Chakraborty et al., 2009].
1.
Enhanced Functional Testing — This method is based on the fact that Hardware
Trojans are triggered by rare events. Therefore, monitor all the rare events during
the testing stage of a chip. The problem with this testing is that there is no standard
definition of rare events. This makes it difficult to generate all the rare event patterns
for testing.
2.
Side-Channel Analysis — Every electronic device when in operation emits different
signals, such as electrical and magnetic fields. These signals can be analyzed to mea-
sure and gain information about the state and the data which the device processes.
These measurements if different from the Trojan-free device indicates that there may
be a Trojan present on the device. For this purpose, using advanced data analysis
methods a side-channel fingerprint is generated of the Trojan-free device and is then
utilized to detect Trojans. Various side-channel parameters, such as The success of
this method depends on the availability of a golden model of the device for compari-
son.
3.
Hardware Obfuscation — The first step in counterfeiting or stealing the design of
a chip (to introduce a Hardware Trojan) is to reverse engineer the chip. Obfusca-
tion methods are used to defend against reverse engineering the chip. For a detail
discussion of these and other methods readers are referred to [Becker et al., 2017].
Here we just list couple of these methods: Camouflage Gates – The logic function of
3.3. HARDWARE VULNERABILITIES AND MITIGATION
38
the gates used in the design of a chip are camouflaged to make them hard to detect
visually. Obfuscating the Connectivity – Connectivity of individual gates reveal a lot
of information to a reverse engineer. Generally, dummy wires are used to conceal the
connectivity.
3.3.2
Side-Channel Attacks
When a computer is in operation, it performs certain activities, such as performing com-
putations, reading and writing memory, consuming power, releasing energy in the form of
electromagnetic waves, and producing sound, etc. All these activities if monitored properly
with other structural information about the computer and algorithms executed may help an
attacker gain access to sensitive information. Side-channel attacks are based on the infor-
mation leaked through a side-channel as listed above (such as power, and sound, etc). We
divide side-channel attacks into two different types, Passive Attacks and Active Attacks.
Passive Attacks
These attacks just perform reading (i.e., they are passive) of the sensitive information from
the side-channels. General classes [Prinetto and Roascio, 2020] of passive side-channel
attacks are:
□
Timing Attacks: These attacks are carried out using the timing information of dif-
ferent operations performed in the hardware. For example, processing of passwords
or encryption keys have a correlation between the computation time and the actual
values of the input. If an attacker knows this correlation, the sensitive information
(the password or the encryption key) can be extracted. Some of the possibilities and
examples of timing attacks are presented in [Kocher, 1996, Bernstein, 2005].
□
Power Attacks: Similar to the timing attacks, this attack is carried out using the
power consumption information of different operations performed in the hardware.
Power consumed during different operations is different, so by measuring this varia-
tion sensible data is read from the device. Some of the possibilities and examples of
power attacks are presented in [Kocher et al., 1999].
□
Acoustic Attacks: These attacks exploit the sound and vibrations produced by dif-
ferent hardware components during a computation. These acoustics are recorded by
a covert device placed close to the computer. Latter these acoustics are analyzed
using signal analysis and machine learning algorithms to detect the keys pressed
[Koushanfar, 2012, Halevi and Saxena, 2015] or correlate the acoustic emission with
the computer activity [Genkin et al., 2014].
□
Optical Attacks: These attacks are carried out using the light emitted by the hard-
ware (e.g., a transistor used as a switch) in the form of photons for a very short
3.3. HARDWARE VULNERABILITIES AND MITIGATION
39
period. Light emitted by the LEDs (light emitting diodes) that may be used to indi-
cate the device activity can also be exploited to steal sensitive information from the
device. Some of the possibilities and examples of optical attacks are presented in
[Ferrigno and Hlava´cˇ, 2008, Loughry and Umphress, 2002].
□
Electromagnetic Attacks: An electromagnetic field is produced around an opera-
tional hardware due to the current flowing in the hardware circuit. The radiation
caused by the electromagnetic field carries useful information about the original dig-
ital source. By capturing this information the original digital signal can be recon-
structed [Yilmaz et al., 2019], which can lead to information leakage.
Active Attacks
During these attacks, faults are introduced (i.e., they are active) into a chip so that it becomes
easy to steal sensitive information from the side-channels present/available in the chip.
These attacks are also called Fault Attacks. General classes [Prinetto and Roascio, 2020]
of active side-channel attacks are:
□
Power Supply Attacks: In this attack power supply of a chip is tapped to wither
increase or decrease the power supplied to the chip. In case the power is decreased,
the delay of logic gates increases and wrong values may get injected. This implies
that one or more faulty bits as injected into he system [Dusart et al., 2003]. In case
the power is increased, a serious damage can be inflicted on the chip.
□
Glitch Attacks: Similar to power supply attacks, it is possible to change the clock
speed of a chip. For example, by doubling the speed of the clock some of the old data
could be used as the new data has not arrived yet [Ko¨mmerling and Kuhn, 1999].
This can cause corruption of some of the data. This process introduces a glitch which
can also influence conditional jumps, by either not performing them or performing
them at wrong time [Anderson and Kuhn, 1997].
□
Heating Attacks: Raising the temperature of a chip generates random currents,
which may lead to bit flipping. This can corrupt the data stored inside memory
of the chip. This can also cause aging of the circuit, and in extreme cases when
the temperature rises to a certain threshold can also destroy or damage the chip
[Hutter and Schmidt, 2013].
□
Optical Attacks: Like heating attacks, a light with specific wavelength focused on a
chip can also flip the bits. For this to be successful the light should be able to reach
the chip, and any protective layer needs to be removed. An example of such a precise
attack is presented in [Skorobogatov and Anderson, 2002].
□
Radiation Attacks: A simple and practical method to induce faults in a chip is
to cause strong electromagnetic disturbances near the chip. This induces currents
in the circuit which in turn alter the level of a signal, i.e., it gives the attacker
3.3. HARDWARE VULNERABILITIES AND MITIGATION
40
control over the bits [Schmidt and Hutter, 2007]. At a certain level of disturbance
the components of the chip may stop working or even be physically destroyed
[Schmidt and Hutter, 2007].
Mitigation
Side-channel attacks rely on the information present in the leaked data. Therefore, to miti-
gate and counter these attacks, there is a need to eliminate either the information leakage or
the correlation between the leakage and the secret data. In the second case it will be difficult
to make any sense of the information leaked. There are different methods and techniques
[Rostami et al., 2014] used to achieve these goals, here we discuss few of these methods.
1.
Leakage Reduction — These methods reduces the relationship and dependency be-
tween the side-channel leakage and the secret data. For example to decrease the
data dependencies of the power consumption, various dynamic and differential logic
styles have been proposed [Tiri et al., 2002]. Other techniques used to decrease the
data dependencies are: hiding – making the leakage constant; masking – making the
leakage dependent on some random value [Goubin and Patarin, 1999]; encryption of
buses [Brier et al., 2001]; and time randomization [May et al., 2001].
2.
Noise Jamming — Jamming the channel with artificial noise reduces the amount
of information in the side-channel leakages. Artificial noise can be introduced by
dummy circuits or operations [Joye, 2009]. This makes it difficult, i.e., increase the
required work, for an attacker to extract the secret data.
3.
Data Scrambling — This method scrambles the data to make it difficult to accumu-
late the secret data. The scrambling is not random and uses a predefined sequence of
the secret data (e.g., secret keys) and synchronized timings to ensure that the data
is consistent for both the communication parties [Kocher, 2003]. Similar to data
scrambling, blinding techniques [Chaum, 1983] can be used to prevent side-channel
attacks. Blinding can change the algorithm’s input into some unpredictable state,
hence preventing some or all leakage of sensitive information.
4.
Physical Unclonable Functions (PUFs) — PUF [Gassend et al., 2002] is a function
implemented in a chip that maps challenges to responses that can be used to authenti-
cate the chip. PUF exploits the inherent randomness during manufacturing of a chip
and provides a unique digital fingerprint to the chip. Due to the effectiveness of side-
channel attacks against PUFs, circuit countermeasures should be used as proposed in
[Ru¨ hrmair et al., 2013].
3.3.3
Physical Attacks
So far we have discussed non-invasive hardware attacks, that can be carried out without
any physical contact with the hardware device. Physical attacks are carried out by taking
3.3. HARDWARE VULNERABILITIES AND MITIGATION
41
invasive actions against the attacked hardware. These actions could include depackaging
or disconnecting internal components of the device, etc. Physical access to the device is
required for these type of attacks. In the following paragraphs we discuss some of these
attacks.
Microprobing
Microprobing is the process of affixing microscopic needles onto the internal wiring of a
chip in order to steal information or to carry out fault attacks. A well known method for
getting access to the internals (circuit and paths) of a chip is by making a hole through the
chip with a Focused Ion Beam (FIB)