Mi banco sigue socavando la educación contra el phishing
(moritz-mander.de)- El banco envía correos promocionales de eventos parecidos a emails de phishing y poco confiables
- Los enlaces y dominios del sitio en el contenido parecen no tener relación con el banco, y al pedir datos personales cuesta distinguir si es phishing
- Incluso después de verificar su autenticidad, saber que era un evento oficial solo aumentó la confusión y la desconfianza
- Esta práctica socava el propósito de la capacitación anti-phishing y eleva el riesgo de que el banco termine asumiendo responsabilidad legal
- Para resolver el problema, se enfatiza la necesidad de usar dominios confiables e implementarlo dentro de la app
Introducción
Viví en carne propia la realidad de que mi banco socava directamente la educación contra el phishing. Un correo sobre un evento enviado por el banco tenía características tan sospechosas que era casi imposible distinguirlo de una estafa de phishing. Pedía ingresar datos personales en un sitio que no usaba el dominio oficial del banco, y esto pone en evidencia los problemas del estado de la seguridad y de la formación en bancos e instituciones públicas, tanto dentro como fuera del país.
Capítulo 1: Llega un correo sospechoso
- Recibí un correo del banco relacionado con “Wero-Win-Wochen” (evento con premios)
- El aviso por correo invitaba a participar en el evento, indicando que se podía ganar hasta 7,000 euros por semana
- En el correo se mencionan Sparkasse (organización de cajas de ahorro regionales de Alemania) y Wero (un nuevo sistema europeo de pagos digitales)
- El enlace dentro del correo apunta a “gewinnen-mit-wero.de”, distinto del dominio oficial del banco
- El contenido y el tono se parecen a un correo de phishing común; solo la dirección del remitente era una dirección oficial de Sparkasse
- Tuve que confirmar en el sitio oficial del banco si el evento era real
¿Qué es Sparkasse?
- Es una caja de ahorro de base regional, operada de forma independiente en cada zona
- Es uno de los grupos de servicios financieros más grandes de Europa
¿Qué es Wero?
- Es un nuevo sistema de pagos digitales creado por la European Payments Initiative (EPI)
- Fue desarrollado con el objetivo de integrar sistemas de pago locales (inicialmente centrado en pagos P2P)
- Se parece a PayPal, pero tiene una estructura distribuida entre distintos bancos
Capítulo 2: La situación empeora – un sitio web sospechoso
- El sitio para participar en el evento al que lleva el enlace del correo tiene un diseño y una estructura muy parecidos a los de un sitio de phishing
- No menciona ninguna sucursal de Sparkasse ni distingue entre bancos (ignorando la independencia de cada entidad)
- El dominio en sí no tiene relación con el dominio oficial del banco y usa un nombre genérico que cualquiera podría registrar
- Incluso usa un certificado SSL gratuito de Let’s Encrypt, lo que reduce la confianza
- Falta contexto o justificación sobre el evento; solo se enfatiza “la oportunidad de recibir dinero”
- Para participar, pide ingresar nombre, fecha de nacimiento, IBAN, correo electrónico y otros datos personales y financieros
- Esto contradice la tendencia habitual de que los eventos financieros digitales modernos estén diseñados para participar solo dentro de la app
Como resultado, la propia institución financiera termina volviendo inútil, a propósito o no, la educación de seguridad dirigida a los usuarios.
El problema de debilitar el efecto de la educación en seguridad
- Si hasta un banco real usa métodos parecidos a correos y sitios de phishing, los usuarios dejan de confiar en la propia formación para detectar phishing
- Se extiende la idea de que “esto parece spam, pero igual podría ser legítimo”
- En el pasado, este banco ya había enviado SMS oficiales con frases y dominios sospechosos (por ejemplo, un enlace a paperless.io)
- Ni siquiera el centro de soporte entiende por qué esto puede parecer spam
Capítulo 3: ¿Cuál es la solución?
- La opción más segura es implementar directamente el proceso de participación del evento dentro de la app
- Si eso no es posible, se debería usar el dominio oficial (por ejemplo, sparkasse.de) o un subdominio de cada sucursal para mantener la confianza
- El gobierno alemán también reforzó la confianza de sus servicios en un caso similar al introducir la política de marca digital gov.de
Capítulo 4: La posibilidad de que la negligencia se convierta en un problema legal
- Últimamente están aumentando los fallos judiciales que obligan a los bancos a indemnizar a víctimas de phishing
- Al determinar si hubo “negligencia” en la filtración de datos personales, los tribunales concluyen que si no hubo culpa del usuario, la responsabilidad recae en el banco
- Si un ataque de phishing ocurriera usando una estructura de correo y sitio como la actual, al banco le sería difícil demostrar que la víctima no actuó con prudencia
- Como el correo y el sitio oficiales del banco se parecen demasiado al phishing real, el riesgo legal aumenta
Conclusión
- Aunque la seguridad técnica ha avanzado, todavía quedan grietas en la seguridad de la experiencia de usuario (USABLE SECURITY)
- Casos como este dañan la confianza en la educación anti-phishing, aumentan la carga legal de los bancos y afectan negativamente al sistema financiero en general
- El problema no se resuelve fácilmente con retroalimentación individual, sino que es un problema estructural del sistema
- Hace falta reconocer con mayor seriedad que esto ocurre incluso en uno de los grupos financieros más grandes de Europa
- La lección final es: “No socaven la educación en seguridad. Mejor préstenle un poco de atención”
2 comentarios
Parece que esa sensación de déjà vu no es solo una ilusión 🤣
Opinión de Hacker News
Mi banco usa un sistema de detección de fraude que me llama cuando detecta actividad sospechosa en mi cuenta, y me pide que vuelva a llamar a cierto número. El problema es que cada vez me da un número de devolución distinto. Si buscas ese número en internet, solo aparece un resultado: la página oficial del sistema de detección de fraude diciendo que no confíes en ninguna llamada por teléfono. Ese consejo tiene sentido, pero irónicamente también implica ignorar incluso sus contactos legítimos.
La única vez que activé el sistema de detección de fraude de mi tarjeta, recibí un mensaje del banco diciendo: “Tu tarjeta fue bloqueada por uso sospechoso, por favor llama al siguiente número”. Ese número también era uno no listado, asignado al azar. La única razón por la que no lo ignoré fue que justo antes había hecho un pago en un sitio web nuevo. Así que llamé directamente a mi banco local para confirmar si la situación era real, y me dijeron que sí. Casi termino desahogándome sobre lo mal diseñado que está ese proceso.
Parece que no hay nadie a cargo de cuidar todo el flujo de experiencia de usuario (UX) del banco. El mío también funciona de manera parecidamente rara. Por ejemplo, cada vez que le transfiero dinero a mi esposa, siempre me hacen varias preguntas por prevención de fraude; pero si las respondo, luego aparece otro mensaje diciendo que “como haces transferencias frecuentes, no se te pedirá código 2FA ni autenticación adicional”. Un UX tan poco lógico probablemente existe porque no hay una sola persona o un solo equipo cuidando el flujo completo.
Los bancos no siguen ni sus propias reglas. Una vez me llamaron del banco por un cambio de seguro que yo había solicitado un mes antes, y me pidieron autenticarme con un dongle de seguridad. Así, la verdad no sorprende que la gente termine cayendo en estafas.
El banco donde trabajo envía mensajes preguntando si emitiste un cheque por “$x” para verificar si hay alguna anomalía. El problema es que la estafa con cheques más común es el “check washing”, donde dejan intacto el monto del cheque y solo falsifican al beneficiario. En ese caso, parece una transacción legítima porque el monto coincide, pero no se puede verificar a quién se le pagó realmente.
Aunque llame al número general del banco y espere un buen rato hasta que me atienda un agente, me dicen que no reconocen ese número aunque en realidad sí sea correcto. Lo más molesto es cuando se trata de un banco que no uso: llamas al número de su sitio web y te mandan directo a un sistema automatizado, y si no tienes número de cuenta ni siquiera puedes acceder, así que tienes que buscar otro número de contacto para poder hablar con una persona.
Mi banco (USAA) incluso ha implementado antes algunas cosas que yo les sugerí. Pero recientemente recibí un correo que parecía legítimo en mi dirección única de email, aunque venía de un dominio distinto al habitual. Me pareció todavía más sospechoso porque acababa de hacer un trámite. Llamé de inmediato al banco y hablé con alguien del departamento de fraude; le expliqué el problema diciendo que “o su sistema interno fue comprometido o están acostumbrando gradualmente a sus clientes al phishing”, y pedí que levantaran un ticket. La persona me dijo que ese dominio no pertenecía a USAA y que ellos siempre usaban usaa.com, y sin más me bloqueó la cuenta. Al final tuve que volver a llamar para que la desbloquearan, y me dijeron que sí habían creado el ticket. Habrá que ver cómo sigue.
Las prácticas tecnológicas y de marketing relacionadas con la experiencia de usuario de los bancos son pésimas. Todos los formularios de inicio de sesión de bancos indios que he usado son:
¡¿No permitir más de 15 caracteres?! Mi banco exige exactamente 6 dígitos, ni siquiera letras, solo números. No puedes usar gestor de contraseñas ni copiar/pegar, y tienes que hacer clic con el mouse en cada casilla numérica. En su obsesión con la “seguridad”, la autenticación secundaria pasó antes de token físico a app, y al final terminó en SMS. Y no estamos hablando de un banco local pequeño, sino del banco más grande de Francia.
Hace unas semanas hubo polémica en Reddit por una captura que mostraba que la app de un banco público de India bloqueaba la app solo porque el usuario tenía instalado Firefox. Los bancos y sitios del gobierno son extremadamente hostiles con los usuarios. Antes pensaba que este enfoque buscaba proteger a quienes no dominan la tecnología, pero ahora me parece más bien una excusa para no adoptar frameworks realmente seguros y cómodos.
Cierta app de un banco público indio ni siquiera arranca si no le concedes permisos esenciales como cámara, sistema de archivos completo, etc. Pero en mi banco nunca he recibido spam como el del OP. Eso sí, existe la percepción generalizada de que empleados de bajo nivel filtran habitualmente información de cuentas a estafadores.
Mi banco obliga a cambiar la contraseña cada 180 días, solo permite contraseñas de 6 a 11 caracteres y además restringe qué caracteres puedes usar. Entonces intentas iniciar sesión y te obliga otra vez a cambiar la contraseña; las contraseñas autogeneradas de Firefox no cumplen con las reglas del banco, así que al final tengo que generar manualmente una contraseña aleatoria desde la terminal para que sí encaje.
No entiendo muy bien por qué sería un problema usar hash de contraseña del lado del cliente.
Esto es todavía peor al comprar o vender una casa. Hay muchas suborganizaciones distintas, cada una usando dominios diferentes, y todo se vuelve más complejo. A mí me pasó algo parecido con un retiro de dispositivos médicos del mercado, donde tuve que confiar en un dominio sospechoso. Esto se resolvería fácil si simplemente publicaran en su página principal una lista de dominios confiables de socios. Mi protocolo personal de seguridad consiste en buscar los datos de contacto de la institución financiera en un sitio .gov, entrar al dominio que aparece ahí, revisar el número de atención al cliente y llamar para averiguar cuál es el dominio realmente confiable. A los agentes de atención normalmente les parecía que yo era raro. Una vez incluso un agente me dijo: “Si en LinkedIn aparece que esa persona trabaja en <Bank Name>, entonces sabes que es real”.
Cuando me dijeron “si en LinkedIn sale que trabaja en <Bank Name>, puedes confiar”, les respondí: “Dame dos minutos y también puedo poner eso en mi perfil. ¿Entonces también me darías mis datos personales?”.
Mi experiencia comprando casa no fue nada complicada. Tramité la hipoteca a través de un corredor y solo traté uno a uno con una sola persona.
La gente ingenua que tiene poder de decisión no termina de entender estos riesgos hasta que ellos mismos o alguien cercano sufre una estafa o un problema legal. En Estados Unidos también había muchas personas así dirigiendo empresas antes de 2012, pero como el hacking white-hat y black-hat se expandió rápido, estos problemas se corrigieron relativamente pronto.
Antes trabajé en una empresa financiera con una cultura de seguridad de la información muy sólida. Después de que la compraron, empezaron a llegar correos de proveedores externos a nombre de ejecutivos de la oficina central pidiendo todo tipo de cosas. Pero bajo la política de seguridad que ya existía, tramitar esos correos estaba prohibido, así que en Slack todos nos pusimos de acuerdo en que, aunque fueran correos reales, debíamos reportarlos como phishing de todos modos. En la práctica era una negativa no maliciosa, pero en realidad esa es la mejor práctica. Después un directivo de la oficina central incluso empezó a mandar correos previos diciendo “va a llegar este email, por favor reaccionen así”. Entonces entre colegas volvimos a discutir: “¿Y cómo sabemos que ese correo previo también es real?”. Al final todos se cansaron y terminaron aceptando las prácticas de seguridad más laxas de la oficina central.
Creo que en organizaciones de este tipo existe una estructura social que dificulta que la gente capaz de tomar decisiones correctas llegue a posiciones donde realmente tenga poder de decisión. Para crear buenas políticas hay que decir “no” muchas veces, y en ese proceso lo más difícil es no quedar mal con quienes controlan los ascensos.
De verdad no entiendo por qué toman decisiones tan absurdas cuando en el organigrama sí existen cargos altos como CISO, EVP, SVP, directores de seguridad, etc. En estos casos es difícil distinguir entre incompetencia y mala fe. Si lo llamas “ingenuidad”, casi parece una forma elegante de justificar un comportamiento que desprecia al cliente. Preocuparse por la seguridad cuesta dinero, y no hacerlo también genera pérdidas, pero por ahora parece que perder usuarios todavía cuesta menos que hacer las cosas de forma segura y correcta. Es una realidad triste para todos.
El banco me llama seguido con llamadas de marketing al azar, y antes de explicarme sus ofertas me pedía mi fecha de nacimiento y el apellido de soltera de mi madre. Cuando yo les respondía que primero me demostraran que realmente eran el banco, siempre se quedaban desconcertados.
Cuando una llamada desconocida me pide confirmar datos personales, siempre respondo: “No sé quién eres, así que no puedo darte información personal”. La mitad simplemente cuelga y la otra mitad pasa de inmediato al discurso de ventas.
Me pasa exactamente lo mismo en el sector médico. El consultorio del especialista llama y lo primero que pregunta es mi fecha de nacimiento; si me niego, se sorprenden muchísimo. Yo pienso igual: si ellos son quienes llaman, entonces primero deberían probar quiénes son.
Mi banco finalmente entendió esto, y ahora implementó un sistema donde puedes verificar desde la app que ese asesor realmente está haciendo una gestión comercial y exactamente qué empleado es.
La idea de “entonces la solución es registrar subdominios” nace de que alguien en TI sabe que delegar autoridad mediante algo como subdominios es arriesgado y por eso lo rechaza. Al final, otros departamentos dentro de la empresa, como marketing, simplemente registran sus propios dominios para saltarse esa restricción. Me pregunto cómo lo resuelven empresas como Google. Comprometer un subdominio de google.com sería uno de los objetivos más atractivos, y aun así Google también usa subdominios con bastante frecuencia. Como ejemplo relacionado, se puede ver este enlace a gist.
Muchas veces ni siquiera pasa por TI. Marketing está separado de TI en la estructura organizacional y no quiere abrir tickets con ellos. TI usa sistemas de tickets lentos e ineficientes y a menudo mete opiniones innecesarias, así que en marketing les da flojera tratar con ellos. Por eso las promociones de marketing se delegan a servicios SaaS o proveedores externos, que tampoco tienen mucha relación con el TI corporativo. Quien trabaja en marketing ni siquiera sabe qué es un subdominio; simplemente opera buscando en Google o dando clic en enlaces. Nadie mira realmente el texto del URL, así que ni siquiera existe conciencia de por qué importaría un subdominio. Si ves cómo usa internet la gente en la práctica, la educación tradicional anti-phishing pierde sentido. Más que “leer cuidadosamente el dominio”, una defensa anti-phishing más realista es “buscar en Google y hacer clic en los primeros resultados”.
Google también es igual de frustrante en este aspecto. Sus correos informativos tienen un formato que fácilmente puede confundirse con phishing, y además usan dominios raros además de google.com, como goo.gl, foobar.google, etc. Ya pasó la época en la que uno podía confiar ciegamente como antes.
Creo que el punto central está en el párrafo 4. Si un banco envía a sus clientes correos que parecen phishing, eso debería considerarse negligencia grave y generar responsabilidad legal.
Este es un caso de la ley de Conway viéndose tal cual en la realidad. El departamento de marketing tiene su propio TI, separado del TI que mantiene el sitio web central. Por eso no pueden desarrollar juntos dentro del mismo dominio web, y terminan lanzando un sitio aparte con una experiencia aparte.
En la empresa donde trabaja un amigo mío, el CISO enviaba un boletín de seguridad a todos los empleados, pero el correo salía desde un dominio externo, no desde el dominio interno de la empresa, y los enlaces también iban a una plataforma externa de hosting en vez de al propio sitio. Siempre parecía phishing, y cuando había sorteos o premios se veía todavía más falso (además, por la reputación de la empresa, premios tan generosos no parecían creíbles).