Riesgos de banca abierta

Las olas de la tormenta digital cubren más y más sectores de la economía, formando una nueva realidad. La industria financiera no fue la excepción: los países, uno tras otro, están desarrollando e implementando un enfoque revolucionario para el trabajo de las instituciones de crédito: el concepto de banca abierta o banca abierta.

Open Banking es una interfaz de software unificada para los sistemas de información bancaria. Puede ser utilizado por desarrolladores de aplicaciones financieras, empresas fintech, para proporcionar a los clientes servicios financieros de nueva generación.

La interacción con los bancos a través de una interfaz abierta no es solo oportunidades, sino también riesgos. En esta publicación, consideraremos los riesgos y amenazas que surgen con la implementación de Open Banking, y discutiremos las posibles opciones de protección contra ellos.

Sobre empresas fintech

A pesar del deseo de los bancos de crear productos financieros innovadores, les resulta difícil competir a este respecto con empresas de tecnología financiera que no están conectadas por los requisitos del regulador y las regulaciones internas. Y la competencia entre los bancos y el deseo de atraer clientes al servicio exactamente para sí mismo impone restricciones naturales a la creación de servicios que integran los servicios de varias instituciones de crédito.

Las empresas fintech se comparan favorablemente con los bancos conservadores. Pueden permitirse atraer clientes de diferentes bancos, introducir rápidamente nuevos productos no estándar y aprovechar todas las ventajas de la independencia del regulador.

La naturaleza dinámica de las empresas financieras y tecnológicas es, en cierta medida, una consecuencia de sus características organizativas. Un análisis de los proveedores de tecnología financiera realizado por Trend Micro en preparación para el estudio " Listo o no para PSD2: Los riesgos de la banca abierta " mostró que la mayoría de estas empresas:

• tener un pequeño número de empleados;
• limitado en recursos financieros;
• utilizar activamente la infraestructura de la nube para el trabajo;
• aplicar virtualización y contenedorización de servicios;
• Utilice SDK de terceros para acortar el ciclo de desarrollo y centrarse en la innovación;
• acortar el ciclo de prueba para ahorrar tiempo y dinero. Esto no es sorprendente. Este enfoque se practica en un esfuerzo por reducir los costos incluso por parte de gigantes como Microsoft, que ha abandonado los evaluadores a tiempo completo en favor de los participantes en el programa Windows Insider.

La otra cara de estas características es una vulnerabilidad significativamente mayor en comparación con los bancos. Con el creciente número de países que introducen la Banca Abierta, el panorama de amenazas se está volviendo más diverso, ya que los cibercriminales tienen a su disposición nuevos objetivos para los ataques. Hablemos de ellos con más detalle.

Objetivos para los ataques de banca abierta

API públicas del banco

La API abierta, implementada en bancos europeos de acuerdo con PSD2 , la “Directiva revisada de servicios de pago”, es solo parte de un gran proceso. La implementación de tales interfaces de programación se está llevando a cabo en muchos países. En algún lugar, estos trabajos son una iniciativa para unir empresas privadas y bancos. Por ejemplo, el desarrollo de la API de datos duraderos en los EE. UU. Está respaldado por la asociación sin fines de lucro FDX , una subsidiaria del Centro de Análisis de Información de Servicios Financieros (FS-ISAC) . Otros gobiernos prefieren tomar el control total del proceso, como México, que aprobó la Ley Fintech , o Australia, en el que el acceso fintech a las interfaces de programación bancaria es solo una parte de un gran conjunto de eventos llamado Consumer Data Right .


El crecimiento de avalanchas de API financieras que se están introduciendo en el mundo. Fuente: Trend Micro

Un aumento en el número de API de banca pública conducirá inevitablemente a un aumento en los intentos de usarlo con fines de lucro. ¿Por qué romper la protección del banco si hay una interfaz a través de la cual puede civilizarse para conectarse a un sistema automatizado y transferir un par de millones a usted mismo?

Un estudio realizado por Trend Micro reveló un número significativo de bancos que divulgan información confidencial: contraseñas únicas, tokens de acceso, correos electrónicos, IMEI y datos de transacciones en API y URL de sitios web.

Aunque el uso de SSL protege contra la intercepción del tráfico, la transmisión de dicha información en la URL es peligrosa porque estos parámetros:

