State of Kenyan mobile banking app security

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.


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, JadeChrispus 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.


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.


Getting started with MARA: Installing and setting up - part 1

This blog post is a follow up to this post on why we developed the MARA framework. This will be a series of blog posts on how mobile app pentesters can take full advantage of MARA. It does have a lot that it offers and the data can be quite overwhelming to consume, decipher, peruse and filter out the key points of interest.

MARA was developed with the express intention to extract as much information as possible and provide various representations of the same data from mobile applications, so that pentesters can work with the version they are comfortable with i.e. java, smali or dalvik bytecode.

I have been getting lots of questions on how to setup MARA with various follow ups on why its breaking while installing. It is my hope that this short blog post will assist anyone who has had challenges on installing and setting it up. 

As seen above, the setup is fairly straight forward provided that the setup script is used to automatically download all the required dependencies. A majority of the issues will generally arise due to either lack of critical dependencies or a partial installation of the same.

The follow up blog post, will focus on using MARA to analyze android applications and various file types that it supports. It will also provide an overview of the data collected from the static analysis and the SSL scans.

MARA Framework - How it all started...

For the past few months, i have been digging into the Android Operating system to understand its inner workings and how different elements are pieced together. I decided to start of with trying to understand how applications are developed and that didn't go so well. I tried to learn java and well, lets just say i didn't have the patience and required consistency to learn. So i decided to start by learning the Android architecture. This was very confusing at first considering i was an avid Blackberry user. I hadn't owned an Android phone for about 3 to 4 years.

I decided to start of with Android forensics, because i thought it would give me a basic understanding of the Android file system and the various libraries and processes. This turned out to be a solid approach  and soon is was scouring through an Android phone i had access to. I scavenged through it to extract and examine apps,files and the data i could find. I didn't use any forensic tools at this point, just simple, old fashioned, manual forensics to better understand where certain data is located and how to extract it.

I soon developed interest in android applications as it seemed like a point of familiarity. The first step was to understand the components of an android application, then later how the operating system executes it, what data is stored, where its stored and who had access to it.

Every Android reverse engineering blog post i read, gave somewhat similar tools on decompiling android applications. Dex2jar, apktool, JD GUI  and baksmali were the most commonly mentioned tools. After successful reverse engineering the next steps were the static and dynamic analysis which also had another horde of tools that assist do the job.

It soon started to become quite frustrating on having to run various tools to get different output. For example, running dex to jar to convert the android application (apk) into a jar file or converting the apk into smali bytecode using baksmali. This process was not only inconvenient and slow, but i could only reverse engineer and study one app at a time. At this point in time my good friend Chrispus was also facing the same challenges on reverse engineering android apps.

So what now? Well, we decided to download all the Android application reverse engineering tools we could our hands on and try figure out which ones were the most reliable in terms of the provided output and  easy to use. In a few weeks of tests, we had a list of tools that became our standard go to tools for the android application reverse engineering. While this was great, we still had two main challenges.  We had to run all the tools individually to get the output we needed and we still, could only analyze one app at a given time.

At this point we decided to write a script that would allow us to automate the android application reverse engineering process. This took a couple of weeks and we were done. We could reverse engineer one application at a time or multiple application in a specified folder.

This was great but we faced yet another challenge. We now had the reverse engineered application,and what was to follow was the static analysis. After a bit of googling we came across MobSF.  Its an awesome tool that performs both static and dynamic analysis of both Android and iOS applications. After downloading the tool from github and poking around in it, we found the strings it was using to perform the static analysis, and that was when we had the light bulb moment.

We figured, why don't we use the same strings to perform the static analysis but dumping the identified matches to a text file for review. First thing first, was to ask Ajin, the creator of MobSF for permission to use the detection strings, of which he obliged. What crossed our minds next was the OWASP mobile top 10, We wanted to figure out which checks are supposed to be performed on an mobile application in accordance to OWASP mobile security threats. We then came across the list of mobile app checklist on the OWASP website for both static and dynamic analysis. This was simply like finding gold to us.

We decided to integrate the static analysis strings from MobSF in line with the OWASP checks into our reverse engineering script. We wanted to begin with the OWASP top 10 as the main focus then include all the other 91 checks progressively. After a few months of bash scripting, the simple reverse engineering script morphed into the MARA framework. A tool that decompiles android application, java classes, dex file and class files into java class files, then proceeds to statically analyze them.

