INSIGHTS | January 8, 2014

Personal banking apps leak info through phone

By Ariel Sanchez
For several years I have been reading about flaws in home banking apps, but I was skeptical. To be honest, when I started this research I was not expecting to find any significant results. The goal was to perform a black box and static analysis of worldwide mobile home banking apps. The research used iPhone/iPad devices to test a total of 40 home banking apps from the top 60 most influential banks in the world.

In order to obtain a global view of the state of financial services security, some of the more important banks from the following countries were included in the research:
 
 
 
Relevant Points
  • The research was performed in 40 hours (non-consecutive).
  • This research does not show the vulnerabilities found and how to exploit them in order to protect the owner of the app and their customers.
  • All tests were only performed on the application (client side); the research excluded any server-side testing.
  • Some of the affected banks were contacted and the vulnerabilities reported.
 
Tests
 
The following tests were performed for each application:
 
  1.  Transport Security
    1.  Plaintext Traffic
    2.  Improper session handling
    3.  Properly validate SSL certificates
  2.  Compiler Protection 
    1.  Anti-jailbreak protection
    2.  Compiled with PIE
    3.  Compiled with stack cookies
    4.  Automatic Reference Counting
  3.  UIWebViews 
    1.  Data validation (input, output)
    2.  Analyze UIWebView implementations
  4.  Insecure data storage
    1.  SQLlite database
    2.  File caching
    3.  Check property list files
    4.  Check log files
  5.  Logging
    1.  Custom logs
    2.  NSLog statements
    3.  Crash reports files
  6.  Binary analysis
    1.  Disassemble the application
    2.  Detect obfuscation of the assembly code protections
    3.  Detect anti-tampering protections
    4.  Detect anti-debugging protections
    5.  Protocol handlers
    6.  Client-side injection
    7.  Third-party libraries
 
Summary
 

All of the applications could be installed on a jailbroken iOS device. This helped speed up the static and black box analysis.
 
 
Black Box Analysis Results
 
The following tools were used for the black box analysis:
    • otool (object file displaying tool)[1]
    • Burp pro (proxy tool)[2]
    • ssh (Secure Shell)
40% of the audited apps did not validate the authenticity of SSL certificates presented. This makes them susceptible to Man in The Middle (MiTM) attacks.[3]
 
A few apps (less than 20%) did not have Position Independent Executable (PIE) and Stack Smashing Protection enabled. This could help to mitigate the risk of memory corruption attacks.
 
>#otool –hv MobileBank
MobileBank:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     ARM         V6  0x00     EXECUTE    24       3288   NOUNDEFS DYLDLINK PREBOUND TWOLEVEL
 
Many of the apps (90%) contained several non-SSL links throughout the application. This allows an attacker to intercept the traffic and inject arbitrary JavaScript/HTML code in an attempt to create a fake login prompt or similar scam. 
 
Moreover, it was found that 50% of the apps are vulnerable to JavaScript injections via insecure UIWebView implementations. In some cases, the native iOS functionality was exposed, allowing actions such as sending SMS or emails from the victim’s device.
 
 
A new generation of phishing attacks has become very popular in which the victim is prompted to retype his username and password “because the online banking password has expired”. The attacker steals the victim’s credentials and gains full access to the customer’s account.
 
The following example shows a vulnerable UIWebView implementation from one of the home baking apps. It allows a false HTML form to be injected which an attacker can use to trick the user into entering their username and password and then send their credentials to a malicious site.
 
 
Another concern brought to my attention while doing the research was that 70% of the apps did not have any alternative authentication solutions, such as multi-factor authentication, which could help to mitigate the risk of impersonation attacks.
 
Most of the logs files generated by the apps, such as crash reports, exposed sensitive information. This information could be leaked and help attackers to find and develop 0day exploits with the intention of targeting users of the application. 
 
 
Most of the apps disclosed sensitive information through the Apple system log. The following example was extracted from the Console system using an iPhone Configuration Utility (IPCU) tool. The application dumps user credentials of the authentication process.
 
…
CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Jun 22 16:20:37 Test Bankapp[2390] <Warning>: <v:Envelope xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns:d=”http://www.w3.org/2001/XMLSchema” xmlns:c=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:v=”http://schemas.xmlsoap.org/soap/envelope/”>
<v:Header />
<v:Body>
<n0:loginWithRole id=”o0″ c:root=”1″ xmlns:n0=”http://mobile.services.xxxxxxxxx.com/”>
<in0 i:type=”d:string”>USER-ID</in1>
<in1 i:type=”d:string”>XRS</in2>
<in2 i:type=”d:string”>PASSWORD</in3>
<in3 i:type=”d:string”>xxxxxxxx</in4>
</n0:loginWithRole>
</v:Body>
</v:Envelope>
Jun 22 16:20:37 Test Bankapp[2390] <Warning>: ]]]]]]]]]]]]] wxxx.xxxxx.com
Jun 22 16:20:42 Test Bankapp[2390] <Warning>: RETURNED:
Jun 22 16:20:42 Test Bankapp [2390] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
…
 
 
Static Analysis Results
 
The following tools were used for the static analysis and decryption:
    • IDA PRO (disassembler tool) [4]
    • Clutch (cracking utility) [5]
    • objc-helper-plugin-ida [6]
    • ssh (Secure Shell)
    • gdb (debugger tool)
    • IPCU [7]
 
The binary code of each app was decrypting using Clutch. A combination of decrypted code and code disassembled with IDA PRO was used to analyze the application.
 
Hardcoded development credentials were found in the code. 
 
