Cómo piratas informáticos robaron US $20MM de banco mexicano

En enero de 2018, cibercriminales altamente organizados -presumiblemente Lazarus-, lograron robar entre USD $15 y $20 millones en un ataque memorable que deja muchas lecciones. En la pasada RSA 2019, Josu Losa, un experto y consultor en seguridad informática, expuso su opinión sobre los factores que habilitaron este ataque en una charla titulada “La amenaza fantasma: El ataque que desvistió a los bancos mexicanos en 2018”. Hace poco Wired hizo un artículo que se ha hecho viral, y acá te contamos los detalles, para no repetir esos errores.

Durante enero de 2018, el banco mexicano Bancomext detectó un ataque sumamente agresivo, en el que se intentaron robar USD $110 millones, y ganó esa batalla.

Unos meses después, en abril, durante la RSA 2018, entre atender a sesiones, visitar vendors y hacer networking, el consultor mexicano Josu Loza recibió el mensaje con el que los oficiales de seguridad tienen pesadillas en las noches. “Tenemos reportes de incidentes de seguridad serios”.

Seguramente el mensaje era para informar del ataque al sistema bancario mexicano, que terminó costando, en un esfuerzo concertado y coordinado, mediante robos de sumas de dinero mucho más pequeños, entre 15 y 20 millones de dólares.

Durante la pasada RSA Conference, fue el turno de José Loza presentar su opinión sobre los factores que contribuyeron a ejecutar este ataque, en una charla en la que además discute sobre los principales ataques hacia sistemas de transferencias bancarias, explica lo básico sobre los sistemas de pago, lo básico sobre construir una infraestructura segura y nos invita a vivir un ciberataque en primera persona y discutir las lecciones aprendidas.

Cuántos ataques se necesitan para que tengamos awareness?

El ataque que afectó al sistema bancario mexicano fue sólo uno dentro de la ola de ataques informáticos a bancos alrededor del planeta. El más reconocido es el que afectó a Bangladesh en febrero de 2016 y en el que cibercriminales intentaron robar mil millones de dólares. De esta misma ola forman parte los ataques que hemos visto hacia bancos en Chile y en el resto de Latinoamérica.

Cómo funcionan los sistemas de pago?

José Loza explica que la arquitectura de sistemas de pago y su operación es realmente sencilla: Un emisor (My bank o Transmitter en el siguiente diagrama) genera una transacción que es enviada a una entidad que la procesa (Payment Concentrator, en el diagrama) y autoriza. Luego, la transacción es enviada al receptor (Receiver; Other Banks), quien es responsable de emitir los pagos a la cuenta que corresponda.

Arquitectura general de una transacción interbancaria

En el proceso hay canales de comunicación, servidores, personas, aplicaciones y aplicaciones legacy…

Si observamos en detalle el esquema de Loza, podemos observar los factores que hacen la transacción interbancaria más compleja, desde el lado del emisor, puesto que interactúan con el sistema de pagos, que posteriormente interactúa con el «Payment Concentrator» o entidad que procesa y autoriza las transacciones interbancarias. 

La transacción se puede generar de diversas formas: a través de online banking, desde una sucursal, o a través de una aplicación. Se envía hacia el banco para ser procesada por una aplicación y es muy probable que pase por un server de aplicación, bases de datos, etc.

Generalmente los encargados de seguridad en un banco tienen que estar pendientes de un sinnúmero de agentes y de la carga a la red interna que las operaciones requieren, y muchos de ellos jamás se han enfrentado a un incidente similar al ocurrido. En una red bancaria compleja, interactúan ejecutivos, usuarios, desarrolladores, contratistas, y muchos de ellos están conectados al sistema de pagos. Si alguno de ellos está, además, conectado a la internet (como el Contractor en el diagrama), deja una puerta abierta hacia el Sistema de Pagos.

Cuántos ataques más se necesitan para llegar al awareness?

Entender esto desde el punto de vista del ataque es vital, puesto que cualquiera de los elementos que interactúan con el sistema de pagos, para un atacante, es un vector de ataque. Y recordemos que la ingeniería social ha demostrado ser tan efectiva para distribuir malware, que podemos afirmar que, dados los recursos suficientes, cualquier atacante avanzado puede establecer comunicación con las redes que desee si en ellas interactúan los humanos. 

Una vez que un atacante ha logrado ingresar a cualquiera de los componentes de la red, si está lo suficientemente bien capacitado, podrá, mediante técnicas de movimiento lateral, desplazarse a través de la red hasta llegar a su blanco.

Posibles formas de ataque son ganar acceso a un servidor expuesto a la internet, como el Web Server, comprometer un ejecutivo mediante phishing o spearphishing. Generalmente no se le permite a los contratistas estar conectados a la internet, pero uno de ellos encontró la forma de conectar su teléfono de ventas al computador para poder acceder a ella. En el caso de los desarrolladores, algunos meses atrás, uno de ellos, que tenía permisos de administrador, compartió sus credenciales con otro desarrollador para que pudiese desplegar más rápidamente.

Todos estos ejemplos ocurrieron en la compañía en la que trabaja Loza. Son ejemplos de la vida real.

Otra forma en que el sistema de pagos puede ser vulnerado es si ocurren ataques a la cadena de suministro. Qué pasaría si la aplicación responsable en el servidor ya contuviese código adicional que gatillase los pagos y automáticamente realizara acciones inesperadas?

Por otra parte, un atacante puede intentar comprometer al Payment Concentrator, la entidad que procesa y autoriza los pagos interbancarios. Los esquemas de red para esta entidad están constituidas por elementos similares a las de los bancos: existen servidores, ejecutivos, usuarios, desarrolladores, contratistas, etc.

Existe infraestructura similar, vulnerabilidades sin parchar, humanos desatentos a la seguridad que pueden clickear en enlaces de phishing y exponer a toda la red interna. Servidores expuestos a la internet pueden, también, ser atacados para alcanzar los objetivos de los ciberatacantes.

Loza explica que el contexto en el que ocurrió el ataque fue instrumental en el desarrollo de éste. Nadie había puesto atención ni estaba preocupado de los ataques previos a bancos fuera de México. Las regulaciones eran mínimas. No había leyes respecto del sistema de pagos. La aplicación fue comprada desde contratistas externos. Los canales de comunicación eran inseguros…

La aplicación estaba ubicada, en la red, junto a otros servidores y tenía conexión a otras aplicaciones, algunas, incluso, legacy. Las prácticas en torno al manejo de usuarios era deficiente. Un desastre esperando ocurrir.