Análise de Segurança em Aplicativos Bancários na Plataforma Android

Full text

An´
alise de seguranc¸a em aplicativos
banc´
arios na plataforma Android
Rafael J. Cruz1, Diego F. Aranha1
1Laborat´
orio de Seguranc¸a e Criptografia (LASCA)
Instituto de Computac¸ ˜
ao (IC) – Universidade Estadual de Campinas (Unicamp)
Av. Albert Einstein, 1251 – Campinas/SP – Brasil
{raju,dfaranha}@lasca.ic.unicamp.br
Abstract.
This paper presents the results of a security analysis on banking
applications in the Android platform. The analysis included some aspects of
the mobile application, the server configuration and the connection between
app and server; and spanned 7 different Brazilian banks: Banco do Brasil,
Bradesco, Caixa Econ
ˆ
omica Federal, Citibank, HSBC, Ita
´
u, and Santander. It
was possible to mount a server impersonation attack in most banks, and obtain
sensitive data, such as authentication credentials and financial information.
Collected observations were not restricted to impersonation attacks, including
server configuration flaws and questionable design choices, such as integration
with social networks.
Resumo.
Este trabalho apresenta os resultados de uma an
´
alise de seguran
c¸
a
em aplicativos banc
´
arios na plataforma Android. A an
´
alise abrangeu alguns
aspectos do aplicativo m
´
ovel, como a configura
c¸ ˜
ao do servidor e a conex
˜
ao entre
aplicativo e servidor. Os bancos analisados foram Banco do Brasil, Bradesco,
Caixa Econ
ˆ
omica Federal, Citibank, HSBC, Ita
´
u e Santander. Foi poss
´
ıvel
montar um ataque de personifica
c¸ ˜
ao do servidor com sucesso na maioria dos
aplicativos e obter informa
c¸ ˜
oes sigilosas, credenciais de autentica
c¸ ˜
ao e dados
financeiros. As observa
c¸ ˜
oes coletadas n
˜
ao se resumiram apenas aos ataques de
personifica
c¸ ˜
ao, mas tamb
´
em a falhas na configura
c¸ ˜
ao dos servidores e decis
˜
oes
de projeto question´
aveis, como integrac¸˜
ao com redes sociais.
1. Introduc¸ ˜
ao
O protocolo SSL/TLS [
Hirsch and Engelschall 2013
]
´
e o mais utilizado para se
estabelecer conex
˜
oes seguras via Internet, mas v
´
arios cuidados precisam ser tomados
em sua implementa
c¸ ˜
ao. Em especial, institui
c¸ ˜
oes financeiras – por sua natureza cr
´
ıtica –
devem manter boas pr´
aticas de seguranc¸a, monitorar novos ataques, substituir algoritmos
criptogr
´
aficos obsoletos e implementar novas medidas de seguran
c¸
a. Isso
´
e essencial
para resistir a agentes maliciosos cada vez mais sofisticados. Os ataques banc
´
arios, por
representarem uma atividade muito lucrativa, possuem intrinsecamente uma natureza
adaptativa.
Segundo a Federa
c¸ ˜
ao Brasileira de Bancos [
FEBRABAN 2014
], cerca de 24% (25
milh
˜
oes) de contas utilizam Mobile Banking, ou seja, uma em cada quatro contas utiliza
a tecnologia, que j
´
a representa 12% do n
´
umero total de transa
c¸ ˜
oes. Um pronunciamento
da FEBRABAN sobre dicas de seguran
c¸
a eletr
ˆ
onica informou que os bancos brasileiros