__text:00056350  ADD             R0, PC ; selRef_sMobileBankingURLDBTestEnv__
__text:00056352 MOVT.W          R2, #0x46
__text:00056356 ADD             R2, PC  ; “https://mob_user:T3stepwd@nulldb.internal/internal/db/start.do?login=mobileEvn”
__text:00056358 LDR             R1, [R0] ; “setMobileBankingURLDBTestEnv_iPad_mobil”…
__text:0005635A MOV             R0, R4
__text:0005635C BLX             _objc_msgSend
__text:00056360 MOV             R0, (selRef_setMobileBankingURLDBTestEnvWithValue_iPad_mobileT_ – 0x56370) ; selRef_setMobileBankingURLDBTestEnvWithValue_iPad_mobileT_
__text:00056368 MOVW            R2, #0xFA8A
__text:0005636C ADD             R0, PC ; selRef_setMobileBankingURLDBTestEnvWithValue_i_mobileT_
__text:0005636E MOVT.W          R2, #0x46
__text:00056372 ADD             R2, PC  ; “https://mob_user:T3stepwd@nulldb.internal/internal/db/start.do?login=mobileEvn&branch=%@&account=%@&subaccount=%@”
__text:00056374 LDR             R1, [R0] ; “setMobileBankingURLDBTestEnvWith_i”…
__text:00056376 MOV             R0, R4
__text:00056378 BLX             _objc_msgSend
 
 
By using hardcoded credentials, an attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.
 
Internal functionality exposed via plaintext connections (HTTP) could allow an attacker with access to the network traffic to intercept or tamper with data.
 
__text:0000C980 ADD             R2, PC  ; “http://%@/news/?version=%u”
__text:0000C982 MOVT.W          R3, #9
__text:0000C986 LDR             R1, [R1] ; “stringWithFormat:”
__text:0000C988 ADD             R3, PC  ; “Mecreditbank.com”
__text:0000C98A STMEA.W         SP, {R0,R5}
__text:0000C98E MOV             R0, R4
__text:0000C990 BLX             _objc_msgSend
__text:0000C994 MOV             R2, R0
…
__text:0001AA70 LDR             R4, [R2] ; _OBJC_CLASS_$_NSString
__text:0001AA72 BLX             _objc_msgSend
__text:0001AA76 MOV             R1, (selRef_stringWithFormat_ – 0x1AA8A) ; selRef_stringWithFormat_
__text:0001AA7E MOV             R2, (cfstr_HttpAtmsOpList – 0x1AA8C) ; “http://%@/atms/?locale=%@&version=%u”
__text:0001AA86 ADD             R1, PC; selRef_stringWithFormat_
__text:0001AA88 ADD             R2, PC; “http://%@/atms/version=%u”
__text:0001AA8A
__text:0001AA8A loc_1AA8A                               ; CODE XREF: -[BranchesViewController processingVersion:]+146j
__text:0001AA8A MOVW            R3, #0x218C
__text:0001AA8E LDR             R1, [R1]
__text:0001AA90 MOVT.W          R3, #8
__text:0001AA94 STMEA.W         SP, {R0,R5}
__text:0001AA98 ADD             R3, PC  ; “Mecreditbank.com”
__text:0001AA9A MOV             R0, R4
__text:0001AA9C BLX             _objc_msgSend
 
 
Moreover, 20% of the apps sent activation codes for accounts though plainttext communication (HTTP). Even if this functionality is limited to initial account setup, the associated risk high. If an attacker intercepts the traffic he could hijack a session and steal the victim’s account without any notification or evidence to detect the attack.
 
After taking a close look at the file system of each app, some of them used an unencrypted Sqlite database and stored sensitive information, such as details of customer’s banking account and transaction history. An attacker could use an exploit to access this data remotely, or if they have physical access to the device, could install jailbreak software in order to steal to the information from the file system of the victim’s device.
 
The following example shows an Sqlite database structure taken from the file system of an app where bank account details were stored without encryption.
 
 
 
Other minor information leaks were found, including:
    • Internal IP addresses:
__data:0008B590 _TakeMeToLocationURL DCD cfstr_Http10_1_4_133
__data:0008B590                                         ; DATA XREF: -[NavigationView viewDidLoad]+80o
__data:0008B590                                         ; __nl_symbol_ptr:_TakeMeToLocationURL_ptro
__data:0008B590                                         ; “http://100.10.1.13:8080/WebTestProject/PingTest.jsp”
    • Internal file system paths:
__cstring:000CC724 aUsersXXXXPro DCB “/Users/Scott/projects/HM_iphone/src/HBMonthView.m”,0
 
 
Even though disclosing this information on its own doesn’t have a significant impact, an attacker who collected a good number of these leaks could gain an understanding of the internal layout of the application and server-side infrastructure. This could enable an attacker to launch specific attacks targeting both the client- and server-side of the application.
 
 
Conclusions
 
From a defensive perspective, the following recommendations could mitigate the most common flaws:
    • Ensure that all connections are performed using secure transfer protocols
    • Enforce SSL certificate checks by the client application
    • Protect sensitive data stored on the client-side by encrypting it using the iOS data protection API
    • Improve additional checks to detect jailbroken devices
    • Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
    • Remove all debugging statements and symbols
    • Remove all development information from the production application
 
Home banking apps that have been adapted for mobile devices, such as smart phones and tablets, have created a significant security challenge for worldwide financial firms.
 
As this research shows, financial industries should increase the security standards they use for their mobile home banking solutions.
 
 
References:
 
[1] http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html
[5] https://forum.appaddict.org/index.php?/topic/40-how-to-crack-ios-apps/