MitM attacks on multi-platform banking applications · MitM attacks on multi-platform banking applications ... This attack was not successfully ... MitM attack provide an own DNS

MitM attacks on multi-platform banking applications

Kim van Erkelens, Sharon Gieske, Eric van den Haak

April 6, 2014

1

Abstract

The research described in this paper gives an analysis on the security of themobile applications of the three most important banks in the Netherlands (bymarket shares) on the three most important mobile operating systems (bymarket shares) against Man-in-the-Middle attacks. An analysis has been doneon applications for ING, ABN AMRO and Rabobank on Android, iOS andWindows Phone 8. The research was conducted into two phases. First, awireless access point was set up in order to sniff and analyze the traffic ofthe banking applications. Then, an isolated environment was set up to testthe vulnerability for man in the middle attacks. The environment had to beisolated because communication to the servers of the banks themselves wasnot allowed for legal reasons. From this research can be concluded that thesecurity of the applications partially depends on the platform it is build on,such as the supported cipher suites and TLS versions. In this research a flawin the applications of ING and ABN AMRO on Windows Phone 8 was found.By adding an own root CA to the device, the applications incorrectly validatedcertificates with the same common name as the certificates of the official bankservers and established a secure connection. This attack was not successfullyperformed on the other platforms and for the Windows Phone 8 applicationof Rabobank.

2

Contents

1 Introduction 41.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Focus of research . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . 51.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Related work 6

3 Approach 73.1 Traffic analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Man in the Middle attack . . . . . . . . . . . . . . . . . . . . . 10

4 Traffic inspection 134.1 Platform-specific analysis . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.3 Windows Phone . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Bank-specific analysis . . . . . . . . . . . . . . . . . . . . . . . 15

5 Man in the Middle attacks 175.1 Self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Certificate signed by own root CA (different CN) . . . . . . . . 175.3 Certificate signed by own root CA (same CN) . . . . . . . . . . 18

6 Conclusion 19

7 Appendices 217.1 Supported cipher suites . . . . . . . . . . . . . . . . . . . . . . 21

7.1.1 Server-side . . . . . . . . . . . . . . . . . . . . . . . . . 217.2 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.2.1 Certificate authorities . . . . . . . . . . . . . . . . . . . 217.2.2 ABN AMRO . . . . . . . . . . . . . . . . . . . . . . . . 227.2.3 ING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227.2.4 Rabobank . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3

1 Introduction

In this section an introduction to this research is given. First, the motiva-tion behind this research is described. Then the research question and itssub-questions are proposed, followed by the ethical considerations taken intoaccount while conducting this research. Lastly, important terminology neededfor this research is explained.

1.1 Motivation

There is a substantial number of mobile subscriptions a year. According to theInternational Telecommunication Union [10], the estimate is 6.8 billion mobilesubscriptions worldwide, which is equivalent to 96 percent of the world popu-lation. Gartner [11] forecasts 1 billion smartphones to be sold in 2013. Withthis increase of popularity of smartphone subscriptions, many web services aretransformed to mobile platforms.

A popular financial service for the mobile platform is mobile banking. In2011 the usage of mobile banking applications has rose 74 percent [8]. Mobileservices are valued by users because of their time and place independence,and the overall effort-saving qualities [9]. However, according to a survey [12]conducted by B2B International with Kaspersky Lab in the summer of 2013,almost one third of users do not feel safe making payments through the mobilebanking services on their smartphones.

The aim of this research is to examine the current state of security in mo-bile banking applications that are used in the Netherlands.

1.2 Focus of research

The research question on which is focused in this project is set as: ”Are theING, Rabobank and ABN AMRO applications on Android, iOS and WindowsPhone 8 vulnerable to Man-in-the-middle attacks?”.

The three mobile banking applications analysed in this research are suppliedby the top three Dutch banks with the biggest market share in the Nether-lands, having a combined market share of more than 90 percent [2]. Theanalysed platforms for this research are the three biggest platforms regardingtheir market share. [1] This research focuses on least invasive Man-in-the-middle attacks, which are attacks where no big changes are made to the user’ssmartphone and the application.

