December 2016

Home » Archives for December 2016

State of Kenyan mobile banking app security

   Wednesday, December 14, 2016      


This blog post focuses on the state of the mobile banking app security. The scope was the 20 banks in Kenya that offer mobile banking services via a mobile app, more specifically an android app. In case you don't want to read through this whole blog to identify what we have uncovered from our independent analysis, here's a quick summary for you.

TL;DR: 

90℅ of Kenyan mobile banking apps are very insecure, they don't follow mobile app development and mobile payment best practices. You are better off sticking with USSD for now, until the respective banks secure their apps. If you have to use the app, stick to mobile data as opposed to WiFi as the attack surface over mobile data is smaller.

If you are reading this, i'm guessing you would like to know what the fuss is all about, regarding the banking apps, well, lets get into it.

Banking app downloads (Android playstore) 

I was pretty curious to find out how many mobile banking users really are there, and how large the user base of the banking apps are. This helps determine how many people per bank can be affected when a bank's app is vulnerable as well as get a feel on how large the users are, as a whole.

The best source of this information i could find, was to go checking the number of installs per app and documenting them. These numbers are only estimates as a user can easily download an app, remove it and then re-install from the playstore. So the stats below are definitely skewed in one way or another. Its only the individual banks that know, how many of their customers have installed their app and how many active users they presently have.


Mobile banking infrastructure setup

Now that we have some numbers on the mobile banking app users, lets have a quick overview on how the infrastructure is setup. Mobile banking does not operate in a vacuum, there are certain utilities and services that they rely upon. Kenyan banks provide mobile banking either via USSD (Unstructured Supplementary Service Data) or a mobile app running on Android, iOS and Windows phones.

A typical USSD infrastructure setup would look like the image below. The banking session is initialized by dialing the bank's respective USSD code e.g *1337# then you can proceed to enter your PIN, once validated, you can check your balance, send some money, repay a loan etc


USSD is quite convenient as a vast majority of mobile phones are GSM enables, irrespective of whether the mobile device is a feature phone e.g. x-tigi 80 or a smart phone e.g. Samsung Galaxy S7. It works in basic voice connectivity and the user does not need to install any application whatsoever on the mobile device.

Attacks over USSD heavily rely on an attacker having an intimate understanding of telecommunications infrastructure i.e. GSM, LTE, CDMA etc. One such attack would be to setup a rogue BTS (Base Transiever Station) using a device such as a USRP, BladeRF or the cheaper alternative which is the Motorola C123. You can read more about rogue base stations here. This area is pretty much out of my depth but a few of my good friends Ty, Jade, Chrispus and Emmanuel can elaborate further on such telco based attacks.

With the increase in smartphones, a number of Kenyan banks have embraced the use of mobile banking apps. Such apps provide additional services that USSD traditionally doesn't support e.g. transferring funds to any phone number on your contact list, creating alerts, setting up budgets etc As with information security, the more convenience is offered on a product, security tends to suffer. Which is the case for Kenyan mobile banking apps.

Below is an illustration of a mobile banking infrastructure setup. Its is typically made up of the respective mobile app (client side), a communication channel (usually over HTTPS) and an application server (sever side) that interfaces with the core banking system.

In the context of mobile banking applications, the attack vectors are the mobile banking app itself, the communication channel in use and ultimately the applications server that it's communicating with. Possibly all the way down into the core baking system if an attacker manages to pivot into the bank's internal network from the application server. .

Attacking a mobile banking app is generally much easier than attacking the telco infrastructure that USSD rides on. Attacking the mobile banking application can compromise a few users probably connecting to the same network. However, compromising the application server, potentially leaves all the users of that service compromised and exposed.

All it takes is someone who understands a bit of reverse engineering, mobile app security and web security with a dash of curiosity and the desire to take things apart to understand how they work.

Top Vulnerabilities

After a review of the 20 mobile banking applications, we found a ton of security issues, well in line with the OWASP top 10 vulnerabilities, some with a very high severity as opposed to others. We used a combination of information gathering tactics, reverse engineering, static analysis, dynamic analysis and forensics analysis so as to be as comprehensive as possible.

