Content uploaded by Diego F. Aranha
Author content
All content in this area was uploaded by Diego F. Aranha on Aug 16, 2022
Content may be subject to copyright.
Security Analysis of Brazilian Mobile Banking Apps on Android
Rafael J. Cruz, Isabela Cota, Diego F. Aranha
Institute of Computing - University of Campinas
raju@lasca.ic.unicamp.br , isabelacota@gmail.com ,
dfaranha@ic.unicamp.br
Abstract. We present a security analysis of eight Brazilian mobile banking applications in the
Android platform, spanning 30 months. The scope included security aspects of the application,
server configuration, and connection between app and server. We demonstrate server
impersonation attacks against most banks, allowing an attacker to obtain sensitive data.
1. Introduction
The SSL/TLS protocol is the standard communication protocol to establish secure connections
through the Internet, but care must be taken during its deployment. In particular, financial
institutions, given the critical nature of their business, should implement best security practices,
monitor upcoming attacks, replace obsolete cryptographic algorithms and frequently deploy new
security measures. These steps are essential to resist against increasingly sophisticated
attacks. Due to their potential profitability, attacks against banking systems are intrinsically
adaptative and improve as soon as new attack vectors become available.
According to the Brazilian Banking Federation, mobile banking using tablets and smartphones is
already the favorite way to perform banking transactions in Brazil, reaching 34% of the total
number of transactions [1]. There is ample space for growth, since only around 20% of the
clients interact with their banks using a mobile device. According to the same institution, the
total amount of losses due to electronic fraud reached 1.8 billion R$ in 2015, with the security
investment reaching 2 billion [2]. The main factors contributing to these losses are credential
stealing and other types of Internet attacks, and credit card cloning and skimming.
This paper updates and extends a security analysis of Android apps from the largest banks in
Brazil [3]. Our effort started in May 2015, by focusing the analysis on client-side security of
mobile banking. The scope of analysis includes some security aspects of the banking apps, the
configuration of the server responding client requests, and the connection between app and
server. At the time, we showed how attackers under control of the networking infrastructure
could mount server impersonation attacks to capture credentials and sensitive financial
information in multiple scenarios. We also detected several flaws in deployed server
configurations and other questionable design decisions involving integration with social
networks, biometric identification and flawed second-layer protocols. Our findings are here
reported from a historical perspective, partially capturing the evolution of mobile banking
security in Brazil for the past 3 years.
This is not the first analysis of its kind. A recent paper by Clothia et al. [4] presents a security
review of the mobile apps provided by leading banks in the UK. They reach similar conclusions,
with several apps vulnerable to man-in-the-middle attacks for credential stealing and in-app
phishing attacks. Compared to their analysis, our scope is broader, because we also scanned
servers for insecure SSL/TLS configurations with obsolete algorithms and deprecated protocol
versions. Major advantages of the approach adopted in both works is to remove the need of
privileged access to infrastructure, allowing analysis to be completely independent, and to better
capture security threats faced by users instead of the banking institution.
In another recent paper, Reavers et al. [5] perform a security analysis of branchless mobile
banking applications in developing countries. Branchless banking is a very interesting space,
because many of the companies are recently-founded startups, presumably without
consolidated security practices. Although the research goal of the authors is different than ours,
in the sense that branchless banking has a different but overlapping attack surface, both studies
find similar security issues in certificate validation and insecure TLS configurations. Their
in-depth analysis spends most of the effort in code inspection after decompilation and reverse
engineering of the selected applications, finding severe issues with authentication mechanisms.
The authors repeated the analysis one year later, essentially reaching the same conclusions [6].
While our analysis on traditional banks is more automated and spans a longer timeframe, we
observe in contrast a significant improvement in security practices employed in the analyzed
mobile banking applications.
The paper is organized as follows. Section 2 gives background information on the SSL/TLS
protocol and some of the main attacks attempting to violate its security properties. Section 3
explains out methodology, while Section 4 presents experimental results with discussion. In
Section 5, we briefly discuss the disclosure process, and Section 6 summarizes the evolution of
results for 30 months after the initial analysis. Section 7 concludes the paper.
2. Background
This section summarizes the main characteristics of the SSL/TLS protocol, how attacks on the
link layer can be used to mount man-in-the-middle attacks against the protocol, and
recommended security practices within is scope.
2.1 The SSL/TLS Protocol
The first version of the Secure Sockets Layer (SSL) protocol was conceived in 1994 by
Netscape, with the first public version (2.0) released in the following year. The initial objective of
the protocol was to establish a secure connection between two parties, with security goals
aligned to the classical properties of confidentiality, integrity, authenticity and nonrepudiation. In
other words, data transported by the protocol should only be accessed by authorized parties,
and the protocol produces evidence of participation by non-repudiable digital signatures. In
addition, the protocol should be light and its mechanisms should not be abused to waste
resources in either end of the communicating parties, as to meet availability requirements.
After several changes to fix major flaws, Netscape published the redesigned 3.0 version of the
protocol in 1996. The next version included more improvements and broke interoperability with
SSL, being renamed to Transport Layer Security (TLS) 1.0, with control transferred to an open
community, the Internet Engineering Task Force (IETF). As expected, the SSL/TLS protocol
soon found application to e-commerce and other financial systems, quickly becoming a
fundamental part of Internet infrastructure. The protocol implements a secure transport layer on
top of TCP, through a combination of 4 main subprotocols [7]:
1. Handshake protocol : negotiates the session information between client and server, such
as the protocol version, session identifier, cipher suite to be used, and data compression
method. The handshake also exchanges public key certificates and encrypted random
bytes to generate shared session keys.
2. Cipher Change Protocol : finishes the handshake and signals the transition to encrypted
communication using the Record protocol .
3. Record Protocol: handles the proper transport functionalities of the protocol, by
encrypting and authenticating data packets using the shared session keys.
4. Alert Protocol: indicates state transitions and error conditions between the
communicating parties. Examples of alerts are when invalid messages are received or
the connection is closed.
The handshake portion of the protocol is critical to security. It specifies all the security
parameters at the beginning of the communication and achieves mutual authentication between
the client and server. Authentication is usually implemented through public key certificates
provided by certificate authorities (CAs). In simple terms, a certificate includes identifying
information binding the certificate to a specified hostname and issuer, the validity period, and a
digital signature computed by the CA. For authentication, the server (and optionally the client)
transmits signed certificates so that the other party can build and verify a chain of trust to one of
the trusted root CAs. The root self-signed certificates are typically selected and preinstalled in
the operating system, but users can usually override this setting and include their own trusted
root certificates.
2.2 Best practices for deployment
In order to achieve the security properties expected from the SSL/TLS protocol, both clients and
servers must implement a set of recommended best practices. For example, client applications
need to carefully validate the server certificate to be sure that they are communicating with the
legitimate party, by following the steps below:
1. Validade that the server certificate is signed by the previous one in the chain, and in
sequence until a trusted root certificate is found.
2. Verify that the certificate matches the server hostname.
3. Verify the current date is within the validity period, so that server certificate is not
expired.
4. Verify that the server certificate is not revocated, by checking it against Certificate
Revocation Lists (CRLs) or an Online Certificate Status Protocol (OCSP) service.
An inherent weakness of the protocol is that the CA certificate store must be trusted, otherwise
an attacker can coerce the user or directly introduce a malicious root certificate to impersonate
servers afterwards. To prevent this, connecting clients should also verify that certificate pinning
is in place [8]. Certificate pinning is possible when the server hostname and expected certificate
are known in advance, and implemented by equipping the client with information about the
certificate, such as the intermediate certificate chain, the server public key or its fingerprint
(hash value). This technique binds the certificate validation to a single trusted root certificate.
Bundling the intermediate chain together with a mobile application is a particularly elegant way
of deploying certificate pinning because it works when the server certificate is renewed, as long
as with the same CA. A standard way of implementing certificate pinning in the HTTP protocol
using a “trust on first use” model was the HTTP Public Key Pinning (HPKP) extension, recently
deprecated in favor of Certificate Transparency (CT) [9], an open framework for monitoring and
auditing SSL certificates in nearly real time. Mobile application scenarios prevent the many
issues around HTTP certificate pinning and consist of an ideal application of the technique,
because usually the same institution is in control of both the client and server applications.
Server deployments must also implement several recommended practices:
1. Support Perfect Forward Secrecy : ephemeral public key pairs are generated at the start
of the handshake protocols and authenticated using the long-term public keys contained
in certificates. The advantage of this optional feature is restricting the impact of a
compromise in the CA infrastructure or the long-term server private keys to
authentication only. This way, the confidentiality of past communications is preserved
even in case of a severe security breach.
2. Update cipher suites : servers should be configured as to remove obsolete cryptographic
algorithms, such as the insecure MD5 and SHA1 hash functions and the RC4 stream
cipher. Disabling outdated algorithms at the server side may break compatibility with
older client applications, but at the same time prevent insecure algorithms do be used.
3. Validate certificates: when optional client certificates are used for mutual authentication,
validation must be as rigorous as in the case of server certificates. The server should
also provide an OCSP service to help clients verify the server certificate.
4. Update protocol version: older versions of the SSL/TLS protocol are deprecated and
should not be enabled in the server configuration or implementation. This might again
break compatibility with older client applications, but protect the connection against
attacks such as exploiting insecure choice of initialization vectors (BEAST), traffic
compression (CRIME AND BREACH), padding oracles to recover plaintext (POODLE)
and timing side-channel leakage (LUCKY 13) [10,11]. Downgrade attacks forcing the
client to use insecure key sizes against RSA (FREAK) and Diffie-Hellman (Logjam) are
also very relevant [12].
2.3 Man-in-the-middle attacks
A man-in-the-middle (MITM) attack aims to intercept all data exchanged between parties in a
session. The attack can be mounted by any compromised intermediate note in the connection
(router, proxy, DNS server), but in this work we assume a malicious computer connected to the
same local network as the client. This way, the attacker may be able to impersonate the server
by presenting a fake certificate to hijack the SSL/TLS connection. Traffic between the legitimate
client and the router can be directed to the malicious computer by forging Address Resolution
Protocol (ARP) responses in a classical spoofing attack. After successfully intercepting the
connection, the attacker establishes two session keys with each communicating party, and thus
becomes able to arbitrarily read or manipulate contents encrypted under those keys.
Preventing the undue interference of intermediate nodes requires a suitable implementation and
deployment of the SSL/TLS protocol, satisfying best practices such that the end-to-end security
properties of the protocol are established between legitimate client and server. Notice that the
attacker may be able to influence the users to install a malicious root certificate. The
corresponding private key can then be used later to sign fake certificates which will be validated
without problem by a client not implementing certificate pinning.
Figure 1 below illustrates the attack. Blue arrows represent a legitimate connection between
client and server. An attacker in the same local network attempts to hijack this connection by
establishing two different ones, and thus read and manipulate traffic. The client may be able to
detect the attack by verifying the server certificate with a CA, but the attacker is able to
circumvent this verification if a fake root certificate is installed in the client machine.
Figure 1. Man-in-the-middle (MITM) attacks mounted by attacker (C) against client (A) and
server (B) in the same local network. A proper use of the CA can stop the attack.
3. Methodology
Our attack environment supposed an Android smartphone connected to a wireless local
network, where a malicious computer is also present. Links for all tools used in the methodology
can be found in our repository [13]. For each mobile application, our analysis methodology
consisted in three main steps:
1. Code analysis and server identification:
a. Capture the server hostnames servicing the mobile banking application, with help
of Wireshark. Some banks have multiple hostnames servicing the same
application.
b. Download the mobile applications in the APK format by using APK Downloader .
c. Decompile the apps using dex2jar to transform the DEX file inside the APK file
into a JAR file, and JD-GUI to obtain JAVA source code.
d. Run the mobile applications with the Android Device Monitor attached to inspect
logging messages during the interaction with the application.
2. Man-in-the-middle attack with and without a malicious root certificate installed:
a. Redirect the traffic between smartphone and wireless router to the malicious
computer. The arpspoof tool was employed to forge responses to ARP resolution
queries.
b. Generate a fake root certificate using OpenSSL.
c. Control SSL/TLS traffic using SSLsplit with the fake root certificate. The
certificate could either be presented as the self-signed server certificate or
optionally installed in the smartphone, in a way that certificates forged by the
malicious computer would be considered valid.
3. Inspection of server configuration in identified server hostnames:
a. Scan server configurations corresponding to the hostnames using the Qualys
SSL Labs tool. The initial scans were performed on a weekly basis, to prevent
temporary configuration artifacts from affecting our results. After we observed
that results were stable across time, we increased the length between scans.
b. Analyze the results and collect most important metrics.
The whole analysis was repeated five times, starting in May 2015. That was the only time we
were able to perform code inspection in decompiled code, due to its time-consuming nature. A
follow-up analysis restricted to the more automated tasks was performed in August, a few
months later, to verify if the issues were solved or mitigated. In 2016, we repeated the analysis
once more in June to capture long-term trends. We ran the analysis again in 2017, in May and
November, as preparation for this work.
4. Experimental results and discussion
We split the analyses in server-side and client-side security, and later discuss results for each
bank individually. Data collection and archived applications are available in our repository [13].
4.1 Server-side security (SSL/TLS configuration)
Following our methodology, the initial results for security of server configurations can be found in
Table 1, corresponding to the first scan in May 2015. We highlight several characteristics that
summarize the quality of a server-side SSL/TLS deployment: (i) support to specific versions of
the protocol; (ii) support to insecure algorithms in the cipher suite or certificate signatures, such
as RC4, the MD5 or SHA1 hash functions; (iii) vulnerability against the Logjam, FREAK or
POODLE attacks; (iv) vulnerability against protocol version downgrade or Denial of Service
(DoS) renegotiation attacks; (v) support to forward secrecy. The scores were assigned by SSL
Labs, according to their criteria. Notice that some banking applications employ multiple
hostnames for different services. For example, Bradesco has two hostnames to service the
mobile application, and HSBC had three different ones. In a deeper analysis, we found out that
HSBC used a global hostname to index country-level hostnames, another one for providing
general services and a national one for the actual financial transactions. This is why multiple
scores are reported for the same bank in the last column of the table.
Table 1 . Results for security analysis of server configuration using scores from the Qualys SSL
Labs tool as of May 2015, with specific characteristics highlighted.
Banco do
Brasil
Bradesco
Caixa
Econômica
Federal
Citibank
HSBC
Itaú
Unibanco
Santander
Supported SSL/TLS
versions
TLS 1.0
SSL 3.0
TLS 1.0
SSL 2/3
TLS 1.0/1.2
SSL 3.0
TLS 1.0
TLS 1.0-1.2
SSL 3.0
TLS 1.0-1.2
SSL 3.0
TLS 1.0
SSL 3.0
Supported weak algorithms
RC4/MD5
/SHA1
RC4/MD5/
SHA1
RC4/SHA1
SHA1
SHA1
RC4/SHA1
RC4/SHA1
Vulnerable to Logjam
✔
✘
✘
✘
✘
✘
✘
Vulnerable to FREAK
✔
✔
✘
✘
✘
✘
✘
Vulnerable to POODLE
✔
✔
✔
✔
✔
✔
✘
Vulnerable to Downgrade
✔
✔
✘
✘
✔
✔
✔
Vulnerable to DoS
✘
✘
✔
✔
✘
✘
✘
Forward Secrecy supported
✘
✘
✘
✘
✘
✘
✘
Score
F
F, F
C
C
C, A-,A-
F
C
4.2 Client-side security (resistance against MITM)
After assembling the local network and performing the man-in-the-middle attacks, results
regarding client-side security were collected and can be found in Table 2, with scores assigned
as follows. Applications not vulnerable to plain MITM attacks scored 3 points, as this is a simpler
attack not requiring access to client devices, and prevented by implementing proper client-side
validation of server certificates. Applications not vulnerable to MITM attacks using fake root
certificates installed in the device scored 2 points, as this attack is more involved and requires
installing a fake root certificate in the device. Applications not leaking authentication credentials
scored 2 points, because this is a direct consequence of the effectiveness of MITM attacks. We
added a separate criteria for applications not leaking financial information, since captured traffic
may have different content than just credentials. Our last criteria partially represented the extent
of attack surface, and applications not integrated with social networks were rewarded 1
additional point. Integrating mobile banking applications with social networks has two problems:
privacy issues when financial information leaks through the integration interface; violation of
defense-in-depth, when vulnerabilities in the social network may impact the mobile application.
Implementing certificate pinning directly affects resistance against our man-in-the-middle
attacks, so this property appears highlighted in the table, but does not provide scoring points. In
summary, resistance against main-in-the-middle attacks (using a fake root certificate or not)
amount to 5 points in our scoring criteria, while leakage of sensitive information under these
attacks amount to 2 points. The simple scoring criteria was designed to capture how critical the
vulnerabilities are, and difficulties imposed to the attacker. Scores between 0 and 10 were
converted to the interval between F and A+ according to the grading adopted by Qualys SSL
Labs, to facilitate comparisons with server results.
Table 2 . Results for client-side security as of May 2015, considering resistance against plain
MITM attacks or when using maliciously installed root certificates, and what information is
disclosed in captured traffic.
Banco
do Brasil
Bradesco
Caixa
Econômica
Federal
Citibank
HSBC
Itaú
Unibanco
Santander
Application version
6.5.0.7
2.9.6
1.3.3
9.0
1.5.10.0
4.1.5
4.4.0
Secure against plain MITM
✔
✔
✔
✔
✔
✔
✘
Secure against MITM with root cert
✔
✘
✘
✘
✘
✘
✘
Credentials are not leaked
✔
✘
✘
✘
✔
✘
✘
Financial information is not leaked
✔
✘
✘
✘
✘
✘
✘
No integration with external social
networks
✔
✘
✔
✘
✔
✘
✔
Employs certificate pinning
✔
✘
✘
✘
✘
✘
✘
Score
A+
E
D
E
C
E
F
4.3 Discussion
Below we collect some observations for each combination of mobile application and server
under the scope of the analysis.
Banco do Brasil: the mobile application employed certificate pinning by storing the
intermediate certification verification chain, isolating the application from the root certificate store
installed in the device. This is a particularly elegant implementation of pinning, because it works
as long as the certificate issuer is not changed. Proper pinning prevented the types of MITM
attacks we evaluated in this work. The application had a sort of internal social network for users,
but as far as we have inspected, there was no integration with external social networks, which is
why it received the maximum score. However, server-side configuration still allowed obsolete
SSL 3.0 clients and insecure algorithms. Newer versions of the protocol, such as TLS 1.1 and
1.2 were disabled on server side.
Bradesco: the combination of application and servers were very vulnerable, and only resisted
against plain MITM attacks. No certificate pinning was implemented and the server had
compatibility with very old versions of the SSL protocol, such as 3.0 and 2.0. The server
configuration also allowed insecure algorithms, POODLE, FREAK and protocol downgrade
attacks. The codebase included references to social networks, but it was not clear if actually
used in the application.
Decompilation of the Bradesco mobile application also unveiled an additional vulnerability in the
optional biometric identification system. After the user turns on this functionality, authentication
credentials (branch, account number and password) are cached in an encrypted file stored in
the device. Enrolled fingerprints are compressed and stored as 32-bit integer numbers
encrypted in the same file, so biometric identification amounts to comparing the 32-bit integer of
the presented fingerprint with the previously enrolled one. The application decrypts the file and,
in case of success in the comparison, the password is later decrypted to perform transactions
under the recovered credentials. The problems we found with this mechanism were the small
space of fingerprints caused by the 32-bit limitation, and the fact that the credential file was
encrypted with a fixed key computed as the SHA1 hash of string “ Varejo ” (Retail in Portuguese).
An attacker obtaining a used smartphone could be able to extract the credentials by just
knowing this encryption key to perform transactions on behalf of the user. More information
about this security vulnerability can be found in [14].
Caixa Econômica Federal: the application did not employ certificate pinning, as in the case of
Bradesco. The server still supported SSL 3.0 and the lack of secure renegotiation allowed a
DoS attack. Another potential security problem we observed in the reverse engineering portion
was the excess of client-side JavaScript, which may allow code injection attacks to perhaps
divert the original functionality of the mobile application.
Citibank: the application only provided resistance against plain MITM attacks, not protecting
against a fake root certificate. Credentials and financial information were visible in the captured
traffic. The lack of secure renegotiation allowed DoS attacks, and the server was vulnerable to
the TLS 1.0 variant of the POODLE attack.
HSBC: the mobile application did not implement certificate pinning and was thus vulnerable
against MITM attacks with a root certificate installed. However, credentials were not found in the
captured traffic, because they were encrypted under an off-band key negotiated between the
mobile application and backend during the enrollment process of a mobile device at the ATM.
Financial information was still leaked in the captured traffic and, because MITM attacks can also
be active and manipulate traffic, certificate pinning must be implemented. The server
configuration was among the best we observed, with only some of the hostnames vulnerable
against POODLE and protocol downgrade attacks.
Itaú Unibanco: resistance against MITM attacks was restricted to the plain case. The server
supported SSL 3.0 and insecure algorithms, such as RC4 and SHA1, and was found to be
vulnerable against POODLE and protocol downgrade attacks.
Santander: the mobile application was found vulnerable against even plain MITM attacks, due
to insufficient validation of the server certificate. On close inspection, we also found that the
second layer protocol transported by SSL/TLS had an additional handshake, perhaps to
mitigate the potential of MITM attacks against SSL/TLS. In the new handshake, the server
transmits a 2048-bit RSA key used by the client to encrypt an ephemeral 1024-bit RSA key,
renewed at each connection. The server encrypts the session key under the client's ephemeral
key. By reverse engineering the decompiled application, we found that the second layer protocol
does not authenticate public keys, being also vulnerable against MITM attacks. It would be of
course preferable to deploy SSL/TLS with adequate protection against MITM attacks than
stacking up two layers of protocols with a vulnerable handshake. The server also supported
SSL 3.0 with a mitigation against POODLE, and weak algorithms such as RC4 and SHA1.
5. Disclosure process
We initiated disclosure of the vulnerabilities to the affected parties between 4PM and 5 PM of
May 26, 2015. The disclosure process started by looking for contact information in the website
of each bank and sending a template message. Not all banks responded, but for the ones who
did, we requested a secure channel to submit our report. We followed with contact through the
telephone for the ones not responding. The secure channel could be a specific contact form or a
PGP public key. We took notes of date, time and tracking numbers to be able to prove later that
disclosure was attempted.
Most of the banks did not seem prepared to receive a vulnerability notification. Santander asked
us to send the report unencrypted through e-mail, Banco do Brasil and Itaú Unibanco suggested
the only way to have a secure channel would be delivering a physical copy of the report in one
of the nearby branches. HSBC quickly responded with an e-mail acknowledgement, and CAIXA
with a PGP key. Bradesco responded our initial contact e-mail with an invitation for an on-site
meeting. Citibank only replied with automated e-mails and refused to register a complaint over
the telephone because we were not customers. We could contact Itaú Unibanco later by
obtaining the e-mail address of a member of the technical team from a colleague professor. We
also found out later that HSBC did not process our notification, despite the acknowledgement,
until they were contacted by the press.
Because of all the problems contacting the banks, we only considered that initial disclosure was
successful after our research was covered in the mainstream press on August 10, 2015, since
all banks had to provide formal statements on our research results [15].
6. Evolution
We repeated the portions of our analysis not involving reverse engineering four more times,
starting with August 2015, to verify if the issues were solved or mitigated by app developers and
server administrators. In 2016, we repeated the analysis once more in June. We ran the
analysis again in May and November of 2017 as preparation for this work. Since the Brazilian
operation of HSBC was acquired in 2017 by Bradesco, we included the branchless banking
application Nubank as a replacement.
Figure 2 presents the evolution of scores assigned by Qualys SSL Labs along the consecutive
analyses. For banks responding through multiple hostnames, we computed an average among
the multiple scores. There is a clear trend of improving the scores after our initial disclosure and
most banks currently satisfy minimum security requirements for their SSL/TLS deployments.
Nubank is an interesting example, in which the SSL/TLS deployment is outsourced to a
specialized company implementing best practices, explaining the consistently high grades.
Figure 2. Evolution of scores for server-side security
Table 3 presents the most up-to-date results of the server configuration analysis. We observe
clear progress in the supported SSL/TLS versions, with only two banks supporting SSL 3.0,
although no bank supports the upcoming TLS 1.3 standard. One of the Bradesco hostnames is
still vulnerable against POODLE and protocol downgrade attacks, so the threat of obsolete and
insecure versions of the protocol still exists. There was also progress in the set of supported
cipher suites and hash functions for authentication, with the prevalence of the RC4 and MD5
algorithms decreasing. Most configurations were also not vulnerable against the Logjam,
FREAK and POODLE attacks. Forward secrecy is now supported across all banks. With the
exception of CAIXA, all CAs issuing server certificates support the Certificate Transparency
model [9], which may facilitate client-side implementations of certificate validation.
Table 3. Results for security analysis of server configuration using scores from the Qualys SSL
Labs tool as of November 2017, with specific characteristics highlighted.
Banco do
Brasil
Bradesco
Caixa
Econômica
Federal
Citibank
Itaú
Unibanco
Santander
Nubank
Supported SSL/TLS versions
SSL 3.0
TLS 1.0-1.2
TLS
1.0-1.2
SSL 3.0
TLS 1.0-1.2
TLS
1.0-1.2
TLS
1.0-1.2
TLS
1.0-1.2
TLS
1.0-1.2
Supported weak algorithms
RC4/SHA1/
SHA1
RC4/SHA1/
SHA1
SHA1
SHA1
SHA1
MD5
MD5
Vulnerable to Logjam
✘
✘
✔
✘
✘
✘
✘
Vulnerable to FREAK
✘
✘
✘
✘
✘
✘
✘
Vulnerable to POODLE
✘
✔
✘
✘
✘
✘
✘
Vulnerable to Downgrade
✘
✔
✔
✘
✘
✘
✘
Vulnerable to DoS
✘
✘
✘
✘
✘
✘
✘
Forward Secrecy supported
✔
✔
✔
✔
✔
✔
✔
Certificate Transparency
✔
✔
✘
✔
✔
✔
✔
Score
C
B,A,A,F
A,C
A,A-
A,A-
B,A
A
Figure 3 presents the progression of client-side security results in terms of MITM attacks. Banco
do Brasil, the highest-ranking mobile application in 2015, still holds the top spot. Itaú Unibanco
reached the maximum score after implementing certificate pinning and discontinuing its
integration with external social networks. Nubank and CAIXA implemented certificate pinning
sometime in mid-2017, also reaching a high score in the latest result. The Santander mobile
application is a very interesting example, contradicting the popular notion that systems get
monotonically more secure with time. Our analysis detected two attempts of implementing
certificate pinning, one after May 2015 and another after June 2016, but the first one was
reverted back during the migration from the 4.x to the 5.x versions of the mobile application.
Table 4 presents the latest results in more detail, with the specific versions analyzed. All banks
currently protect against plain MITM attacks and most adequately implement certificate pinning.
Bradesco and Citibank still lack certificate pinning, such that authentication credentials and
financial information are visible in the captured traffic. Bradesco, Santander and Nubank include
references to popular social networks in their codebase.
Figure 3. Evolution of scores for client-side security
Table 4. Results for client-side security as of November 2017, considering resistance against
plain MITM attacks or when using maliciously installed root certificates, and what information is
disclosed in captured traffic. Scores between 0 and 10 were converted to the interval between F
and A+ using the Qualys SSL Labs grading to facilitate comparisons with server results.
Banco do
Brasil
Bradesco
Caixa
Econômica
Federal
Citibank
Itaú
Unibanco
Santander
Nubank
Application version
6.31.1.0
3.2.28
3.2.3
15.1.0
6.2.6
6.9.0.7
4.30.0
Secure against plain MITM
✔
✔
✔
✔
✔
✔
✔
Secure against MITM with root cert
✔
✘
✔
✘
✔
✔
✔
Credentials are not leaked
✔
✘
✔
✘
✔
✔
✔
Financial information is not leaked
✔
✘
✔
✘
✔
✔
✔
No integration with external social
networks
✔
✘
✔
✔
✔
✘
✘
Employs certificate pinning
✔
✘
✔
✘
✔
✔
✔
Score
A+
E
A+
D
A+
A
A
7. Conclusion
We finish the paper with a set of recommendations for customers and developers of mobile
banking applications and SSL/TLS servers administrators. Customers should take extra care
when using unknown or public wireless networks, especially those requiring the installation of
root certificates, as this puts the network operator in a privileged position to mount
man-in-the-middle attacks. We observed that successful traffic interception attacks capture both
authentication credentials and sensitive financial information. Additionally, important mobile
applications should always be kept up-to-date to receive the latest security improvements,
although security regressions were also observed in-between versions. Developers of mobile
banking applications should implement more robust security testing to prevent regressions, and
deploy certificate pinning through one of the various available methods. Integration with
Certificate Transparency to check for validity of the server certificate is a recent trend. According
to our analysis, server administrators are becoming more security-aware and there was clear
progression in support for more recent versions of the SSL/TLS protocol, stronger cryptographic
algorithms and perfect forward secrecy. A final recommendation we can make to all banks is to
improve the notification mechanisms for security researchers, so future research work can be
more quickly assimilated as improvement of security practices.
8. REFERENCES
[1] FEBRABAN - Brazilian Banking Federation. Research on Banking Technology for the year
2016 (In Portuguese), 2017. Available at
https://cmsportal.febraban.org.br/Arquivos/documentos/PDF/Pesquisa%20FEBRABAN%2
0de%20Tecnologia%20Banc%C3%A1ria%202017.pdf
[2] Estado de São Paulo. Cybercrime makes banks lose 1.8 billion (in Portuguese), 2015.
Available at
http://link.estadao.com.br/noticias/cultura-digital,cibercrime-faz-ba
ncos-perderem-r-18-bilhao,10000028721
[3] Rafael J. Cruz and Diego F. Aranha. Security Analysis of Mobile Banking Apps in the Android
Platform (In Portuguese). Undergraduate Research Workshop (WTICG) of the Brazilian
Symposium on Information and Computational Systems Security (SBSeg). Brazilian Computer
Science, 2015, 377-387, 2015.
[4] Tom Chothia, Flavio D. Garcia, Chris Heppel, and Chris McMahon Stone. Why Banker Bob
(still) Can’t Get TLS Right: A Security Analysis of TLS in Leading UK Banking Apps. In:
Financial Cryptography 2017, 579-597, 2017.
[5] Bradley Reaves, Nolen Scaife, Adam M. Bates, Patrick Traynor, Kevin R. B. Butler: Mo(bile)
Money, Mo(bile) Problems: Analysis of Branchless Banking Applications in the Developing
World. USENIX Security Symposium 2015: 17-32
[6] Bradley Reaves, Jasmine Bowers, Nolen Scaife, Adam M. Bates, Arnav Bhartiya, Patrick
Traynor, Kevin R. B. Butler: Mo(bile) Money, Mo(bile) Problems: Analysis of Branchless Banking
Applications. ACM Trans. Priv. Secur. 20(3): 11:1-11:31, 2017
[7] Dierks, T., Rescorla, E.: The transport layer security (TLS) protocol version 1.2. RFC 5246
(Proposed Standard), August 2008. https://tools.ietf.org/html/rfc5246
[8] Chris Evans, Chris Palmer. Certificate Pinning Extension for HSTS. IEFT Draft published at
https://tools.ietf.org/html/draft-evans-palmer-key-pinning-00 , 2011.
[9] Ben Laurie. Certificate Transparency. ACM Queue 12(8): 10-19 (2014)
[10] Christopher Meyer, Jörg Schwenk: SoK: Lessons Learned from SSL/TLS Attacks. WISA
2013: 189-209
[11] Jeremy Clark, Paul C. van Oorschot: SoK: SSL and HTTPS: Revisiting Past Challenges
and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and
Privacy 2013: 511-525
[12] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J.
Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin
VanderSloot, Eric Wustrow, Santiago Zanella Béguelin, Paul Zimmermann: Imperfect Forward
Secrecy: How Diffie-Hellman Fails in Practice. ACM Conference on Computer and
Communications Security 2015: 5-17
[13] Rafael J. Cruz. Security Analysis of Brazilian Banking on Android. Github repository, 2018.
Available at https://github.com/rafajunio/sec-banks-br
[14] Isabela Cota, Diego F. Aranha. Security Analysis of Biometric Authentication on Android
Banking Apps (In Portuguese). Undergraduate Research Report, 2015. Available at
https://sites.google.com/site/dfaranha/pubs/biometria-apps-bancarios.
pdf
[15] Altieres Rohr. Brazilian banking apps have security flaws, says research (In Portuguese).
Digital Security - G1, 2015. Available at
http://g1.globo.com/tecnologia/blog/seguranca-digital/post/apps-de-ba
ncos-brasileiros-tem-deficiencias-de-seguranca-diz-pesquisa.html