In order to answer the research question, the following subquestions will beanswered:

1. What are the differences between platforms in the communication be-tween each application and the bank?

4

2. What are the differences between bank specific applications in the com-munications between each application and bank?

3. Is it possible to start a secure connection with the banking applicationwith incorrect verification?

1.3 Ethical Considerations

We have not asked the banks for permission for this research. Therefore weonly have tested the possibility of performing a MiTM attack without changingany data. Also, we do not intervene in traffic to the banking servers. Theapproach to answer the research question, as described in section 3, made useof an isolated environment, i.e. without any communication to the outsideworld at all.

1.4 Terminology

In this subsection, two important terms for further understanding of the paperare described.

Man-in-the-Middle (MitM) attack: a MitM attack is a technique to vi-olate confidentiality and/or integrity of communication by ’inserting’ a thirdparty on the communication line without the knowledge of the client andserver.

TLS/SSL: Transport Layer Security (TLS), as well as its predecessor SecureSocket Layer (SSL), is a widely deployed security protocol. TLS/SSL connec-tions enforce HTTPS which provide authentication of the website and associ-ated web server that one is communicating with. It also provides bi-directionalencryption of the communication between both parties. Parties are authenti-cated by validating their public key certificates signed by (trusted) certificateauthorities.

Certificate pinning: The security of mobile applications can be increasedby implementing certificate pinning. By integrating certificates into the appli-cation, full control over the certificates to trust is achieved and the applicationis thereby protected against MitM attacks.

5

2 Related work

In this research a Man-in-the-middle (MitM) attack is conducted. In the paperof Welch and Lathrop [14], threats for wireless security are described. Multipleimplementations of this attack are possible, such as MitM using an authen-ticated session underway which is broken and replaced with a session with aman in the middle. With the use of an Address Resolution Protocol attack, itis also possible for a MitM attack to circumvent the authorization mechanism.In research by SMobile Security [4] a MitM attack is successfully conductedon four smartphones through compromised Wi-Fi spots. Research by Chenet al. [3] on MitM attacks on wireless networks describes a mathematicalmodel to analyze Man-in-the-Middle attacks in diverse wireless networks. Inour research, a practical approach using a compromised Wi-Fi spot is takento analyze the vulnerability for MitM attacks in mobile banking applications.

Mobile banking applications often deploy SSL connections to securely commu-nicate between client and server. Several studies have been done in the fieldof SSL security and mobile platforms. Research about Android SSL securityin general is performed by Fahl et al [5]. In this research the tool MalloDroidwas developed which uses static code analysis to detect whether an Androidapplication uses SSL/TLS incorrectly and thus could be vulnerable to MitMattacks. However, to verify this vulnerability, manual auditing is required. Inresearch by Georgiev et al. [6], broken SSL certificate validation is demon-strated in security-critical applications and libraries by exploiting logic errorsin client-side SSL certificate validation. They also found that SSL in mobileapplications is usually implemented through the use of standard libraries pro-vided by mobile SDKs. In their research code analysis is done to uncover theseerrors. Our approach is to directly perform MitM attacks on the applications,without code analysis and auditing.

Security research on the topic of Dutch mobile banking applications has pre-viously been done in another Security of Systems and Networks project. Thisproject focused on the Android application of ABN AMRO which turned outto be vulnerable to MitM attacks [13]. The application did not correctly checkthe validity of the SSL certificate, giving access when using a certificate withan incorrect hostname and a trusted certificate authority. Another researchon mobile banking applications has been done by security expert Floor Terraregarding the ING application on the Android platform. This application alsoshowed to be vulnerable to a MitM attack [15] via incorrect validation of theSSL certificate. In this research, a wider approach will be taken by focusing onmultiple banking applications on three different mobile platforms: Android,iOS and Windows Phone 8.

6

3 Approach

