Seguridad en Cajeros Automáticos ATM
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 laconferencia 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.
Fuente: http://foro.hackhispano.com
Seguridad en Cajeros Automáticos ATM
Reviewed by Zion3R
on
19:42
Rating:
Reviewed by Zion3R
on
19:42
Rating:
