Like it or not, mobile apps are a central part of our lives. In fact, in many developing countries, the mobile phone is a user’s primary means of accessing the Internet. Businesses owe it to these consumers to safeguard their confidential data. With the proliferation of IoT, essentially all data can be accessed from any device, as long as authentication is complete.
In a recent breach in Aug 2018, Air Canada reported that attackers got access to passport numbers, expiry dates, NEXUS numbers for frequent travelers, and dates of birth of up to 20,000 of its app users. All of these sell profitably on the Dark Web, and each of it is an identity fraud case waiting to happen. Obviously, it’s a bad look for the business, and more specifically, the developers behind the scenes.
This problem is not isolated to enterprises with huge customer bases. According to the Abandoned Web Applications: Achilles’ Heel of FT 500 Companies report by High-Tech Bridge Security Research, 92% of web applications come with exploitable security vulnerabilities.
Security over convenience is a concept we emphasize at Horangi. But while modern organizations want to prioritize data security, having best-in-class UI and customer experience has become a major competitive edge today.
The onus then falls on application developers to bring out the best of both worlds in the app — and this includes even third party integrations, which is another discussion altogether.
Organizations that want thorough visibility of their biggest application security risks can engage security partners to conduct pentesting on their mobile apps, whether built on iOS or Android. The 2018 Trustwave Global Security Report notes that 16% of vulnerabilities in tested applications were found to be medium, high, or critical risk. The top high-risk vulnerabilities were cross-site scripting errors, vertical privilege escalation flaws, and default credential use.
Revealing all the vulnerabilities and addressing them systematically is an effective way of improving app security. Today, we look into Horangi’s methodology behind Android app pentesting. This checklist below provides a repeatable process for organizations to follow in future updates and launches.
Android App Pentesting Checklist: Based on Horangi’s Methodology
Part 1: Reconnaissance
The initial phase sets the stage for the biggest risk areas that need to be tested. So the pentesting team needs to identify the main uses of the app in question. Besides studying the full range of app functionalities, it is important to check the data flow for potentially vulnerable areas as well as undocumented libraries or functions. In addition to performing an initial network scanning of the Web API, it is also essential to gather essential information from the publicly available information as well, such as Google Search, WHOIS, sub-domain search/bruteforce and sources from other Open-source Intelligence (OSINT)
Part 2: Static Analysis
In static analysis, the raw source code needs to be broken down for the team to understand if any static information stored in the APK can be used to break the application protection mechanism or expand the attack vector. This is done by decompiling and disassembling the binary and APK from the raw source code. Static analysis checks for but is not restricted to the following: Code Obfuscation, JailBreak Detection and Prevention mechanism, SSL Pinning Mechanism, Levels of access to other applications, Storage of sensitive and cleartext application secrets on the device.
Part 3: Dynamic Analysis
Dynamic analysis helps to discover vulnerabilities while the app is running in real time. This usually involves either hooking onto the functions/calls (via Frida or Drozer) intercepting the traffic in real-time via proxies. Common runtime vulnerabilities to look out for are authentication and authorization flaws, content spoofing, memory leaks, insufficient transport layer protection, application logic flaws, and cross-site scripting.
According to the 2018 Application Security Statistics Report by WhiteHat Security, 45% of vulnerabilities discovered during Dynamic Application Security Testing (DAST) result in information leaks.
Part 4: Findings Report
As soon all the vulnerabilities are discovered, they should be risk-qualified via CVSS v3 and documented in a report, which will come with remediation recommendations and clear objectives.
Seeing the business implications and risk level of each vulnerability helps the internal team prioritize the areas to first address.
Part 5: Remediation
Remediation can be performed by either the internal team or security vendor and will be in accordance to the recommendations in the findings report. Consistent follow-ups on these issues are required to ensure vulnerabilities are resolved.
In the interest of time, not all vulnerabilities can be addressed. The organization needs to acknowledge the existing risks before making a decision to proceed with a major app update.
Pentesting Outside the Mobile App
Obviously, the security posture of an Android app does not hinge on the components within the app, but also the APIs and servers. External pentesting with SQL injections, insecure direct object references, and insecure communications will help to identify these vulnerabilities.
App developers can embed good security habits and checks with code scanners. These scans can happen more frequently and because they don’t take much time, developers can integrate that into their workflow.
At Horangi, we recommend that organizations implement both short and long term solutions so they stay resilient and proactive about their app security.