We have decided to split our investigation in two stages, because we wantedto sniff the traffic first before performing a real Man in the Middle attack.In the first stage we will just sniff and analyze the traffic as is, and in thesecond stage we will try to be in the middle and let the banking applicationscommunicate with us instead of the bank. For the latter case, we were notallowed to really be between the bank and our devices, so we had to work onan environment having no internet connection.

Figure 1: Initial approach

Our initial plan was to first use a laptop as an access point. Then for theMitM attack provide an own DNS server which would reroute the traffic forthe banks to our own Dummy server. If we would be able to be in the middle,we then could do this on a live environment. This is however prohibited.

7

3.1 Traffic analysis

For setting up the traffic analysis environment, we used a HP ProBook lap-top. This laptop provides an Ethernet network device and a wireless networkdevice. We also had to decide what operating system we were going to use.Candidates were Windows and Linux.

We considered Windows because last years SSN project was also based onWindows. We could then just use their paper to set up our own environment.On the other hand, our group had a lot of experience with Linux. With ArchLinux (figure 2), the running environment is so minimalistic that you can setthe whole environment to your own hand. Also, all necessary tools are alsoavailable for Linux. With this in mind we decided to use Arch Linux insteadof Windows.

Figure 2: Arch Linux logo

Bridge

To set up the access point, we first made a network bridge with netctl1;

File: /etc/netctl/bridge

-----

Description="Trudy Lan bridge"

Interface=br0

Connection=bridge

BindsToInterfaces=(eth0)

IP=dhcp

-----

We did only connect the eth0 device to the bridge because the wireless accesspoint software should add the wlo1 device to the bridge.

1Arch build in network profile manager

8

Wireless Access point

For the wireless access point we used hostapd. Hostapd is a open sourcesoftware access point for Linux, available in the core repositories of ArchLinux. We used the following configuration (only the changes to the defaultare shown):

File:

/etc/hostapd/hostapd.conf

------

ssid=Trudy Lan

interface=wlo1

bridge=br0

auth_algs=3

channel=7

driver=nl80211

wpa=2

wpa_key_mgmt=WPA-PSK

wpa_pairwise=TKIP CCMP

wpa_passphrase=evelovestrudy

We did secure the environment with a pass-phrase because we did not wantunaware people to use our environment. We then might see traffic we wouldnot want see.

Wireshark

With the bridge and access point running, we used Wireshark (figure 3) tomonitor the traffic on the bridge.

Figure 3: Wireshark logo

9

3.2 Man in the Middle attack

For the MitM attack we based our environment upon the traffic analysis en-vironment. We had to change a few configuration files and install additionalsoftware.

Bridge

Our goal was to provide a closed environment. We had thus no connectionwith the rest of the network and could therefore not rely on the DHCP serveron the LAN. We made some changes to support this;

File: /etc/netctl/bridge_mitm

-----

Description="Trudy Lan MitM bridge"

Interface=br0

Connection=bridge

BindsToInterfaces=(eth0)

IP=static

Address=(139.96.30.101)

Gateway=(139.96.30.101)

DNS=(139.96.30.101)

-----

We made the bridge having a static IP.

DHCP server

As DHCP server we used dhcpd out of the core repository of Arch Linux.With a relatively easy configuration file it worked as expected:

File: /etc/dhcpd.conf

-----

option domain-name-servers 139.96.30.101;

option subnet-mask 255.255.255.0;

option routers 139.96.30.101;

subnet 139.96.30.0 netmask 255.255.255.0 {

range 139.96.30.110 139.96.30.150;

}

-----

10

DNS server

We used BIND as nameserver. BIND was also available in the core repositoryof Arch Linux. In BIND we created a root zone, and made a wildcard A recordwhich pointed to our own IP.

* IN A 139.96.30.101

HTTP webserver

To be able to receive HTTP requests, we have set up our own web server. Weused Apache2 combined with mod php because we have a lot of experiencewith both. Because there is no internet connection, the idea was that everyHTTP(S) request would end up at our own server. We wanted to have asingle script that would be executed for every request, so we could log the fullrequest. We created the following PHP script:

file: index.php

-----

<?php

http_response_code(503); //Service unavailable

// Create a file under /logs and add request data.

