There are apps sold to the general public and ones that are made available by businesses to their customers, as well as proprietary apps used only within organizations. What all of these apps have in common is that, without proper security, they are all vulnerable to attack. And each of those 200 billion downloads represents an ever-expanding pool of potential hackers and victims.
That’s why conducting penetration tests on mobile applications is one of the most important services we offer here at Raxis. We’ve tested apps for Apple, Android, and Windows phones, using up-to-date devices, jailbroken iPhones, and rooted Android devices, as well as emulators that allow further testing.
Here are some of the most common issues we find:
Jailbroken or Rooted Devices
Ideally, apps should be setup so that they won’t even run on devices that are jailbroken or rooted. People often do that to their devices to have more control than the vendor intended, allowing them to download unauthorized apps from stores such as Cydia. The danger is that such apps that may allow nefarious activities or steal users’ data.
Phones that have been jailbroken or rooted are also open to attacks on the operating system itself, possibly giving an attacker control of the device as well as control of legitimate applications. Our strong recommendation to developers is to build into apps the ability to recognize a device that has been compromised and to block its access until the device is updated correctly.
No SSL Certificate Pinning
We also find many mobile apps that don’t use SSL certificate pinning. SSL certificate pinning validates the authenticity of an SSL certificate. When an application fails to verify the certificate, it opens the door for a man-in-the-middle (MitM) attack, in which the attacker can insert himself into the encrypted traffic between the app and the server. This can be accomplished through name resolution poisoning, adding a proxy server, or a number of other ways.
The attacker then can use his own certificate to impersonate the API server and decrypt the application traffic, read or manipulate it, re-encrypt it, and forward it onto the intended destination without detection. This type of attack not only allows an attacker to decrypt both incoming and outgoing traffic (such as credit card numbers and passwords), but also allows the attacker to change it. Using a typical bank transaction as an example, the hacker could transfer the funds to his account instead of yours.
Shared Vulnerabilities
Not all vulnerabilities are exclusive to mobile applications. We also find many, such as SQL injection (SQLi) attacks, that can be weak points within web applications as well. That’s why it’s important to test mobile apps separately from web apps. Even though they may use the same APIs and databases, and the user experience may feel nearly identical, the platform code and environment are different. Testing each one ensures that a hacker can’t exploit the app simply by changing platforms.
Internal Apps
Raxis has tested apps that are made available for customers as well as proprietary apps that are used within organizations, such as on flights for meal service. We’ve worked with companies that were less concerned with internal apps and proprietary devices because they were only available to employees. In those cases, we explain that personal and proprietary devices could fall into the wrong hands. If an internal mobile device or app runs on a production network, an attacker that gains access to the device is one step closer to accessing company data that may be on that network.
What You Can Do
Many of the companies that come to Raxis for mobile tests use that as a marketing tool. They are proud to show potential customers that they have a strong focus on securing their data. So, take a look at the apps on your mobile device. Do you know if they’ve been tested by a company like ours? It’s always a good idea to read the security and privacy data before you download.
And remember, if you’re not sure, you can always ask – in public forums or user groups, or even directly to the app developers themselves. If they don’t currently conduct routine penetration testing, your questions might convince them they should.
*SOURCE: Statista c. 2020