Is it possible to steal money from mobile banking? Part 2

We continue the topic of mobile banking security, which we started in the first part . Probably many have already guessed, this article will focus on the man-in-the-middle attack, MitM. This attack was not chosen by chance. If the data channel between the mobile banking application and the server is controlled by an attacker, the latter can steal money from the client’s account, that is, cause direct financial damage. But first things first.


In general, to conduct this study we were prompted by two reasons. First, from project to project, we see a recurring sad picture of vulnerabilities. According to the results of the audit, it turns out another short film with MB hacking for the customer. Secondly, two very interesting publications were published: “The Most Dangerous Code in the World: Validating SSL Certi fi cates in Non-Browser Software” and “Rethinking SSL Development in An App ed Ed World” - we advise you to read them. But first things first.

Man-in-the-middle

The main scenarios for the implementation of the attack "MitM" :
- Connecting a user to a fake Wi-Fi access point. This is the most common and real scenario MitM-attacks. It can be easily reproduced in a cafe, shopping or business center. Software to conduct this attack is easy to find in the public domain.
- Connection to a fake base station operator. This scheme is becoming more accessible to the masses due to the rich choice of hardware and software and its low cost. The situation must be taken under control as quickly as possible.
- Using infected network equipment. The infection of network equipment means not only the execution of malicious code on it, but also its targeted malicious reconfiguration, for example, through a vulnerability. We already know many examples of the implementation of such attacks.
It is worth saying that these are just a few of the many possible scenarios. The main thing that is necessary for an attacker is to ensure that the network traffic from the victim to the server goes through the host under his control.
')

Malicious SOHO routers

A cool find and study from the guys from Team Cymru - they found malware that, when getting into the internal network, changed the DNS settings to their own. What does it mean? Now that the sites controlled by the attacker were redirected not only to the internal machines, but also to all the mobile devices that cling to these routers via WiFi! And here we have such an intricate MiTM.

The specifics of mobile devices with Wi-Fi-networks:
- Automatic connection to known Wi-Fi networks (based on PNL, Preferred Network List)
o Not everywhere can be disabled or configured in any simple way.
- Network identification is based on SSID (network name) and security settings
- If there are several known networks, each OS has a different connection choice.

The attacker can deploy its own Wi-Fi network, completely identical to the known network for a mobile device. As a result, the device will automatically connect to such an access point and will work through it. For example, using the KARMA program. This scheme and the lack of simple management of trusted networks simplifies the implementation of “MitM” for an attacker.

Channel protection

Before breaking, let's examine what can prevent us from doing this.
A secure channel is a channel in which encryption and integrity monitoring is used to ensure data transfer. But you should not forget that not all cryptographic algorithms remain stable and the use of cryptography does not always occur correctly.

Channels can be divided into 3 main groups:
- Open
Being in the same network with the victim, the attacker sees all the client-server interaction in the clear.
- Protected by non-standard methods
As our practice shows, this is not the best solution: it leads to a number of errors that lead to the compromise of the transmitted data.
- Protected by standard methods
The most common option is SSL / TLS

Certificate Verification Process

To ensure the efficiency of this scheme, there are many root certificates (CA) on the device, which are stored in a special store of trusted root certificates, and everything that they have signed is trusted for the device.

Certificates are divided into:
• system - pre-installed in the system
• custom - set by user
Verification of certificates goes on a chain: from sent to the device to the root (CA), which the device trusts. Next come the hostname, revocation, and so on. Further checks may vary (this, by the way, can also be played when attacking a particular application) depending on the implementation of the library, OS, etc.

SSL and Android

In Android OS up to version 4.0, all certificates were stored in a single file - Bouncy Castle Keystore File.

File: /system/etc/security/cacerts.bks

It was impossible to change it without root privileges, and the OS did not provide any ways to modify it. Any certificate change (addition, revocation) required an OS update.
Starting with the version of Android 4.0, the approach to working with certificates has changed. Now all certificates are stored in separate files, and if necessary, you can remove them from trusted ones.