file_put_contents("/logs/log-" . time(1),print_r(getallheaders(),1).print_r($_SERVER,1));

// For iOS to be able to connect to the wifi access point, we had to fake a call home.

// Otherwise the iOS device would simply disconnect from the wifi.

// For any other request, print the headers.

if($_SERVER[’REDIRECT_URL’] != ’/library/test/success.html’)

die(print_r(getallheaders(),1));

?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>

<HEAD>

<TITLE>Success</TITLE>

</HEAD>

<BODY>

Success

</BODY>

</HTML>

-----

11

We put this script in the root of the web server, and we enabled SSL with aself signed certificate. To redirect all traffic to this script, we used mod rewriteof Apache.

File: .htaccess

-----

RewriteEngine On

RewriteRule ^.*$ index.php [NC,L]

-----

We now have a full logging webserver, catching all HTTP(S) requests.

Burp Suite

We used Burp Suite as a proxy. This is the only commercial software we haveused. However, there is a free non-commercial version available (http://portswigger.net/burp/).Burp is able to intercept HTTP(S) requests and responses, and allows you tomonitor/modify them. It also supports to add own certificates, which is ex-actly what we were looking for. To make Burp work for every connected client,we had to use iptables to transfer all HTTP(S) traffic from ports 80 and 443to 8080, where Burp was listening.

Rules:

-----

iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080

iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 443 -j REDIRECT --to-ports 8080

-----

We now have a working MitM environment.

12

4 Traffic inspection

The first step of the experiment was gathering information from the trafficbetween the applications and the banks. We were especially interested in thetype of SSL connection and the URL of the bank service in the DNS request.The latest version of each application is used in the experiments. This chapteris divided into two sections. First, we describe the platform specific analysisand then the bank specific analysis.

4.1 Platform-specific analysis

As shown in Table 4.1, the banking applications on Android and WindowsPhone use TLS version 1.0, while iOS uses TLS version 1.2. TLS version 1.0is proven vulnerable to BEAST attacks, in which a java applet is used to hijackbrowsing sessions in order to steal credentials and more. This attack requiresa more invasive MitM attack therefore is not analyzed as a vulnerability inthis research. TLS version 1.0 can also be vulnerable to downgrading attacks,which makes it possible for the attacker to downgrade the communication toSSL version 3 for example.

ABN AMRO ING Rabobank

Android TLSv1 TLSv1 TLSv1

iOS TLSv1.2 TLSv1.2 TLSv1.2

WP8 TLSv1 TLSv1 TLSv1

Table 4.1: TLS versions

4.1.1 Android

This section describes our findings of the traffic inspection regarding the An-droid platform. The experiments are conducted on version 4.1.2. Table 4.2gives an overview of the results for each application. As seen in table 4.1 theapplications on Android platform all use TLS version 1.0. To look up theserver of the bank, all applications create a DNS query for the A and AAAArecords of the server, supporting IPv6.The cipher suites Android 4 offers are a total of 35 different cipher suites,including Elliptic curve diffie–Hellman (ECDH) and Ephemeral elliptic curveDiffie-Hellman (ECDHE) variants. It therefore also has extensions concerningelliptic curves.

13

ABN ING Rabobank

SSL Version TLSv1 TLSv1 TLSv1

Chosen Algorithm 0x0035 0x0035 0x0035

Client Best Algorithm 0x0004 0x0004 0x0004

Client Nr. Algorithms 35 35 35

DNS Lookups A & AAAA A & AAAA A & AAAA

Algorithm table:0x0035 TLS RSA WITH AES 256 CBC SHA0x0004 TLS RSA WITH RC4 128 MD5

Table 4.2: Summary of the traffic inspection findings regarding Android

4.1.2 iOS

This section describes our findings of the traffic inspection regarding the iOSplatform. The experiments are conducted on iOS version 6.0 for ING and ABNAMRO and version 6.1.3 for the Rabobank. Table 4.3 reviews the results foreach application. The most important finding is the consequent use of thenewest TLS version by all the applications.Another notable finding is about the Rabobank application. When it estab-lishes an SSL session with statistiek.rabobank.nl, it first checks the status ofthe certificate with OCSP (Online Certificate Status Protocol). This is not thecase when an SSL session with bankservices.rabobank.nl is established. Fur-thermore, this behavior is only seen with the iOS application of the Rabobank.Before the OCSP check a DNS query lookup for the A-record of EVIntl-ocsp.verisign.com is performed. This returns the CNAME oscp.verisign.netand the IP-address 199.7.52.72.The reason of this behavior can be credited to the use of the iOS TLS securitypolicy in combination with an Extended Validation Certificate. The ABNAMRO application also uses this type of certificate but the traffic does notshow OCSP packets or a DNS lookup for an OCSP server. The applicationprobably uses another policy that does not perform OCSP checking.

14

ABN ING Rabobank

Service www.abnamro.nl services.ing.nl bankservices.rabobank.nlstatistiek.rabobank.nl

EVIntl-ocsp.verisign.com

IP 167.202.214.30 145.221.55.12 145.72.64.63145.72.64.76199.7.52.72

SSL Version TLSv1.2 TLSv1.2 TLSv1.2

Chosen Algorithm 0x0035 0x003d 0x0035

DNS Lookups A A A

Algorithm table:0x0035 TLS RSA WITH AES 256 CBC SHA0x003d TLS RSA WITH AES 256 CBC SHA256

Table 4.3: Summary of the traffic inspection findings regarding iOS

4.1.3 Windows Phone

On Windows phone we have found the following;ABN ING Rabobank

Service www.abnamro.nl services.ing.nl bankservices.rabobank.nl

IP 167.202.214.30 145.221.55.12 145.72.64.63

SSL Version TLSv1 TLSv1 TLSv1

Chosen Algorithm 0x0035 0x0035 0x0035

Client Best Algorithm 0x0035 0x0035 0x0035

Client Nr. Algorithms 24 16 3

DNS Lookups A A AAlgorithm Table

0x0035 TLS RSA WITH AES 256 CBC SHA

Table 4.4: Summary of the traffic inspection findings regarding WindowsPhone

On Windows phone we see that every application uses TLSv1. And eventhough the applications support a variance of cipher suites, they all end upusing the same. Remarkably, the Rabobank application supports only 3 ci-phers. Among them are two flavors of AES and RC4. These are known strongciphers. It is however recommended not to use RC4 anymore. One recom-mended is Microsoft which disabled the cipher in Internet Explorer 11 [7].

15

4.2 Bank-specific analysis

In table 4.5 bank specific information of the applications is displayed. Appli-cations use a bank specific service regardless of their banking platform. Anexception is made for the Rabobank application which uses multiple serviceson the iOS platform, nevertheless the same bank specific primary servicesare used. Also shown are the supported protocols and number of cipher suitesavailable at the server side, revealing a larger support of cipher suites for ABNAMRO.

Bank Service Supported protocols # cipher suites

ABN AMRO www.abnamro.nl TLS 1.2, 1.1, 1.0, SSL 3 10ING services.ing.nl TLS 1.2, 1.0 5Rabobank bankservices.rabobank.nl 2 TLS 1.2, 1.1, 1.0, SSL 3 5

Table 4.5: Protocols & cipher suites

Important to note is that the ING server supports only two protocols, pre-venting a downgrade attack in TSL version 1.0 by not supporting protocolslower than this version. The ABN AMRO and Rabobank servers do supportSSL 3.

As shown in the Appendix 7.1.1 different cipher suites are available per bankserver. All servers have an AES CBC variant chosen for best algorithm. How-ever, ABN AMRO and Rabobank also provide support for RC4 algorithms,which is recommended to not be used anymore [7]. ABN AMRO offers sup-port on more cipher suites using Ephimeral Diffie-Hellman (DHE). The serversonly supports a limited suite and can thereby increase the level of security ofthe communication by only being able to select between the intersection ofsupported ciphers on the client and server side. Supporting only a few goodciphers decreases the size of this intersection and increases the possibility fora good algorithm.

16

5 Man in the Middle attacks

For each bank-platform combination multiple MitM attacks are tried. Thefirst experiment used a self-signed certificate with the same common name(CN) as the original certificates from the banks. The second experiment useda certificate signed by an own root certificate authority (CA) but with a dif-ferent common name. Therefore we had to add the root CA certificate to themobile phones. In the last experiment we used a certificate signed by our rootCA with the same common name as the banks. During the experiments allthe traffic was captured with Wireshark.

The tables within the subsections of this chapter contain our findings. Wehave determined the following values:

Fatal The connection failed and we witnessed a fatal error in the SSL layer

Non-trusted The connection failed without witnessing a fatal error in the SSL layer

Trusted The application trusted us and communicated with us.

5.1 Self-signed certificate

Table 5.1 reviews the results with the self-signed certificates.


Android Fatal Non-trusted Non-trusted

iOS Fatal Fatal Fatal

WP8 Fatal Fatal Non-trusted

Table 5.1: Summary of experimentation server responses with self-signed cer-tificates

The first MitM test we did was with self signed certificates, having the samecommon name as the certificates of the corresponding bank. There was nosingle application that trusted our certificate. Looking at the table, the dif-ferent platforms all had different issues. They at least all had a case in whichwe witnessed a fatal SSL error and a case where the application simply toldus that the service was temporary unavailable. Only for the ABN AMROapplication, we witnessed an SSL error on every platform.

5.2 Certificate signed by own root CA (different CN)


Android non-trusted non-trusted non-trusted

iOS Fatal: Handshake Failure Fatal: Handshake Failure ?

WP8 non-trusted non-trusted non-trusted

Table 5.2: Summary of experimentation server responses with own root CAand different CN

17

The second MitM test was performed using a certificate which has a differentcommon name from the original bank certificate, but which is signed by atrusted root CA. None of the applications trusted the certificate from which wecan conclude the common name is important for validation of the certificate.Platform specific reactions were given, where the reaction of Android andWindows Phone applications was non-trusted, whereas iOS issued a Fatalmessage regarding a handshake failure. Both different reactions resulted in aninoperable application.

5.3 Certificate signed by own root CA (same CN)

The last type of MitM attack we performed used a certificate signed by our rootCA and contained exactly the same common name as the original certificatesof the banks. This experiment resulted in a successful MitM attack on two ofthe WP8 applications: the one from ING and the one from ABN AMRO. Asshown in tabel 5.3 the attacks on the other applications weren’t successful.


Android Non-trusted Non-trusted Non-trusted

iOS Fatal Fatal Fatal

WP8 Trusted Trusted Non-trusted

Table 5.3: Summary of experimentation server responses with own root CAand same CN

The Apache log files as well as the captured traffic are showing that the appli-cations successfully established a session with our server. The requests fromING and ABN AMRO contained the following information:

[SERVER_NAME] => services.ing.nl

[REQUEST_URI] => /mb/authentication/getVariables?profileId=xxxxxxxx-

xxxx&nocache=yyyyyy-yyyyyyy

[SERVER_NAME] => www.abnamro.nl

[REQUEST_URI] => /session/loginchallenge?accountNumber=123456789

&cardNumber=123&accessToolUsage=SOFTTOKEN

Note:Variable values within the request uri’s are obscured for privacy reasons.

By comparing the findings from section 5.2 and 5.3 we can conclude thatthe hostname (CN) is being checked by both ING and ABN AMRO. How-ever, their WP8 applications are both failing in validating the root CA. Thisattack would not have been possible if the applications made use of pinnedcertificates.

18

6 Conclusion

In this section a conclusion to the research sub-questions are given, in orderto answer the research question and give a conclusion of this research.

What are the differences between platforms in the communica-tion between each application and the bank?

The security of the applications partially depends on the platform where theyare built on. Platforms differ in their cipher suites and the TLS versions theysupport. Further, the libraries that are provided for securing communicationplay a role in the security of the applications. It is important that they supportstrong security measures especially for applications used for online banking.We can conclude that the vulnerabilities we have found are platform-specific.Two of the three applications on Windows Phone 8 turned out to be vulner-able to MitM attacks. The cause could be the lack of support for SSL/TLScertificate chain inspection in the WP8 libraries.

What are the differences between bank specific applications inthe communications between each application and bank?

The security of the application also, for a smaller part, depends on the bank-specific implementations with regards to the implementations at the serverside of the bank. The bank servers supply the TLS protocols on which thecommunication channel can be created and the cipher suites supported for theTLS protocols. These values differ per bank. The banks especially have astrong influence on the reduction of the cipher suite choice because the bankservers only support few cipher suites. Supporting only a few good ciphersuites can increase security in terms of downgrade attacks on cipher suites.There are no vulnerabilities found for MitM attacks regarding bank-specificfeature.

Is it possible to start a secure connection with the banking applica-tion with incorrect verification?

We have found that all banking applications are secured via SSL/TLS. Wehave also found that the implementations of SSL/TLS on Windows phone forthe ING and ABN AMRO applications have a small flaw. In our experimentswe were able to add our own root certificate authority onto the device andsign our own ING and ABN AMRO certificates, which the applications trusts(the applications have no pinned certificates). Our conclusion is thus that itis possible to start a secure connection with incorrect verification on WindowsPhone 8 for ING and ABN AMRO, as long as someone is able to install a rootCA on the device.

19

Are the ING, Rabobank and ABN AMRO applications on Android,iOS and Windows Phone 8 vulnerable to Man-in-the-middle at-tacks?

We have found that the ING and ABN AMRO applications of Windows Phoneare vulnerable to platform-specific MitM attacks due to incorrect verification,created when a trusted root CA is added to the device. A solution for theseincorrect verifications is certificate pinning.

20

7 Appendices

7.1 Supported cipher suites

7.1.1 Server-side

ABN AMRO (10):

1. TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256

2. TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168

3. TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)

