Security By Default: cajeros

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

Una de las muchas noticias de seguridad que han sido la comidilla de los últimos días, con repercusión internacional, es el ataque que se ha descubierto para extraer dinero, de determinados cajeros automáticos, cuya aplicación funciona sobre un sistema operativo Windows XP.

El ataque tiene cierta complejidad puesto que, para su éxito se necesita conectar físicamente un teléfono móvil al puerto USB de la máquina que gestiona el cajero, e inyectar el malware Ploutus, tal y como publicó Symantec. A partir de aquí, mediante el envío de mensajes de texto, es posible decirle al ATM cuánto dinero debe dispensar, ir al cajero y recoger el dinero. Es decir, que se puede hacer en remoto y enviar diferentes “mulas” a “cargar con la cosecha”.

En este sentido, hay que tener en cuenta que Windows XP termina su soporte para cualquier tipo de parche por parte del propio fabricante, Microsoft, el 8 de Abril de 2014 (es decir, que quedan menos de dos semanas). Me gustó mucho la reflexiones que hacía ayer Chema Alonso en El Lado del Mal, en las que calificaba muy acertadamente, a mi parecer, como "negligencia" que determinados puestos de trabajo como los de Administración Pública y empresas que manejan nuestros datos sigan utilizando Windows XP, más allá de la fecha prevista. Coincido con él que en cuanto a sistema operativo de escritorio, es sangrante que no se haya hecho una migración total a Winodws 7 (que en mi opinión, es como Windows Vista, pero sin el proceso que se come todo el sistema).

Sin embargo, para sistemas tan herméticos como un cajero automático, me asaltan las siguientes dudas:

1.-) ¿ Qué han estado haciendo los fabricantes de cajeros automáticos durante este tiempo?

Siendo que la fecha del fin de soporte y publicación de actualizaciones y parches de seguridad para Windows XP era más que conocida desde hacía años ¿por qué empresas serias como Nixdorf, Bull o NCR no han tenido a bien poner en producción, con tiempo suficiente, nuevos cajeros basados en otro sistema operativo. ¿Van a esperar al 9 de Abril para hacerlo? Lo normal sería que, si tienen pensado poner en producción el sistema en un sistema operativo con soporte, se hubiesen distribuido ya a las diferentes entidades

2.-) ¿ Por qué utilizar un sistema operativo generalista, conocido, accesible por millones de usuarios de todo el mundo?

Sé de buena tinta que los sistemas operativos que utilizan son versiones más securizadas, y no la versión genérica del mismo. Recuerdo que en el Ethical Hacking Conference en Santa Cruz de la Sierra en Bolivia, asistí a una charla en la que se hablaba de los cajeros de uno de estos fabricantes. Entre otras cosas se hablaba de un módulo intermedio, y cómo a partir de una vulnerabilidad con parches publicados por Microsoft mucho tiempo atrás, se llegaba a tener control total del mismo. Es decir, que desde este punto de vista, y siendo el sistema operativo Windows como es, que cada parche que se publica, no es posible saber con anterioridad qué ficheros va a modificar y si va a sobrescribir alguna librería que deje inoperativos los cambios que haya hecho cada suministrador de cajeros automáticos. Se presupone que cada entidad bancaria ya protege el ATM a nivel físico de manera que no sea posible su manipulación, más allá de la pantalla táctil para las operaciones del ATM,… y si no hay fallos ahí, no se aplican otros parches.

Ya habló Yago, tiempo atrás, sobre su punto de vista ante la utilización de sistemas operativos “generalistas” o “no especializados”, para el control de determinados elementos de infraestructuras críticas, y dejaba abierta la oportunidad a partir de un sistema operativo que sea más específico, personalizable, modular y que disponga de una base más sólida que un Windows XP: es decir, algo basado en alguna distribución Linux con soporte (¿alguien ha dicho RedHat?) o algún BSD.

3.-) ¿Cuántos exploits 0-Day habrá para Windows XP escondidos esperando al 9 de Abril?

Tengo claro que si tuviese un 0-Day “de alto impacto” para XP, me lo guardaría para el 9 de Abril, cuando estos cajeros se encontrarán "sólos ante el peligro” sin posibilidad que el fabricante solucione un problema gordo. ¿Cuántos de vosotros esperáis solucionar vuestras deudas a partir del 9 de Abril?

4.-) ¿Han tenido en cuenta los bancos este hecho en su provisión anual de fraude?

Las entidades financieras, todos los años disponen de un presupuesto destinado a pagar el fraude que tengan que asumir. Normalmente, los bancos disponen de medidas de seguridad elevadas, procesos revisados, redundancia de sistemas, altas inversiones en auditoría y desarrollo seguro. Sin embargo, con el tema de los cajeros, supongo que la responsabilidad final ante un fraude de las características descritas con los ATMs, será responsabilidad de ambas partes, puesto que si la entidad bancaria no aplica las medidas necesarias a la protección física de los cajeros, ataques como Ploutus será igualmente viable. En cualquier caso, ¿habrán tenido en cuenta las entidades financieras que la negligencia de seguir usando Windows XP en los cajeros puede incrementar el coste del presupuesto de fraude?

5.-) Al igual que hacen los gobiernos ¿Se rendirá Microsoft a los encantos de la banca?

Leí hace unos días (no recuerdo dónde) que había varias empresas que estaban proponiendo pagar a Microsoft por un soporte extra para sus infraestructuras. Al final, es siempre el dinero que hay encima de la mesa quien toma estas decisiones, y si a Microsoft le parece rentable, estoy seguro que “hará la excepción necesaria” para seguir manteniendo el que parece que se va a consolidar como el COBOL de los sistemas operativos.