We included androbugs to scan for potential vulnerabilities in the apk, alongside a number of other tools. There is also an integrated SSL scanner for scanning domains extracted from the resulting source code. This was nothing more than a script to make our work easier, faster and more efficient.

We saw the potential of the tool to assist not only mobile application developers but also mobile app penetration testers in analyzing mobile applications. So we uploaded it here on github for any developer or pentester to make use of and contribute to its development.

It currently only supports static analysis of Android applications but within the next few months we intend to integrate iOS mobile application reverse engineering and static analysis support alongside dynamic analysis of android applications. The MARA framework is fairly easy to setup and use. The wiki highlights its decencies and the installation procedure.

In the next follow up blog post, i will give an overview of the MARA Framework setup process and how it can expedite your android app reverse engineering and static analysis process. I'll also dive into the mobile app pentest methodology that i use to try and identify potential vulnerabilities and insecure coding practices in android apps.

Installing OWASP Mth3l3m3nt on Kali Nethunter

I've been porting some of the tools i use on a day to day to my Kali Nethunter device for portability of course a little bit of on the go hacking. 

I decided to install the Mth3l3m3nt framework on nethunter due to the tool's awesome capabilities. My good friend Munir did a really great job on this one in collaboration with OWASP. Let's get down to it, shall we.

We shall be installing everything on the Kali Nethunter chroot environment, so now would a great time to boot into it. For this tutorial is shall be doing the setup over adb as it is much faster.
  • adb shell
  • su
  • bootkali
Now that we are in the Kali Nethunter chroot, there are a few pre-requisites to installing the Mth3l3m3nt. These are apache web server and git. Kali comes with these pre-installed but in any case, they are installed with the command below.
  • apt-get install git apache2 

Preparing Apache

Now we edit the apache config file and add the following:
nano  /etc/apache2/apache2.conf

<Directory /var/www/>
    Options -Indexes +FollowSymLinks +Includes
    AllowOverride All
    Order allow,deny
    Allow from all
   # This is required for apache 2.4.3 or higher, if lower version remove the line below
   Require all granted

In my case, i uncommented the default directory tag for consistency

Downloading Mth3l3m3nt

Next we download mth3l3m3nt to our device and move it to the apache web root folder (/var/www/html)
  • mkdir -p ~/dumps
  • cd ~/dumps
  • git clone --recursive https://github.com/alienwithin/OWASP-mth3l3m3nt-framework
  • mv OWASP-mth3l3m3nt-framework /var/www/html/mth3l3m3nt

Configuring the install

Next we configure the necessary rights and permissions:
  • chown -R www-data:www-data /var/www/html
  • cd  /var/www/html/mth3l3m3nt
  • chmod -R 0777 tmp/
  • chmod -R 0777 framework/data/
  • chmod -R 0777 incoming/
  • chmod -R 0777 scripts/
Edit .htaccess by uncommenting out the line with RewriteBase the base mth3l3m3nt folder:
  • nano .htaccess
  • RewriteBase /mth3l3m3nt
Create the mth3l3m3nt virtual host file in /etc/apache2/sites-available folder:
  • touch /etc/apache2/sites-available/mth3l3m3nt.conf
  • nano /etc/apache2/sites-available/mth3l3m3nt.conf
Copy the text below to mth3l3m3nt.conf and save:
<VirtualHost localhost:80>
    ServerAdmin admin@test.com
    ServerName mth3l3m3nt
    ServerAlias www.mth3l3m3nt.com
    DocumentRoot /var/www/html

    <Directory /var/www/html/mth3l3m3nt>
          Options -Indexes +FollowSymLinks +Includes
          AllowOverride All
          Order allow,deny
          Allow from all
          #This is required for apache 2.4.3 or higher, if lower version remove the line below
          Require all granted


Enable the virtual host:
  • a2ensite mth3l3m3nt.conf
Restart apache:
  • service apache2 restart

Accessing the panel

Now you can access mth3l3m3nt on:

The default credentials for the cnc panel are:
username: mth3l3m3nt
password: mth3l3m3nt

If all went well, you should be able to access the Mth3l3m3nt panel as shown below.