(DH 1024 bits (p: 128, g: 1, Ys: 128) FS) 256

4. TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)

(DH 1024 bits (p: 128, g: 1, Ys: 128) FS) 168

5. TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256

6. TLS_RSA_WITH_RC4_128_MD5 (0x4) 128

7. TLS_RSA_WITH_RC4_128_SHA (0x5) 128

8. TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128

9. TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)

(DH 1024 bits (p: 128, g: 1, Ys: 128) FS) 128

10. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)

ING (5):

1. TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256

2. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128




Rabobank (5):




4. TLS_RSA_WITH_RC4_128_SHA (0x5) 128

5. TLS_RSA_WITH_RC4_128_MD5 (0x4) 128

7.2 Certificates

7.2.1 Certificate authorities

id value

commonName VeriSign Class 3 Extended Validation SSL SGC CorganizationalUnitName VeriSign Trust NetworkorganizationName VeriSign, Inc.

Table 7.1: VeriSign Class 3 Extended Validation SSL SGC C

21

id value

commonName VeriSign Class 3 International Server CAorganizationalUnitName VeriSign Trust NetworkorganizationName VeriSign, Inc.

Table 7.2: VeriSign Class 3 International Server CA

Both signed by VeriSign Class 3 Public Primary Certification:

id value

commonName VeriSign Class 3 Public Primary CertificationorganizationalUnitName VeriSign Trust NetworkorganizationName VeriSign, Inc.