tiveram uma perda de R$ 1,4 bilh
˜
ao devido a fraudes em 2012 [
FEBRABAN 2012
]. Houve
na ocasi
˜
ao uma certa comemora
c¸ ˜
ao, apesar do valor expressivo informado, j
´
a que o valor
representa menos de 0,007% das transac¸ ˜
oes banc´
arias.
2. Fundamentac¸ ˜
ao Te´
orica
Nesta se
c¸ ˜
ao discute-se o protocolo SSL/TLS, a resolu
c¸ ˜
ao da camada f
´
ısica, o ataque
Homem No Meio e pr´
aticas recomendadas de seguranc¸a.
2.1. Protocolo SSL/TLS
Em 1994, a empresa Netscape reconheceu a necessidade de se estabelecer uma
conex
˜
ao segura para realizar com
´
ercio eletr
ˆ
onico e projetou a primeira vers
˜
ao do protocolo
criptogr
´
afico SSL (Secure Sockets Layer 1.0). Este protocolo foi concebido com o objetivo
de fornecer as propriedades cl´
assicas da Seguranc¸a da Informac¸˜
ao:
•Confidencialidade: ´
e a garantia do sigilo das informa
c¸ ˜
oes fornecidas e prote
c¸ ˜
ao
contra sua revelac¸˜
ao n˜
ao autorizada.
•Integridade:
significa ter a disponibilidade de informa
c¸ ˜
oes confi
´
aveis, corretas e
em formato compat
´
ıvel com o de utiliza
c¸ ˜
ao. Em outras palavras, que a informa
c¸ ˜
ao
n˜
ao foi alterada de forma indevida.
•Disponibilidade:
refere-se a resist
ˆ
encia a falhas e manuten
c¸ ˜
ao do servi
c¸
o pelo
m
´
aximo de tempo poss
´
ıvel. No contexto de seguran
c¸
a, h
´
a
ˆ
enfase em resis-
tir n
˜
ao apenas a falhas e acidentes, mas tamb
´
em a ataques de nega
c¸ ˜
ao de
servic¸o [Handley and Rescorla 2006].
•Autenticidade:
consiste na identifica
c¸ ˜
ao e a confirma
c¸ ˜
ao de origem da informa
c¸ ˜
ao.
•Irretratabilidade:
propriedade do que n
˜
ao pode ser rejeitado e tratado novamente.
´
E frequentemente associada `
a natureza irrevog´
avel de assinaturas digitais.
Ap
´
os v
´
arias mudan
c¸
as no protocolo SSL, o navegador Netscape lan
c¸
ou a vers
˜
ao
3.0 em 1996. Entretanto, uma contribui
c¸ ˜
ao mais fundamental seria essencial para o
desenvolvimento do protocolo. Em 1999 surgiu o sucessor do protocolo SSL: o protocolo
TLS 1.0 (Transport Layer Security) – que agora
´
e controlado por uma comunidade aberta,
aIETF – Internet Engineering Task Force.
2.1.1. Descric¸ ˜
ao do protocolo
O SSL/TLS funciona na camada de aplica
c¸ ˜
ao do modelo TCP – ponto onde s
˜
ao
processados dados para envio – e acima da camada de transporte – local onde mensagens
s
˜
ao enviadas. Qualquer aplica
c¸ ˜
ao que fa
c¸
a uso do protocolo SSL/TLS fica isolada da
camada de transporte, ou seja, suas mensagens passam primeiro pelo SSL/TLS, antes de
prosseguir para a camada de transporte.
Enlace
Internet
SSL/TLS
Transporte
Aplicação
Record Protocol
Handshake
Protocol
Cipher Change
Protocol
Alert
Protocol
HTTP, FTP, SSH, DNS ...
TCP, UDP, SCTP, RTP ...
IP, ARP, RARP, ICMP, IPsec ...
Ethernet, Wi-Fi, Modem ...
Figura 1. Modelo TCP com SSL/TLS sobre a camada de aplicac¸ ˜
ao.

Dentro do protocolo SSL/TLS h´
a quatro subprotocolos:
•Handshake Protocol:
negocia as informa
c¸ ˜
oes de sess
˜
ao entre o cliente e o servidor.
As informa
c¸ ˜
oes de sess
˜
ao consistem na identifica
c¸ ˜
ao da sess
˜
ao, troca de certificados,
conjunto de algoritmos a serem utilizados, algoritmos de compress
˜
ao e um segredo
compartilhado usado para gerar chaves;
•Cipher Change Protocol:
troca dados para gerar chaves criptogr
´
aficas entre cliente
e servidor. O subprotocolo consiste de um
´
unica mensagem enviada para a outra
entidade da sess
˜
ao SSL/TLS, o emissor deseja utilizar um certo conjunto de chaves.
A chave ´
e computada das informac¸ ˜
oes trocadas pelo Handshake Protocol;
•Alert Protocol:
indica mudan
c¸
as no estado ou condi
c¸ ˜
ao de erro entre as entidades
envovildas. Os alertas s
˜
ao comuns quando a conex
˜
ao
´
e encerrada, uma mensagem
inv
´
alida
´
e recebida, a mensagem n
˜
ao pode ser decifrada, ou o us
´
uario cancela a
operac¸ ˜
ao;
•Record Protocol:
faz a seguran
c¸
a e verifica
c¸ ˜
ao dos dados da aplica
c¸ ˜
ao, usando as
chaves criptogr´
aficas derivadas durante a etapa de handshake.
2.1.2. Handshake
No protocolo SSL/TLS, a etapa de handshake [
Moser 2009
] especifica como se
d
´
a a troca de mensagens no in
´
ıcio da conex
˜
ao, onde o cliente faz um pedido de conex
˜
ao
ao servidor e obt
´
em uma resposta informando que o servidor est
´
a pronto para a conex
˜
ao.
Em uma conex
˜
ao segura, a troca de mensagens
´
e bem mais intensa do que em uma co-
nex
˜
ao comum. Isso porque, al
´
em do cliente e do servidor aceitarem a conex
˜
ao um do
outro, devem tamb
´
em combinar uma maneira segura para se comunicarem. Durante esta
troca de mensagens do handshake seguro, h
´
a a op
c¸ ˜
ao de utilizar a fun
c¸ ˜
ao de certifica
c¸ ˜
ao
digital, que ´
e um modelo onde ´
e poss´
ıvel comprovar por terceiros – Autoridade Certifica-
dora [
Instituto Nacional de Tecnologia da Informac¸ ˜
ao (ITI) 2014
] – que tanto o servidor
quanto opcionalmente o cliente, s
˜
ao realmente quem dizem ser. Al
´
em da autentica
c¸ ˜
ao,
´
e
tamb
´
em poss
´
ıvel negociar quais algoritmos criptogr
´
aficos ser
˜
ao utilizados posteriormente,
durante a troca efetiva de dados.
2.1.3. Algumas vulnerabilidades do SSL/TLS
Nem mesmo a vers
˜
ao mais recente do protocolo (1.2, publicada em 2008) est
´
a
imune aos ataques, como sugere o Triple Handshake Attack [
Bhargavan et al. 2014
].
Grande parte dos ataques no protocolo SSL/TLS buscam brechas na implementa
c¸ ˜
ao
ou na configurac¸ ˜
ao do protocolo SSL/TLS. Dentre eles, destacam-se:
1.
O ataque
BEAST
[
Sarkar and Fitzgerald
] explora escolha n
˜
ao aleat
´
oria do vetor
de inicializac¸ ˜
ao no modo de operac¸ ˜
ao CBC de uma cifra de bloco;
2.
Os ataques
CRIME
e
BREACH
[
Sarkar and Fitzgerald
] analisam a compress
˜
ao
do protocolo SSL/TLS para capturar informa
c¸ ˜
oes. A compress
˜
ao torna alguns
bytes previs´
ıveis;
3.
O
TIME
[
Sarkar and Fitzgerald
] analisa diferen
c¸
as no tempo de envio e recebi-
mento de mensagens comprimidas;

4.
O
LUCKY 13
[
Sarkar and Fitzgerald
] analisa varia
c¸ ˜
oes no tempo de verifica
c¸ ˜
ao
de pacotes autenticados contendo 13 bytes do cabec¸alho;
5.
No
Ataque a Cifra RC4
[
Sarkar and Fitzgerald
], um atacante ativo pode for
c¸
ar
um cliente estabelecer ou renegociar diversas vezes as chaves de sess
˜
ao at
´
e que um
mesmo texto seja cifrado com chaves RC4 diferentes;
6.
O
FREAK
[
CVE 2014
] opera sobre a negocia
c¸ ˜
ao de chaves entre o cliente e o
servidor, for
c¸
ando a utiliza
c¸ ˜
ao de uma chave RSA de apenas 512 bits. Um ataque si-
milar no acordo de chaves Diffie-Hellman
´
e chamado
Logjam
[
Adrian et al. 2015
].
7. O POODLE [CVE 2014] opera sobre o preenchimento inadequado do cabec¸alho
dos protocolos SSL 3.0 e TLS 1.0. O ataque necessita de 256 requisi
c¸ ˜
oes para
recuperar um byte de mensagem cifrada.
2.2. Resoluc¸ ˜
ao na camada f´
ısica
O Protocolo de Resolu
c¸ ˜
ao de Endere
c¸
o (ARP – Address Resolution Proto-
col) [
Plummer 1982
]
´
e utilizado para encontrar o endere
c¸
o f
´
ısico da camada de enlace
(endere
c¸
o MAC no protocolo Ethernet) a partir do endere
c¸
o da camada de rede local
(enderec¸o IP). O ARP cont´
em dois m´
etodos de resoluc¸ ˜
ao de nomes:
(i)
o emissor difunde em broadcast – envio de mensagem para todos na rede local –
um pacote ARP, contendo o endere
c¸
o IP do outro host e espera uma resposta com
o respectivo enderec¸o MAC;
(ii) o emissor difunde em broadcast seu MAC com seu respectivo IP.
O mapeamento obtido durante a resolu
c¸ ˜
ao
´
e armazenado em uma tabela de mapea-
mento em cache, para reduzir a lat
ˆ
encia e carga na rede caso as mesmas resolu
c¸ ˜
oes sejam
realizadas no futuro pr
´
oximo. Esta tabela cont
´
em um tempo limite de armazenamento e,
se algum host solicitado tiver sua entrada na tabela expirada, a resoluc¸˜
ao ´
e repetida.
2.3. Ataque De Homem No Meio - MITM
BANCO
Login:
Senha:
Servidor
Cliente
Atacar!!!
Atacante
Rede Local
x
1
2
6
5
3
4
Quem é o servidor? EU!!!
Sou um cliente,
posso conectar?
Tudo bem.
Figura 2. Ataque Man In The Middle dentro de uma rede local.
O ataque Homem No Meio (do ingl
ˆ
es Man In The Middle – MITM)
´
e uma forma
de ataque em que os dados trocados entre duas partes s
˜
ao interceptados, registrados e
possivelmente alterados sem que as v
´
ıtimas percebam. O ataque pode ser tentado por
qualquer agente intermedi
´
ario em uma conex
˜
ao (roteador, proxy ou servidor DNS, por

exemplo), mas no contexto desse trabalho, assume-se que o ataque
´
e realizado na mesma
rede local em que encontra-se o cliente. Desta forma, o agente malicioso
´
e capaz de
personificar o servidor apresentando um certificado falso para interceptar o conte
´
udo de
uma conex
˜
ao SSL/TLS. Para isso, basta que o atacante seja o administrador da rede ou
forje a resolu
c¸ ˜
ao do ARP. No caso de forjar o ARP, o atacante deve direcionar tanto o
tr
´
afego do cliente quanto do servidor para a m
´
aquina maliciosa, forjando a resolu
c¸ ˜
ao ARP
de maneira bidirecional.
A Figura 2 apresenta o funcionamento geral do ataque e pode ser detalhada da
seguinte forma:
•
Mensagens
1
e
2
: referem-se
`
a conex
˜
ao normal entre o servidor e o cliente, sem
influˆ
encia maliciosa;
•
Mensagem
3
: o agente malicioso percebe que o cliente deseja entrar em contato
com o servidor alvo;
•
Mensagem
4
: o agente malicioso responde prontamente para o cliente, personifi-
cando o servidor. Com isso, a falsa conex
˜
ao cliente-servidor est
´
a estabelecida entre
o cliente e o atacante;
•
Mensagem
5
: o agente malicioso finge ser o cliente para o servidor e abre uma
nova conex˜
ao;
•
Mensagem
6
: o servidor aceita a conex
˜
ao, e ao finalizar o passo 6, o atacante det
´
em
toda a informac¸ ˜
ao para realizar o ataque com sucesso.
A preven
c¸ ˜
ao desse tipo de ataque
´
e realizada com uma boa implementa
c¸ ˜
ao do
protocolo SSL/TLS, pois suas propriedades de seguran
c¸
a estabelecem seguran
c¸
a fim-a-fim,
evitando influˆ
encia indevida por m´
aquinas intermedi´
arias.
Ataque MITM com Certificado Autoassinado
Figura 3. Propriedade de autenticidade do SSL/TLS, supondo que o cliente n ˜
ao
possui certificado digital.
´
E necess
´
ario analisar a Figura 3 para compreender o funcionamento da variante
deste ataque. Observe que a conex
˜
ao faz uso da autoridade certificadora descrita durante
ohandshake. Com isso,
´
e poss
´
ıvel concluir que a verifica
c¸ ˜
ao cuidadosa do certificado
invalida o ataque MITM.