• Puede aparecer en los registros del servidor web;
• Se mostrará en la URL del navegador;
• Aparecer en el historial de navegación del navegador;
• Serán visibles para cualquier dispositivo que realice la intercepción SSL, por ejemplo, equipos de monitoreo de red con un certificado de confianza.

Datos confidenciales en URL de API bancarias. Fuente: Trend Micro

En algunos navegadores, el historial de navegación se comparte entre dispositivos, como una computadora portátil, teléfono inteligente y tableta. Mostrar información confidencial en una URL debilitará potencialmente la eficacia de la autenticación multifactor, permitiendo que los piratas informáticos ataquen los dispositivos menos seguros para robar esta información.


Ejemplo de la vida real: una empresa europea de tecnología financiera con millones de clientes ha publicado documentación de API que indica que las direcciones de correo electrónico, contraseñas, contraseñas e identificadores de clientes se envían en URL de API.
Fuente: Trend Micro

Otro método de uso malicioso de las API públicas son los ataques DoS / DDoS. Cualquier pirata informático interesado puede probar el método de prueba y error para encontrar una combinación de parámetros que causará una falla en el servicio.

Aplicaciones móviles

Además de los ataques tradicionales a aplicaciones móviles que utilizan superposiciones y otras opciones familiares, el uso de SDK de terceros también conlleva un peligro adicional.

Hay casos en los que se les introdujeron funciones maliciosas que suscribieron al usuario de un programa que usa esta biblioteca a SMS premium o servicios pagos, como E xpensiveWall, que estaba incrustado en la biblioteca gtk , o DrainerBot, que se introdujo en Tapcore SDK y mostró videos invisibles para engañarlos. .

En algunos casos, las aplicaciones inicialmente seguras y útiles de repente se volvieron maliciosas, como el creador CamScanner - Phone PDF, que de repente obtuvo una biblioteca con características troyanas .

Obviamente, la funcionalidad oculta en los programas para trabajar con datos financieros puede tener las consecuencias más desagradables.

E incluso si las aplicaciones de Open Banking están limitadas en el derecho a pagos en nombre de los clientes, los atacantes aún podrán usarlas para obtener ganancias. Los datos sobre transacciones completadas también son un bien valioso. La información sobre cuándo y dónde se realizan las compras le permite tener una idea de los movimientos diarios de los usuarios, sus hábitos, intereses y situación financiera.

Otro objetivo para atacar aplicaciones móviles son los informes de errores. Si la aplicación falla, la información sobre el estado del dispositivo y las circunstancias que causaron el error se envía al servidor del desarrollador. Además, la información transmitida también puede contener información confidencial:



Informe de error Fuente: Trend Micro

Si un atacante compromete al desarrollador de software para los informes de fallos, obtendrá acceso a esta información.

Infraestructura de empresas fintech

El uso de infraestructura en la nube para la implementación de proyectos fintech es una forma razonable de salvar a la empresa del costo de adquirir servidores "de hierro" y garantizar su buen funcionamiento. Sin embargo, en este caso, se agrega otro participante a la empresa, el banco, el cliente y la organización fintech: el proveedor de servicios en la nube.

Los piratas informáticos pueden organizar un ataque a la cadena de suministro al infiltrarse en la red del proveedor de la nube. Tal ataque afectará a varias compañías fintech que tienen recursos en esta nube. Su peligro es que ni los clientes, ni los bancos, ni las empresas fintech aprenderán sobre el compromiso, ya que el ataque ocurrirá fuera de su alcance.

Los usuarios

Los ataques a los usuarios están en primer lugar en términos de eficiencia y relevancia. Son mucho más simples y más baratos de implementar que los ciberataques "técnicos".

Durante su trabajo con los usuarios, los bancos lograron asegurarse de que los correos electrónicos de phishing masivo como “Sus credenciales para SuperCredit Bank no estén actualizadas. Haga clic aquí para restablecer la contraseña "perdió su efectividad. Los usuarios se han vuelto más cautelosos con ellos.

Cuando se trabaja con una aplicación fintech, esta experiencia ya no es aplicable. Por lo tanto, la carta "Somos una empresa de tecnología financiera MegaTech, un proveedor de servicios para SuperCredit Bank. Haga clic aquí para actualizar los detalles de su cuenta. ”Parece completamente seguro. Los usuarios no se dan cuenta de que la contraseña de la cuenta del proveedor fintech es tan importante como la contraseña del banco de Internet. Y lo más triste es que los bancos no se enterarán del compromiso del usuario.