7.2.2 ABN AMRO

id value

commonName www.abnamro.nlorganizationalUnitName Internet BankingorganizationName ABN AMRO Bank N.V.localityName AmsterdamstateOrProvinceName Noord-HollandcountryName NL

Table 7.3: www.abnamro.nl

Signed by VeriSign Class 3 Extended Validation SSL SGC C

7.2.3 ING

id value

commonName services.ing.nlorganizationalUnitName VeriSign Trust NetworkorganizationName VeriSign, Inc.localityName Amsterdam ZuidooststateOrProvinceName Noord-HollandcountryName NL

Table 7.4: services.ing.nl

Signed by VeriSign Class 3 International Server CA - G3.

22

7.2.4 Rabobank

id value

commonName bankservices.rabobank.nlorganizationalUnitName Name IT btorganizationName Rabobank NederlandlocalityName UtrechtstateOrProvinceName UtrechtcountryName NL

Table 7.5: bankservices.rabobank.nl

Signed by VeriSign Class 3 Secure Server CA - G3.

id value

commonName statistiek.rabobank.nlorganizationalUnitName Name IT btorganizationName Rabobank NederlandlocalityName UtrechtstateOrProvinceName UtrechtcountryName NL

Table 7.6: statistiek.rabobank.nl

Signed by VeriSign Class 3 Extended Validation SSL SGC C