Um agente malicioso pode ser capaz de convencer o usu
´
ario a instalar um certifi-
cado raiz. Este fator
´
e o que torna o ataque poss
´
ıvel, j
´
a que o certificado instalado permite
a validac¸˜
ao no resultado com MITM da Figura 3.
Para evitar este problema, as boas pr
´
aticas de seguran
c¸
a determinam ent
˜
ao, que
o aplicativo seja capaz de detectar a valida
c¸ ˜
ao indevida do certificado falso, a partir da
implementa
c¸ ˜
ao de uma t
´
ecnica de pinagem de chave p
´
ublica, ou seja, qualquer informa
c¸ ˜
ao
relevante sobre os certificados do servidor armazenada no cliente, por exemplo: a autori-
dade certificadora ou hash da cadeia de certificados.
2.4. Pr´
aticas recomendadas
Para adquirir um bom n
´
ıvel de seguran
c¸
a ao implementar o protocolo SSL/TLS,
servidores devem realizar os seguintes procedimentos:
•Suporte a Segredo Futuro [Kaliski 1999]: ´
e a propriedade em que uma
comunica
c¸ ˜
ao presente
´
e confidencial, e espera-se que ela se mantenha confiden-
cial no futuro, mesmo que as chaves de longa dura
c¸ ˜
ao de um ou de outro (chave
privada correspondente ao certificado do servidor, usu
´
ario/senha do cliente) sejam
comprometidas. Alternativamente, se uma
´
unica comunica
c¸ ˜
ao for comprometida,
n
˜
ao h
´
a impacto na confidencialidade de todas as comunica
c¸ ˜
oes anteriores a ela.
Uma maneira de realizar uma implementa
c¸ ˜
ao do Segredo Futuro,
´
e gerar chaves de
sess˜
ao – chave utilizada ap´
os o handshake – de maneira aleat´
oria.
•Atualizac¸ ˜
ao de algoritmos:
remover o suporte a algoritmos criptogr
´
aficos in-
seguros. Algumas fun
c¸ ˜
oes de hash ultrapassadas, como MD5 [
Rivest 1992
] e
SHA-1 [
Eastlake and Hansen 2011
], devem ser atualizadas para algoritmos mais
seguros (SHA-2 [
Eastlake and Hansen 2011
], por exemplo), e deixar de utilizar
algoritmos de cifra
c¸ ˜
ao como RC4, que permite recupera
c¸ ˜
ao trivial da chave de
sess˜
ao utilizando o ataque de criptograma escolhido.
•Validac¸ ˜
ao de Certificados:
obter um certificado adequado e utiliz
´
a-lo coerente-
mente no protocolo
´
e de suma import
ˆ
ancia. Uma boa cadeia de certifica
c¸ ˜
ao gerada
pelas autoridades certificadoras (VeriSign, Equifax, Certisign, entre outros), ga-
rante o in
´
ıcio de uma boa seguran
c¸
a, o que significa utilizar certificados confi
´
aveis.
Fornecer uma lista de certificados revogados (CRL [
Housley et al. 2002
]) e um
protocolo de verifica
c¸ ˜
ao do estado do certificado (OCSP [
Santesson et al. 2013
])
auxiliam na verificac¸˜
ao da validade do certificado.
•Atualizac¸ ˜
ao de vers˜
ao de protocolo:
abandonar protocolos obsoletos, como
SSL 3.0. Protocolos antigos e mal implementados deixam o servidor
vulner
´
avel a ataques como POODLE [
CVE 2014
], FREAK [
CVE 2014
] e
DoS [
Handley and Rescorla 2006
], vulner
´
avel
`
a ataques de deteriora
c¸ ˜
ao (que redu-
zem a capacidade do hardware ou software – neste caso reduzem a seguran
c¸
a
dos algoritmos criptogr
´
aficos, o que permite o FREAK, por exemplo), m
´
a
implementa
c¸ ˜
ao do Diffie-Hellman [
Rescorla 1999
], entre outros. Ainda no proto-
colo,
´
e poss
´
ıvel fazer uso do HTTP Public Key Pinning (HPKP) [
Evans et al. 2015
]
e OCSP [Santesson et al. 2013].
A responsabilidade do cliente envolve prevenir configura
c¸ ˜
oes inseguras do servidor
quando poss´
ıvel e, especialmente:

•Validac¸ ˜
ao cuidadosa de chave p´
ublica:
os clientes devem avaliar cuidadosa-
mente as chaves p
´
ublicas do servidor trocadas durante a conex
˜
ao, e portanto, uma
m
´
ınima verifica
c¸ ˜
ao do certificado
´
e necess
´
aria, para comprovar sua autenticidade –
consultando os certificados das autoridades certificadoras instaladas nos dispositi-
vos, por exemplo. H
´
a ainda, a possibilidade de verificar a expira
c¸ ˜
ao do certificado,
atrav
´
es da sua lista CRL e do seu OCSP. O cliente tamb
´
em deve realizar a pinagem
no certificado. Caso o servidor n
˜
ao tenha suporte a pinagem, atrav
´
es da extens
˜
ao
HPKP, a verifica
c¸ ˜
ao
´
e feita por alguma informa
c¸ ˜
ao instalada no pr
´
oprio cliente. O
artigo [
Georgiev et al. 2012
] cont
´
em v
´
arios exemplos, obtidos de algumas biblio-
tecas da Amazon e Paypal, de verifica
c¸ ˜
ao insuficiente da chave p
´
ublica por parte
do cliente. Isto refor
c¸
a ainda mais o cuidado que aplica
c¸ ˜
oes cr
´
ıticas devem ter ao
realizar a verificac¸˜
ao do certificado.
3. Metodologia
A metodologia consistiu em trˆ
es grandes partes:
1. An´
alise dos c´
odigos e identificac¸ ˜
ao dos servidores de cada aplicac¸ ˜
ao banc´
aria:
•
Capturar os hostnames de servidores banc
´
arios, com aux
´
ılio da ferramenta
Wireshark
[
Wireshark Project
]. Alguns bancos cont
´
em mais de um
servidor atendendo o aplicativo.
•
Baixar os aplicativos banc
´
arios no formato
.apk
, utilizando
APK
Downloader [Redphx ].
•
Descompilar os aplicativos com as ferramentas
dex2jar
[
Pan
], que trans-
forma o
.apk
para o
.jar
, e
JD-GUI
[
Java Decompiler
], que transforma
o.jar para arquivos em .java.
•
Utilizar os aplicativos banc
´
arios com o
Monitor-SDK
[
Google, Inc.
],
que mostra alguns logs do aplicativo conforme h´
a iterac¸ ˜
ao no aparelho.
2. Ataque Homem no Meio com e sem certificado raiz forjado instalado:
•
Redirecionar o tr
´
afego de rede sem fio para o computador malicioso. No
caso do sistema operacional Linux basta alterar iptables.
•
Na rede local, controlar a rota do cliente atrav
´
es de um proxy malicioso ou
ataque na resoluc¸ ˜
ao ARP com a ferramenta arpspoof [Song ].
•Gerar um certificado com aux´
ılio do OpenSSL [The OpenSSL Project ].
•
Controlar o tr
´
afego SSL/TLS de forma transparente, atrav
´
es da ferramenta
sslsplit
[
Roethlisberger
]. O
sslsplit
utiliza o certificado forjado
para trocar informa
c¸ ˜
oes na conex
˜
ao SSL/TLS. Opcionalmente instalar o
certificado forjado no smartphone (ataque MITM com certificado raiz).
3. Exame dos servidores identificados:
•
Exames semanais, por tr
ˆ
es meses, das configura
c¸ ˜
oes dos servidores atrav
´
es
do SSLlabs [Qualys, Inc. ].
4. Resultados e discuss ˜
ao
Seguindo a metodologia proposta, podemos utilizar os resultados semanais do
SSLlabs para avaliar os servidores na Tabela 1. As notas s˜
ao atribu´
ıdas pelo SSLlabs.
Em particular, o Bradesco cont´
em dois servidores para atender a aplicac¸ ˜
ao m´
ovel.
O HSBC
´
e um aplicativo global (tamb
´
em funciona fora do Brasil), por este motivo cont
´
em

tr
ˆ
es servidores para atender a aplica
c¸ ˜
ao m
´
ovel. Em uma an
´
alise mais profunda foi poss
´
ıvel
verificar que h
´
a um servidor para os membros (Nota C), um servidor para servi
c¸
os (Nota
A-) e um servidor nacional para transac¸ ˜
oes (Nota A-).
Tabela 1. Resultado do SSLlabs sobre os servidores examinados. As notas va-
riam de F a A+.
Banco do
Brasil Bradesco
Caixa
Econˆ
omica
Federal
Citibank HSBC Ita´
u Santander
Emprega TLS 1.2 8 8 4 8 4 4 8
Emprega TLS 1.1 8 8 8 8 4 4 8
Emprega TLS 1.0 4 4 4 4 4 4 4
Suporta SSL 3.0 4 4 4 8 4 4 4
Suporta SSL 2.0 8 4 8 8 8 8 8
Suporta RC4 4 4 4 8 8 4 4
Suporta MD5 4 4 8 8 8 8 8
Suporta SHA-1 4 4 4 4 4 4 4
Suporta Segredo Futuro 8 8 8 8 8 8 8
Suporta OCSP 8 8 8 8 4 8 8
Suporta HPKP 8 8 8 8 8 8 8
Diffie-Hellman Inseguro 4 8 8 8 8 8 8
Vulner´
avel a Deteriorac¸ ˜
ao 4 4 8 8 4 4 4
Vulner´
avel ao POODLE 4 8 4 4 4 4 8
Vulner´
avel ao DoS 8 8 4 4 8 8 8
Vulner´
avel ao FREAK 4 4 8 8 8 8 8
Nota F F, F C C C, A-, A- F C
Propriedades: (Boa) |(Neutra) |(Ruim) k4Sim/Aplica-se |8N˜
ao/N˜
ao se Aplica.
Ap
´
os a montagem da rede local e realiza
c¸ ˜
ao de ataques seguindo a metodologia
descrita, os resultados dos clientes analisados foram coletados e podem ser encontrados
na Tabela 2. As notas foram obtidas como a seguir:
n˜
ao sofre MITM comum
pontua 1,5
estrela, por ser um ataque simples que n
˜
ao precisa de nada instalado no cliente;
n˜
ao sofre
MITM com certificado raiz
pontua 1 estrela, pois necessita do certificado autoassinado
instalado no dispositivo da v
´
ıtima, sendo mais intrusivo;
n˜
ao vaza credenciais
pontua
1 estrela, por ser uma das consequ
ˆ
encias do MITM;
n˜
ao vaza informac¸ ˜
oes financeiras
pontua 1 estrela, por tamb
´
em ser uma das consequ
ˆ
encias do MITM;
n˜
ao cont´
em redes
sociais externas
pontua 0,5 estrela, j
´
a que integra
c¸ ˜
ao com redes sociais pode gerar pelo
menos duas consequ
ˆ
encias: vazamento de dados banc
´
arios (privacidade) e comprometi-
mento da defesa em profundidade, j
´
a que a seguran
c¸
a do aplicativo pode ser fragilizada
por vulnerabilidades na rede social por transitividade. Pinagem de chave p
´
ublica afeta
diretamente os ataques realizados, portanto o uso de pinagem n
˜
ao garante pontua
c¸ ˜
ao.
Ainda assim, destacamos essa propriedade para fins de ilustra
c¸ ˜
ao. A vulnerabilidade contra
ataques MITM (comum ou com certificado raiz) conta um total de 2,5 estrelas, enquanto
o vazamento de informa
c¸ ˜
ao sens
´
ıvel (credenciais ou informa
c¸ ˜
ao financeira) representa
2 estrelas. Os crit
´
erios de pontua
c¸ ˜
ao foram projetados para capturar a gravidade das
vulnerabilidades e a dificuldade imposta ao atacante.
Algumas observa
c¸ ˜
oes gerais coletadas para cada aplicativo e servidor correspon-
dente podem ser encontradas a seguir:

Tabela 2. Resultado dos aplicativos Android analisados quanto `
a vulnerabilidade
a ataques de personificac¸ ˜
ao e outras decis ˜
oes de projeto. As notas variam de 0
a 5 estrelas.
Banco do
Brasil Bradesco
Caixa
Econˆ
omica
Federal
Citibank HSBC Ita´
u Santander
Vers˜
ao analisada 6.5.0.7 2.9.6 1.3.3 9.0 1.5.10.0 4.1.5 4.4.0
N˜
ao sofre MITM comum 4 4 4 4 4 4 8
N˜
ao sofre MITM com certificado raiz 4 8 8 8 8 8 8
N˜
ao Vaza credenciais 4 8 8 8 4 8 8
N˜
ao Vaza informac¸ ˜
oes financeiras 4 8 8 8 8 8 8
N˜
ao cont´
em redes sociais externas 4 8 4 8 4 8 4
Utiliza pinagem de chave p´
ublica 4 8 8 8 8 8 8
Nota
4Sim/Aplica-se |8N˜
ao/N˜
ao se Aplica.
•Banco do Brasil (BB):
a solu
c¸ ˜
ao do banco para pinagem de chave p
´
ublica foi
instalar um arquivo no aplicativo que cont
´
em a cadeia de certifica
c¸ ˜
ao do servidor.
Al
´
em disso, o BB tem sua pr
´
opria rede social interna. O servidor utiliza o protocolo
SSL 3.0 e algoritmos inseguros, como RC4, MD5 e SHA-1, al
´
em de n
˜
ao utilizar
novos protocolos, como TLS 1.2 e 1.1. Estas configura
c¸ ˜
oes permitem que o BB
seja vulner´
avel `
a maioria dos ataques citados na Tabela 1.
•Bradesco:
o conjunto aplicativo-servidores mostrou-se muito vulner
´
avel – apesar
da resist
ˆ
encia contra o ataque MITM comum. Para deixar de ser vulner
´
avel aos
ataques deste trabalho, o Bradesco deve realizar algum tipo de pinagem no cliente
ou servidor (ou ambos). O servidor tem compatibilidade com protocolos muito
antigos, como SSL 2.0 e SSL 3.0, al
´
em de utilizar algoritmos inseguros, como
RC4, MD5 e SHA-1. Um outro problema de seguran
c¸
a
´
e a integra
c¸ ˜
ao do aplicativo
com redes sociais externas (como Facebook).
•Caixa Econˆ
omica Federal (Caixa):
o aplicativo ainda precisa realizar a pinagem
de chave p
´
ublica, assim como o Bradesco. O servidor suporta SSL 3.0 e a falta de
uma renegocia
c¸ ˜
ao segura de chaves permite o ataque DoS. Um outro problema de
seguran
c¸
a,
´
e o excesso de utiliza
c¸ ˜
ao do JavaScript, que fica armazenado no cliente
de maneira transparente, permitindo uma poss´
ıvel injec¸˜
ao de c´
odigo.
•Citibank:
a situa
c¸ ˜
ao do aplicativo
´
e absolutamente an
´
aloga ao Bradesco. A falta
de renegocia
c¸ ˜
ao segura de chaves permite o ataque DoS e a n
˜
ao verifica
c¸ ˜
ao do
preenchimento restante da mensagem permite a utilizac¸ ˜
ao do POODLE em TLS.
•HSBC:
apesar de sofrer o ataque MITM com certificado autoassinado, n
˜
ao trans-
mitiu de maneira clara – sem cifrar – as credenciais do cliente, pois a habilita
c¸ ˜
ao
de um dispositivo m
´
ovel permite negocia
c¸ ˜
ao pr
´
evia de chaves criptogr
´
aficas. En-
tretanto, algumas informa
c¸ ˜
oes financeiras dos clientes foram vazadas no tr
´
afego
capturado, como saldo e limite do cart
˜
ao de cr
´
edito, por exemplo. Ainda assim,
´
e
necess
´
ario realizar pinagem de chave p
´
ublica, como o Bradesco. Do ponto de vista
de seguranc¸a, um dos servidores precisa de uma melhor configurac¸˜
ao.
•Ita´
u:
a situa
c¸ ˜
ao do aplicativo
´
e absolutamente an
´
aloga ao Bradesco. O servidor
utiliza SSL 3.0 e algoritmos inseguros, como RC4 e SHA-1, al
´
em de permitir
ataques de deteriorac¸ ˜
ao e POODLE.
•Santander:
dada a vulnerabilidade a ataques MITM comuns, o aplicativo opta por
utilizar um protocolo adicional customizado na camada de aplica
c¸ ˜
ao, ao inv
´
es de
utilizar somente o protocolo SSL/TLS. Nesse protocolo, o servidor envia uma chave
p
´
ublica RSA de 2048 bits que
´
e utilizada pelo cliente para cifrar uma chave p
´
ublica

ef
ˆ
emera de 1024 bits, gerada a cada conex
˜
ao. Ao recuperar a chave p
´
ublica ef
ˆ
emera
utilizando sua chave privada, o servidor cifra uma chave de sess
˜
ao para proteger
a comunica
c¸ ˜
ao subsequente com o cliente. Verificou-se por engenharia reversa
do aplicativo ofuscado que o protocolo customizado tamb
´
em n
˜
ao faz nenhuma
autentica
c¸ ˜
ao de chaves p
´
ublicas, tornando-se trivialmente vulner
´
avel ao ataque
MITM. A corre
c¸ ˜
ao pode ser feita ao n
˜
ao depender do protocolo customizado e
utilizar o protocolo TLS de maneira correta, pois desta maneira, haver
´
a pelo menos
dois benef
´
ıcios: ganho de desempenho por ter apenas um protocolo utilizado e
corre
c¸ ˜
ao dos ataques detectados por este trabalho. O servidor utiliza o protocolo
SSL 3.0, mas apesar da corre
c¸ ˜
ao do ataque POODLE,
´
e necess
´
ario abandonar este
protocolo. O servidor ainda utiliza algoritmos inseguros, como RC4 e SHA-1.
5. Conclus˜
ao
Como continuidade do trabalho, todos os bancos foram notificados dos problemas
encontrados. Entretanto, o departamento de seguran
c¸
a quase sempre foi de dif
´
ıcil acesso,
o que mostrou-se preocupante, uma vez que este departamento deve ser um dos mais
acess
´
ıveis para pesquisadores notificando vulnerabilidades.
´
E importante ressaltar que o
banco
´
e respons
´
avel por proteger as credenciais e informa
c¸ ˜
oes financeiras de seus clientes,
desta maneira deve haver uma maior preocupa
c¸ ˜
ao na corre
c¸ ˜
ao dos problemas encontrados.
Os resultados foram coletados em Maio de 2015 e os bancos notificados alguns dias ap
´
os
as coletas. At
´
e o prazo de submiss
˜
ao da vers
˜
ao final, os autores puderam verificar que
nenhum dos bancos analisados mitigou completamente o impacto das falhas descobertas.
Espera-se que os resultados deste trabalho sejam
´
uteis para aprimoramento de
seguranc¸a de aplicativos banc´
arios, pela adoc¸ ˜
ao de duas medidas principais:
1.
Aplica
c¸ ˜
oes do lado do cliente precisam avaliar cuidadosamente chaves p
´
ublicas
do servidor enviadas durante a conex
˜
ao. Durante a valida
c¸ ˜
ao feita pelo cliente,
deve-se tamb´
em checar CRL, OCSP e pinagem de certificado.
2.
Servidores tamb
´
em devem aumentar o n
´
ıvel de seguran
c¸
a. Este objetivo pode ser
alcan
c¸
ado abandonando algoritmos e protocolos criptogr
´
aficos obsoletos, al
´
em de
implementar novas medidas de seguranc¸a (Segredo Futuro, por exemplo).
Referˆ
encias
Adrian, D., , Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., and others. (2015).
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., and Alfredo Pironti, P.-Y. S. (2014).
Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS.
CVE (2014). Common Vulnerabilities and Exposures: FREAK - CVE-2015-0204, POO-
DLE - CVE-2014-3566.
Eastlake, D. and Hansen, T. (2011). RFC 6234 - US Secure Hash Algorithms (SHA and
SHA-based HMAC and HKDF).
Evans, C., Palmer, C., and Sleevi, R. (2015). RFC 7469 - Public Key Pinning Extension
for HTTP.
FEBRABAN (2012). Federa
c¸ ˜
ao Brasileira de Bancos d
´
a dicas de seguran
c¸
a eletr
ˆ
onica.
https://www.febraban.org.br/Noticias1.asp?id_texto=1886.

FEBRABAN (2014). Pesquisa de Tecnologia Banc
´
aria da Federa
c¸ ˜
ao Brasileira de Bancos.
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and Shmatikov, V. (2012). The
most dangerous code in the world: validating ssl certificates in non-browser software.
In ACM Conference on Computer and Communications Security, pages 38–49.
Google, Inc. Device Monitor.
https://developer.android.com/tools/
help/monitor.html.
Handley, E. M. and Rescorla, E. E. (2006). RFC 4732 - Internet Denial-of-Service
Considerations.
Hirsch, F. J. and Engelschall, R. S. (2013). SSL/TLS Strong Encryption: An Introduction.
Housley, R., Polk, W., Ford, W., and Solo, D. (2002). RFC 3280 - Internet X.509 Public
Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
Instituto Nacional de Tecnologia da Informa
c¸ ˜
ao (ITI) (2014). Autoridades Certificadoras.
Java Decompiler. JD-GUI - Java Decompiler. http://jd.benow.ca.
Kaliski, B. (1999). IEEE 1363-2000: IEEE Standard Specifications For Public Key
Cryptography.
Moser, J. (2009). The First Few Milliseconds of an HTTPS Connection.
Pan, B. dex2jar - tools to work with android .dex and java .class files.
https://github.
com/pxb1988/dex2jar.
Plummer, D. C. (1982). RFC 826 - An Ethernet Address Resolution Protocol – or –
Converting Network Protocol Addresses.
Qualys, Inc. SSLlabs - Qualys SSL Labs. https://www.ssllabs.com.
Redphx. APK Downloader - Download APK files from Android Market to PC.
http:
//codekiem.com/2012/02/24/apk-downloader.
Rescorla, E. (1999). RFC 2631 - Diffie-Hellman Key Agreement Method.
Rivest, R. (1992). RFC 1321 - The MD5 Message-Digest Algorithm.
Roethlisberger, D. SSLsplit - transparent and scalable SSL/TLS interception.
https:
//github.com/droe/sslsplit.
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C. (2013).
RFC 6960 - X.509 Internet PKI Online Certificate Status Protocol - OCSP.
Sarkar, P. G. and Fitzgerald, S. Attacks on SSL a Comprehensive Study of BEAST,
CRIME, TIME, BREACH, LUCKY 13 & RC4 biases. White paper.
Song, D. Dsniff - a collection of tools for network auditing and penetration testing.
http://www.monkey.org/˜dugsong/dsniff.
The OpenSSL Project. OpenSSL - The Open Source toolkit for SSL/TLS.
https:
//www.openssl.org.
Wireshark Project. Wireshark - Go Deep. https://www.wireshark.org.