System files are stored in: / system / etc / security / cacerts
Custom stored in: / data / misc / keychain / cacerts-added

To view certificates in Android OS, go to Settings -> Security -> Trusted certificates (Settings -> Security -> Trusted credentials).
The number of system certificates in different versions of Android:
- Android 4.0.3: 134
- Android 4.2.2: 140
- Android 4.4.2: 150
The number of certificates may also vary from manufacturer to manufacturer and for each device model.
To install a user certificate in Android OS, you need to upload the root certificate to the SD card and go to Settings -> Security -> Install from a memory card or via MDM (DevicePolicyManager) in Android, starting with version 4.4. Making a user install a certificate using social engineering is possible, but not very easy.

SSL and iOS

On iOS, you cannot view embedded certificates, and you can only get information about them from the Apple website . To view user certificates, go to Settings -> General -> Profile (s).

System stored in: /System/Library/Frameworks/Security.framework/certsTable.data
Custom stored at: /private/var/Keychains/TrustStore.sqlite3
The number of system certificates in different versions of iOS (The number of certificates can be updated):
- iOS 5: 183
- iOS 6: 183
- iOS 7: 211

On iOS, there are several ways to install user certificates:
- Via Safari browser - you need to follow the link on which the certificate with the .pem extension or the configuration profile with the .profile extension rests
- By attaching the certificate to the E-mail
- Through MDM API

It can be seen that installing a user certificate through social engineering on iOS is much easier than on Android.

Possible vectors for installing certificates through social engineering:
1) The user does everything himself because of ignorance. For example, promises free access to the Internet at a particular access point after installing a specific certificate;)
2) Acquired second hand phone with embedded malicious certificate
3) The certificate is installed on an iOS phone in a few seconds if it happens to be in the hands of an attacker (for example, he asked to call)
4) Network equipment with a “good” certificate - here the NSA and everything. In the process of viewing the system certificates were seen certificates from Japan and America. That is, they can conduct MiTM, re-signing their own certificate, and the device does not even “prick” about the attack (and the backdoor is not needed in the crypt). Ours are not there = (

Vulns, bugs, errors, ...

In this section, we will look at what problems exist in the interaction between the client application (in our case, the mobile banking application) and the server.
All the examples cited here are real, we received this information in the process of auditing the security of mobile banking applications.

- No HTTPS (SSL)
No matter how surprisingly it sounded, a year ago we met mobile banking applications in which all communication, including financial transactions, was carried out using the HTTP protocol: authentication, transfer data — everything was open. This means that the attacker, in order to obtain financial gain, needed to simply be with the victim on the same network and have the minimum qualifications. Then, for a successful attack, it was enough to correct the numbers of the target accounts and, if desired, the amount.
As for the interaction of the application with third-party services, compared to last year, the situation has become a little better, but still most of them go for additional information for their operation through an open channel, which can be easily affected by an attacker. This information is usually associated with:
• bank news
• ATM location
• currency exchange rate
• social networks;
• program statistics for developers;
• advertising

At best, the attacker can simply misinform the victim, and at worst, they can inject their own code that runs on the victim's device, which will later help steal authentication data or money. The reason is that the Android OS allows you to load code from the Internet and then execute it. Such a code, the attacker may, under certain circumstances, to introduce into the public channel. Or another situation where the developer transmits the crash dump program through the open channel, and there you can find the username and password from MB and other interesting information.

- Own encryption
This option we also met both in practice and in the research process. Its use is incomprehensible to us, but, according to our assumptions, it may be associated with well-established internal processes of the bank. At the same time, SSL traffic is not additionally wrapped by the developer.
As our practice shows, the use of our own encryption does not lead to good. Sometimes it is not even encryption, but simply its own binary protocol, which, at first glance, seems incomprehensible, encrypted. So after a little manual analysis, MiTM is also possible.

- Incorrect use of SSL
The most common class of errors is the incorrect use of SSL. Most often it is associated with the following reasons:
• Lack of customer test infrastructure
Sometimes a customer cannot, for one reason or another, provide a good test infrastructure. And this leads to the fact that developers have to go to a number of tweaks to verify the correctness of the application.
• developer negligence
This item is partially related to the previous one, and leads to the fact that the development process uses a different debugging code to speed up the testing process. And before the release of the program about this code is forgotten.
• Use of vulnerable frameworks
Often, developers use various frameworks to simplify. In other words, they use someone else's code, the low-level part of which is often hidden and inaccessible. This code also contains vulnerabilities, which developers often do not even guess. This is especially true in light of the active cross-platform development for mobile devices. Example, vulnerability in Appcelerator Titanium or Heartbleed (CVE-2014-0160) in OpenSSL (you can also attack the client - exploit ).
• Developer errors
The developer can use different libraries for working with SSL, each has its own specifics, and it should be taken into account. So, with the transition from the library to the library, the developer can incorrectly use a constant during initialization or override a function with his own.

The main errors when working with SSL:
- Disabling checks (debug API)
- Incorrect redefinition of standard handlers to your own
- Incorrect configuration of API calls
- Weak encryption options
- Using the vulnerable version of the library
- Incorrect handling of call results
- Lack of verification for the host name or the use of incorrect regular expressions for verification

Unconditional classic - disable certificate validation!


Unconditional classic - disable the verification of the host name in the certificate!

Compromise of the root certificate

When using SSL, there is a dependency on root certificates. We can not exclude the possibility of their compromise - remember, for example, the latest incidents with Bit9, DigiNator and Comodo. Do not forget about the certificates of other countries, companies for which traffic can be said to be open.
As already shown, devices have a large number of CA certificates, and if any of them are compromised, almost all SSL traffic for the device is compromised.

If the CA certificate is compromised:
1) User can delete certificate from trusted
a. In the Android OS, the user can do this with both embedded certificates and user certificates.
b. In iOS, a user can only delete user certificates.
2) The OS developer may release an update.
3) The certificate issuer may revoke its certificate. The certificate verification mechanism can dynamically verify this.
a. Android does not support either CRL or OCSP
b. iOS uses OCSP

It is difficult to hope that the user will manage root certificates himself. So the only way is to wait for the OS update. OCSP is not implemented everywhere. The user is vulnerable during the time between compromise and system update.
CA certificates are of different types - more precisely, they can be used for different purposes (mail encryption, code signing, etc.), but they are usually stored in the same secure storage and can be used to verify trust in an HTTPS connection. Unfortunately, the correct verification of the purpose of the certificate is not implemented everywhere. Thus, an attacker can obtain a legitimate certificate from the issuing center for the same purpose, and use a MitM attack to establish an HTTPS connection during the process.
In addition, when the user is working in the browser, he may notice actions with a suspicious certificate on the red padlock icon in the address bar. In the same situation, when working through the application, the user will not be informed in any way, unless the developer has foreseen this in advance, which makes the attack hidden.

SSL pinning

SSL Pinning approach can be used to protect against compromise of root system certificates and specially embedded user certificates.
Pinning is the process of associating a host with its expected X509 certificate or public key. The approach is to embed a certificate or public key, which we trust when interacting with the server, directly into the application and refusing to use the built-in certificate store. As a result, when working with our server, the application will check the validity of the certificate only on the basis of the cryptographic primitive stitched in it.
Applications for MB are great for using SSL Pinning, as developers know exactly which servers will connect to the application, and the list of such servers is small.

SSL Pinning comes in two basic types:
- Certificate Pinning:
o Ease of implementation
o Low approach flexibility
- Public Key Pinning:
o Implementation issues on some platforms
o Good flexibility of approach

Each approach has its pros and cons .
The advantage is also the ability to use:
1) Self-Signed Certificates
2) Private CA-Issued Certificates

To implement SSL Pinning, you must override some standard functions and write your own handlers. It should be noted that SSL Pinning cannot be implemented if you use WebView in Android and UIWebView in iOS due to their specificity.


SSL Pinning Mechanism
App1 to check the validity of the certificate will use only the embedded certificate or public key.
App2 to check the validity of the certificate will go to the system certificate store, where it will sequentially pass through all the certificates.