7.3 Contribution

Kim van Erkelens Report, Setting up Phones and Environment, Traffic analysis

Sharon Gieske Report, Related works, Setting up Environment, Traffic analysis

Eric van den Haak Report, Requesting bank account, Setting up environment, Traffic analysis

References

[1] Android and iOS Combine for 92.3% of All Smartphone Operating Sys-tem Shipments in the First Quarter While Windows Phone LeapfrogsBlackBerry, According to IDC (Press Release). url: http://www.idc.com/getdoc.jsp?containerId=prUS24108913 (visited on 12/12/2013).

[2] Banken.nl. Nederlandse bankensector. url: http://www.banken.nl/bankensector/bankensector-nederland (visited on 12/13/2013).

[3] Zhe Chen et al. “Modeling of man-in-the-middle attack in the wirelessnetworks”. In: Wireless Communications, Networking and Mobile Com-puting, 2007. WiCom 2007. International Conference on. IEEE. 2007,pp. 2255–2258.

23

[4] Dancho Danchev. Man-in-the-middle attacks demoed on 4 smartphones.2009. url: http://www.zdnet.com/blog/security/man-in-the-middle-attacks-demoed-on-4-smartphones/4922 (visited on 11/21/2013).

[5] Sascha Fahl et al. “Why Eve and Mallory love Android: An analysis ofAndroid SSL (in) security”. In: Proceedings of the 2012 ACM conferenceon Computer and communications security. ACM. 2012, pp. 50–61.

