Meu banco continua prejudicando a educação contra phishing
(moritz-mander.de)- O banco envia e-mails promocionais de eventos parecidos com e-mails de phishing não confiáveis
- Os links e domínios do site no corpo da mensagem parecem não ter relação com o banco, e como pedem dados pessoais fica difícil julgar se é phishing
- Mesmo após confirmar que era real, o autor descobriu que era um evento oficial, o que ampliou a confusão e a desconfiança
- Essa prática prejudica o propósito da educação contra phishing e aumenta o risco de o banco assumir responsabilidade legal
- Para resolver o problema, é enfatizada a necessidade de usar domínios confiáveis e implementar isso dentro do app
Introdução
Vivenciei na prática como meu banco está prejudicando diretamente a educação contra phishing. Um e-mail de evento enviado pelo banco tinha características tão suspeitas que era quase impossível distingui-lo de um golpe de phishing. Ele fazia a pessoa inserir dados pessoais em um lugar que não usava o domínio oficial do banco, e isso expõe problemas tanto no estado da segurança de bancos e órgãos públicos, dentro e fora do país, quanto na realidade da educação em segurança.
Capítulo 1: A chegada de um e-mail suspeito
- Recebi do banco um e-mail sobre o “Wero-Win-Wochen (evento com prêmios)”
- O aviso por e-mail incentivava a participação no evento com a informação de que seria possível ganhar até 7.000 euros por semana
- Sparkasse (rede alemã de bancos regionais) e Wero (um novo sistema europeu de pagamentos digitais) eram mencionados na mensagem
- O link dentro do e-mail levava para “gewinnen-mit-wero.de”, diferente do domínio oficial do banco
- O conteúdo e o tom eram parecidos com um e-mail de phishing comum; só o endereço do remetente era um endereço oficial da Sparkasse
- Foi preciso verificar no site oficial do banco se o evento era mesmo real
O que é a Sparkasse?
- É um banco de poupança com base regional, operado de forma independente em cada região
- É um dos maiores grupos de serviços financeiros da Europa
O que é o Wero?
- É um novo sistema de pagamentos digitais criado pela European Payments Initiative (EPI)
- Foi desenvolvido com o objetivo de integrar sistemas locais de pagamento (inicialmente com foco em pagamentos P2P)
- É parecido com o PayPal, mas tem uma estrutura distribuída entre os bancos
Capítulo 2: A situação piora – um site suspeito
- Ao clicar no link do e-mail, o site de participação no evento apresenta vários elementos de design e estrutura muito parecidos com os de um site de phishing
- Não há qualquer menção à agência da Sparkasse nem distinção entre bancos, ignorando a independência de cada instituição
- O próprio domínio não tem relação com o domínio oficial do banco e usa um nome genérico que qualquer pessoa poderia registrar
- O certificado SSL também usa o Let’s Encrypt gratuito, o que reduz a sensação de confiança
- Há pouca explicação sobre o contexto ou a base do evento, e o site apenas enfatiza “a chance de receber dinheiro”
- Para participar, são solicitados nome, data de nascimento, IBAN, endereço de e-mail e outras informações pessoais/financeiras
- Em geral, eventos financeiros digitais modernos costumam ser projetados para participação apenas dentro do app, então isso destoa bastante
Com isso, a instituição financeira acaba deliberadamente tornando sem sentido a educação de segurança voltada aos usuários.
O problema da perda de eficácia da educação em segurança
- Se até bancos reais usam métodos parecidos com e-mails/sites de phishing, os usuários deixam de confiar na própria educação de detecção de phishing
- Espalha-se a percepção de que “isso parece spam, mas pode ser legítimo”
- No passado, esse banco já havia enviado SMS oficiais com frases e domínios suspeitos (por exemplo, links para paperless.io)
- Nem mesmo a central de atendimento entende why isso pode parecer spam
Capítulo 3: Qual é a solução?
- A forma mais segura é implementar diretamente no app o processo de participação no evento
- Se isso for inevitável, deve-se usar o domínio oficial (por exemplo, sparkasse.de) ou o subdomínio de cada agência para manter a confiabilidade
- O governo alemão também reforçou a confiança em serviços ao adotar a política de marca digital gov.de em um caso semelhante
Capítulo 4: A possibilidade de negligência virar problema jurídico
- Nos últimos tempos, vêm aumentando os precedentes judiciais de bancos tendo de indenizar vítimas de phishing
- Ao decidir se houve “negligência” no vazamento de dados pessoais, os tribunais concluem pela responsabilidade do banco quando não há culpa do usuário
- Se um ataque de phishing fosse realizado usando a mesma estrutura atual de e-mail/site, seria difícil para o banco provar que a vítima não foi cautelosa
- Como os e-mails/sites oficiais do banco e o phishing se parecem demais, o risco jurídico cresce
Conclusão
- A segurança técnica está avançando, mas ainda há brechas na segurança da experiência do usuário (USABLE SECURITY)
- Casos assim prejudicam a confiança na própria educação contra phishing e afetam negativamente tanto a carga legal dos bancos quanto todo o setor financeiro
- O problema é um problema estrutural de sistema que dificilmente se resolve com feedback individual
- É preciso reconhecer com ainda mais seriedade que isso acontece até em um dos maiores grupos financeiros da Europa
- A lição final é: “Não prejudiquem a educação em segurança. Em vez disso, deem um pouco mais de atenção a isso”
2 comentários
Acho que a sensação de déjà vu não é imaginação 🤣
Comentários do Hacker News
Meu banco usa um sistema de detecção de fraude que me liga quando detecta atividade suspeita na conta e pede para eu retornar a ligação para um número específico. O problema é que eles dão um número de retorno diferente toda vez. Se eu procuro esse número online, aparece exatamente um resultado: a página oficial do sistema de detecção de fraude dizendo para não confiar em nenhuma ligação. O conselho faz sentido, mas ironicamente acaba significando ignorar até o contato legítimo deles.
A única vez em que acionei o sistema de detecção de fraude do cartão, recebi uma mensagem do banco dizendo: “Seu cartão foi bloqueado por uso suspeito, ligue para o número a seguir”. Esse número também era um número aleatório não listado. A única razão para eu não ignorar foi que eu tinha acabado de fazer um pagamento em um site novo. Então liguei diretamente para a agência do meu banco para confirmar se aquilo era real, e me disseram que era mesmo. Quase comecei a reclamar do quão desastroso esse procedimento é.
Parece que não existe ninguém responsável pelo fluxo completo de experiência do usuário (UX) do banco. O meu também funciona de um jeito parecido e estranho. Por exemplo, toda vez que transfiro dinheiro para minha esposa, ele faz várias perguntas de prevenção a fraude. Depois que respondo, ainda aparece uma mensagem dizendo algo como “como você transfere com frequência, não vamos pedir código 2FA nem autenticação adicional”. Esse tipo de UX sem lógica provavelmente existe porque não há uma pessoa ou equipe olhando o fluxo inteiro.
Os bancos não seguem nem as próprias regras. Uma vez o banco me ligou sobre uma alteração de seguro que eu tinha solicitado um mês antes e pediu para eu me autenticar com meu dongle de segurança. Desse jeito, não surpreende que as pessoas caiam em golpes.
O banco onde trabalho envia mensagens perguntando “você emitiu um cheque de $x?” para verificar se há algo anormal. O problema é que o golpe de cheque mais comum é o "check washing", em que o valor do cheque fica igual e só o beneficiário é adulterado. Nesse caso, parece apenas uma transação legítima com o valor correto, mas não dá para verificar para quem o pagamento foi feito de fato.
Mesmo quando você liga para o número geral oficial do banco, espera um tempão e finalmente consegue falar com um atendente, eles dizem que não reconhecem aquele número, embora ele esteja correto. E é ainda mais irritante no caso de bancos que eu não uso: se você liga para o número do site, cai direto num sistema automático e, sem número de conta, nem consegue acessar. Aí você acaba precisando procurar outro número para conseguir falar com alguém.
Meu banco (USAA) já implementou sugestões que eu dei no passado. Mas recentemente recebi um e-mail aparentemente legítimo no meu endereço exclusivo, só que vindo de um domínio diferente do usual. Isso me deixou ainda mais desconfiado porque tinha acontecido logo depois de eu resolver algo com eles. Liguei imediatamente para o banco e falei com alguém do departamento de fraude, explicando que ou o sistema interno deles tinha sido comprometido ou estavam acostumando os clientes ao phishing, e pedi que abrissem um ticket. A atendente disse que aquele domínio não pertencia à USAA e que eles só usavam usaa.com, então bloqueou minha conta sem muita conversa. No fim, tive de ligar de novo para desbloquear a conta, e me disseram que o ticket tinha sido aberto. Agora resta acompanhar.
As práticas de tecnologia e marketing ligadas à experiência do usuário nos bancos são péssimas. Todos os formulários de login de bancos indianos que usei são:
Limite de 15 caracteres? O meu banco exige exatamente 6 dígitos. Nem letras pode, tem de ser número. Não dá para usar gerenciador de senhas, copiar/colar é bloqueado e você precisa clicar nos campos numéricos com o mouse. Na obsessão por “segurança”, a autenticação em duas etapas foi de token físico para app e, por fim, acabou em SMS. E não estamos falando de um banco de bairro pequeno, mas do maior banco da França.
Algumas semanas atrás houve polêmica no Reddit com uma captura mostrando que o app de um banco estatal indiano bloqueava o aplicativo só porque o usuário tinha instalado o Firefox. Bancos e sites do governo são extremamente hostis ao usuário. Antes eu achava que isso era para proteger usuários menos familiarizados com tecnologia, mas hoje me parece mais uma desculpa para não adotar frameworks realmente seguros e convenientes.
O app de certo banco estatal indiano nem funciona se você não conceder permissões essenciais como câmera e acesso ao sistema de arquivos inteiro. Mas, no meu banco, nunca recebi spam como o do post original. O que existe no imaginário popular é o boato de que funcionários de baixo escalão vazam dados de contas para golpistas com frequência.
Meu banco obriga a trocar a senha a cada 180 dias, só aceita senhas de 6 a 11 caracteres e ainda restringe quais caracteres podem ser usados. Então, quando tento entrar, ele manda trocar a senha de novo, e as senhas geradas automaticamente pelo Firefox não seguem as regras do banco. Acabo tendo de gerar uma senha aleatória manualmente no terminal para atender aos requisitos.
Não entendo bem por que usar hash de senha no lado do cliente seria um problema.
Na compra de imóvel isso é ainda pior. Existem várias suborganizações usando domínios diferentes, e tudo fica bem mais confuso. Também já passei por algo parecido tendo de confiar em um domínio suspeito por causa de um recall de dispositivo médico. Isso poderia ser resolvido facilmente se eles simplesmente publicassem no site uma lista de domínios parceiros confiáveis. Meu protocolo pessoal de segurança é procurar o contato da instituição financeira em um site
.gov, entrar no domínio encontrado e confirmar por telefone qual é o domínio realmente confiável. Os atendentes costumavam achar isso estranho. Um dia uma atendente chegou ao ponto de dizer: “Se no LinkedIn aparecer que a pessoa trabalha no <Nome do Banco>, então você sabe que ela é real”.Quando ouvi “se no LinkedIn consta que a pessoa trabalha no <Nome do Banco>, então pode confiar”, respondi: “Se você me der 2 minutos, também posso colocar isso no meu perfil; então você vai me passar seus dados pessoais?”
Minha experiência na compra da casa não teve complexidade nenhuma. Eu fiz o financiamento imobiliário por meio de um corretor e só lidei diretamente com uma pessoa.
Pessoas ingênuas em posição de decisão não percebem bem esses riscos até elas mesmas, ou alguém próximo, sofrer um golpe ou problema jurídico; só então entendem. Nos EUA também havia muitas pessoas assim comandando empresas antes de 2012, mas, como o hacking white hat e black hat se espalhou rápido, esses problemas foram sendo resolvidos relativamente depressa.
Eu trabalhava numa instituição financeira com uma cultura de segurança da informação muito forte. Depois que a empresa foi adquirida, começaram a chegar pedidos por e-mail de fornecedores externos em nome de executivos da matriz. Só que, pela política de segurança que já existia, atender esse tipo de e-mail era proibido. Então, no Slack, todo mundo concordou que, mesmo sendo e-mails reais, pela política eles deveriam ser reportados como phishing sem exceção. No fim, era uma espécie de descumprimento sem má intenção, mas na prática isso era o certo a fazer. Depois, um executivo da matriz começou a mandar avisos prévios dizendo “esse tipo de e-mail vai chegar, então reajam assim”. Aí a discussão entre os colegas virou: “e como sabemos que esse aviso prévio também é verdadeiro?”. No fim, todo mundo se cansou e acabou aceitando as práticas de segurança mais frouxas da matriz.
Acho que, em organizações desse tipo, existe uma estrutura social em que pessoas competentes e capazes de tomar a decisão correta têm dificuldade de chegar a posições com poder de decisão real. Para criar boas políticas, você precisa dizer “não” para muita coisa, e isso torna muito difícil agradar quem manda nas promoções.
Mesmo no papel existindo CISO, EVP, SVP, diretor de segurança e outros cargos altos, eu realmente não entendo por que tomam decisões tão absurdas. Nesses casos, é difícil distinguir incompetência de malícia. Chamar isso de “ingenuidade” parece até uma forma de desculpar um comportamento que despreza o cliente. Levar segurança a sério custa dinheiro, mas não levar também traz prejuízo. Só que, pelo menos por enquanto, a perda por afastar usuários ainda é menor que o custo de fazer as coisas de forma realmente segura e correta, então esse modelo continua. No fim, é triste para todo mundo.
O banco me liga com frequência para fazer marketing aleatório e, antes mesmo de explicar a oferta, pede minha data de nascimento e o nome da minha mãe. Quando eu retruco dizendo “prove primeiro que você é realmente do banco”, eles sempre ficam desconcertados.
Quando alguém em uma ligação desconhecida pede para eu confirmar meus dados pessoais, eu sempre respondo: “Não sei quem você é, então não posso passar informações pessoais”. Metade simplesmente desliga, e a outra metade já emenda no discurso de vendas.
Vivo a mesma coisa na área da saúde. O consultório de um especialista liga e, assim que a chamada começa, já pede minha data de nascimento. Quando eu me recuso, a pessoa do outro lado fica muito surpresa. Eu penso da mesma forma: se foi você quem ligou para mim, então é você que deve provar sua identidade primeiro.
Meu banco acabou entendendo isso e hoje tem um sistema em que, pelo app, dá para verificar se aquele atendente está mesmo em atividade comercial e exatamente qual funcionário ele é.
A ideia de “então a solução é registrar subdomínios” existe porque alguém do TI sabe que delegar autoridade por subdomínio pode ser perigoso e por isso barra a proposta. Então outros departamentos da empresa, como marketing, acabam contornando isso registrando domínios próprios separados. Fico curioso sobre como empresas como o Google resolvem isso. Um comprometimento de subdomínio de google.com seria um alvo extremamente valioso, mas ainda assim o Google usa subdomínios com bastante frequência. Há um exemplo relacionado neste link do gist.
Na prática, muitas vezes isso nem passa pelo TI. Marketing é separado de TI na estrutura organizacional e não gosta de depender deles. O TI usa sistemas de tickets ineficientes e lentos e, muitas vezes, ainda dá opiniões desnecessárias, então o pessoal de marketing acha um incômodo. Por isso campanhas promocionais são entregues a serviços SaaS ou fornecedores externos, que também não têm ligação com o TI corporativo. O pessoal de marketing muitas vezes nem sabe o que é um subdomínio; trabalha só pesquisando no Google ou clicando em links. Como ninguém olha o texto da URL, nem percebem por que subdomínio seria importante. Observando o jeito como as pessoas realmente usam a internet, o treinamento tradicional anti-phishing perde o sentido. Na prática, “pesquisar no Google e clicar no primeiro resultado” é uma forma mais realista de prevenção do que “ler cuidadosamente o domínio”.
O Google também é frustrante nesse aspecto. Mensagens de aviso chegam em formatos que facilmente parecem phishing, e eles usam uma variedade de domínios estranhos além de google.com, como goo.gl e foobar.google. Já passou o tempo em que dava para confiar nisso sem questionar.
Acho que o ponto principal é o item 4. Se um banco envia e-mails aos clientes que parecem phishing, isso deveria ser considerado negligência grave e gerar responsabilidade legal.
Este é um caso claro da lei de Conway em ação. O departamento de marketing tem seu próprio TI e é separado do TI que administra o site principal. Então eles não conseguem desenvolver juntos no mesmo domínio web e acabam lançando um site separado, com uma experiência separada.
Na empresa onde um amigo trabalha, o CISO enviava uma newsletter de segurança para todos os funcionários, mas o e-mail vinha de um domínio externo, não do domínio interno da empresa, e os links também iam para uma plataforma externa de hospedagem, então sempre parecia phishing. Quando havia sorteios ou brindes, parecia ainda mais falso, especialmente porque, dada a reputação da empresa, prêmios tão generosos não combinavam com a realidade.