Using SSL Pinning these days

For the first time, technology has spread widely in Chrome 13 for Google services. Next were Twitter, Cards.io, etc.
Now all mobile app stores (Google Play, App Store, Windows Phone Market) use this approach to work with their devices.

The code for SSL Pinning can now be found on the OWASP website for Android, iOS and .NET. Starting with Android 4.2, SSL Pinning is supported at the system level.

SSL Pinning Bypass

SSL Pinning can be bypassed / disabled if jailbreak or root access is present on the mobile device. As a rule, only researchers need this to analyze network traffic. To turn off on Android, there is the Android SSL Bypass program, for iOS, the iOS SSL Kill Switch and TrustMe programs.
In theory, malware can use these same approaches.

Like any code, SSL Pinning checks may not be implemented correctly, and you should pay attention to this.

Analysis

Enough theory, let's move on to practice and results!
For this study, we used 2 devices: iPhone with iOS 7 and Android with 4.0.3
Of the tools used: Burp, sslsplit, iptables and openssl. Here is a simple set. As you can guess, dynamic analysis was used - just an attempt was made to authenticate with the bank through the application. It's funny that all applications are available for free in stores (Google Play and the App Store), and we do not need registered accounts in all (there are several exceptions) banks! So this experiment can be carried out by anyone with a certain level of knowledge and “straight” hands.

We tested two aspects:
1) How valid is the SSL certificate validation on the client:
- Used self-signed certificate
- Used a certificate issued by a trusted CA to another host name
2) Is SSL Pinning enabled:
- Used CA certificate for this host;

We carried out an active attack "MitM". To do this, we forced the victim to access the Internet through our controlled gateway, which was used to manipulate certificates.
To test the work with self-signed certificates, we generated our own.
To verify the presence of SSL Pinning and the correctness of checking the host name, we generated our own root certificate and installed it on a mobile device.

So, the results:
IOS has 6% of applications, and Android has 11% of applications had their own protocol, and the security of this interaction requires deep manual analysis. From the visual analysis of the traffic, it can be said that it contains both clear, readable data and compressed / encrypted data. Our practice and international experience suggest that, most likely, these applications are vulnerable to the MitM attack.
14% of iOS applications and 15% of Android applications are vulnerable to self-signed certificates. Stealing funds for these applications is only a matter of time.
14% of iOS apps and 23% of Android apps are vulnerable to CA-signed cert hostname. It can also be noted that when checking host names, there may be many verification errors. Due to the fact that this test was performed with only one name, these results can only be considered as the lower limit of the number of vulnerable applications.
It should be said that only one bank has simultaneously a vulnerable application for iOS and Android.
SSL pinning is very rare: in 1% of applications for iOS and in 8% of applications for Android. It is worth noting that, perhaps, this check did not pass for any other reasons not related to SSL pinning, and the percentage of applications using this mechanism is even smaller. We also did not try to circumvent this defense mechanism, did not analyze the correctness of its implementation.

As shown by our experience in analyzing the security of mobile applications, almost always there is code that is responsible for disabling certificate validation. Functions are usually named after Fake *, NonValidating *, TrustAll *, etc. This code is used by developers for test purposes. In this regard, due to the negligence of the developer, the code can get into the final release of the program. Thus, the certificate validity vulnerability can appear in one version and disappear into another, which makes this vulnerability “floating” from version to version. As a result, the security of this code depends on the correctness of the processes organized by the developer.

CONCLUSION

Incorrect work with SSL is just one of the vulnerabilities that leads to the theft of money from the accounts of bank customers. Using other vulnerabilities (sometimes less critical) and their chains, can also lead to financial losses. At the same time, on the server side, too, sometimes all is not well ( ABS sometimes beckons to itself), but this is another story.

PS It should be noted that similar vulnerabilities were found by the author in the process of participating in various BugBounty programs;)
PSS Thanks to Egor Karbutov, Ivan Chalykin, Nikita Kelesis for help in analyzing such a huge number of programs!