[6] Martin Georgiev et al. “The most dangerous code in the world: vali-dating SSL certificates in non-browser software”. In: Proceedings of the2012 ACM conference on Computer and communications security. ACM.2012, pp. 38–49.

[7] IE11 Automatically Makes Over 40Making Sure Sites Continue to Work.2013. url: http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-

while- making- sure- sites- continue- to- work.aspx (visited on11/12/2013).

[8] Sarah Lenart Nathan Frederiksen. “2011 State of Online and MobileBanking”. In: (2012). url: http://www.comscore.com/OnlineBanking.

[9] Mari Suoranta. Adoption of mobile banking in Finland. Jyvaskylan yliopisto,2003.

[10] ITU Telecommunication. ICT facts and figures. 2013. url: http://www.itu.int/en/ITU-D/Statistics/Documents/facts/ICTFactsFigures2013.

pdf.

[11] Gartner Says Worldwide Mobile Phone Sales Declined 1.7 Percent in2012 (Press Release). 2013. url: http://www.gartner.com/newsroom/id/2335616 (visited on 11/21/2013).

[12] “Security in a multi-device world: the customer’s point of view”. In:Kasperky Lab (2013).

[13] Bas Vlaszaty Thijs Houtenbos Jurgen Kloosterman and Javy de Koning.Security in mobile banking. Tech. rep. System & Network Engineering,University of Amsterdam, 2012.

[14] Donald Welch and Scott Lathrop. “Wireless security threat taxonomy”.In: Information Assurance Workshop, 2003. IEEE Systems, Man andCybernetics Society. IEEE. 2003, pp. 76–83.

[15] Arnoud Wokke. Mobielbankieren-app ING controleerde ssl-certificaat bankniet. 2012. url: http://tweakers.net/nieuws/80816/mobielbankieren-app-ing-controleerde-ssl-certificaat-bank-niet.html.

24