Linköpings universitet
Linköping University | Department of Computer and Information Science
Bachelor’s thesis, 16 ECTS | Information Technology
2019 | LIU-IDA/LITH-EX-G--19/029--SE
Testing and Improving the
Secu-rity of a Mobile Application
Testning och förbättring av säkerheten i en mobilapplikation
Sofia Gyulai
William Holmgren
Supervisor : Simin Nadjm-Tehrani Examiner : Marcus Bendtsen
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från pub-liceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till doku-mentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgäng-ligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i så-dant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Students in the 5 year Information Technology program complete a semester long software development project during their sixth semester (third year). The project is completed in midsized groups, and the students implement a mobile application intended to be used in a multiactor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students form small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.
Abstract
When making new software systems, security testing should always be included in the process. In this thesis, attacks were identified and performed against a system consisting of two servers and an Android application. A penetration test was also performed against parts of the system. If an attack was successful, this was considered a vulnerability. The attacks that were identified and performed were a NoSQL injection attack a man-in-the-middle attack and reverse engineering. Through the man-in-the-man-in-the-middle attack and reverse engineering, breaching security properties such as confidentiality and integrity was possi-ble. The NoSQL injection attack was not successful in breaching neither. No results from these could be used to exploit the system further. Countermeasures were taken to secure against the discovered vulnerabilities, and new instances of the attacks were performed after this as well. The overall conclusion is that the system is now secure against our im-plementations of the attacks performed in this thesis.
Acknowledgments
First, we want like to thank our supervisor Simin Nadjm-Tehrani for her support and help during the progression of this thesis. She has inspired and motivated us to do the best work we can achieve. Also, we would like to thank all the members in our group, who together with us developed the system we use during this thesis.
Contents
Abstract iii
Acknowledgments v
Contents vi
List of Figures vii
1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 1 1.3 The System . . . 1 1.4 Problem Statement . . . 3 1.5 Delimitations . . . 3 1.6 Structure . . . 3
2 Tools for Security Testing 4 2.1 Security Testing . . . 4
2.2 Penetration Testing . . . 5
2.3 SQL and NoSQL Injection . . . 7
2.4 Man-in-the-Middle . . . 7
2.5 Reverse Engineering . . . 8
3 Work Approach and Choice of Attacks 9 3.1 Testing Approach . . . 9
3.2 Motivation . . . 9
4 Performed Attacks and Implemented Countermeasures 11 4.1 Penetration Testing . . . 11 4.2 NoSQL Injection . . . 16 4.3 Man-in-the-Middle . . . 17 4.4 Reverse Engineering . . . 20 5 Discussion 24 5.1 Method . . . 24 5.2 Results . . . 25
5.3 The Work in a Wider Context . . . 28
6 Conclusion 29
Bibliography 31
List of Figures
1.1 Communication flow within the system . . . 2
1.2 Server-client architecture in the system . . . 2
1.3 Relation model for the system’s database . . . 3
3.1 Testing approach flow chart . . . 10
3.2 Methods targeting different parts of the system . . . 10
4.1 Results from openSSH search on exploitDB . . . 13
4.2 Results from Metasploit user enumeration . . . 14
4.3 Results from MySQL search on Metasploit . . . 16
4.4 Results of the first attack using NoSQLMap . . . 18
4.5 Visible data sent while using Bettercap . . . 19
4.6 Viewing the APK file with JADX-GUI . . . 20
4.7 Viewing the APK file with JADX-GUI . . . 21
4.8 Viewing the APK file with JADX-GUI . . . 21
4.9 Results after reverse engineering the obfuscated APK file . . . 22
4.10 API endpoint for creating a search effort . . . 22
4.11 Class with the name of the server . . . 23
A.1 Results from the scan using Nikto . . . 34
A.2 Results from the scan using Nikto . . . 35
A.3 Results from nmap -A -T4 -p- <Target IP> . . . 36
A.4 Results from nmap -A -T4 -p- <Target IP> . . . 37
A.5 Results from nmap -A -T4 -p- <Target IP> . . . 38
A.6 Results from nmap -sV –script ssl-enum-ciphers -p 80 <Target IP> . . . 39
A.7 Results from nmap -sV –script ssl-enum-ciphers -p 80 <Target IP> . . . 40
A.8 Results from nmap -sV –script ssl-enum-ciphers -p 80 <Target IP> . . . 41
1
Introduction
The amount of mobile devices and smartphones continue to increase yearly, as well as the number of people that are using them. This places heavy demands on the security of the ap-plications that run on these mobile devices, since there are more devices exposed to malicious attacks and threats.
1.1
Motivation
Studying and understanding attacks from an attacker’s perspective is important in order to create more secure systems. The attackers are usually persistent and will not stop trying new and different ways to perform a security breach, which is why ways to stop the attacks as well as how they happen, is always relevant to research. By studying some common attacks and their countermeasures, the goal is to perform some security measures a system developer can take against harmful attacks that happen frequently.
1.2
Aim
This thesis investigates the security of a system with respect to confidentiality and integrity and tries to make the system more secure. This is accomplished by performing successful attacks against the system and then implementing countermeasures in the system to secure against these attacks. These countermeasures are then tested by performing new iterations of the same attacks against the system.
1.3
The System
In order to perform attacks and implement countermeasures a system is needed. The system used is a proof-of-concept made by a group of students during the same time period as this thesis was being written. The group was supposed to create a communication system that could help the Swedish police find missing people.
Briefly, the system consist of two servers, with a database each, and an Android application that can be installed on Android mobile devices. These devices will be referred to as clients.
1.3. The System
The communication flow for the system can be viewed in figure 1.1, and will be explained further. Both servers can communicate with each other and servers can communicate with clients by having the clients use an API (Application Programming Interface) to interact with the servers. In the beginning of the project, the data was sent through HTTP, but was later changed to HTTPS, which will be described later in chapter 4.
Figure 1.1: Communication flow within the system
In figure 1.2 the structure of the system’s components are described. There is a MongoDB database on both servers, where MongoDB is one of the most popular NoSQL databases today. Replication between these servers occurs, meaning the same information can be ob-tained from both servers. This replication is done by Mongo Replica Set, which is a group of processes maintaining the same data set.
1.4. Problem Statement
The relation model for the database can be seen in figure 1.3. In the figure the terms search effort, search group and users are used. A search effort represents a case of a missing person. In one search effort, there can be many different groups being a part of a search effort. Every group can consist of many people, which are referred to as users. Users can be both civilians participating in the search effort and police officers leading the search.
Figure 1.3: Relation model for the system’s database
Through the application the client can get a contact list of the people in the same search group. The client can also see a map with placed pins of notable locations related to the case. If the user is authorized with NFC, the client can also see a list of all search efforts as well as all search groups in their own search effort. The application therefore requires the phone to enable NFC if the client wants to authorize. The direct assets that are identified in the system are personal information, access to services and case specific information.
1.4
Problem Statement
Using the system implemented within our project group, in this thesis the following problems will be studied:
1. Identify, describe and implement at least three attacks to the system where at least one attack makes it possible to breach confidentiality and at least one makes it possible to breach integrity.
2. Implement countermeasures that can be taken to secure the system against the success-fully implemented attacks.
3. For each countermeasure implemented, investigate whether another instance of the same attack would affect the system despite the current countermeasure.
1.5
Delimitations
For this thesis denial-of-service attacks (DoS attacks) will not be studied and used against the system and because of this the availability of the system will not be studied. Also, a security analysis of the system will not be covered in the thesis. Social engineering attacks, such as phishing, will not be described or attempted either.
1.6
Structure
The second chapter describes some tools and attacks that will be used during the thesis. Chapter three presents the work flow used when attacking the system and chapter four con-tains the results from the attack methods used. The fifth chapter discusses the method and the results and puts the work in a wider context as well. Finally, chapter six concludes the thesis with a summary of the work relating to the problem statement.
2
Tools for Security Testing
In this chapter software security testing and penetration testing including network-based and web-based attacks will first be described, then a few other major attacks are presented in more detail. This will give a basic understanding of different tools and techniques that can be used to attack a system in order to test its security and give the opportunity to secure against discovered flaws and vulnerabilities.
2.1
Security Testing
In security testing there are security properties related to the assets. Some of these properties are confidentiality, integrity, availability, authentication and authorization and can be described as the following [9]:
• Confidentiality is achieved when no unauthorized person or device can access informa-tion.
• Integrity assures that the data has not been modified, altered or destroyed compared to the original source, maliciously or accidentally.
• Availability lets authorized users get reliable and timely access to services.
• Authentication verifies individuals’ authorization and validates messages as a security measure.
• Authorization grants access privileges to users or programs.
Assets are data or components of a system in need of protection. Each asset has one or more of these security properties assigned to it that needs to be ensured. In case either one of the properties are not ensured, it results in a security breach.
2.1.1
Software Security Testing
Software security testing is about software behaving in a correct way despite a malicious at-tack against the system. If it is done right it should include port scanning, examining the
2.2. Penetration Testing
software behaviour and functional testing as well as using the system’s architecture and en-tering the attacker’s mindset. By identifying risks in the system and focusing the attacks on them, it is more likely to identify relevant attacks [21].
Probing for vulnerabilities can result in errors in the software that the attacker can exploit. There are many different types of vulnerabilities, but they can be categorized as bugs in im-plementation or flaws in the design.
2.2
Penetration Testing
Penetration testing is a form of software security testing and can be defined as the following according to Engebretson and Kennedy [8]:
“... a legal and authorized attempt to locate and successfully exploit computer systems for the purpose of making those systems more secure.”
It includes investigating what vulnerabilities a system might have and then performing proof-of-concept attacks to show that the vulnerabilities actually exist or document their absence. It is recommended that the penetration testing results in a conclusion where the discovered issues are mentioned along with a recommendation of how to fix those issues [8]. Vulnerability assessment is sometimes mixed up with penetration testing, but there is a dis-tinct difference between the two. When performing a vulnerability assessment, services and systems are reviewed for potential security issues, while performing a penetration test actu-ally exploits the system and shows that the security issues exist. Vulnerability assessment is a part of the penetration testing method where it is used to identify the relevant exploits in the penetration test. Penetration testing simulates a hacker activity and opens the opportunity to view the organization or system in the hacker’s point of view [8].
More specifically, there are a four phases included in penetration testing, which are recon-naissance, scanning, exploitation and maintaining access [8]. These four phases will be described more detailed in the following subsections. When referring to the target in the following phase, in this thesis it will translate to the system.
2.2.1
Reconnaissance
In the first phase as much information as possible is gathered about the target. When this is completed, the information is sorted and a list of target IP addresses is created.
The information gathering process is supposed to be thorough and therefore, there are sev-eral steps within reconnaissance that explain this process. These do not necessarily need to be followed in order, but typically the first step would be to investigate the target’s website. After this a tool could be used to find all email addresses related to the target. In this pro-cess, accessing specific information, such as the target’s IP addresses or host names of the company’s DNS servers is possible [8].
Another part of the reconnaissance phase is to examine the DNS servers that belong to the target. The DNS translates the domain names to IP addresses and by gaining full access to the DNS server, a full list of all internal IP addresses can be acquired [8].
2.2. Penetration Testing
2.2.2
Scanning
The goal with the second phase is to map the IP addresses found in phase one to open ports and services. This phase contains three distinct activities: determining if a system is alive, port scanning and vulnerability scanning. Determining if a system is alive is a process where the target system is examined to see if it is turned on and can communicate or interact with the attacker’s machine. Both port and vulnerability scanning deals with scanning the target IP addresses received from phase one, whereas the first results in a list of open ports and services running on a specific host and the second identifies specific weaknesses in the target machine’s software and services [8].
To scan ports, Nmap [18] is a suitable tool. It was written by Gordon “Fyodor” Lyon and is free to use. A web vulnerability scanner, Nikto [17], is a tool written by Chris Sullo and David Lodge. With Nikto, a web server can be scanned automatically in order to find malicious files on the server as well as unpatched or out-of-date software or other issues. It can also check for configuration issues and other specific issues [8].
2.2.3
Exploitation
In this third phase the attacks are carried out against the target, and the goal of these attacks is to gain administrative-level access to the target in order to alter the system. An exploit could in this case be described as a bug in the software that would allow the attacker to modify the software code [8].
Exploitation can be achieved in many different ways. For example, the output from the sec-ond phase can present that some IP addresses include some type of remote access service such as SSH, FTP, VNC, PC Anywhere and Telnet. If access is gained to any of these examples it usually results in owner rights to the target. If these are found in phase two (scanning), the password needs to be cracked to be able to control the target. The password can be cracked through brute forcing for example, but is faster cracked if the information about the target is used. For example, email addresses and other facts about the target found in phase one (reconnaissance) could be useful [8].
A general exploit tool that can be used is Metasploit [15], which offers open source free access to a service that can perform different exploits to a selected target. The user can choose from different payloads, which is the change in behaviour or the new functionality wanted in the target. This is what the attacker wants to be done once full control over the machine is accomplished. Examples of payloads that can be applied to the target machine are creating new users or installing new software. Metasploit is a tool that exploits the scanned system which could potentially harm the system, unlike a vulnerability scan that only scans to check for potential vulnerabilities [8].
Sniffing, which is a process that captures and views traffic passing through a network, can also be used to gain access to a system. Wireshark [28] is an example of a tool that can perform this sniffing. To be able to sniff the data sent on the network, the attacker and the target needs to be connected to the same network. The attacker also needs to set the network card to promiscuous mode if it is not already in it. In promiscuous mode, the network interface card (NIC) will pass on all packets that arrive in the network instead of only those specifically addressed to them [8].
Code injections attacks exist in many different forms and the most basic type is SQL injection. These attacks can be used to go around an authentication process, to manipulate data, to view confidential information and in some cases to execute commands on the target host [8]. SQL and NoSQL injections are described more in the section 2.3.
2.3. SQL and NoSQL Injection
2.2.4
Maintaining Access
In the last phase a way to keep administrative access despite rebooting of the target can be achieved, which is called a backdoor. It is achieved by creating some software and placing it on the target computer and is useful for a penetration tester who wants to maintain ad-ministrator access at any time, despite program shutdowns and reboots of the target system. However, this is usually not something the company ordering penetration testing wants, since there is a risk that this backdoor will be discovered by a real attacker. If a backdoor is implemented, it needs to be done carefully by the ethical hacker [8].
2.3
SQL and NoSQL Injection
The basic idea with an SQL injection is to manipulate or access data in a database without the proper authorization [14]. SQL injections are claimed by many to only work for SQL databases, as the name might indicate. MongoDB belongs to the group NoSQL database, as all other databases that are not SQL. A NoSQL injection is therefore used for all NoSQL databases, where the principle is exactly the same as for SQL injections, only the grammar form of the injection content needs to be changed. An example of how a NoSQL injection could work will be explained in the next two paragraphs.
Normally when a user tries to login to a webpage, the packet sent to the server would contain a line similar to username=ExampleUser&password=ExamplePass. A MongoDB database would then try to find a user with these credentials with the query db.logins.find( username: ‘Exam-pleUser’, password: ‘ExamplePass’). However, an attacker could use associative arrays to try to login without having any valid credentials. An associative array is an array that contains one or more pairs where each pair consists of a key that maps to a value [22].
For example, an attacker could send username[$ne]=1&password[$ne]=1 to the server where [$ne]=1 is an associative array with the key [$ne] mapping to the value 1. The database would then use the query db.logins.find( username: $ne: 1 , password $ne: 1 ) to try to find this user. Since $ne is the command for not equal in MongoDB, this means that the database tries to find all usernames that are not equal to 1 and all passwords that are not equal to 1. This would potentially return all the users in the database which in this case would lead to a successful login without needing correct credentials [22].
2.4
Man-in-the-Middle
A MITM attack is one of the most common attacks [1] that can be performed in many different ways and on every network layer [6]. The basic principle of a MITM attack is that a man-in-the-middle intercepts the data sent between two units and after reading or altering the data, he forwards it to the intended unit. This can be done without the two units’ knowledge due to the usage of public encryption keys.
In order to perform a MITM attack, the attacker needs to intercept the sent messages, which is usually done by something called ARP spoofing [6]. Spoofing is the act of faking ones identity and ARP stands for Address Resolution Protocol, which is used to connect a MAC address to an IP address. ARP works by sending out a broadcast to the whole subnet to ask who has a certain IP address and tell them to send back their MAC address [23]. Hence, ARP spoofing is simply to send out that someone’s MAC address is connected to another device’s IP address, usually the gateway router, to deceive the other clients on the network by pretending to be that device. Since the victim now thinks the attacker is the gateway router, all their traffic will go through the attacker which makes him a successful man-in-the-middle.
2.5. Reverse Engineering
Since sniffing HTTP data is relatively easy, most data is nowadays sent using HTTPS. To be able to intercept data when HTTPS is used, a tool called SSLstrip can be used [16]. This tool is used to convert a HTTPS connection into a HTTP connection, which means going from encrypted to plain text. This is possible since the client usually first connects to the server via a normal HTTP request and then is redirected to HTTPS by the server. SSlstrip changes the HTTPS in the redirect to HTTP in a way that the client never starts a HTTPS connection with the server and keeps sending traffic via HTTP to the attacker. The attacker then converts this to a HTTPS and forwards to the server so that the server will think it communicates via HTTPS. If the victim is observant, she could notice that HTTP appeared in the browser instead of HTTPS, but this is rarely the case [3].
2.5
Reverse Engineering
Udupa, Debray, and Madou experiments with methods to reverse engineer different kinds of obfuscated code in their paper [27]. The knowledge they state regarding how and why obfuscation is used is relevant for this thesis.
A commonly used definition of reverse engineering was made by Chikofsky [4] when he defined it as following:
“Reverse engineering is the process of analyzing a subject system to • identify the system’s components and their interrelationships and
• create representations of the system in another form or at a higher level of abstraction.”
This is similar to Tonella’s [25] definition which follows:
“Reverse engineering aims at recovering design views from the source code, to offer programmers a faithful, high level representation of the program that is en-sured to be consistent with the actual implementation.”
From these quotes, the conclusion is that reverse engineering is used to be able to understand how the source code of the system works, even with no access to it. It can therefore also be used to be able to spot security flaws in the system and in some cases extract critical information.
A common way to try to defend against reverse engineering is to obfuscate the code. This is done by making the functions more complicated and sometimes putting in redundant or unused code. The goal of this technique is to make it too expensive to reverse engineer the program for the attackers. However, it has been shown that it is possible to greatly reduce the effects of some obfuscations to understand the source code nevertheless [27].
3
Work Approach and Choice of
Attacks
In this chapter, the flow chart describing the testing approach for these three attacks is first de-scribed. Then the penetration testing method and the attack methods are dede-scribed. Finally, a motivation of the choices of attacks is presented.
3.1
Testing Approach
The general approach for attacking the system in order to make it more secure is to perform attacks where they each target different parts of the system. For the MITM attack, reverse engineering and NoSQL injection, the same testing approach was used. This approach was also used for the exploits performed in the penetration test and this method is described in figure 3.1. In this method, first, the attack is identified, then an attack is created (this process is presented in chapter 4). In those cases where an attack is successful, a countermeasure will be implemented to secure against the attack and then a new instance of the same attack will be performed. This loop will continue until the attack is no longer successful, then the system will be considered secure against this type of attack.
To perform attacks we used a virtual machine and installed Parrot OS [20]. Parrot OS is a Debian based Linux system that has some different versions available, where the one for security testing was chosen. We chose Parrot OS since it has many tools, runs well and is user friendly for new Linux users. These tools can make the process of security testing easier since new tools rarely need to be downloaded or configured. Parrot OS also has many files used for password cracking and similar, and these files are filled with huge amounts of common passwords that a software can go through in a brute force attack.
3.2
Motivation
When choosing attack methods the goal was to attack as many different parts of the system as possible. Figure 3.2 illustrates what part or parts of the system that is targeted. The pene-tration test was made with the goal to gain administrator access to the database or the server of the system, not any other parts of the system. The NoSQL injection attack targets the API which manipulates the database. The MITM attack targets the link between the server and
3.2. Motivation
Figure 3.1: Testing approach flow chart
client, which is the traffic sent between them. Finally, reverse engineering is used to target the client application.
4
Performed Attacks and
Implemented Countermeasures
In this chapter a penetration test is performed along with three attacks. The penetration test and the three attacks are all using the testing approach described in section 3. The results of each attack will be presented in the same order as the work flow in figure 3.1, with one or more iterations of the loop. One thing to be mentioned before we get in to this chapter is that there are some results indicating that port 80 uses SSL. This is because HTTPS was first implemented using port 80, but we later realized that this was a mistake and changed it to port 443 instead, which is the standard port for HTTPS. Unfortunately we did not have time to remake all the results after this change so every attack except for the MITM attack will still show 80 as the port used for HTTPS.
4.1
Penetration Testing
In this section the results from the penetration test is presented, where the goal is to gain administrator access to the database or server. The testing approach is applied in the ex-ploitation phase, where attacks are identified and created and then the success is assessed. The penetration testing method is also applied, since in order to perform attacks in the ex-ploitation phase, the reconnaissance and scanning phase first have to be carried out.
4.1.1
Reconnaissance
The goal with the first phase in a penetration test is, as mentioned in chapter 2, to retrieve a list of target IP addresses. If the addresses are not publicly available, which is rarely the case, an attack might be needed to solely to retrieve it. To receive the IP address a tool called tPacketCapture [26] was used. This is an Android application that can be downloaded to a mobile device to record the data traffic. We started tPacketCapture on the device and then started the target application to contact the server. By opening the tPacketCapture file in Wireshark we were able to see TCP handshakes between the mobile device and the target server IP address.
4.1. Penetration Testing
4.1.2
Scanning
In the second phase the goal is to map the IP addresses found in the first phase to open ports and services as well as scan for vulnerabilities. Therefore, port scanning and vulnerability scanning was performed in this step. The port scanning was performed using Nmap and the vulnerability scans were made with Nikto. The results of these scans are shown in appendix A.
For Nmap the following commands were used:
//Nmap scan with flags -A for aggressive which enables OS detection and //version detection, script scanning and traceroute
//-T4 is a timing flag and -p- means all ports nmap -A -T4 -p- <Target IP>
//Nmap scan with flags -sV for version detection and then //ssl-enum-ciphers is a script to check cipher strength nmap -sV --script ssl-enum-ciphers -p 80 <Target IP>
From the port scanning there appeared to be only a few ports open and therefore limited the possibilities to exploit many ports. All the ciphers on port 80 got the highest grade of security, as can be seen in appendix A. Apart from port 80, only two ports were found to be open, port 22 and port 3306. It could be seen from the scanning results that port 22 was using SSH and 3306 was using MySQL or SSL. If the server would use a vulnerable software to manage the connection to these ports, an attacker could find an exploit to expose the vulnerability and possibly get unauthorized access to the system.
For the Nikto scan we ran the following commands:
//Install Nikto if not already installed apt-get install nikto
//Run Nikto with -h for host and ">" speciefies output file nikto -h <Target IP> > /home/user/Desktop/nikto_serv1
The results from the Nikto scan mainly resulted in XSS vulnerabilities, but since the targeted system did not have a webpage or intended to have one, this was not relevant for this thesis. The scan did not give any other results that we were able to use either. The full scan results can be viewed in figure A.1 and A.2 in appendix A.
4.1.3
Performing the Attack
Now the exploitation phase of the penetration test will be presented. The first open port that could be exploited was port 22, which ran openSSH version 7.4, as seen in the output in figure A.3. First we checked in ExploitDB if there were any matching exploits. This can be done by either searching for results on the internet or installing ExploitDB on your system and search there. We choose the latter by doing following:
//Install ExploitDB on the system apt-get install exploitdb
//Search ExploitDB for openSSH exploits searchsploit openSSH
4.1. Penetration Testing
In figure 4.1 the result from this search can be seen. At (1) in the figure we see two possible exploits for the openSSH version used by the system (7.4), and at (2) we also see a possible ex-ploit. The two exploits at (1) in the figure were first attempted, but only resulted in throwing some exceptions. It seemed as if the software that the exploits were using had been updated in a way that made them crash. To reverse this update we installed an older version of the software with the command pip install paramiko==2.0.81. The exploit at (2) in the figure did not have these issues and was run directly. The three exploits from ExploitDB were then run by writing the following:
Figure 4.1: Results from openSSH search on exploitDB
//Run the exploit at (2) with admin as a username
python /usr/share/exploitdb/exploits/linux/remote/45939.py <Target IP> admin //Downgrade the Paramiko version to get the other two exploits to work
pip install paramiko 2.0.8
//Run the first exploit at (1) and use an userlist we created python /usr/share/exploitdb/exploits/linux/remote/45233.py --userList /path/to/userlist.txt <Target IP>
//Run the second exploit at (1) and try a single username (admin) python /usr/share/exploitdb/exploits/linux/remote/45210.py
<Target IP> admin
The result from these were that all usernames tested were valid. We found this odd and tried some usernames which were just random letters and numbers, which also resulted in being valid. This made us believe the exploits were not working as intended on the system since it returned completely random usernames as valid.
We then tried using the general exploit tool, Metasploit, by writing the following commands:
4.1. Penetration Testing
//Open up Metasploit msfconsole
//Search for possible exploits for openSSH search openSSH
//Use the exploit connected to enumeration use auxiliary/scanner/ssh/ssh_enumusers //See info for how the exploit is used info
//Check for false positives set CHECK_FALSE true
//Set target IP
set RHOSTS <Target IP>
//File with usernames to test that we created set USER_FILE /path/to/userlist.txt
//Run the exploit run
The result was that Metasploit found false positive results and aborted the exploit, this can be seen at (1) in figure 4.2. Continuing, the info command showed that there were two types of attacks: malformed packet technique and timing attack technique, where malformed packet technique was the standard. Then the timing attack technique was attempted by writing following in the same session as before:
Figure 4.2: Results from Metasploit user enumeration
//Change the type of attack set ACTION Timing Attack //Run the exploit
run
The result was that no false positives were found, but neither did it find any of the users. Therefore, a better username file was used. Parrot OS has many files filled with common usernames and passwords that an attacker can use located under usrsharewordlists. This was to try to simulate an attacker’s perspective and try many users, which can be very time con-suming. We therefore increased the thread count in the module to increase the speed of the attack. We tried a list containing usernames, called unix_users.txt, by writing following:
//Set threads to 20 instead of 1 set THREADS 20
//Testing a userlist that came with Parrot OS
set USER_FILE /usr/share/wordlists/metasploit/unix_users.txt //Run the exploit
4.1. Penetration Testing
The result from this was that no usernames were valid so another file called http_default_users.txt from Parrot OS was used by writing following in the same session:
//Try another userlist that came with Parrot OS
set USER_FILE /usr/share/wordlists/metasploit/http_default_users.txt //Run the exploit
run
Again, no match was found. Therefore, we decided to search for Amazon server usernames using Google, since it was known from the Nmap scans earlier that it was an Amazon server. We found a user guide from Amazon [5] which contained the following line explaining how to connect to the server: ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com. Therefore, ec2 and ec2-user was added to our file containing usernames and the test was performed once again with our constructed file. Unfortunately, there were still no matches. It is possible that we did have a valid username in our list, but the user enu-meration tool was not working as intended. We decided to check with our project group and this was the case; the correct username was ec2-user and the user enumeration tool did not work on our server. This also means that the line we found on Amazon’s website on how to connect to the server, namely ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com, was correct. From this line we can see that it uses the -i flag followed by /path/my-key-pair.pem. The -i flag means that a private key file is used to connect via ssh, which is also indicated by the file after the flag. Therefore we drew the conclusion that we would not continue to try to get access through this port because we would then have to attempt to retrieve the private key file from members in our project group, which would be outside of the scope for this thesis.
The last open port to try to exploit is now 3306 which is probably running a ssl/mysql service, as seen in the scan output in A.4. We ran a user enumeration script in Nmap to find any valid users by typing the command nmap –script mysql-enum <Target IP>, but it resulted in nothing found, and printed ERROR: The service seems to have failed or is heavily firewalled.... After that Metasploit was attempted again by writing following:
//Open up Metasploit msfconsole
//Search for exploits related to MySQL search mysql
This gave the result shown in figure 4.3 and we started by trying the fourth option from above called mysql_sql located at (1) in the figure.
//Use the exploit we thought could be work for us use auxiliary/admin/mysql/mysql_sql
//See info about the exploit info
//Set target IP
set RHOSTS <Target IP> //Run the exploit run
4.2. NoSQL Injection
Figure 4.3: Results from MySQL search on Metasploit
The connection timed out and gave no other results. We also tried mysql_enum at (1), mysql_hashdump at (2) and mysql_udf_payload at (3). These also all resulted in the connec-tion timing out. We drew the conclusion that the port was secure since none of the exploits could even establish a connection to it. There is much that can be done when performing a penetration test. Since this thesis is limited in time, we decided to stop here since no obvious leads were found that could expose any vulnerabilities. Therefore, no countermeasure was implemented and no backdoor could be created since no exploits succeeded.
4.2
NoSQL Injection
In this section the results of attacking the system with NoSQL injections are presented. The goal with this attack is to gain access to functions in the database without proper authoriza-tion.
4.2.1
Performing the Attack
Since the system does not have a login page we could not write our NoSQL injections directly in the application. We therefore decided to try to perform the NoSQL injection by contacting the API endpoints directly. To find an API endpoint to test we once again used the app tPack-etCapture. We started it and then started the target application to contact the API endpoint we wanted to test. After this was done we once again opened the file with Wireshark and analyzed it to be able to see the URL to the API endpoint the target application contacted. Once the URL was retrieved, the injections could be made. A tool that is fitting for this is NoSQLMap [10], which is an open source tool that can be used to target MongoDB databases [13]. This tool tries several different injection types to obtain access to functions in the database that should not be allowed. This will work in a similar way as the example in section 2.3 did. The commands used were the following:
//Download the git repository
git clone https://github.com/codingo/NoSQLMap.git //go into the downloaded folder
cd NoSQLMAP
4.3. Man-in-the-Middle
python setup.py install //Start NoSQLMap
nosqlmap.py //Set options 1
//In options list we choose set target IP 1
//Enter the IP requested <Target IP>
//In options list we choose API path 3
//API path we got from the MITM attack
/api/effort/5ccc212ab8c0e5000a4faab4/group/5ccc212ab8c0e5000a4faab5 ?user_ID=5cd57abfdea103a173195a53
//Go back to main menu x
//Choosing NoSQL Web App attacks from the menu 3
//Entering a random string size 5
//Choosing "Alphanumeric" from the menu 1
//Choosing the only option available(user_ID) 1
//Starting timing based tests y
//Saving the results to a file y
//entering file name nosqlmap_results
The output file did not contain any information other than the fact that no injections suc-ceeded. We can see this result in figure 4.4 with the different injections at (1) in the figure. As the output indicates, all injections failed.
4.2.2
Countermeasure
Since no possible injections were found to work with NoSQLMap and the target application does not have a login page that could be used to apply injections to, no countermeasure needed to be applied to the NoSQL injection attack.
4.3
Man-in-the-Middle
In this section the results of the MITM attack is described. The goal of the attacker is to sniff data sent between the client and the server.
4.3.1
Performing the Attack
A MITM attack was carried out by using Parrot as mentioned in section 3.1. This OS has many built in security testing tools like ARP spoof and SSLstrip. To make the attack easier to execute, a tool called Bettercap [2] was used, which already has all the tools needed for this attack implemented. Since the used system did not send data through HTTPS at first,
4.3. Man-in-the-Middle
Figure 4.4: Results of the first attack using NoSQLMap
the SSLstrip tool was not needed for the first MITM attack. Instead, only ARP spoofing was executed and to perform it, the following commands were used:
//Install Bettercap if the tool isn’t already installed apt-get install bettercap
//Start Bettercap bettercap
//Find possible victims net.recon on
//Show the possible victims net.show
//Select target for the ARP spoof set arp.spoof.targets <Victim IP>
//Turns off detailed packet sniffing to make view clearer set net.sniff.verbose false
//Activate HTTP proxy so we can access the HTTP data sent http.proxy on
//Start ARP spoofing the victim arp.spoof on
//Start sniffing for the packets sent net.sniff on
The data received from this can be seen in figure 4.5. Here we can see the victim contacting an API endpoint at (1) in the figure and the response from the server at (2). The sniffed data indicates that a marker was placed in the system during the ARP spoofing. It is also visible how the endpoint was contacted to create the marker and which ID:s that were used to send it. This means that new markers can be created by using these ID:s.
From section 1.3 case specific information is a known asset. A marker represents a location connected to the case and therefore, this asset is not secured, since authorization, integrity and confidentiality for this asset were breached during the MITM attack. The attacker could
4.3. Man-in-the-Middle
access privileges without authentication, marker data was modified and an unauthorized person could access the information of a recently placed marker.
Figure 4.5: Visible data sent while using Bettercap
4.3.2
Countermeasure
To prevent attackers from being able to sniff the data sent, we implemented encryption and started using HTTPS traffic instead of HTTP. We closed down port 80 which was used for HTTP traffic and instead opened port 443 for HTTPS. Also a privately signed certificate au-thority was created on the server, which was used in the SSL encryption. The client applica-tion was then set to trust this certificate authority.
4.3.3
Performing the Attack
To evaluate the implementation of the HTTPS countermeasure the MITM attack was re-peated, which resulted in no information retrieved. After that, similar commands were per-formed in Bettercap while turning on SSLstrip to see if the client could be prevented from establishing a HTTPS connection. The commands used for this were the following:
//Start Bettercap bettercap
//Select victim for the ARP spoof set arp.spoof.targets <Victim IP> //Tell our HTTP proxy to use SSLstrip set http.proxy.sslstrip true
//Turn off detailed packet sniffing set net.sniff.verbose false
//Start ARP spoofing the victim arp.spoof on
//Start the HTTP proxy http.proxy on
//Start sniffing for the packets sent net.sniff on
4.4. Reverse Engineering
This resulted in not receiving the specific data requested by the victim which means the at-tack failed. Since we were unable to see the requested data, no further MITM atat-tacks were implemented.
4.4
Reverse Engineering
In this section the results of performing reverse engineering is described. The attacker’s goal is to change parts of the code or contact the API to be able to send or receive data.
4.4.1
Performing the Attack
In the first attempt to perform reverse engineering, an APK file of the application was first created. APK is the file format used to distribute and download applications for Android in the Google Play store. By using the APK file it emulates a situation where the attacker did not have full access to the source code from the beginning, but retrieved it through reverse engineering.
To retrieve the APK file, a program called JADX [11] was used. After installing JADX, the graphical user interface was run by writing ./path/to/jadx/build/jadx/bin/jadx-gui. Then the choice to reverse engineer the desired APK file was made.
This resulted in the source code of the system’s application, where parts of the code is shown in figure 4.6, 4.7 and 4.8. In figure 4.6, the classes of the application can be seen at (1), some values used by the application at (2) and a method to get the server URL at (3). In figure 4.7 the different URL:s to the server can be seen at (4) and finally in figure 4.8, a method to create a search effort is seen at (5). To create a search effort a Stringbuilder is used, which then uses the code at (2), (3) and (4) to get the resulting string https://ec2-34-254-172-108.eu-west-1.compute.amazonaws.com:80/api/effort/.
By contacting the server with this address, a search effort is created, which results in a security breach for the asset case specific information. When a new search effort is created, case specific information has been modified since a new, fake case is added to the database that the police could then treat as a real case. In conclusion, an unauthorized attacker can see information in the code that enables modifying of case data. The aforementioned asset is therefore not secured if a confidentiality or an integrity attack via reverse engineering attack were to be carried out.
4.4. Reverse Engineering
Figure 4.7: Viewing the APK file with JADX-GUI
Figure 4.8: Viewing the APK file with JADX-GUI
4.4.2
Countermeasure
To prevent this kind of reverse engineering attack we chose to obfuscate the code. Android Studio [7], which was used to develop the system’s application, has a built in feature that enables obfuscation of the code [24]. Just by changing the parameter minifyEnabled from false to true in the Gradle.build file, the signed APK file will be obfuscated. After trying to retrieve the new APK file in the same way as before, the results changed. The same parts of the code is shown in the previous section is now obfuscated and shown in figure 4.9. As the figure indicates at (1), most classes are changed to random letters. If we compare the code at (2) with the previous section we can see that none of the variables or objects are shown clearly. (3) is very similar to the previous section even though it is harder to know what bVar.d is compared to server.hostname.
4.4.3
Repeating the Attack
The same attack method as in the previous attack instance was once again carried out and the goal is still to be able to create a search effort. This was once again successful even after the code had been obfuscated. The differences that made the process harder with the obfuscation was the following:
• The Stringbuilder in the create effort method now first appends se.liu.tddd82.grupp1.klientapplikation.a.c.a(g2) as can be seen at (4) in figure 4.10.
• We find se.liu.tddd82.grupp1.klientapplikation.a.c.a(g2) at (3) in figure 4.9, it’s not clear what bVar.d refers to this time.
4.4. Reverse Engineering
Figure 4.9: Results after reverse engineering the obfuscated APK file
• To find the value of bVar.d we looked around at the different classes. Eventually we found some server addresses that can be seen at (5) in figure 4.11. We could assume one of bVar.d would take one of those values based on how an URL is built.
The result of putting everything together was once again https://ec2-52-213-186-24.eu-west-1.compute.amazonaws.com:80/api/effort/. This can be seen as a breach of confidentiality in the same way as for the first attack, since it enables breaching integrity for the asset case specific information. It was therefore decided another countermeasure was needed.
4.4. Reverse Engineering
Figure 4.11: Class with the name of the server
4.4.4
New Countermeasure
Even though the source code was more difficult to understand after the countermeasure, this is not considered more secure, since security by obscurity has been considered bad practise for a long time and is a widely held design principle that expects the security of a system to depend on the secrecy of the user-specific keys [12]. The goal with using obfuscation is usually to make it too expensive for the attackers to deobfuscate the code, but it should not be the only means of security, which is why a second countermeasure was implemented [27]. Since the previous instance of the attack showed that security by obscurity could be worked around relatively easily for the system, new attempts were made to make the system more secure. This was done by removing API endpoints that could cause critical damage from the application and instead make administrators of the system handle these functions directly in the database. Some API endpoints that can cause less damage are still accessible to the public, but requires a hidden key, such as an NFC ID, which is sent for the server to verify. With this countermeasure, an attacker should not be able to cause serious damage to the system even if he would manage to fully reverse engineer the obfuscated code. This because the attacker can not exploit the endpoints without verifying his authorization.
4.4.5
Repeating the Attack
The next attempt to attack the system was made the same way as the previous instance. When the source code was visible, we tried to use all API endpoints found to see if they could be used without authorization. We did not find any API endpoints where this was the case and therefore concluded the system secure against reverse engineering.
5
Discussion
This chapter contains discussion regarding methods attempted in this thesis as well as the results obtained. Also, the work is discussed in a wider context through an ethical and a societal perspective.
5.1
Method
One of the hardest parts of this thesis was to decide how much depth to go into for each attack method. We were unsure if it was more valuable to do as many attacks as possible or choose a few and dig deeper into those. We chose the latter by doing an iterative process where we tried to attack and secure the system until we no longer were successful with the attacks.
This iterative process brought some challenges because our limited knowledge made it dif-ficult to know whether the attacks were not successful because the system was secure, or because we did not perform the attacks well enough. It might therefore have been a good idea to read more literature when the attacks were performed in chapter 4. Learning about rankings and success rates for the different attacks could have helped us decide when the sys-tem was secure enough. This could also have brought a deeper understanding of the attacks and how threatening they would be against the system, if the system would be made public. However, spending more time on literature study would have decreased the amount of time spent on finding and performing attacks. This would have made our knowledge of how to perform the attacks more limited, while the knowledge of their potential impact would grow instead.
5.1.1
Replicability
The concept of replicability is that if this study is repeated with the same method, the results would be the same. This is not relevant for this thesis, since the goal is to analyze and im-prove our developed system’s security through some testing, attacks and implementations. Other people would most likely want to analyze and improve their own system’s security and would then need to change a few steps in the attack method to achieve this. Because of this
5.2. Results
replicability is not something we are striving for in the methodology. However, the testing approach described in section 3.1 can be applied to other systems and therefore replicated.
5.1.2
Validity and Credibility
In this thesis some means to violate the confidentiality and integrity of the system were pre-sented. The goal was to secure the against the attacks that could breach security properties, which we, based on the results have achieved. The security of a system is difficult to measure, and a system can never be fully secure. However, by using a few of the more common attacks and securing against these, the system can be considered secured against the implemented attacks. We believe this reduced how vulnerable the system was greatly and even if the sys-tem can not be considered secure by modern security standards, we came a good bit along the way.
5.1.3
Source Criticism
It is important to understand that there is an extensive amount of information and data that can be accessed through the internet and to be able to make sure that the gathered informa-tion is correct, mainly peer-reviewed sources such as reports and papers are used. Also a book with a knowledgeable and educated author has been used, which is Engebretson and Kennedy. He has a Doctor of Science degree with a specialization in information security from Dakota State University and has many years of experience researching and educating in penetration testing and security. Although this book is published 2013, the process of how a penetration test is performed is still the same. The tools recommended in the book were not always used since other, more convenient tools have been created since then. It is also limited to only describe the basics of penetration testing and there is more to learn than what is written [8].
In some cases when carrying out the attacks, some tools were well explained by the software developer that has developed the tool, which is why websites are sometimes used as sources as well. This might seem untrustworthy, but since the information gathered is regarding the used tool, there are probably not any reports or papers that have more correct information about the tool than the developers themselves. All the theory about different concepts and terms are still backed up by reliable sources of peer-reviewed material.
5.2
Results
The system was continuously being developed while this thesis was written and while attacks were implemented. This resulted in some inconsistencies in the attacks since the system changed while they were being performed. We dealt with these inconsistencies the best we could, but it made it more difficult to plan future attacks because it was not certain how the system would change until the planned attack was implemented. Some attacks might have been effective against the system during a certain stage of development, but not effective at another.
Looking back, we probably should have used git management to have the system in the same state during all attacks. While using the same git version of the system through all attacks would remove the inconsistencies of the attacks, we would have to wait longer to attack and perform tests since much of the functionality of the system developed later. Waiting longer to start attacking and securing would result in less time to perform the attacks and implement the security measures.
There are however advantages with testing and improving a system as it is developed instead of after it is finished, since this usually reduces the costs by a lot if changes are made at an
5.2. Results
early stage. Considering this, our approach of not using the same version might not have been wrong in a ordinary security test, but in this thesis it was outside the scope. If we wanted to use different versions and secure the system as it developed we should have put more thought into when the same version was used and not. For example, when one kind of attack was performed, the system should be at the same state, but for another type of attack, the system could be updated to a newer version, as long as it is the same through the whole attack.
Since the people in the project group developing the system depended on the system working properly, we were afraid that some of our attacks would create real harm to the system. One way to deal with this issue would be to use a testing environment for the system, for example by using a container. This was not done due to the limited time. We also wanted to implement a log in page to the system which could have been used to perform the NoSQL injections against. This was not done partly because we did not want to affect the project group too much, but also because of time limitations.
From chapter 2 it is clear that many different tools can be used to attack and test a system and its vulnerabilities. From the literature, reports and websites providing information regarding how to use these tools, almost in every single case, the tool had to be configured to be able to use it against our system. This could be very time consuming since we sometimes had to go through many files used by the tool to for example change the HTTPS port from 443 to 80. Also, in many reports and papers about tools and tests, the whole process is seldom explained, which meant that information often had to be combined from many sources in order to perform the attacks.
5.2.1
Penetration Testing
From reading literature about penetration testing, we expected to be able to attack at least one port and find some vulnerabilities that could be exploited. Unfortunately, this was not the case. We think that this might be caused by the servers being set up for a small project where only a few ports had to be used. Therefore only a few ports were opened, which reduced the risk of open ports being vulnerable to an attack. More tools are adapted for attacks toward MySQL and we found an open designated port for MySQL database server connections on port 3306, which we could see from one of the scans in figure A.4. In section 4.1.3 we were unable to establish a connection to this port, which we believe is because it was not used since the system uses MongoDB. This is a potential security flaw in itself to leave unused ports open and port 3306 should therefore have been closed to make the system more secure. However, since the attacks against the port was not successful we did not implement a countermeasure to close it, since we followed our testing approach in section 3.1.
Penetration testing of a system is supposed to be performed after the implementation of the system is finished. Because of this, performing a penetration test as the only security measure could result in many security flaws and bugs late in the development. Therefore, the security of the system also needs to be integrated during the development by other methods [21]. Considering this, the penetration test with its exploits should have been executed last, after the system was considered finished, which it was not in this thesis. The MITM attack, reverse engineering and NoSQL injections can be seen as other methods used to increase the security during the development of the system, since they were performed as the system developed.
5.2.2
Reverse Engineering
We thought it was surprising how easy it was to reverse engineer the application and get such good results. Even though reverse engineering is not always that harmful in itself it can be used in combination with other attacks or to find vulnerabilities for other attacks.
5.2. Results
Having full access to the source code can potentially be very harmful depending on how the system is implemented. As discussed briefly in section 4.4.4, a secure system should not depend on whether an attacker has gained knowledge about how it is implemented or not [12]. Hoepman and Jacobs present their main argument for using open source in the following quote [12]:
“Our main argument is that opening the source allows independent assessment of the exposure of a system and the risk associated with using the system, makes patching bugs easier and more likely, and forces software developers to spend more effort on the quality of their code.”
We agree with this view of why open source is a better approach for security of a system and it is also why we decided to implement our second countermeasure the way we did. Assuming an attacker would have access to the source code, she would still not be able to harm the system.
5.2.3
Man-in-the-Middle
In the first attack we saw the importance of using HTTPS when confidential data is sent. The system attacked chose to send the verifying information directly in the URL which is a big security flaw. To prevent this security flaw we implemented HTTPS on port 443 and closed down port 80. This means we replaced all HTTP traffic with HTTPS traffic and we did this because of two reasons. Firstly, as we saw in section 2.4, the SSLstrip exploits the first HTTP request that is sent between the client and the server. If there is no first HTTP request then there will be nothing for SSLstrip to exploit and the connection will therefore be secure against this type of attack. Secondly, a lot of sensitive information is included in the URL for the API endpoints themselves, like personal user ID:s or NFC ID:s. We therefore concluded it would be best to try to make the connection between the clients and server as secure as possible by removing all unencrypted communication. Even after implementing HTTPS it would probably have been a good idea to hash the ID:s since both the client and server have access to them. The server can then compare the hashes of the ID:s to see if they are valid instead of comparing the ID:s directly. Since we deemed this part of the system secure against the attack performed, we did not implement this feature, but implementing it would make the system even more secure.
5.2.4
NoSQL Injection
This attack was hard for us to perform since there was no way to directly send user data to the server from the application itself. Therefore we had to try sending this data through the API endpoints directly. Also, since we did the MITM attack before this attack, all API endpoints were contacted through HTTPS. From an attacker’s perspective this meant no access to them could be granted and without access to any endpoints we could not use the tool that we had planned, which was NoSQLMap. We also could not remove the HTTPS implementation until late because it was used in the project group developing the system. In the end we removed the HTTPS implementation when the project was finished, which let us use NoSQLMap as planned.
We are still not entirely sure why we were unable to succeed with the NoSQL injection attack. The tool is designed to work against MongoDB databases and it performed many different injections designed against MongoDB. It is continuously updated as can be seen on their Github [10] and should therefore stay up to date with the attacks. We can think of three different reasons why the attacks did not succeed: MongoDB is secure against the attacks performed, the server code is implemented in a way that protects the system from the attack
5.3. The Work in a Wider Context
performed or the attack was implemented in an incorrect way. It could also be possible that several of these are partly true. We believe the third reason is the primary reason why the at-tack did not work. This is because NoSQLMap in itself could have been used incorrectly and because NoSQLMap as a tool might not have been effective against the system at all. Even if we assume NoSQLMap was used correctly and simply not effective against the system, this does not mean that the system is secure against a NoSQL injection attack - only against a NoSQL injection attack performed using NoSQLMap. This could create a false sense of security since it might still be other ways to perform a NoSQL injection attack that would be successful against the system even if NoSQLMap fails.
5.3
The Work in a Wider Context
Creating new technology and developing new software products can always be questioned whether it will be used for good or bad purposes. The technology itself is not evil, but the usage of it could potentially cause harm for others.
Analyzing the security of a product could be compared to this, since hacking could be used for non ethical reasons such as stealing credentials or information. Instead, when someone does not want to use their skills of hacking for illegal purposes, it can be referred to as ethical hacking. This is what a penetration tester does and it should complete many of the same activities as a malicious attacker does, but with a different purpose. Ethical hacking is per-formed to secure against potential future malicious attacks, which is why it is important to investigate in what ways a system can be attacked, so these vulnerabilities can be secured. As we explain different attacks that can be performed to a system in this thesis, some people might use this information for illegal purposes, which is something we can not control. How-ever, by explaining ways to secure against these attacks, we hope that software developers can use this information to make their system more secure.
6
Conclusion
The aim of this thesis was to make a system more secure by first attacking it and then securing against the attack. Since we wrote this thesis simultaneously as we developed the system we noticed that we started to apply adversarial thinking in the project meetings. We started thinking about how new implementations to the systems could be vulnerable to certain types of attacks. Being able to see the risks and not just the benefits of new implementations is a step in the right direction when developing secure systems.
We will now present the results for the problem statement defined in chapter 1 of the thesis.
Identify, describe and implement at least three attacks to the system where at least one attack makes it possible to breach confidentiality and at least one makes it possible to breach integrity
The first attacks performed were MITM, reverse engineering and NoSQL injection. We also implemented several attacks as a part of the penetration test, which only targeted the database and the server. The MITM attack was only successful once, but through it, both con-fidentiality and integrity could be breached. The reverse engineering attack was successful twice and made breaching both confidentiality and integrity possible both times. Our imple-mentations of NoSQL injection and penetration testing were not successful in leading to a breach in neither integrity nor confidentiality within the given time frame.
Implement countermeasures that can be taken to secure the system against the successfully implemented attacks
To secure against the MITM attack the countermeasure was to implement HTTPS. Because we closed down port 80 and only used port 443, all HTTP communication with the server was removed.
Two different countermeasures were implemented against reverse engineering; first against reverse engineering itself, called obfuscation, and then against what could be done with the information retrieved from reverse engineering, namely an approach similar to open source.
