Developing secure mobile applications

Today, the number of smartphone users worldwide is over 3 billion, and this number is forecasted to grow by several hundred million over the next few years. 

And it’s logical to assume that the number of mobile applications will increase as well. We’re already considerably dependent on our mobile applications. We use them for communication, banking, shopping, working and entertainment. Given the fact that we use apps for practically everything, these applications handle a huge amount of our personal and corporate information. This information is a fundamental part of what makes these apps so useful in our daily lives. Yet, this information is also what makes building secure mobile apps so important.

At Star, we work with start-ups and established industry leaders, designing mobile applications that make life easier for their customers. One of the most important factors we look at when building mobile apps is security – how we can protect both consumer and corporate data, while still building an application that is meaningful for both parties. In this article, we examine the most common security risks to mobile applications and how to address these during the development process. First, let’s take a closer look at mobile app vulnerabilities.

What makes mobile apps vulnerable

Modern mobile devices have several communication facilities that are connected to the Internet: WiFi, Bluetooth, NFC and GSM module, just to name a few. They also contain sensors such as GPS, gyroscope, camera, microphones and hotspots. All of these functions are what make our mobile phones “smart”, and we take many of them for granted. Yet they are also all potential access points, which an attacker could use to access sensitive information.

Legitimate threats to mobile security

While some might think that mobile software security is more about paranoia than actual threat protection, the growth of the mobile security market would suggest otherwise. For example, Technavio has been monitoring the mobile security software market, which is poised to grow by USD 1,862.62 million during 2020-2024, progressing at a CAGR of over 8% during the forecast period. The increasing incidence of cyberattacks has been instrumental in driving the growth of the market. This prompts a number of questions:

• Just how secure are mobile phones?
• What are the security risks for mobile applications?
• Is iOS more secure than Android?
• Is it really possible to extract sensitive information from a mobile phone?

Let’s address these questions one at a time.

How secure are mobile phones?

2020 is looking like the year of mobile sneak attacks. Last year, cybercriminals and nation-states increased their mobile attacks with a wide variety of methods, from backdoors to mining cryptocurrencies. This year, they have expanded the ways of hiding their attacks and frauds, making them increasingly difficult to identify and remove.

Most cybercrime is now mobile. Over 60% of online fraud is accomplished through mobile platforms. Additionally, 80% of mobile fraud is carried out through mobile apps instead of mobile web browsers.

An average of around 24,000 malicious mobile apps are blocked daily on the internet.

What are the security risks for mobile applications?

Let’s first take a look at four common threats to mobile device and app security. 

Threat #1 Malware

One possible threat to mobile app security is malware, which is installed on the device. Mobile devices are often configured to only allow application installation from an authorized app store (e.g., Google Play or Apple Store). With malware, a hacker places a malicious application in an authorized app store, enabling the application to be installed onto targeted devices.

Threat #2: Lost or stolen device

Another huge threat is that mobile devices could be lost, or even stolen. A person with physical access to a mobile device may try to bypass the device's lock screen in order to access sensitive information stored on the device.

Threat #3: Biometric spoofing

If a mobile phone uses biometric authentication, a hacker could attempt to spoof a mobile device's biometric authentication mechanism.

In order to get a better picture of this threat’s credibility, just think about the fingerprint. We leave our fingerprints everywhere; including on the devices they protect. Fingerprint authentication doesn’t provide the desired security, as long as hackers can produce spoofs (“fake fingers”) from these pervasive copies.

Touch and swipe sensors are equally duped by spoofs. For example, this video shows how an iPhone 4s-taken photo results in a fingerprint spoof that unlocks a Thinkpad laptop, a Fujitsu smartphone and an iPhone 5s.

“What about facial recognition?”, you might ask. Surely that’s a far more secure method. That’s what life-long friends Brad and Joe thought as well. As reported in the media, Joe injured his Achilles tendon while working out at the gym. He passed his phone to Brad, so he could call Joe’s worried girlfriend. Brad noticed that the screen unlocked when he looked at Joe's phone, revealing that Apple's Face ID facial recognition system thought he was Joe.

