1.

Un cajero automático está compuesto por subsistemas electrónicos con

controladores industriales. Sin embargo, tras los terminales hay un ordenador
totalmente convencional que controla el sistema, en muchos casos con un sistema
operativo anticuado.
2. Si el cajero funciona con Windows XP, ya no recibirá el soporte técnico de
Microsoft con lo que cualquier vulnerabilidad que sufra se quedará sin parchear,
quedando desprotegido frente a los ataques de los hackers.
3. L s sistemas de los cajeros cuentan con un software vulnerable, desde
reproductores de Flash sin actualizar, y con más de 9.000 bugs conocidos, hasta
herramientas de administración remota.
4. Los fabricantes de estos terminales suelen pensar que los cajeros siempre operan
en condiciones normales y que no tienen errores de funcionamiento. Por ello, en
muchos casos, los cajeros no cuentan con antivirus, ni con autenticación de la
aplicación que se encarga de envíar comandos al dispensador de efectivo.
5. Si una parte del cajero no contiene dinero ¿por qué preocuparse de su seguridad?
Lamentablemente, esto es lo que piensan la mayoría de fabricantes de cajeros.
Así, acceder al depósito y dispensador de billetes es una tarea complicada ya que
suelen estar blindados y bloqueados. Sin embargo, el acceso al ordenador del
cajero es bastante sencillo. Las medidas de seguridad no son suficientes para
detener a los cibercriminales, ya que el ordenador está protegido únicamente por
una carcasa de plástico o un fino metal.
6. Los módulos de los cajeros automáticos suelen estar conectados con interfaces
estándar, normalmente a través de puertos USB y COM (puerto serie). Sin
embargo, muchas veces se puede acceder a distancia a la interfaz.
7. Dado que Internet es la forma de comunicación más económica hoy día, los
bancos usan la Red para conectar los cajeros automáticos a sus centros de
procesamiento. Sin embargo, muchos bancos no saben que sus terminales
aparecen en el motor de búsqueda Shodan. Este site permite a cualquiera
encontrar una gran variedad de sistemas conectados sólo con la palabra “admin”
como nombre de usuario y “1234” como contraseña, quedando así demostrada la
poca seguridad de estos dispositivos.

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:

• Cifrado de comunicaciones (se suele usar VPN por que la comunicación del propio software
no se permite cifrado por iniciativa de interoperabilidad)
• Cifrado de disco
• Protección de BIOS
• Configuración de nuevos componentes (verificar que se puedan poner en producción y emitan
errores si es necesario en el Journal Virtual)
• Pasar los estándares Payment Card Industry
• Compra de soluciones Antivirus, Antimalware, listas blancas
• 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 ;) )
• 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
• Políticas de seguridad del sistema operativo Windows
o Gestión de contraseñas (lo administra el dueño del ATM)
o Restricción de accesos (lo administra el dueño del ATM)
o Protección de llaves acceso al software (lo administra el fabricante es su puerta de acceso)
o 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)
• Dispositivos anti skimming
• Políticas de respuesta a incidentes, políticas de detección, remediación, recuperación etc..
(todas las políticas que quieras pueden existir)
• 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 ej1emplo 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.