Todos en algún momento hemos utilizado un Cajero automático ATM o si no lo hemos visto por la calle, esos aparatos que sacan dinero (siempre que tengas en una cuenta asociada a tu tarjeta), la idea principal es profundizar en los vectores de ataque que existen en esas plataformas y desmitificar algunos puntos negros de la industria .

Primero que todo empezamos con identificar las tres grandes marcas:

  • Wincor Nixdorf
  • Diebold
  • National Cash register (NCR)

Son las más conocidas (si obviamos otras como triton, wrg o nautilus) y utilizadas para proporcionar servicios bancarios a clientes desde retirar dinero a consultar su estado de cuenta así como en algunos bancos hacer transacciones, depósitos u otros servicios (dependiendo del perimetral que adquiera el banco).

Para eliminar un poco el miedo, o incrementarlo, os contaré que la gran mayoría de ATMs del mundo funcionan en Windows XP y 7 (habéis leído bien, sigue habiendo ATMs en XP, sin soporte y sin licencia). Sólo menos del 1% del mundo funciona en Linux (SUSE) y para mejor tranquilidad de todos se vienen ATM en sistemas operativos en Android hechos por NCR (si no tenemos suficiente vulnerabilidades de Android cada día para que dentro de poco sean táctiles, con Android y saques dinero).

Pero las partes que caracteriza los servicios del ATM son los perimetrales (hardware) y el software que se instala en los Windows, del cual cada marca tiene su propio nombre comercial, pero que en sí, todos deben cumplir con una norma de transferencia de información mediante protocolo Exchance Financial Services (XFS) (semi regulada por el CEN europeo) también existen variaciones como J/XFS o WOSA/XFS o FREEXFS que son básicamente aceptaciones del estándar base hechas con diferentes lenguajes y fabricantes.

Luego también sobre XFS existe el software conocido como "Multivendor", básicamente un XFS que puede funcionar con diferentes marcas de ATM y permite interactuar con cada hardware de ATM (que por cierto hay un montón de versiones diferentes de hardware y de perimetrales pero también hay que decir que tienen cosas malas los multivendor).

Una lista de nombres de proveedores XFS (por nombrar algunos de los más utilizados)

  • NCR – Aptra
  • Diebold – Agilis (Puede funcionar como multivendor pero es un problemón instalarlo que no vale la pena ponerlo  como multivendor)
  • Wincore - Procash/probase (Puede funcionar como multivendor)
  • KAL – kalignite (Compañia independiente que tiene productos multivendor)
  • Dynasty - Jam services (antiguos contratistas de Diebold que ahora pertenecen a Wincor y tienen su propia gama de soluciones multivendor) 
  • FreeXFS

Todos desde fuera conocemos la carcasa de ATM o inclusive algunos de lobby podemos ver toda su envergadura.

Foto de un Diebold opteva 522FL lobby Cash Dispense

Otro punto importante es la comunicación del ATM al servidor central que permite o deniega la transacción financiera de acuerdo a las reglas (por decirlo claro si no tienes pasta en la cuenta o crédito no puedes sacar dinero, transferirlo o pagar servicios)

Algunos puntos importantes sobre el protocolo de comunicación:

• Todos los cajeros requieren comunicarse con el Core Network para verificar transacciones (para aprobar, Denegar, emitir errores o enviar mensajes específicos)

• Por facilidad y gran adaptación del mercado de cajeros a Windows como sistema operativo se utiliza una comunicación TCP/IP para la comunicación fiable con el Core network desde el ATM

• El protocolo de comunicación está basado en la Norma ISO 8583 (ISO 8583 Financial transaction card originated messages)

• La información del protocolo se transmite en TEXTO PLANO! (hay algunas soluciones para esto pero como todo es un negocio, por defecto no viene cifrado)

Generalmente, al estar en Windows los cajeros, las recomendaciones que siguen la industria de cajeros que siempre escucharan son las siguientes:

1. Cifrado de comunicaciones (se suele usar VPN por que la comunicación del propio software no se permite cifrado por iniciativa de interoperabilidad)
2. Cifrado de disco
3. Protección de BIOS
4. Configuración de nuevos componentes (verificar que se puedan poner en producción y emitan errores si es necesario en el Journal Virtual)
5. Pasar los estándares Payment Card Industry
6. Compra de soluciones Antivirus, Antimalware, listas blancas
7. Gestión de parches (depende del contrato con el fabricante generalmente suelen ser a cada 3 meses los más precavidos y algunos fabricantes no actualizan parches cruciales como Java... para qué, si java todos sabemos con no tiene fallas de seguridad ;) )
8. Correlación de eventos (básicamente esto se entiende como extraer un archivo que se llama Journal donde están los registros de todo lo que ocurre a nivel de XFS en el ATM), pero también se implementa en algunos casos a nivel de Windows
9. Políticas de seguridad del sistema operativo Windows
   • Gestión de contraseñas (lo administra el dueño del ATM)
   • Restricción de accesos (lo administra el dueño del ATM)
   • Protección de llaves acceso al software (lo administra el fabricante es su puerta de acceso)
   • Actualizaciones del sistema operativo de Windows (lo administra en algunos casos el fabricante. No en todos, pero si no hacen caso al fabricante, se quitan la responsabilidad por cualquier modificación al sistema operativo Windows,... pero al fin y al cabo es Windows)
10. Dispositivos anti skimming
11. Políticas de respuesta a incidentes, políticas de detección, remediación, recuperación etc.. (todas las políticas que quieras pueden existir)
12. Identificación del personal que tiene acceso (trasportadoras de valores, personal técnico interno , proveedor etc..)

La foto anterior detalla un poco la red bancaria desde Visa hasta el punto de atención al cliente en este caso el ATM (depende del banco pueden implementar más capas, conectores u otros servicios secundarios)

Bueno hay una larga lista de recomendaciones en promedio se pueden dar más de 300 recomendaciones desde el proceso de compra, manufactura, implementación mantenimiento etc.. No vamos a entrar en tantos detalles.

Aquí lo importante es la proliferación de malware para cajeros automáticos que según los últimos análisis de Kaspersky, son el TOP5 objetivos de ciber ataques y las faltas de prácticas correctas dejando todo a empresas de seguridad como antivirus y soluciones. La verdad que como muchos conocemos las “Big Enterprises” con productos de seguridad hacen su mejor esfuerzo pero en general utilizan soluciones reactivas (no tienen muchos métodos pro-activos) y al final llega un ruso (quien dice ruso dice ucraniano, chino o mafia... bueno ya me entendéis) y te parte en dos la red con un buen 0day. Se puede ver un ejemplo de esto en la nota extraída de la conferencia EAST, la red de pagos electrónicos en Ucrania, que tuvo su peor noche en el 2014, fue el Jackpot de 54 cajeros automáticos, que sumado, es un montón de pasta por un 0day y un poco de coding de XFS.

Los casos de malware para ATM empezaron desde la publicación de las APIs de interacción de XFS de NCR de ex trabajadores chinos y, desde ahí, ha ido migrando en múltiples malware como:

• Tyupkin y sus derivados
• Plotus y sus derivados( estaba destinado a NCR inicialmente pero existen ajustes también para diebold)
• Carbanak (estaba enfocado a comprometer la red del banco pero utiliza mensajes XFS para enviar órdenes a los cajeros automáticos para extraer dinero físicamente)
• SUCESSFULL (el primer malware multivendor)
• GreenDispenser (primera aparición finales de Septiembre 2015 en mexico también multivendor)

Hay que tener claro que las soluciones de seguridad enfocadas en software del mercado están pensadas para asegurar el sistema operativo Windows y sus aplicativos (igual te sirve para un desktop), pero NO están pensados para asegurar los dispositivos del ATM y sus comunicaciones porque generalmente suelen ser cajas bobas (que solo reciben instrucciones) para efectuar las órdenes enviadas por el host de transacciones central. Por lo que pinta, continuarán así hasta que no haya productos enfocados al core de negocio de ATMs y menos al sistema operativo

También encontramos productos como skimmers, que permiten la clonación de la tarjeta en el momento de su inserción junto con la utilización de cámaras. Krebsonsecurity tiene una sección completa explicando muchos ejemplos reales.

Esta es una slide que suelo utilizar para explicar el tipo de atacante que ha penetrado en la institución o la red y que conocimientos “teóricamente” requiere para llevar a cabo los ataques.

NOTAS:

• Generalmente las bandas menos avanzadas tecnológicamente utilizaran skimmers que se implementan en la carcasa del ATM y fácilmente adquiribles por internet
• Luego tienes las partes modificadas (que se está poniendo de moda) donde encuentran internamente (tienen acceso físico) en el ATM componentes de comunicación GSM (primeras versiones de malware utilizaban mensajes de celular para enviar ordenes mediante usb a los cajeros o hardware que se comunica mediante bluetooth para enviar la información
• Luego vienen los más avanzados que ya te comprometen una red bancaria o la gran mayoría de ATMs y que como veremos interactúan con el XFS directamente aprovechando vulnerabilidades del Windows para escalar los privilegios necesarios si así fuese necesario
• También encuentras grupos que no solo involucran conocimiento de desarrollo de software sino también de hardware para clonación de tarjetas chip EMV

En este primer nivel de presentación (aplicaciones del proveedor de ATM) que es generalmente donde el proveedor técnico interactuará mediante las aplicaciones podemos encontrar por nombrar algunas:

Diebold:

• ACU.exe
• OSD+.exe
• TMPtool.exe

NCR:

• Ulmntapp.exe

Wincor Nixdorf:

• FWMAIN32.exe
• Cfgmanager.exe

En este segundo layer (API XFS) podemos encontrar los permisos y conectores para interactuar con el XFS es la API que permite que los programadores desarrollen de la forma correcta y autorizada.

Podemos encontrar archivos como:
NCR:

• UsbEPP2.dll
• NCRUsb80.dll
• NCRDisp.dll
• Program Files/Common files/ncr/ ul*.dll

Diebold:
Aquí encontramos todas las librerías de EmPower para interacción con cada dispositivo son cientos entonces describirlas es un poco largo pero dentro de la carpeta diebold en el directorio C:/ .

En el tercer layer (XFS MANAGER) se encuentra el core de la comunicación y los estándares que todo proveedor debe de seguir de acuerdo al CEN de estándares europeo.

Su última versión 3.20 hay métodos como:

• WFS _CMD _CIM _CASH _IN
• WFS _CMD _CIM _CASH _IN _END
• WFS _CMD _CIM _CASH _IN _ROLLBACK
• WFS _CMD _CIM _RETRACT
• WFS _CMD _CIM _SET _CASH _IN _UNIT _INFO
• WFS _CMD _CIM _END _EXCHANGE
• WFS _CMD _CIM _RESET
• WFS _CMD _CIM _REPLENISH
• WFS _CMD _CIM _CASH _UNIT _COUNT

Bueno que para los que programen en C tiene todo inclusive el código fuente. Es bastante entretenido, mas de 70 pdf con todas las especificaciones (ahí esta la base de interacción de malware SUCESSFULL)

En este ultimo layer (Sistema operativo) podemos encontrar las librerías necesarias y drivers para operar la intercomunicación con los perimetrales actualmente lo más común es que todo esté conectado por USB, aunque en el caso de Diebold vienen también puertos firewire de 9 pines, básicamente nuestro sistema operativo Windows 7 professional.

Se puede acceder a cualquiera de las capas directamente, como lo demuestran los malware saltándose los controles de accesos mediante diferentes técnicas, pero como podemos ver en éste, es un ejemplo que entraremos en profundidad más adelante. Para ir entrando en materia, esto es un poco de las tripas de un cajero NCR cuando termina sus operaciones de comprobación y se dispone a enviar las instrucciones para que el "device controler" del dispensador envíe las instrucciones para dispensar/presentar el dinero requerido por el cliente

• Una de las librerías que hemos hablado para dispensar dinero. Este ejemplo es NCRDisp.dll, no vamos a entrar mucho en detalle para una introducción pero:

Como podemos ver mediante aDeviceimageUSB (de la primera foto) envía las instrucciones de kernel mode de dispensado de dinero una vez que ha verificado que la tarjeta existe, el cliente insertó el Pin correcto, luego había disposición del dinero y la transacción fue autorizada. Estos procesos de verificación no se toman en NCRDisp

Pero el deviceIOControl hace el release de la información para que lo opere el board de interacción que se encuentra dentro de la caja fuerte del ATM que mueve los cabezales para la extracción del dinero de las cajas de forma que el cliente a seleccionado.

Que si esto mismo intentamos interactuar con esta instrucción por API requeriremos la guía de desarrollo de NCR WOSA XFS (que por cierto se publico en baidu) developer guide pero requerirá de los accesos y permisos de APTRA o poner a APTRA en modo silent debug, más adelante profundizaremos en la interacción para evitar los controles.

En este otro ejemplo (de “get rick or die trying”) este mismo proceso que hemos visto en NCR lo identificamos en un Wincor Nixdorf en Windows 7. Entenderemos cómo opera para efectuar las funciones de dispensado. En este ejemplo Wincor hace uso de driver convencional usbio.sys que interactúa mediante usb para enviar las instrucciones al dispensador.

De la misma manera, en este gráfico de llamada de funciones (callgraph) se puede observar cómo se comunican entre sí. En este caso, a través del envió de IOCTLs, usando el API DeviceIoControl A su vez, esta DLL es importada por PSAPI.DLL que, de la misma manera importa la DLL necesaria para describir la comunicación con cada dispositivo.

A continuación se puede observar en el desensamblado de PSCOUT30.dll (librería que define la comunicación con el cash dispenser) una de las funciones exportadas que permiten controlar el perimetral. (En este caso: Dispensar dinero) A través de este análisis se puede percibir que cualquier proceso con privilegios elevados posee la capacidad de controlar el driver para enviarle instrucciones a los dispositivos, pudiendo en este caso, instrumentarlo para dispensar dinero.

Por lo tanto, primero requieres conseguir ciertos privilegios en el sistema operativo y luego interactuar con el "device controler".

Espero que esto haya valido como introducción, y concienciar que los ATMs son extremadamente vulnerables puesto que todo lo proveen unos fabricantes y se les hace caso ciego (100% de obediencia a lo que ellos dictan), algunos factores como la falta de acceso físico por la entidad bancaria, las constantes y dementes formas de operar la industria por seguridad mediante oscuridad y la sobre complejidad en los procesos y software de ATM solo dificultan el asegurarlo para las instituciones bancarias correctamente, porque para los ciber atacantes lo ven como un reto y con mucho beneficio liquido disponible.