Financial Apps are Ripe for Exploit via Reverse Engineering

White hat hacker reverse engineers financial apps and finds a treasure trove of security issues.

A white hat hacker reverse engineered 30 mobile financial applications and found sensitive data buried in the underlying code of nearly all apps examined. With this information a hacker could, for example, recover application programming interface (API) keys and use them to attack the vendor’s backend servers and comprise user data, researchers said.

The apps in question were all Android and culled from eight sectors including retail banking, healthcare and auto insurance. Companies behind the apps ranged from Fortune 100 companies and down, according to Arxan Technologies, the company that conducted the research titled In Plain Sight: The Vulnerability Epidemic in Financial Mobile Apps.

“Many of the findings were shocking to say the least,” said Alissa Knight, senior cybersecurity analyst with Aite Group, who conducted the research. “I even found that some financial institutions were hard coding private keys, API keys and private certificates – all in the actual code or storing them in subdirectories of the app.” In other instances, Knight said, she found URLs that the apps use to communicate with, which would allow an adversary to target the APIs of the backend servers as well.

Key findings include the fact that 97 percent of all Android apps tested lacked binary code protection. “This makes it possible to reverse engineer or decompile the apps; exposing source code to analysis and tampering,” according to the report scheduled to be released Tuesday.

Vulnerability Findings Across All Financial Apps

“It would be near impossible to find these holes if app developers implemented application shielding and other security such as application binding, repackaging detection and tamper detection, data-at-rest encryption and key protection,” Knight said.

The report’s author did not identify the apps studied. Neither did she test Apple iOS apps, explaining a limited Android scope to her research.

Reverse engineering software has long been a technique used by black hat and white hat hackers. Last month at the RSA Conference in San Francisco the U.S. National Security Agency released its Ghidra reverse-engineering platform to much fanfare.

For white hats, tools like Ghidra play a vital role helping them reverse engineer malware to assist them in understand how it works, what it does and reveal clues about who wrote it or where it came from. Black hats can glean similar data from code and use it as a hacking springboard for an attack.

Knight said her reverse engineering efforts on 30 sample apps revealed 83 percent of the apps tested insecurely stored data outside of the apps control. For example, Knight said, data can be stored in a device’s local file system or external storage where it can be copied to a clipboard – allowing shared access with other apps, she said.

Another 80 percent implemented “weak” encryption algorithms or the incorrect implementation of a strong cipher, “allowing adversaries to decrypt sensitive data and manipulate or steal it as needed.” Lastly, 70 percent of apps use an insecure random-number generator, making the values easily guessed and hackable. Mobile apps rely on random number generation for both function and encryption.

“During this research project, it took me 8.5 minutes on average to crack into an application and begin to freely read the underlying code, identify APIs, read file names, access sensitive data and more,” Knight wrote.

Lack of binary protections she said allowed her to find eleven unique weaknesses including; insecure data storage, unintended data leakage, client-side injection, weak encryption, implicit trust of all certificates, execution of activities using root, world readable/writable files and directories, private key exposure, exposure of database parameters and SQL queries and insecure random number generation.

The solution, the report concludes, is adoption of application shielding, application binding, repackaging detection, tamper detection, data-at-rest encryption and key protection through white-box encryption.

“It’s really critical not only to have obfuscation, but also encryption. App developers need some sort of a detection and response capability, so that you can understand what exactly is happening to that application and control it before it turns into a breach,” she said.

Suggested articles