Below are basically some of the security vulnerabilities we have identified at each segment. This should make it easier to identify what security measures need to be taken at each segment.

Mobile app (client side)
  • OWASP Top 10 Mobile Vulnerabilities
  • Hardcoded information such a certificates, API keys, URLs                 
  • Insecure SSL implementation of the mobile app
  • Weak of cryptography technologies
  • Allow app backup
  • Use of insecure random number generation
  • Reverse engineering attacks
  • Application code injection attacks
  • Insecure implementation of 3rd party services
  • Internal IP address exposure
Communication channel
  • Insecure transfer of sensitive information
  • Improper server side data validation
  • Lack of secure session management
Web server (sever side) 
  • OWASP Top 10 Web Vulnerabilities
  • Running services and version
  • Insecure Transport Layer Security (TLS)/Secure Sockets Layer (SSL) implementation
  • Multiple TLS/SSL based vulnerabilities
  • Insecure Application Program Interface (API) implementation 
  • User login enumeration via brute forcing 
  • Use of vulnerable web services and applications

How bad are the apps, security wise? 

To be frank, most of the banking apps are really PoCs that are running on production. I know this is going make a lot of mobile banking app developers angry but its the honest truth. Out of the 20 banking apps, only 2 have indications that the people who made them care about their customer's security. They are not perfect, they do have a long way to go but its a solid start.

It's quite unfortunate to note that mobile banking app developers who have multiple banks as their clients, are simply copy & pasting apps, down to the infrastructure setup. This leaves multiple vulnerabilities running across all their clients. This is not to mention, social media links and domains from one bank present in another bank's app. This shows that applications are simply not being reviewed before uploading to the app stores and the lack of due diligence by the said developers.

So how do you fix the security gaps above?

It does not add much value identifying readily exploitable vulnerabilities and leave it at that. A few pointers on how to develop secure mobile banking applications are as highlighted below.
  • Develop the application according to available standards and guidelines
    • OWASP mobile 2016 (release candidate)
    • PCI Mobile Payment Acceptance Security Guidelines
    • VISA Secure Mobile Payment Systems Guide
  • Implement SSL pinning on mobile banking application
  • Properly implement SSL on the application server
  • Implement the use of secure cookies
  • Use secure cryptographic technologies
  • Properly obfuscate the mobile application

What next from here?

Kenyan banks don't develop the banking apps in-house, they are developed by contracted developers who in my opinion, most of them don't really care about mobile application security. In my opinion, banks need solid service level agreements (SLAs) with their mobile banking developers that require their apps be thoroughly penetration tested prior to every release, this is alongside the banks' infosec or audit team, also testing the app and giving their stamp of approval before uploading it to the various app stores.

This should be done in due consideration that a proper mobile app penetration test cannot be conducted a week due to launch or upload to the app store. Anyone doing this, should consider giving adequate timeline for the pentests. Good security needs time to implement properly and validate it.

Building these banking applications with Secure Software Development Life Cycle (SecSDLC) from the very beginning of the project will at least eliminate a very huge chunk of the vulnerabilities identified, not to mention saving yourself from embarrassment and reputational damage when your app is hacked and customer data is leaked on the internet.

The bank's' internal infosec and audit teams need to conduct regular tests at least once every three months to ensure both the mobile banking application and the application server is well secured and potential vulnerabilities are patched in a timely fashion.

Final Remarks

At the end of the day, all banking customers (me included) deserve well secured products and services. We are a mobile first nation, with consumers who deserve continuous effort to ensure their security is well provided and ensured to the best of the banks ability.  More so when money, is involved.

Credit

I would like to thank Ruby and Charles for the assistance in the mobile banking app analysis. It took quite a large amount of effort to refine the analysis process and also update these findings as from the AfricaHackOn conference this year. I would also like to thank Chrispus on his insight with regard to mobile application security analysis. Not to mention Munir and Gabriel for corroborating our findings from the analysis.

References:

  

at Wednesday, December 14, 2016
Subscribe to: Posts ( Atom )