Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Fintech fiddles as home burns: 97% of apps lack basic security

Richi Jennings Your humble blogwatcher, dba RJA

This is not fine. A white-hat researcher examined 30 financial apps, looking for information security issues—worryingly, all but one of them were insecure.

The failures were mind-numbingly familiar, and dead easy to find. It’s as if the industry has learned nothing and is walking around with a sign on its back, saying, “Rob me.”

Have we learned nothing? In this week’s Security Blogwatch, we’re full of despair.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Alice’s black hole.

Nero ignores conflagration

What’s the craic? As Lance Whitney reports, financial institutions are risking customer data through insecure mobile apps:

[A] report discovered several key security flaws among 30 mobile apps offered by financial institutions. Almost all of the apps researched could easily be reverse engineered, providing access to sensitive source code data, including account credentials, API keys, server file locations, and incorrectly stored health savings account information.
  • 97% of the apps tested lacked the proper code protection, opening themselves up to reverse engineering or decompiling. …
  • 90% of the financial institution (FI) apps shared services with other programs on the device. …
  • 83% insecurely stored data. …
  • 80% of the FI apps used weak encryption algorithms or incorrectly implemented strong ciphers. …
  • 70% of the apps used insecure random number generators to limit access to sensitive information. …
Financial companies should adopt a more comprehensive approach to security, according to the report. Those approaches might include app shielding, encryption, and threat detection and response. Developers … should also be trained in the use of secure programming and should implement security measures.

The apps tested spanned eight financial sectors, including retail banking, credit card, mobile payment, cryptocurrency, health savings accounts, retail brokerage, health insurance, and auto insurance. The size of the companies covered ranged from small and middle-market firms to large institutions with more than $10 billion in market capitalization.

Ouch. But which companies? Evan Schuman quips, You might want to go back to that money-under-the-mattress tactic:

A new report from a well-regarded payments consulting firm has found a lengthy list of security insanity. [It] said many procedures were simply sloppy. Cyberthieves love sloppy.

[This] is certainly a courtesy that will be much appreciated in the dark web, although likely less so by the financial institution's customers. That said, those customers will be unable to do anything about this — such as switching banks — because Aite declined to identify which companies they looked at. … Given that Aite has to work with these companies, it makes sense that it wouldn't want to flag [them].

Hint to FI companies: Hire a pen tester today to check out your site and apps. Some of you have massive issues.

Aite? Self-confessed “recovering black-hat hacker” Alissa Valentina Knight exorcises The Devil in the Details:

When a financial institution’s mobile app can be decompiled, adversaries can access sensitive information inside the source code, which may lead to a range of exploits against the FI or its customers. [Such] financial services companies … leave a monumental attack surface exposed.

The apps were accessed via the Google Play store. … APK Extractor was used to extract the mobile apps. … Apktool version 2.3.4 was used to reverse-engineer Android binaries. Static code analysis was performed using MobSF. … Network interdiction for analysis of network traffic was performed using Burp Suite.

Our analysis of the FIs’ mobile apps highlights 11 types of vulnerabilities: … Lack of binary protections, 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, insecure random number generation.

FIs are still failing to write secure code. … The amount of sensitive data surrounding the FIs’ API servers contained in these apps is alarming. … FIs are still using rampant insecure coding. … FIs’ mobile apps rarely use sandboxing to store sensitive data. … None of the FIs implemented any control mechanisms to detect whether the app was being reverse-engineered.

So tell me more about this decompilation. Tom Spring rebounds with Apps are Ripe for Exploit via Reverse Engineering:

Reverse engineering software has long been a technique used by … hackers.

Last month at the RSA Conference in San Francisco the U.S. National Security Agency released its Ghidra reverse-engineering platform. … For white hats, tools like Ghidra play a vital role helping them reverse engineer malware to assist them in understanding 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.

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.

The research was sponsored by Arxan, whose VP of product management is one Rusty Carter:

We saw a lot of this happening in Eastern Europe last year, with this repackaging and distribution of apps. They were going to a legitimate bank, but also exfiltrating all the data at the same time.

Clearly there's a problem here. You need to know that adversaries are beginning to target this area.

This is the new frontier. This is a new area of focus for adversaries and this report is meant to get financial services companies to see how big of a problem they've got here and how they can address it.

Slightly scary? Erich G.—@ErichG69—is terrified:

These are the sorts of errors one expects from hobbyists, not professional organizations. It speaks to a stunning lack of DevOps and security Architecture.


But Michael is nonplussed:

Why waste our time if you won’t tell us which apps are most vulnerable???

I know, right? John Croix sounds cross: [You’re fired—Ed.]

This sounds somewhat disconcerting at first but then it becomes a joke.

“The apps are vulnerable but we’re not going to tell you which one, and oh yes we’re not going to tell the banking institutions either. We just want to scare you but watch this site we’re going to offer to fix the problem for you. It’ll be a subscription service that offers a two year contract and we won’t tell you if your bank is on the list until you have signed up.”

Meanwhile, Dave Chisholm—@lonecrowdotnet—sings a lonely song:

Client injection! Still??

Devs need a sense of belonging to a profession with principals that clients can't bargain away. Like Dr or Lawyers.

I have been a freelance developer for a very long time, many clients skimp on security if it saves them a buck. If you're a lawyer you are disbarred if you act unethically at client's request.
Devs need to display more professionalism.

The moral of the story?

User-controlled endpoints are not secure! Design for an adversarial world; pen-test and red-team the result.

And finally

First ever look at a Black Hole from the Event Horizon Telescope

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: KC Green (cc:by)

Keep learning

Read more articles about: SecurityInformation Security