Vulnerabilidades de la lógica bancaria avanzada Los bancos forman el núcleo de la economía. Hoy en día, los ataques cibernéticos ocurren a diario y los bancos de todo el mundo se ven afectados. En el último año, hemos observado la de varios bancos en términos de seguridad de aplicaciones móviles. Las fallas de seguridad descritas son aquellas debidas a malas prácticas de programación. seguridad åLos defectos se pueden dilucidar de la siguiente manera: Ataque de repetición Eludir el pago a un beneficiario malicioso Omitir respuesta de desafío en 2FA Para describir los ataques, considere un banco ficticio, "SPDL Bank". Los clientes del banco son Alice y Bob, y el hacker es Eve. Queremos reflejar fallas en la lógica, y usamos Charles Proxy para rastrear el tráfico SSL entre el banco móvil y el servidor del banco. Una aplicación de móvil debe permitir a los usuarios realizar un subconjunto de operaciones que pueden realizar en el banco. Por lo tanto, establecemos nuestras suposiciones de cómo debería funcionar realmente la aplicación de banca móvil. Al realizar un pago, una solicitud de pago debe ser válida solo una vez. Del mismo modo, las transferencias deberían ser posibles solo a beneficiarios aprobados y de confianza. Pasando a la respuesta de desafío, los bancos, como una capa adicional de seguridad, pueden solicitar ciertos dígitos de una contraseña (como el segundo, tercer y séptimo dígito) o una forma similar de autenticación secundaria. Solo al responder con lo solicitado se procesa la transacción. banca 1). Ataque de repetición Supongamos que Alice está transfiriendo dinero a Bob a través de la aplicación de banca móvil. La solicitud de pago debe ser válida solo una vez. Cualquier intento de proporcionar lo mismo al banco debe considerarse inválido. En un escenario práctico, supongamos que Alice está transfiriendo 10 $ a Bob de forma legítima. Bob puede emparejarse con la hacker Eve y puede repetir la solicitud 10 veces. Por lo tanto, 90 $ se desvían de la cuenta de Alice sin su autorización. La defensa contra los ataques de repetición es un nonce, o un secreto entre el cliente y el servidor en función del tiempo. 2. Omitir ataque de pago Como parte del trabajo diario, Alice transfiere 100 $ a Bob. Esta es una transacción válida ya que Bob existe en la lista de beneficiarios aprobados. Los pasos para completar una transacción son los siguientes: Alice->Servidor: Transferir 100$ a Bob Servidor-> Alice: OK; Dame números de autenticación: 1, 5, 8 Alice->Servidor: Transferir 100$ a Bob; Autenticación 1:22 5:45 8:12 Transferencia exitosa Los caracteres de autenticación se pueden considerar como pares de valores clave, donde hay 16 claves 1…16. Existen dígitos de autenticación para cada uno de estos El truco del pago de Bypass ocurre en el paso 3. Eve, el adversario puede manipular la solicitud como 3. Alice -> Servidor: Transfiere 10000$ a Eve; Autenticación 1:22 5:45 8:12 El servidor lo acepta y la transferencia se realiza correctamente. El problema es Falta de verificación en el paso 3, si el destinatario es un beneficiario Estado no mantenido entre el paso 1 y 3. Por lo tanto, el dinero puede desviarse hacia entidades malintencionadas. 3. Omisión de autenticación de dos factores Como se describe en los pasos de la transacción, se deben proporcionar los valores de autenticación. El servidor solicita 3 valores al azar de 16, como una autenticación de dos factores. Un ataque está cambiando las preguntas de respuesta al desafío. En el paso 2, cuando el banco solicita el 2FA 2. Servidor-> Alicia: OK; Dame números de autenticación: 1, 5, 8 Eve puede alterar la respuesta de la solicitud y proporcionar los 3 pares de valores clave válidos que conoce. Por lo tanto, independientemente de lo que solicite el servidor, Eve puede proporcionar los pares de valores clave que conoce, y la transacción aún se realiza. Por lo tanto, pasa por alto el mecanismo de seguridad, ya que puede falsificar cada transacción. Alice->Servidor: Transferir 100$ a Bob; Autenticación 1:22 2:99 3:10 Este ataque es avanzado y requiere que Eve posea la clave de sesión. Sin embargo, una vez que lo tiene olfateando una transacción en vivo, al combinar las vulnerabilidades 2 y 3, puede crear transacciones maliciosas. Estas fallas están relacionadas con la lógica y es posible que no se incluyan en el modelo de amenazas de los bancos, ya que asumen que la aplicación se encuentra en la base informática confiable. Sin embargo, esta suposición puede no ser cierta, dado lo fácil que es envenenar el almacén de certificados del teléfono a través de una aplicación con permisos engañosos. Public Key Pinning resolvería el problema en el sniffing. Sin embargo, puede haber un tráfico de sniffing adversario en la primera instalación y ejecución de la aplicación bancaria. Además, estas vulnerabilidades lógicas existirían incluso en la aplicación de banca web. En Spherical Defense (neural.ai), estamos desarrollando tecnología para que los bancos detecten intentos de intrusión en tiempo real utilizando Deep Learning mediante el aprendizaje de la gramática y la semántica de la comunicación confiable.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Questions about cloud security? Get answers here.

Hackear un banco : 101

Demasiado Largo; Para Leer

Dishant Shah

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Hackear un banco : 101

Demasiado Largo; Para Leer

Dishant Shah

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS