Análisis de malware en cajeros automáticos Tyupkin

Análisis de malware

Análisis de malware en cajeros automáticos Tyupkin

enero 19, por Chamán Vilén

Introducción

Hace algún tiempo, Kaspersky descubrió e informó sobre un nuevo tipo de programa malicioso llamado Tyupkin, que apunta a los cajeros automáticos, yendo más allá de atacar a los consumidores con skimmers de tarjetas que roban números de tarjetas de débito, para obtener efectivo directamente de un cajero automático sin la necesidad de una tarjeta falsificada o robada. .

En el corazón de la explotación de los cajeros automáticos por parte de Tyupkin está el simple hecho de que requiere acceso físico a un cajero automático. El atacante necesitaría un CD de arranque para instalar el malware en el cajero automático. Por esta razón, se deben tomar seriamente en consideración los elementos de seguridad física.

Según Kaspersky, este malware estaba activo en más de 50 cajeros automáticos en Europa del Este, pero según los envíos de VirtualTotal, consideramos que este malware se ha extendido a varios otros países, incluidos EE. UU., India y China.

Estos son los pasos básicos de cómo este malware realiza su ataque:

  • Solo está activo en momentos específicos de la noche en ciertos días de la semana, entre el domingo y el lunes de 1:00 a 5:00.
  • Hay una ventana oculta que ejecuta el malware en segundo plano. Cuando el usuario ingresa la clave correcta en el teclado, muestra la interfaz del programa y luego genera una clave basada en una semilla aleatoria. Por supuesto, el algoritmo responsable de esta operación sólo lo conocen los autores del malware para evitar que nadie interactúe con el cajero automático.
  • Cuando se ingresa la clave correcta, se inicia el proceso para retirar dinero de la red.

    • Descripción general de WOSA/XFS

    En primer lugar, permítanme ofrecerles una breve descripción general de lo que está relacionado con la tecnología bancaria.

    Históricamente, los proveedores de hardware han adoptado un enfoque propietario, con productos y protocolos diseñados exclusivamente para sus propias máquinas. Esto ha promulgado los problemas habituales de los sistemas cerrados: pérdida de independencia del hardware, incapacidad de tener una implementación de proveedores mixtos, alto costo de cambio, etc.

    Ahora se están introduciendo estándares para toda la industria, una medida que está creando un entorno abierto y que tendrá amplias ramificaciones para la industria del autoservicio.

    El más destacado entre estos estándares es WOSA, que ha sido desarrollado por Microsoft y está compuesto por muchos de los principales integradores y proveedores de hardware. Han tomado la arquitectura de servicios abiertos de Windows de Microsoft y han agregado extensiones para servicios financieros (la parte XFS) para cumplir con los requisitos especiales de las aplicaciones financieras para el acceso a servicios y dispositivos.

    La esencia de WOSA es que permite la integración perfecta de las aplicaciones de Windows con los servicios y capacidades empresariales que necesitan los usuarios y desarrolladores. Es una familia de interfaces que protegen a los usuarios y desarrolladores de las complejidades del sistema y que ofrecen, por ejemplo, acceso estándar a bases de datos (ODBC) y acceso estándar a servicios de mensajería y soporte de comunicación, incluidos SNA, RPC y Sockets. Cada uno de los elementos de WOSA incluye un conjunto de Interfaces de Programa de Aplicación (API) e Interfaces de Proveedor de Servicios (SPI) con el software de soporte asociado.

    WOSA XFS incorpora la definición de una API adicional y el conjunto correspondiente de SPI. La especificación define un conjunto estándar de interfaces de modo que, por ejemplo, una aplicación que utiliza la API configurada para comunicarse con un proveedor de servicios en particular puede funcionar, sin necesidad de mejoras, con el proveedor de servicios de otro proveedor, siempre que ese proveedor sea compatible con WOSA XFS. .

    Aunque WOSA XFS define una arquitectura general para el acceso a proveedores de servicios desde aplicaciones basadas en Windows, el enfoque inicial ha sido brindar acceso a dispositivos periféricos que son exclusivos de las instituciones financieras, como los cajeros automáticos. Dado que estos dispositivos suelen ser complejos, difíciles de gestionar y propietarios, el desarrollo de una interfaz estandarizada para ellos ofrece a las instituciones financieras ganancias inmediatas en productividad y flexibilidad.

    WOSA XFS cambió su nombre a simplemente XFS cuando el estándar fue adoptado por el organismo de normalización internacional CEN/ISSS. Sin embargo, los participantes de la industria lo llaman más comúnmente CEN/XFS.

    Como hemos visto anteriormente, los Sistemas de Pago y Transferencia Electrónica de Fondos es un arte negro debido a que todo es propietario. Debe trabajar como empleado de un gran proveedor (como NCR, Diebold, etc.) o en una institución financiera o banco para comprender el panorama de principio a fin. No encontrará suficiente información simplemente buscando documentos y códigos disponibles gratuitamente en Internet, ¡sólo porque estos estándares no son abiertos en absoluto!

    Volviendo a Tyupkin, este malware utiliza WOSA/XFS o CEN/XFS que cumplen diferentes proveedores de hardware. Por lo que a nosotros respecta, consiguen algunas referencias manuales que contienen información detallada sobre cómo interactuar con el cajero automático. Hemos encontrado documentos de especificación XFS publicados por CEN que utilizaremos a lo largo de este análisis para comprender la arquitectura XFS. También hemos visto algunas filtraciones sobre el motor de búsqueda Baidu publicado por F-Secure , pero no estamos seguros de que fueran las utilizadas por los ciberdelincuentes.

    Arquitectura WOSA/XFS

    La arquitectura del sistema Extensiones para Servicios Financieros (XFS) se muestra a continuación:

    Las aplicaciones se comunican con los proveedores de servicios a través de Extensions for Financial Services Manager utilizando el conjunto de API.

    XFS Manager proporciona gestión general del subsistema XFS. El Administrador XFS es responsable de asignar las funciones API (WFS…) a las funciones SPI (WFP…) y de llamar a los proveedores de servicios específicos del proveedor adecuados. Tenga en cuenta que las llamadas son siempre a un proveedor de servicios local.

    Se accede a cada servicio XFS de cada proveedor a través de un módulo específico del servicio llamado proveedor de servicios. Por ejemplo, se accede a la impresora de diario del proveedor A a través del proveedor de servicios de impresora de diario del proveedor A y a la impresora de recibos del proveedor B a través del proveedor de servicios de impresora de recibos del proveedor B.

    Análisis técnico

    SHA256: b670fe2d803705f811b5a0c9e69ccfec3a6c3a31cfd42a30d9e8902af7b9ed80

    Vamos a utilizar estas herramientas para realizar el análisis:

    Este ejemplo ha sido compilado con el lenguaje C# Dot NET:

    Al observar las importaciones/exportaciones:

    Como puede ver, MSXFS.DLL es nuestro dll de Microsoft que contiene las llamadas a funciones de API y SPI.

    Después de ejecutar la muestra, se suspende durante 10 minutos para evadir las herramientas antimalware:

    Luego, llamará a InitializeComponent (), que es responsable de configurar los nombres correctos para las etiquetas, fuentes y colores de los diferentes objetos del formulario, incluida la ventana principal. Luego, llama a SHGetFolderPath dos veces para obtener el directorio del sistema y el directorio de inicio.

    Persistencia para reiniciar en la clave de registro:

    A continuación, llama a prepareXFSManagerAndOpenServiceProvider. Básicamente, antes de que a una aplicación se le permita utilizar cualquiera de los servicios administrados por el subsistema XFS, primero debe identificarse ante el subsistema. Esto se logra utilizando la función WFSStartUp. Solo se requiere que una aplicación realice esta función una vez, independientemente de la cantidad de servicios XFS que utilice, por lo que esta función normalmente se llamaría durante la inicialización de la aplicación. De manera similar, la función complementaria, WFSCleanUp, normalmente se llama durante el cierre de la aplicación. Si una aplicación sale o se cierra sin ejecutar la función WFSCleanUp, XFS Manager realiza la limpieza automáticamente, incluido el cierre de cualquier sesión con los proveedores de servicios que la aplicación haya dejado abierta.

    Una vez que se ha negociado con éxito una conexión entre una aplicación y XFS Manager a través de WFSStartUp, la aplicación establece una sesión virtual con un proveedor de servicios emitiendo una solicitud WFSOpen. Las aperturas están dirigidas a “servicios lógicos” tal como se define en la configuración de XFS.

    Se asigna un identificador de servicio (hService) a la sesión y se utiliza en todas las llamadas al servicio durante la vida de la sesión. Finalmente, cuando una aplicación ya no requiere el uso de un servicio en particular, emite un WFSClose.

    Después de preparar con éxito el administrador de servicios XFS, el malware inicia dos subprocesos y, si falla, simplemente elimina el contenedor silenciosamente y sale.

    El hilo TimeInterval determinará si la hora actual del sistema es domingo o lunes, entre la 1:00 y las 5:00 a.m. Si se cumple la condición, se marcará como PIN_PAD_ACTIVE_TIME. El segundo hilo MainLoop busca este campo booleano. Si es verdadero, si se cumple la condición, llama a waitForMasterKey, que se explica por sí mismo. Dentro de esta función, llama a WFSExecute con el atributo WFS_CMD_PIN_GET_DATA (0x198).

    WFSExecute envía un comando específico del servicio a un proveedor de servicios, aquí está el prototipo que corresponde a esta API:

    HRESULT WFSExecute (hService, dwCommand, lpCmdData, dwTimeOut, lppResult)

    hService es el identificador del servicio devuelto por WFSOpen, y WFS_CMD_PIN_GET_DATA es el comando que se utiliza para devolver las pulsaciones de teclas ingresadas por el usuario. Configurará automáticamente el teclado PIN para que haga eco de los caracteres en la pantalla, si hay una pantalla. Por cada pulsación de tecla, se envía un evento de notificación de ejecución para permitir que una aplicación realice la acción de visualización adecuada. El tercer argumento es interesante, es un puntero a una estructura de datos de comando que se pasará al proveedor de servicios, y esta estructura de datos se define de la siguiente manera:

    usMaxLen Especifica el número máximo de dígitos que se pueden devolver a la aplicación en el parámetro de salida, que en nuestro caso es igual a 10.

    Si bAutoEnd se establece en verdadero, el proveedor de servicios finaliza el comando cuando se ingresa el número máximo de dígitos. De lo contrario, como en nuestro caso, el usuario finaliza la entrada utilizando una de las claves de terminación. Cuando se alcance usMaxLen, el proveedor de servicios desactivará todas las teclas numéricas.

    El tercer y cuarto parámetro no son importantes para nosotros. uTerminateFDKs Especifica aquellos FDK que deben finalizar la ejecución del comando. En nuestro caso, este valor es igual a 0x400, que es la tecla ENTER: #define

    WFS_PIN_FK_ENTER

    ( 0x00000400 )

    Luego, prueba si WFSExecute devolvió el valor correcto, que es 0; de lo contrario, cuando hay un error, vuelve a llamar a prepareXFSManagerAndOpenServiceProvider y a la API de WFSExecute.

    #definir

    WFS_SUCCESS

    ( 0 )

    #definir

    WFS_ERR_NOT_STARTED

    (- 39 )

    Finalmente, llama a la función escenario (), y dependiendo de qué secuencia de teclas se haya grabado en el PINP AD, Tyupkin hace lo siguiente:

    Cuando se ingresa el código correcto, DISPENSE_SESSIOM_ACTIVE es igual a Verdadero.

    Después de que el usuario ingresa el número del casete y presiona Enter, llama a getDecimalNumberFromPINFKDigit para convertir el número ingresado a un número entero, luego verifica si es mayor que 1 y menor que el número total de casetes y llama a ejecutarDispense, que a su vez llama a WFSExecute con WFS_CMD_CDM_DISPENSE, luego llama a getCashUnitInfo/getCashUnitInfo, que llama a WFSGetInfo (recupera información del proveedor de servicios especificado) para obtener información relacionada con cada casete y cuántos ingresos hay en él.

    Conclusión y COI

    En lo que a mí respecta, vamos a ver más casos relacionados con malwares en cajeros automáticos, porque ahí es donde está el dinero. Apuntar directamente a las instituciones financieras es mejor para los ciberdelincuentes que hacer skimming o ejecutar desguazadores de RAM o realizar inyecciones web y cosas ATS.

    Ya se ha demostrado que el malware Ploutus existe antes, y Tyupkin es ahora una debilidad concreta en la infraestructura de los cajeros automáticos. Además, el hecho de que muchos cajeros automáticos ejecuten sistemas operativos no compatibles, como Windows XP, y la ausencia de soluciones de seguridad es otro problema que debe abordarse con urgencia. Mi recomendación para los bancos es revisar la seguridad física de sus cajeros automáticos y de sus empleadores (¿internos?).

    Indicadores de compromiso:

    Verifique el equipo del cajero automático para ver los siguientes archivos:

    ¡Conviértete en un ingeniero inverso certificado!

    Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

    Verifique la siguiente clave de registro:

    Referencias