Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer and Information Science
Bachelor’s thesis, 16 ECTS | Computer Science
2020 | LIU-IDA/LITH-EX-G--20/076--SE
Security Auditing and Testing of
two Android Client-Server
Applications
Matilda Engström Ericsson
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 publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten 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 upphovsman-nens 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 down-load, 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/.
Abstract
How secure is your application? How can you evaluate if it is secure? The threats are many and may be hard to find. In a world where things are more and more automated; how does manual labour contribute to security auditing applications? This study aims to assess two proof of concept Android client-server applications, developed by students to suit the needs of a fictitious Police Department and Fire Department, respectively. The approach is unconventional yet supported by well-established theory. The gist of a vulner-ability assessment methodology initially developed to assess the security of middleware is followed and applied to the entire architecture of these client-server applications. How the manual labour contributed to the end results, in comparison to the use of automated tools and a list of known threats, is then evaluated.
It is concluded that the applications encompass multiple of the Open Web Application Security Project (OWASP) Top 10 Mobile Risks and that automated tools find most of those vulnerabilities. However, relying on automation may lead to a false sense of security, which in effect may cause developers to lose understanding of why vulnerabilities occur and how they should be mitigated. Understanding how the design and architecture of the application influence its security is key.
As of Android 9.0+, default is that applications use SSL encrypted communication. Only 40% of Android users are in 2020 affected by this change according to Android studio developer information, leaving a majority of users unaware of if or how their data is being protected, also observed in analysis results from this thesis work. One should consider if or how to inform users of how their data is being handled, not only in newer Android versions or regarding SSL communication.
This work also shows that developers’ decisions may be greatly affected by time pressed situations, which is reflected upon in the last chapter. Another important find-ing was that the third-party software Sinch, which enabled the use of voice and video communication in one of the applications, sent IP addresses and usernames of the users in clear text during the binding request, when the Session Traversal Utilities for NAT (STUN) protocol was used.
Students in the 5 year Information Technology program complete a semester-long soft-ware development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor 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 culmi-nates 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 create small groups and specialise in one topic, resulting in a bache-lor thesis. The current report represents the results obtained during this specialisation 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.
Acknowledgments
I want to send a special thanks to my supervisor Simin Nadjm-Tehrani and to Nina Lindström for their immense help and support during this project, as well as a thank you to the members of the project groups that helped develop these two applications for their involvement.
Contents
Abstract iii
Acknowledgments v
Contents vi
List of Figures viii
List of Tables ix 1 Introduction 1 1.1 Motivation . . . 2 1.2 Research questions . . . 3 1.3 Related work . . . 3 1.4 Structure . . . 4
2 Background and Selected Methods 5 2.1 Vulnerability Assessment . . . 5
2.2 Penetration Testing . . . 6
2.3 OWASP Top 10 Mobile Risks . . . 6
2.4 Work Approach and Chosen Tools . . . 7
3 Results 9 3.1 Vulnerability Assessment Outcomes . . . 9
3.2 Penetration Testing Outcomes . . . 17
3.3 Summary of found Vulnerabilities . . . 17
4 Discussion 19 4.1 M1 Improper Platform Usage . . . 19
4.2 M2 Insecure Data Storage . . . 19
4.3 M3 Insecure Communication . . . 19 4.4 M4 Insecure Authentication . . . 21 4.5 M5 Insufficient Cryptography . . . 21 4.6 M6 Insecure Authorisation . . . 22 4.7 M10 Extraneous Functionality . . . 22 4.8 Other Risks . . . 22 5 Conclusions 23 5.1 Comparison of security implementations in the applications . . . 24
5.2 Reflections upon manual and automated labour . . . 26
Bibliography 27
6.1 Voice and Video communication audit . . . 29
6.2 Nmap scans . . . 30
6.3 Results from Authorisation attack on Police Department Server . . . 31
6.4 Mobile Security Framework (MobSF) Static Analysis . . . 33
List of Figures
1.1 High level architectural overview . . . 1
3.1 Architectural Overview - Fire Department application . . . 10
3.2 Resource Diagram - Fire Department application . . . 11
3.3 Architectural Overview - Police Department application . . . 14
3.4 Resource Diagram - Police Department application . . . 15
3.5 Proxy Attack Topology . . . 17
3.6 Police Proxy Results . . . 17
3.7 Authorisation attack: Attack flow . . . 18
6.1 Voice and Video calls in Wireshark - Sinch, Fire Department application . . . 29
6.2 Nmap scan results - Fire Department application . . . 30
6.3 Nmap scan results - Police Department application . . . 30
6.4 Authorisation attack part 1: Log in as low privilege user . . . 31
6.5 Authorisation attack part 2: Create high privilege user . . . 31
List of Tables
3.1 Resources and their associated actions - Fire Department application . . . 11
3.2 Extent of Access and Damage - Fire Department application . . . 12
3.3 Resources and their associated actions - Police Department application . . . 15
3.4 Extent of Access and direct Damage - Police Department application . . . 16
3.5 Found Vulnerabilities . . . 18
6.1 Supported ciphers for Fire Department certificate . . . 44
1
Introduction
The thesis aims to give a broad picture of the security implementations, or lack thereof, re-garding confidentiality and integrity in two proof of concept Android Client-Server applica-tions. Confidentiality is ensured if the resource in question is protected so that only autho-rised people can access it. The integrity of the resource is ensured if it has not been tampered with and the information is still correct [1]. The applications were developed in conjunction with the work on this bachelor’s thesis in two separate project groups of about 9 people each. They are developed to suit the needs of a fictitious Police Department and Fire Department respectively and will in the rest of the thesis be referred to as the Fire Department application and the Police Department application.
Figure 1.1 displays a high level overview over their architecture. The figure is not intended to display the full information flow in the system, merely how components are connected. The applications are essentially made to enable employees to view, report on and create new missions. There are two major components involved in this part: the server and the client. The client-server communication implements HTTPS exclusively. For the server-server
1.1. Motivation
munication, both applications implement a warm backup solution where the primary server sends data to the secondary server without receiving any acknowledgements and the sec-ondary server takes the primary servers place, should a failure occur in the primary server.
These applications were required to enable voice and video communication between users. The open-source Web Real-Time Communication (WebRTC) project provide the means for peer-to-peer communication via an IP network. It is implemented in Android applications by including an external WebRTC library in the APK. The Fire Department application chose a Sinch external library and the Police Department application chose Mesibo.
There are different privilege users in both applications. For the Fire Department applica-tion, the highest privilege user is called ”RC User”, whose job it is to coordinate information. This user is situated in an office in contrast to the two lower privilege users ”SL User” and ”BM User” who also work in field. The Police Department application has two different privilege users. The ”0 ranked” user has a lower security level than the ”1 ranked” user.
1.1
Motivation
Gary McGraw, who is considered a giant in software security, claims that there are seven touchpoints of security. They are in descending order of effectiveness; code review, architec-tural risk analysis, penetration testing, risk-based security tests, abuse cases, security require-ments and security operations [14].
When developing the applications, the project groups were aware of the importance of security and produced several artefacts during the sprints. Sprints are an iteration, or a time period used in agile software development. A background analysis was produced before the development phase began. Other artefacts are an ethical risk analysis, a reliability analysis, a CORAS risk analysis and an architecture and design artefact. This work aims to shed a light on what these efforts resulted in, by essentially performing application vetting that focuses on McGraw’s first three touchpoints of security: code review, architectural risk analysis and penetration testing.
The aim is to examine how a manual, more labour-intensive approach contributes to the application vetting. Nowadays it seems that many people dream of utilising automated tools that can do the job for them. So, the intention is to investigate if it is desirable to automate the entire process, parts of it or not any of it at all. The report aims to follow the gist of the First Principles Vulnerability Assessment [11] in an unconventional way. The methodology was initially made to assess the security of middleware, in this case it is applied to the entire architecture of the client-server applications. The methodology assumes access to the source code, documentation, and the developers of the applications. Acting as if they were not accessible would be deceptive. As it is ”designed to find new threats to a system, and is not dependent on a list of known threats”, it seems appropriate to evaluate it to such a one. A well-suited list of known threats to mobile applications is the Open Web Application Security Project (OWASP) Top 10 Mobile Risks1from 2016. The use of automated tools is encouraged to use at a later stage in the assessment process, and so the intention is to investigate how much the manual labour contributes to the end result.
As I had a part in developing the Fire Department application, thus I cannot gain an outside perspective on it as I can on the Police Department application, which should be con-sidered when analysing the results from this thesis. Both applications are however in-house developed applications. When auditing an in-house developed application focus should lie on security vulnerabilities, malicious functionality in third-party software and security fea-tures in the mobile platform according to a MITRE report on Mobile App Vetting2.
1https://owasp.org/www-project-mobile-top-10/
2
1.2. Research questions
1.2
Research questions
• Is it desirable to automate security auditing? To what extent does manual labour con-tribute to the vetting process in this thesis in comparison to the use of automated tools and the OWASP Top 10 Mobile Risks list of security threats?
• What security differences are there between the different applications?
1.3
Related work
Deng and Cheng [6] designed and implemented a Android-based Health and Healthcare sys-tem, which as the applications in this thesis would contain sensitive data. This work has a similar presentation style for the results in the vulnerability assessment. They for instance display the architecture of the system as well as program flow diagrams and enumerate the resources for that system. In that work they do functional testing of the system, which how-ever is not the focus of this thesis.
Android
Botas et al. [5] introduce a methodology to security audit mobile software applications that focuses on OWASP Top 10 Mobile Risks 2014. Although the methodology is not followed to the letter in this thesis, this approach is similar, however with less focus on run time be-haviour in the Android environment and more focus on static analysis and on the interaction between client and server.
Bojjagani and Sastry [4] produced a paper that inspired to use OWASPs Top 10 Mobile Risks as a list of wellknown security threats in this thesis. They did Vulnerability Assessment and Penetration Testing of mobile banking apps. In the paper they did both dynamic and static testing of the OWASP listed mobile security risks on the applications that store sensitive data, just like the proof-of-concept applications evaluated in this thesis.
The following works were important in giving an understanding for Android applications and their security needs. Ma et al. [12] gave an understanding of the differences between An-droid applications and Web applications and why AnAn-droid applications require a different approach. Tam et. al. [15] gave an understanding of the Android environment and its po-tential weaknesses, which gave an important insight when auditing the client side of the applications. Wang et al. [16] conducted a study covering four types of app signing issues. Both applications suffer from these issues, which would’ve been an issue had they been in-tended for production. The app signing process is supposed to protect the integrity of the application. By extension, problems like these enable malicious agents to reverse engineer the application.
Mobile networks
There has already been a lot of research on HTTPS in Android and other non-browser en-vironments. Georgiev et al. [7] studied standard SSL libraries and their implementation in non-browser software. They concluded that many SSL certificate validations are performed incorrectly, or not at all. Four years later Wei and Wolf [18] studied SSL implementations specifically in Android applications, which usually rely heavily on third-parties. The papers conclude that the reason behind improper SSL implementations varies, from Android devel-opers lacking understanding of the technology to server misconfiguration, both of which are analysed in this thesis.
Anthi and Theodorakopoulos [2] examined almost 100 Android and iOS applications us-ing three different approaches. Usus-ing wireless packet sniffus-ing with Wireshark they showed that 85% of the TLS connections support weak ciphers and 25% of the Android applications transmit unencrypted user data over the WiFi network. This thesis examines the voice and
1.4. Structure
video calls using a very similar approach. The second approach by Anthi and Theodor-akopoulos evaluated the security of the TLS cipher suites that the applications use by using O-Saft. In this thesis sslscan is used instead and the scan is made on the server side instead of the client side.
Hubbard et al. [9] did two different types of proxy attacks on Android and iOS applica-tions. One where they used the tool sslsniff and one manual proxy attack where a device is manually connected to a WiFi hot spot. The latter was also performed by Anthi and Theodor-akopoulos and is reproduced in this thesis. The first one showed that out of the 41 Android applications tested, 11 accepted invalid certificates and three applications did not use SSL at all. Their results showed that Android applications were more prone to insecure certificate validation.
Server
Austin and Williams [3] conducted a case study on two electronic health record systems where they compared four vulnerability discovery techniques (systematic and exploratory manual penetration testing, static analysis, and automated penetration testing) and found that no single one of them discovered every type of vulnerability. The work highlights the importance of using several approaches when auditing applications. They also discovered that automated penetration testing detected the most vulnerabilities per hour, which was the basis of choosing automated tools in this thesis. Masood and Java [13] review techniques and static code analysis tools that may prevent OWASP top 10 vulnerabilities for web ser-vices. This work highlighted the differences between Simple Object Access Protocol (SOAP) web services and Representational state transfer (REST) web services and in choosing the relevant approach for applications in this thesis. The work of Wang and Yang [17] was very educational and inspired to use Nmap as a network vulnerability scanning tool.
Huluka and Popov [10] suggest that focus should be on proactive security and not reactive security, and although their work is based on web applications some of the root causes of session management and broken authentication vulnerabilities may be applicable in non-browser applications or web services. This work, as well as the book by Howard et al. [8] aided in finding methods for the manual code review of the servers.
1.4
Structure
The remainder of the thesis will be as follows: Chapter 2 will cover background information, selected methods, work approach and chosen tools. In Chapter 3 the results of the thesis will be presented. Chapter 4 includes a discussion on the different identified risks and mitigations, both present in the applications and otherwise possible. Chapter 5 explains the conclusions of this thesis and future work.
2
Background and Selected
Methods
This chapter will cover the background necessary for following the approaches used in the thesis, it explains the work approach and identifies the available tools to be used.
2.1
Vulnerability Assessment
A Vulnerability Assessment aims to systematically identify and describe vulnerabilities within an information system according to NIST Glossary1. There is no common agreement in the industry of how a vulnerability assessment should be conducted and as previously mentioned this report aims to follow the First Principles Vulnerability Assessment [11]. It consists of the five steps that are explained below.
Architectural Analysis
The architectural analysis aims to identify major components in the system and how they interact with each other and users. In this step a document showing the structure of the system and the interactions of different components or end users should be produced. It is important to include how the components interact to build an understanding of how trust is delegated in the system.
Resource Identification
The Resource Identification step addresses examination of key resources such as files, databases, logs, and devices. The resource is either an end target or an intermediate target. This step should include a description over how components can access resources and how resources can run operations. The architectural diagram should be annotated with resource descriptions, but in this thesis a new diagram is created.
Trust and Privilege Analysis
Trust and Privilege Analysis investigates how guarded components are as well as who is given access to them. The level of trust put into the component should take both hardware
2.2. Penetration Testing
and software in consideration. However, evaluation of the hardware is out of scope for this report. If a component is dependent on other components, it is important to also take their security in consideration. The level of privilege will depend on 1) "the extent of access for the component" and 2) "the extent of damage that can be accomplished directly"; more commonly known as threat model.
Component Evaluation
A vulnerability report is produced in the Component Evaluation step. Each component should be analysed but components that, based on previously gathered information, are con-sidered more important should be prioritised and analysed in depth. Automated scanning tools may aid in this step. Part of this phase will be processed in the discussion and conclu-sion of the thesis.
Dissemination of results
This stage is about how the results of the vulnerability assessment affects the rest of the com-munity and how to approach any eventual actions that may need to be made. This part will be processed in the discussion and conclusion of the thesis.
2.2
Penetration Testing
Though the methodology is different from a vulnerability assessment, Penetration Testing aims to identify security risks. In penetration tests attacks that exploit systems are performed. Since an attacker only needs one entry point to exploit the system the approach may not necessarily be systematic and may leave other vulnerabilities undetected.
According to the Penetration Testing Execution Standard (PTES)2, that was developed due to the lack of standard in the field, there are seven phases. Most of which will overlap with the vulnerability assessment method; however, for the Penetration Testing section in Chapter 3 the exploitation phase will be the centre of attention.
2.3
OWASP Top 10 Mobile Risks
The second way the applications are evaluated is through the OWASP Top 10 Mobile Risks3. The list will be used to evaluate not only the client side, but the entire architecture. An alternative to this was to use The Common Weakness Enumeration (CWE) list of Top 25 software and hardware weaknesses4. If I would have done this again, I would have followed the Mobile app security checklist by OWASP. As most of the vulnerabilities fit into the 10 risk categories from OWASP, this list was opted for. The full list can be found on their website, but relevant to this thesis are the following.
”M1 Improper Platform Usage” includes security control that is part of the mobile oper-ating system such as Android intents and platform permissions. ”M2 Insecure Data Storage” may include SQL databases, Log files, manifest files, Binary data stores vulnerabilities that occur for instance when a device is lost or stolen or there is malware. ”M3 Insecure Commu-nication” includes sensitive data that is somehow intercepted in the network. ”M4 Insecure Authentication” occurs for instance when passwords or shared secrets are stored locally on the device, or if a weak password policy is used to simplify entering a password. Authentica-tion confirms that users are who they say they are. ”M5 Insufficient Cryptography” concerns implementing either an algorithm that in nature is weak or a process behind the encryption or
2http://www.pentest-standard.org/index.php/Main_Page 3https://owasp.org/www-project-mobile-top-10/ 4https://cwe.mitre.org/top25/
2.4. Work Approach and Chosen Tools
decryption that is weak. ”M6 Insecure Authorisation” for instance includes a vulnerable au-thorisation scheme. Auau-thorisation gives authenticated users permission to access a resource. ”M10 Extraneous Functionality” includes leaving functionality enabled in the app that was not intended to be released.
2.4
Work Approach and Chosen Tools
The work on this thesis aims to implement McGraw’s [14] first three touchpoints of secu-rity; code review, architectural risk analysis and penetration testing. The code review and architectural risk analysis will be processed in a Vulnerability Assessment. The results from the Vulnerability Assessment lies as a foundation for the Penetration Testing phase, which is meant to reduce the time it takes to find exploitable vulnerabilities and to make it eas-ier to assess the criticalness of the vulnerability. According to the Vulnerability Assessment methodology followed, no vulnerability is confirmed until it has been confirmed in a pene-tration test.
For Vulnerability Assessment
This phase follows the steps explained in 2.1. The code review and architectural risk analysis require access to the source code as well as the design and specification of the systems. The code review aims to uncover bugs in the system and the architectural risk analysis aims to uncover logical errors and flaws. Performing one without the other leaves approximately half of the systems weaknesses undiscovered [14]. The Component Evaluation step includes both manual code review and utilising different tools to aid in the evaluation process. The servers are manually code reviewed according to the book by Howard et al. [8]. The chosen tools range from passive tools that examine the system to active tools that find vulnerabilities by trying to exploit the systems5. The results are displayed in Chapter 3 under section Vul-nerability Assessment Outcomes, and results from the scans are more extensively displayed in the Appendix. More about the chosen tools below.
Static Analysis Tools
These tools examine source code and are known as Source Code Scanners or Static Applica-tion Security Testing (SAST) Tools6. It is important to note that this kind of tool cannot find
vulnerabilities that are not yet discovered or in their set of rules.
The static analysis tool used on the client code was Mobile Security Framework (MobSF). The scan was made inside of a Docker container which was started by running the following terminal command:
sudo docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
where -it is short for "–interactive + –tty" and starts the container in interactive mode and the flag -p refers to exposing and mapping the container’s internal port to the host port [host port : container port]. The container is accessed in the web browser, localhost http://0.0.0.0:8000/, where the apk files are uploaded and analysed. The results from these scans are also displayed in Appendix 6.4.
5https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf 6https://owasp.org/www-community/Source_Code_Analysis_Tools
2.4. Work Approach and Chosen Tools
Dynamic Analysis Tools for network analysis
Dynamic code analysis examines how the system behaves in a run-time environment. These tools do not require access to the source code and may be referred to as automated vulnera-bility scanners or penetration testing tools [13].
On Kali Linux an Nmap scan was performed on each of the primary servers using the command
nmap -sV -T4 <IP-address>.
The flags that are used in the scan are -sV, which stands for version detection, and -T4, which stands for aggressive speed scan.
Also on Kali Linux, an SSLscan was performed on both of the primary servers by running sslscan <IP-address>.
To identify the behaviour of the voice and video calls the tcpdump tool tPacketCapture was used on a Samsung S9 phone to make a packet capture, which then was displayed in Wireshark. This will only be displayed for the Fire Department application, as the call func-tionality at the time of the test did not work for the Police Department application.
For Penetration Testing
The Penetration Tests are performed after the Vulnerability Assessment, which uncovers pos-sible exploits. Two successful attacks are performed during this phase, where the first one tries to exploit the fact that the applications use self-signed certificates, and the second one tries to exploit authorisation vulnerabilities found in the Police Department application. Manual Proxy Attack
There are several possible approaches to a proxy attack. Hubbard et al [9] don’t specifically state which tool they used as the manual proxy. They state that for some applications, it is possible to perform a successful attack using mitmproxy, when a manual proxy failed. Anthi and Theodorakopoulos [2] use Burp Suite and mitmproxy when they perform their proxy attack while Bojjagani and Sastry [4] used Burp Suite. They generate a self-signed certificate though it and saves it in the Android user space.
The approach in this thesis is most similar to the latter one, although the tool Zed Attack Proxy (ZAP)was used as proxy instead of Burp Suite. Firstly, a ZAP Certificate was generated and sent to the Android device where it was opened. In the ZAP tool the proxy settings were after that configured by leaving the IP address blank and entering port 8080 in the Options setting. Switching to the Android device, the network settings for the same network that the ZAP tool runs on were changed by using the advanced options. By selecting Manual Proxy and entering the IP address of the laptop that was running the ZAP tool into the Proxy hostname and 8080 into the Proxy port7.
Authorisation attack on Police Department application
In the Trust and Privilege Analysis step for the Police Department application it was found that users are only granted access to missions of a certain security level that corresponded to their rank. It was also found that all users can edit user information in the database.
This attack attempts to register a new user with a higher security level than the user that is used to create the new user. It requires access to a user’s valid SessionID or login credentials, as well as knowledge of api end points, i.e. how you log in to the system and how you create new users in it. The tool Postman was used to create and send custom requests to the server of choice.
3
Results
This chapter covers the results from the Vulnerability Assessment and the Penetration Test-ing. Lastly, there is a summary over all found vulnerabilities.
3.1
Vulnerability Assessment Outcomes
The outcomes of the Vulnerability Assessment will be presented separately for each applica-tion.
Fire Department Application
There are three different privilege users in the Fire Department Application. The only user that is stationed in an office is the ”RC User”, which also has the highest priority and whose job it is to coordinate missions with users in the field. The user with highest privilege in the field is the ”SL User”, and users with the lowest privilege are called ”BM User”.
Architectural Analysis
The major components in the system are the Android clients and the servers. Figure 3.1 shows a high level overview over how they interact with each other and users.
The Client-side box illustrates that users can either change view or request data through an intent. The data can either be run time environment data or data received from the back-end server. The client uses Android hardware and front-back-end Java code with minimum An-droid API level 26, which corresponds to AnAn-droid 8.0. Not displayed in this figure is the third-party service Sinch that provides a Voice over IP (VoIP) service used for both the voice and video calls. Sinch uses its own signalling protocol and is implemented in the client side by including an external library1.
The Server-side box portrays two Amazon Web Services (AWS) Virtual Machine (VM) ec2. The VM contains a server and a MySQL database that communicates with each other over Localhost. The servers are developed in Node.js using Express.js framework. One of the servers acts as primary server, and the other one as backup server. They communicate with each other by using "warm backup" internally on Amazon Web Services, which means
3.1. Vulnerability Assessment Outcomes
Figure 3.1: Architectural Overview - Fire Department application
that the primary server sends data continuously to the back-up server, without receiving any acknowledgements. They were later in the thesis moved from AWS, but still function in the same manner.
Resource Identification
As mentioned in the previous section, there are two databases that are connected to the pri-mary respectively the backup server. These databases contain files about
• Log in credentials (Username + Password) • Mission information (Missions)
• Contact information (Contacts), such as information about – the employees; name and profession (EmployeeInfo) – and their voice and video ”phone number” (Call ID) • JSON web token (Session ID)
All resources, except for the log in credentials, are also stored in variables in the Android device after connecting with the server. The Android device also stores the User ID that the Linux kernel has assigned to the Android application, that is supposed to secure it from other applications on the phone. Both the servers and the Android devices contain logs. They are also the only devices in the system.
Sinch also has servers and databases that provide the calling functionality. As they are third-party, they cannot be analysed in the same manner as the in-house ones. However, information such as IP addresses and Call ID has been provided to them.
The first column in table 3.1 displays the resources. Users can interact with these re-sources. For instance, when the user logs into the application, it receives a Session ID. This is what the first and second columns represents. To receive it, the user needs to provide valid log in credentials, in this case a username and a password. So, there are different criteria that need to be met depending on what type of user it is, which are displayed in the third and fourth column of the table. For instance, the SL and BM Users need to be assigned to a mission to receive it, and to receive contact information they need to be assigned to the same mission as that contact.
Figure 3.2 shows how resources are distributed in the system and the possible actions in practice. The resources in the figure have a "Res" image to the left of the it, and possible actions are listed beneath it.
3.1. Vulnerability Assessment Outcomes
Figure 3.2: Resource Diagram - Fire Department application
Resource Action Required: SL, BM User Required: RC User
Session ID Log in Username, Password Username, Password
Missions Get, Add Session ID, Assigned to Session ID
Missions Edit - Session ID
Contacts Get Session ID, Assigned to Session ID
Contacts Add, Edit - Session ID, NFC Tag
Employee ID Scan NFC Tag Session ID Session ID
Call ID Voice and video call Session ID Session ID
Table 3.1: Resources and their associated actions - Fire Department application
Trust and Privilege Analysis
As many of the components are dependent upon the user type that utilises is, the extent of access and damage for different user types is described first. The extent of access and damage is then described for each actual component. Table 3.1 displays the results of this analysis. It is very important to note that it is the direct damage of the component that is referred to in this table. Components may be dependent upon other components and are therefore con-nected to more severe damage than at first glance apparent.
FOR DIFFERENT USER TYPES. As previously mentioned, the RC user has access to all resources, while the other users only have access to those that they are assigned to. The RC user is the only user type that that can assign employees to or remove employees from a Mis-sion resource. With access to a valid NFC tag, they can also create or edit a Contact resource, as well as adding or removing an NFC Tag for a Contact resource. All user types can make voice or video calls to contacts that are available to them. User types RC user and SL user can create Mission resources that are considered prioritised, as well as normal priority Mission
3.1. Vulnerability Assessment Outcomes
Access Direct Damage
No Low Moderate High No Low Moderate Severe
RC User x x BM, SL User x x Client x x Sinch ? ? ? ? Network x x Server/Database x x
Table 3.2: Extent of Access and Damage - Fire Department application
resources. The BM user can only create the latter one. The RC user has high privilege had can inflict severe direct damage while it is low for other user types.
FOR THECLIENT COMPONENT. The Android device initially, without logging into the application, has no access to any of the resources mentioned in the previous section. It is however possible to see how the fictitious government agency operates, therefore the com-ponent has low access and direct damage. It is dependent on which user type that utilises it and on the Sinch developed WebRTC library.
FOR THETHIRD PARTYSINCH. The extent of access for third party Sinch is not estab-lished yet, it depends on what access they have in the external library. It is however es-tablished that they have access to the IP addresses of the users making the calls and to the resource Call ID, which makes it at least moderate. As they do not know what IP address is linked to which user type, the extent of damage is considered at least moderate.
FOR THE NETWORK COMPONENT. As resources only temporarily cross the network, there is no extent of access for the network component without the interaction of different users. The users can make voice or video calls and, in that case, the only exposed resources are the IP addresses of the users and the Call ID. They can also interact with the server. In the first interaction between client and server the user provides log in credentials and if valid re-ceives a Session ID. The client is required to provide it in all further communication between them.
Since there is no access without the interaction of users there is no direct damage. It is however important to note that it may be possible to intercept or modify all resources if it is utilised by for instance the RC User, in which the direct damage is severe.
FOR THESERVER/DATABASECOMPONENT.The server and database communicate with each other over localhost and are tightly coupled, since the server already has access to the valid log in credentials. The database contains all resources as well as shared secrets such as an SSL certificate and an SSH certificate. The extent of access is high for them both and the direct damage that can be accomplished is severe. Regarding the connection between client and server, it is also dependent on which user type that connects to it.
Component Evaluation
CLIENTCOMPONENT.The MobSF scan uncover that the application uses an Android Debug certificate that was signed using SHA1 and RSA. Clear text traffic and debug mode is enabled, that the application is in test mode and application data can be backed up. The Sinch Service is not protected by any permission and may be accessible to other applications on the device. It has access to local I/O operations in two of its client classes. SHA1 is used in a client and a service class as well as Base64 Encode/Decode. Sinch can make HTTP connections and the URL Connection supports file, http, https, ftp and jar.
There are no browsable activities, but the application has a Network Security Configura-tion. There is a certificate and a key file stored inside of the applicaConfigura-tion. An IP address is hardcoded and stored in clear text in the two in-house classes. The application may contain
3.1. Vulnerability Assessment Outcomes
hardcoded sensitive information in one in-house class and a Sinch client class. The manual code review shows that application uses Android 8.0, which enables app- and block-level encryption2. There are information logs in many places in the application, made by both the third party and in-house development team.
NETWORK COMPONENT. Packet captures of the voice and video call are displayed in Wireshark in Figure 6.1 in Appendix 6.1. The captures show that the Client and Server Hello are protected using Datagram Transport Layer Security (DTLS) version 1.2. The Session Traversal Utilities for Network Address Translators (STUN) protocol is commonly used by WebRTC applications when searching for the public IP address of the client and determining if a connection can be established between the peers. However, when this protocol is used during the Binding request, both the username of the user that makes the request/call and the user that is to receive the call are fully visible. Later in the communication so is the IP address of the user.
The SSL scan shows that the client-server communication accepts both TLS version 1.2 and 1.3 are accepted when connected to port 443, although it was not possible to connect to port 3306, which is the standard port for MySQL databases. The communication is pro-tected by a self-signed certificate, signed with RSA and SHA256. All supported ciphers are displayed in the table 6.5 in Appendix 6.5.
SERVER/DATABASECOMPONENT. The server can be accessed via ssh if valid log in cre-dentials is provided and a certificate verifies the identity of the user. Access to the database in the server requires another set of log in credentials.The server communicates with the database using predefined SQL statements for the GET requests. POST requests have pa-rameterized queries ready that are sanitised by checking for any question marks. So, String concatenation or string replacement is never used to build the SQL query. The information kept in the database is not encrypted.
There are no password requirements and no detection mechanism for “repeated guessing trial” of password. The Session ID, a JSON web token, is valid for 4 hours and any request, but the first one, that lacks the SessionID is refused.
Communication between primary and backup server requires the servers to authenti-cate themselves using both IP address and a server token, otherwise any request would be blocked. The Nmap port scan show that ports 22, 80, 443 and 3306 are open, as displayed in Figure 6.2 in Appendix 6.2. It shows that a Node.js with Express framework application lis-tens on port 80 and 443, that OpenSSH 7.4 lislis-tens to port 22 and that the database is a MySQL database, which cannot be accessed in this scan.
Police Application
There are two different privilege users in this application. The user with the highest privilege is a ”1 ranked” user, and the other one is a ”0 ranked” user. Both user types may work in field.
Architectural Analysis
The architecture is very similar to the Fire Department application; major components in the system are the Android clients and the servers that are displayed in Figure 3.3.
The major Client-side difference between the applications is that this application instead is built with a minimum API level 16, which means that devices running Android 4.1 or later can run this application. Not displayed in the Figure is the third-party service Mesibo, which handles the voice and video calls. There are three different external libraries3included in the APK.
2https://pages.nist.gov/mobile-threat-catalogue/application-threats/APP-2.html#page 3com.mesibo.api:webrtc:1.0.4, com.mesibo.api:mesibo:1.0.89 and com.mesibo.api:calls:1.0.74.
3.1. Vulnerability Assessment Outcomes
Figure 3.3: Architectural Overview - Police Department application
The Server-side is also similar to the Fire Department application as can be seen in Figure 3.3. The major differences are that nginx forwards the requests to the back-end server, and that the back-end server is build using the Python language and Flask framework. The pri-mary server communicates with the client and periodically sends the backup server a copy of all files that have been updated since last backup. The backup server acts as a primary server if the primary server becomes unreachable and updates the primary server with any new data once it is reachable again. As with the Fire Department servers, they were later in the thesis moved from AWS, but still function in the same manner.
Resource Identification
The databases in the Police Department application contain files about • Log in credentials (NFC Tag + Password)
• Map information (Map) • User information (Users)
– ”Phone number” (Call ID) • JSON web token (Session ID)
Data received from the server is saved in a single JSONArray variable that is overwritten and cleared after the user logs out of the application. The calling actions are only available if the JSON web token has not yet expired. The Session ID and rank of the user are however stored in separate variables.
Mesibo provides this application with voice and video calling functionality and have servers and databases setup to do this. As with Sinch, these cannot be analysed like the in-house servers, but they have access to information such as IP addresses and Call ID.
In contrast to the Fire Department application there are no special actions available for different users, as seen in table 3.1. However, users can only receive map resources if their rank is the same as the resource. Figure 3.4 displays the resources and available actions connected to them just like the diagram for the Fire Department application.
Trust and Privilege Analysis
The extent of access and direct damage is displayed in table 3.1. It is very important to note that these components may also be dependent upon each other.
3.1. Vulnerability Assessment Outcomes
Figure 3.4: Resource Diagram - Police Department application
Resource Actions Required
Session ID Log in NFC Tag, Password
Map Get, Add, Edit Session ID, Rank
Users Get, Add, Edit Session ID
Call ID Voice and video call Session ID
Table 3.3: Resources and their associated actions - Police Department application
FOR DIFFERENT USER TYPES.Lower ranked users are only granted access to information
about lower ranked missions, while higher ranked users can also access the information of higher ranked missions. All users can access and edit both mission and user information in the database. They also receive all contacts in the system and can make voice or video calls to all employees in the company, if they are still authenticated according to the Session ID, which expires after 10 minutes. Since all users can add and edit all information, they can cause severe damage though the ”0 ranked” user only has moderate access to the resources.
FOR CLIENT COMPONENT. With the same reasoning as in the Fire Department appli-cation the extent of access and direct damage in the client component is low. It however depends on the user type that utilises it and the Mesibo external library.
FOR THIRD PARTY MESIBO. In short, the extent of access and damage is the same as third party Sinch in the Fire Department application.
FOR NETWORK COMPONENT. As in the Fire Department application, there are no re-sources or other confidential information to be found in this component without the inter-action of the users. Therefore, there is no access or direct damage for this component. The damage inflicted by intercepting or modifying resources may be severe, as it is dependent on the which user type that utilises it.
FOR SERVER/DATABASE COMPONENT. The extent of access and direct damage is the
3.1. Vulnerability Assessment Outcomes
Access Direct Damage
No Low Moderate High No Low Moderate Severe
”1 ranked” User x x ”0 ranked” User x x Client x x Mesibo ? ? x Network x x Server/Database x x
Table 3.4: Extent of Access and direct Damage - Police Department application
Component Evaluation
CLIENT COMPONENT. The application uses the same type of Android Debug certificate as the Fire Department application and leaves clear text traffic and debug enabled. Appli-cation data can be backed up. There are no browsable activities and no Network Security Configuration. IP addresses are identified in an in-house class as well as in a Mesibo crash log. The scan was also able to find a lot of information about the IP addresses. Mesibo can also read or write to external storage in three different classes. Local I/O operations can be made by two. Mesibo can make an HTTP connection and has access to WiFi details in the Network State Receiver. There is a Mesibo Connection Service used for making calls and a Network State Receiver for monitoring changes in the network. Both are Broadcast receivers. Providers Mesibo File Provider and Generic Receiver are also used. All but the Mesibo Connection Service are unprotected. The Mesibo Connection Service is protected by the permission BIND_TELECOM_CONNECTION_SERVICE, which is supposed to ensure that only that Connection Service can bind to it, according to Android API the protection level is ”signature|privileged”.
Some of the classes were investigated and reviewed manually. The Network State Re-ceiver checks if the phone is connected to WiFi, 2G, 3G or 4G and if there are any changes. It checks if it is connected, roaming and the speed. They get the Network operator name which is used to see if the network is changed. They do not log any information in this class. One Mesibo class uses the encryption algorithm MD-5 as a message digest.
NETWORKCOMPONENT. According to the developers for the Police Department appli-cation both the caller and the receiver need to authenticate through the Mesibo server when call requests are made. When authenticated, they receive an access token each from the server and can then start communicating with each other directly. All communication is encrypted using either TLS or DTLS 1.3. This is not verified in this thesis.
The SSL scan shows that the server uses a self-signed certificate. TLS versions 1.0, 1.1 and 1.2 are accepted and secure renegotiation is supported when connected to port 443. As in the Fire Department application no connections could be made to port 3306. All supported ciphers are displayed in table 6.5 in Appendix 6.5.
SERVER/DATABASECOMPONENT. The log in procedure is the same as in the Fire De-partment application. The SQL queries take user input and there is no implemented function to make ensure that the user input is valid before using it. String concatenation or string replacement are not used in building the SQL queries.
There are no password requirements, any password a user chooses is allowed. No de-tection mechanism for “repeated guessing trial” of password. The Session ID is valid for 10 minutes. The primary server and the backup server will only send log files and backup requests to each other’s ip addresses. Figure 6.3 in Appendix 6.5 shows an Nmap port scan made on the primary server. Ports 22, 80, 443 and 3306 are open. The ssh service and database are the same as in the Fire Department application, however, nginx is listens to ports 80 and 443.
3.2. Penetration Testing Outcomes
3.2
Penetration Testing Outcomes
This section covers the exploitation of some selected vulnerabilities found in the previous section.
Manual Proxy Attack
Figure 3.5: Proxy Attack Topology
Figure 3.6: Police Proxy Results
Figure 3.5 displays how the different entities are connected in this attack. The client and the proxy are in the same LAN and are connected to the same WiFi Router, while the server can be reached via the public internet. Firstly, a connection to a normal website was estab-lished to check if the configuration works properly. After a good result from that, the attention is turned to each of the applications. Both times it was attempted to log into the application with valid log in credentials. The Fire Department application crashes and no requests or connections can be seen in the proxy. This is not the case for the Police Department appli-cation. Figure 3.6 displays the request that was made by the Police Department application in the ZAP tool on the computer. Since it is visible there, the application does not refuse the connection.
Authorisation attack on the Police Department application
Figure 3.7 displays how the attack is carried out. The client in this case is the Postman tool that creates, sends and receives all messages displayed in Figures 6.4, 6.5 and 6.6 in Appendix 6.3. The attack commences by firstly logging into the application as a low privilege, or ”0 ranked” user. Using the Session ID received from the server a new user with higher privilege, a ”1 ranked” user, is created. It is then attempted to log in as the new, higher privilege user. As this log in attempt is successful, so is the attack.
3.3
Summary of found Vulnerabilities
All found vulnerabilities are reported in table 3.3. The F in the table stands for Fire Depart-ment application, P for Police DepartDepart-ment application, S for Sinch and M for Mesibo. The ”x” represents a found vulnerability and ”-” that it has not been evaluated. The sixth col-umn displayes how the vulnerability was found. Most are found by different tools used in
3.3. Summary of found Vulnerabilities
Figure 3.7: Authorisation attack: Attack flow
Vulnerability F P S M Found by OWASP Risk
Local I/O Operations x x MobSF M1
External I/O Operations x MobSF M1
WiFi Details x MobSF M1
Bluetooth details x MobSF M1
Hardcoded sensitive information x x MobSF M2
Log files x x x x MobSF M2
No encryption on data in database x x VA M2
Self-signed SSL certificate x x sslscan M3
Visible IP addresses x - VA M3
Certificate/Key files in APK x MobSF M4
Authorisation vulnerability x VA M4
No password requirements x x VA M4
SHA1 x MobSF M5
MD-5 x MobSF M5
Android Debug Certificate x x MobSF M10
Clear text traffic enabled x x MobSF M10
Debug enabled x x MobSF M10
Application data can be backed up x x MobSF M10
Application in test mode x x MobSF M10
Open ports x x - - nmap
Visible version running on port x x - - nmap Table 3.5: Found Vulnerabilities
the component evaluation phase. However, VA stands for Vulnerability Assessment and rep-resents the vulnerabilities that required manual labour to find. This includes vulnerabilities that were found by manual code review, reviewing the design and architecture of the applica-tions or tools that are not automated. The last column displays, if applicable, which category in OWASP Top 10 Mobile Risks the vulnerability belongs to.
4
Discussion
In this chapter found or possible vulnerabilities and mitigations for each OWASP Top 10 Mobile Risk will be discussed.
4.1
M1 Improper Platform Usage
The MobSF scans revealed that both Sinch and Mesibo utilise local I/O operations in two classes each. Mesibo can also read and write to external storage in three call classes, seemingly because they transfer the audio, video and images as files.
They can both make HTTP connections and Mesibo has access to WiFi details in a Net-work State Reciever. It has access to the IP address of the user as well as the used gateway and the location. The IP address and gateway are seemingly used to monitor the stability of the connection and is used to predict its behaviour. Mesibo also has access to Bluetooth details.
4.2
M2 Insecure Data Storage
There are logs made by in-house developers on both client and server side as well as in the external libraries developed by Sinch and Mesibo.When a user logs out of the Fire Depart-ment application all logs in the client are cleared. The MobSF scan revealed that Mesibo logs IP addresses in its crash log.
According to the scan there is hard coded information in the third parties’ client classes: IP addresses may be passed to some methods.
Should an adversary gain access to the servers or databases, they would get access to a lot of confidential information as the information kept in the database is not encrypted in either application.
4.3
M3 Insecure Communication
The client-server communication is protected by self-signed SSL certificates for both applica-tions. The implementation in the client component is however approached differently. The Fire Department developers implemented a custom network security configuration where
4.3. M3 Insecure Communication
they included a certificate and a key file inside of the APK. As could be seen in the manual proxy attack this prevents man in the middle attacks as other certificates are not accepted by the application. The Network Security Config feature that was introduced in Android 8.0 allows developers to indicate that they only intend to use encrypted network traffic. The Police Department developers override the Android trust manager and make it trust all cer-tificates. This makes it possible to intercept the network traffic, which also could be observed in the manual proxy attack. As Georgiev et al [7] also concluded: if the certificates cannot be validated correctly, an adversary in the network may bypass the security implementations that the certificates are supposed to reinforce. To summarise, self-signed certificates forces unconventional implementations in the Android clients and the original Android trust man-ager must be overridden by either storing shared secrets locally on the device or trusting all certificates. Among these options, the first one is preferred according to Wei and Wolf [18]. However, when shared secrets are stored in the APK an adversary could get a hold of it by reverse engineering the application.
As already mentioned in the related works section, there has been a lot of research made on SSL implementations in mobile and Android environments. The research has shown that it is not just the proof of concept applications in this report that are not up to par when it comes to SSL implementations; there are also applications in Google Play store that aren’t. Wei and Wolf [18] discussed in their paper the impact that Stack Overflow may have on decisions made when building an application. The Police Department developers were very aware of the fact that this was not a secure implementation and had also written a comment about it in the code referring to a Stack Overflow post. Although people responding to questions in Stack Overflow may stress that solutions like these should not be part of production code and are not secure, stressed developers that try to meet deadlines might not care. The problems arise when these easy and quick solutions that were not intended for production code, are missed in the audit.
There may be many reasons why developers make improper SSL implementations. Al-though many Android developers are very well informed of how security should be tackled there needs to be ways for users to know if their data is in the hands of these competent de-velopers or in the hands of less competent dede-velopers. When using web browsers, users can easily see if the connection is trusted. There is both an icon for it by the navigation bar and it is possible to check if the URL contains ‘’https” or ‘’http’. Tools like Wireshark are needed in-vestigate whether Android applications make trusted connections. Regular users do not have the competence to use these tools to investigate if their data is being sufficiently protected. If the platform does not force developers to make secure implementations, users should be able to see how applications use their data and make decisions for their own. Different Android Icons could be introduced to solve problems like these. If there is no accountability or en-forcement from the platforms part, developers do not ”have to know” these things. Luckily, Google has removed HTTP connections by default on Android 9.0, which make it more diffi-cult to implement insecure SSL connections than before. However, in 2020 only 40% of users are affected by this change according to Android Studio developer information. Changes like these, that make it more difficult for developers to implement bad security practices, are very important. Many developers go for implementations that take less time and work to implement for many different reasons: such as the many tough deadlines they face.
Although the certificates are self-signed, the quality of them seem fair. The certificate key size upholds the current standard for best practice for both the Fire Department application and the Police Department application, as it is 2048 bits with RSA encryption algorithm with SHA256. The Fire Department application supports TLS version 1.3 and 1.2, while the Po-lice Department application supports TLS versions 1.0, 1.1 and 1.2. The reason behind the Police Department’s use of older TLS versions is that the client component implements An-droid version 4.1, and so the TLS versions must be backwards compatible due to legacy
rea-4.4. M4 Insecure Authentication
sons. According to OWASP it is correspondent to the ”OWASP Cipher String C”1, the second weakest collection of ciphers. Since the Fire Department application supports Android 8.0, they can use ”OWASP Cipher String A”, which include the strongest ciphers present today. Surprisingly, according to the O-Saft evaluation method2, the servers of both applications use Cipher Suites of high security, which in comparison to the study by Anthi and Theodor-akopoulos [2] is a very good result, as 85% of all TLS connections they studied in 2016 support weak ciphers. Interestingly, the Police Department certificate does not use the GCM version of the cipher as its preferred cipher, as opposed to the Fire Department certificate, although it is considered to be more secure.
There were no browsable activities found in either application, which rules out any Cross-Site Scripting (XSS) vulnerabilities.
The extent of access and damage is directly linked to the user types, as shown by the trust and privilege analysis for both applications. To reduce the risks associated with the higher privilege user types, client certificates could be installed for these user types so that the servers more accurately can verify the identity of the clients.
The calling functionality was only reviewed for the third-party Sinch in this thesis. The component evaluation showed that the IP address and User ID were visible during the Bind-ing request phase. This compromises the security of the Fire Department users as an adver-sary can identify their IP address, which endangers the entire client-server communication as well.
4.4
M4 Insecure Authentication
The Police Department application requires the user to be authenticated to use the calling functionality provided by Mesibo. The user is automatically unauthenticated after 10 minutes when as the Session ID is no longer valid.
Neither application have any password requirements nor a detection mechanism for “re-peated guessing trial” of password in either application, which in a production deployment would leave the server very vulnerable.
The log in procedure is different in both applications. The Fire Department application has a more traditional authentication procedure that requires the user to provide username and password. The Police Department application requires two factor authentication from all users upon log in, where the user is required to scan an NFC Tag and provide a password. This may make it harder to get access to the Android application. However, it is still possible to sniff the value in the network and send requests to the server from Postman. If one reverse engineered the application, it would be possible to hard code a valid value and that way log into the Android application.
There are several other instances where two factor authentication is required in the Fire Department application. The RC user needs to authenticate itself using both an NFC Tag and Session ID when trying to add or edit contact information. This is also the case in the server-to-server communication where the Fire Department application requires the server to identify itself by not only by IP address but also by sending a valid server token connected to that IP address. This reduces the risk of an adversary forging a correct IP address and gaining access to data in the server. Should the server token be compromised, it could be replaced.
When logging into the server two factor authentication is required for both applications.
4.5
M5 Insufficient Cryptography
The MobSF scan shows that Sinch uses SHA1 in one client class and one service class, while a Mesibo Message Digest is encoded using MD5 in one of its classes. Both encryption
al-1https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html 2https://github.com/OWASP/O-Saft/blob/master/o-saft.pl
4.6. M6 Insecure Authorisation
gorithms are very weak and are not recommended to use. However, this thesis does not examine for what purpose they are used.
4.6
M6 Insecure Authorisation
The results show that there is a serious authorisation vulnerability in the Police Department application. It is possible to access and edit all information in the data base if an adversary attains log in credentials for a lower privilege or ”0 ranked” user as the Custom attack shows that they can create a higher privilege or ”1 ranked” user. The authorisation scheme is more restricting in the Fire Department application. It is not possible for lower privilege users to edit mission information or to add or edit contact information.
When handling user input, the servers use predefined SQL statements that do not use string concatenation or string replacement. The Fire Department server also checks the user input for question marks and does not allow them if present.
4.7
M10 Extraneous Functionality
There are five different vulnerabilities found in both the Fire Department and Police Depart-ment application. These applications were never intended for production, which is evident here. The clients use an Android Debug certificate, the applications are in test mode. They have both Debug and Clear text traffic enabled. The application data can also be backed up. These facts all make the applications easier targets than others to reverse engineer. Partly because the Debug certificate lets an adversary act as if it is the original creator of the appli-cation, and partly since it is possible to recreate the applications with malicious functionality or access to confidential information when applications are debuggable and application data can be backed up. Compared to a study of mobile banking applications there were very few of them that had a Debuggable app [4], still shows that it is not impossible to forget to change such a thing even in production code.
As there is no confidential information in the client before a user has logged into the application, and if the user manually logs out of the applications the variables are cleared, it would not be the end of the world if an adversary got a hold of the device. However, a lost or stolen phone that has not been logged out of is in more danger. It allows an attacker to access the user’s data by rooting or jailbreaking the device, which is especially easy to obtain as the information is stored in clear text in both applications. However, the Fire Department application also benefits from the fact that app- and block-level encryption is enabled by default in Android 8.0.
4.8
Other Risks
The Nmap scan shows that ports 22, 80, 443 and 3306 are open in both applications and which services are listening to them. Both applications run OpenSSH 7.4, protocol 2.0 and a MySQL database. The firewall blocked traffic from the outside to reach the database in both cases. The difference is the services that listen to port 80 and port 443. The Fire Department application runs a Node.js with Express framework while the Police Department runs nginx, a HTTP and reverse proxy service. The reverse proxy hinders an adversary from knowing which type of server is running on the backend. From the code review it is evident that nginx acts as a reverse proxy that tunnels the network traffic to the python Flask server, but there is no way for an adversary to know this by using this type of scan. The reverse proxy does not protect from application vulnerabilities such as SQL injections, but it does prevent an adversary from getting to know the exact programming language used and possibly what vulnerabilities there are connected to it. Nginx is also able to send traffic to several different servers behind the scenes, which in that case may be seen in the url sent to nginx.