Threat #4: Code guessing

A more straight-forward approach to bypassing phone security is the Code Guessing or Brute Force method. In this method, the potential thief tries to crack the lock screen passcode (typically a PIN or password). This could be by brute force or by something known as “shoulder surfing”, where someone observes the device owner's use of the lock screen passcode. 

Our list of four common threats to mobile device security is by no means exhaustive. But it does give you an idea of the wide range of threats out there. Which leads us to the next question: 

Are iOS devices more secure than Android?

If we look at the threats discussed in the previous section, you can see why some might draw that conclusion. According to Nokia’s threat intelligence report, Android devices are nearly fifty times more likely to be infected by malware than Apple devices.

Android is more often targeted by hackers, too, because the operating system powers so many mobile devices today. The Android operating system’s global popularity simply makes it a more attractive target for cybercriminals.

One should not conclude based on these facts that iOS devices are completely secure. For example, developers have periodically demonstrated techniques that exploit vulnerabilities on Android, iOS and other mobile devices to bypass the device lockscreen. These vulnerabilities are generally addressed by security patches, once they are brought to the vendor’s attention.

However, identifying potential vulnerabilities is one thing. Successfully extracting sensitive data from a mobile device is another. Which brings us to our fourth, and final question:

Is it really possible to extract sensitive information from a mobile device?

The answer to this question is, unfortunately, yes. Here are a few examples of techniques hackers have used to unlock mobile devices:

• A vulnerability exists in Android 5.x <= 5.1.1 (before build LMY48M) that allows a hacker to crash the lockscreen and gain full access to a locked device, even if encryption is enabled on the device. By manipulating a sufficiently large string in the password field when the camera app is active, a hacker can destabilize the lockscreen, causing it to crash and revert to the home screen. At this point, the hacker can run arbitrary applications or enable adb developer access to gain full access to the device and expose any data on it.
• Hackers can also obtain sensitive information by installing a trojan. For example, Monokle is a new and sophisticated set of custom Android surveillance ware tools. Monokle possesses Remote Access Trojan (RAT) functionality, uses advanced data exfiltration techniques and has the ability to install a hacker-specified certificate to the trusted certificates store on an infected device that would facilitate man-in-the-middle (MITM) attacks.
• Another type of malware can read notifications sent by the operating system or other applications, which may contain sensitive data such as one-time authentication codes sent over SMS, email, or other media. This malicious application can also dismiss notifications to prevent the user from noticing that the notifications arrived and can trigger action buttons contained within notifications.

How to create a secure mobile app

So far, we’ve identified the common threats to mobile device security. Now we’ll take a look at what we do to build a secure mobile application. The process we describe below is based on recommendations from the Open Web Application Security Project (OWASP), an online community that produces free and publicly-available tools and technologies related to web application security. The process consists of the following steps:

1. Perform a risk assessment.
2. Define the security requirements. 
3. Secure Design.
4. Secure Implementation. 
5. Secure Verification. 
6. Secure Release. 

Each phase has corresponding documentation that must be followed. The documentation is available via the OWASP website, and consists of the following documents: 

• Mobile Application Security Verification Standard (MASVS)
• Mobile Security Testing Guide (MSTG)
• Mobile App Security Checklist

The picture below illustrates all the phases and corresponding documentation:

Step 1: Performing a risk assessment

Before the project starts, we perform a risk assessment for the application and its components to identify their risk profiles. These risk profiles typically depend on the applicable regulatory requirements. We consider a variety of risks: financial, marketing, industrial, etc. The MSTG includes a set of data classification policies that specify which data is sensitive and how it must be secured. Sensitive data in the context of the MASVS pertains to both user credentials and any other data considered sensitive in the particular context, such as:

• Personally identifiable information (PII) that can be abused for identity theft: Social security numbers, credit card numbers, bank account numbers and health information;
• Highly sensitive data that would lead to reputational harm and/or financial costs if compromised: Contractual information, information covered by non-disclosure agreements and management information;
• Any data that must be protected by law or for compliance reasons.

Step 2: Defining security requirements

Next, we define the application’s security requirements, which we do in parallel with the app’s functional requirements. For example, if the mobile app will collect and store sensitive user data, we need to define requirements for how the data should be encrypted, both when stored and transmitted. We perform this step at the beginning of a project or development cycle. This helps minimize the risk of schedule disruptions and reduce expenses later on. For each new use case, we create abuse cases as well. We use the OWASP MASVS to determine the security requirements of mobile applications on the basis of the risk assessment phase. It’s also common for us to review the requirements iteratively as we add new features and data classes.

Secure Coding training

It might also be appropriate during Step 2 to give the development team a Secure Coding training to refresh knowledge. This training is based on official recommendations from Apple and Google for Secure Coding. It also includes OWASP Mobile top 10.

Step 3: Secure design

Once we’ve captured the mobile application requirements, we create an architecture that corresponds to the requirements. This phase also includes designing appropriate security controls for the types of sensitive data we identified during the previous phase.

You can also perform threat modeling during this step to identify and address the security risks associated with the application. The purpose of threat modeling is to apply a structured approach to the identification, enumeration, prioritization and initial handling of threats, and establish appropriate mitigations. You should also establish Secure Coding rules and create the list of Security tools you will use. This phase also includes clarifying your Security testing strategy.

When we do a threat modeling exercise, we think about the following questions:

• What can go wrong with mobile devices/applications/data?
• How can we address these issues?

We use this image to help you understand and identify the risks associated with a particular mobile application.

Step 4: Secure development

Now we move on to the next phase, which is to securely develop the software. The focus of this phase is on establishing best practices for detecting and removing security issues. Activities at this stage may include: 

• Security Code Reviews, 
• Static Application Security Testing, and 
• Security Unit Testing. 

Running static analysis on the source code early in the life cycle helps to fix code-level bugs before the application is released for general use. Static analysis finds incorrect coding that can potentially cause security risks. We perform the analysis without actually executing the program. This kind of analysis covers the entire source code or binary. It can be built in the development process and performed early in the software development life cycle.

For example, at this stage we use OWASP Dependency check to identify project dependencies and check if there are any known, publicly disclosed, vulnerabilities.

Also, we use approved and up-to-date tools during development. 

Step 5: Secure verification

During the Secure Verification phase, we ensure that the code meets the security and privacy tenets established in previous phases. We use OWASP checklists for verification and do both manual and automated Penetration Testing ("Pentests"). We usually perform Dynamic Application Security Testing during this phase as well. Also, we often use third party companies for penetration testing.

At this stage, we can perform fuzz testing, which involves inducing program failure by deliberately introducing malformed or random data.

For example, we use Mobile Security Framework (MobSF), an automated, all-in-one mobile application pen-testing framework capable of performing static, dynamic analysis for both Android and iOS devices. MobSF is designed to make your CI/CD or DevSecOps pipeline integration seamless.

Step 6: Secure release

The Secure Release phase involves:  

• preparing the project for public release, 
• conducting the final security review, 
• planning ways to effectively perform post-release servicing tasks, such as fixing bugs and 
• addressing the security or privacy vulnerabilities that may occur later. 

A key step in this phase is to create an incident response plan which identifies appropriate security emergency contacts and establishes security servicing plans for code inherited from other groups or licensed third-party code.

Prioritizing mobile app security

As we’ve discussed, mobile device and application security are important issues, especially as our device dependency increases. At Star, we help our clients design secure mobile applications, which protect their brand, information and customers.  And we walk the talk: we’re ISO 27001 certified, and we follow the highest information security standards on an organizational, technical and management level, so we can provide the best service for our customers.