Una forma más difícil de atacar a los usuarios son las aplicaciones fintech falsas, que se muestran en Play Market o App Store, y luego roban credenciales, información financiera y dinero.

Cómo proteger la banca abierta

La lucha efectiva contra los estafadores proporciona un conjunto de medidas, y la banca abierta no es una excepción. Enumeramos las formas de proteger a los clientes fintech de las amenazas.

Autenticación multifactor

Este es un requisito obligatorio de la directiva PSD2 y regulaciones similares relacionadas con la Banca Abierta. Según Microsoft, el uso de autenticación de múltiples factores bloquea el 99.9% de los intentos de crackear cuentas.


Tres ballenas de AMF: conocimiento, posesión, biometría. Fuente: WSO2

Además de MFA, PSD2 agrega el concepto de vinculación dinámica : el uso de código de autenticación que depende de la cantidad y el destinatario. Cualquier cambio en estos parámetros invalidará este código.

API segura

Como tal, Open Banking propone utilizar la API de grado financiero (FAPI) , una interfaz de software basada en OAuth 2.0. FAPI, que está siendo desarrollado por la Fundación OpenID y la organización británica para la implementación de la banca abierta.

FAPI es una versión más segura del protocolo OAuth 2.0, que permite a terceros acceder a un proveedor de servicios sin proporcionar credenciales de usuario. En lugar de una contraseña, un tercero recibe un token para acceder a los datos del usuario después de obtener su consentimiento explícito. El usuario controla los derechos de acceso de terceros con la ayuda de un token, por ejemplo, acceso temporal y acceso de solo lectura. Puede retirar el token en cualquier momento y, en caso de robo, no se requiere un cambio de contraseña, ya que no se le proporcionó a nadie.


Interacción con FAPI. Fuente: Trend Micro

Los desarrolladores de FAPI han agregado módulos de seguridad a OAuth 2.0. Entre estos módulos, vale la pena señalar:

• mTLS (mutuo TLS) es un protocolo de autenticación mutua similar a HTTPS, pero aquí no solo el servidor confirma su autenticidad al cliente, sino también el cliente al servidor. En otras palabras, para completar una transacción, una aplicación fintech no solo debe verificar la autenticidad del servidor, sino también confirmar su autenticidad al servidor.
• Enlace de token OAuth 2.0 (OAUTB): enlace de tokens de acceso y / o códigos de autorización a una conexión TLS. Si un atacante roba un código de autorización, no podrá usarlo en otra conexión TLS. Desafortunadamente, el token token actualmente solo es compatible con Microsoft Edge.
• Declaraciones de clientes Firma web JSON (Afirmaciones de clientes JWS): establece que solo un cliente específico puede usar el token de acceso en el servidor de autorización bancaria.
• Clave de verificación de intercambio de código (PKCE): ayuda a evitar que los atacantes usen un token de acceso de cliente. Para hacer esto, la aplicación envía un código de verificación adicional al servidor de autenticación para confirmar que el cliente quiere usar este token de acceso.

Actualmente, la FAPI ha identificado problemas de seguridad que deben abordarse.

Infraestructura y seguridad de punto final

La protección de la infraestructura de las empresas de tecnología financiera es un factor importante que cierra las lagunas para los piratas informáticos. Deben protegerse los puntos finales , los sistemas en la nube y los mecanismos de desarrollo , así como el monitoreo de extremo a extremo de toda la infraestructura .

Hablamos sobre la seguridad de los puntos finales en la publicación Cuando los muros no son suficientes. Cómo proteger los puntos finales " .

Conclusión

Cualquier tecnología nueva requiere no solo la consideración de las perspectivas, sino también un análisis cuidadoso de los riesgos que plantea. Es especialmente importante considerar los peligros en el caso de que se esté introduciendo un nuevo enfoque en el campo al que tradicionalmente se ha dirigido la atención más cercana de los ciberdelincuentes.

Open Banking ya está cambiando el panorama de las relaciones financieras. En los próximos años, estos cambios pueden cambiar nuestras vidas, revolucionando la forma en que administramos nuestro dinero. Para que estos cambios sean positivos, es extremadamente importante que las empresas de tecnología financiera, los bancos y otros participantes en el proceso no solo tengan en cuenta las amenazas identificadas, sino que también refinen rápidamente las API y los estándares para eliminar los problemas de seguridad.