"Hackin" ATMs isn't magic ...

Over the past few weeks, not a day passed without a news outlet or an AV vendor coming up with another post or article on ATM hacking. Today was no different.

Network World published an elaborate article that drew the attention to a "mysterious" DLL (msxfs.dll) that allowed the "hackers" to interact with the ATM's pin pad.

Analyzing the code, we started wondering how the malware author knows which pin pad service name to provide to the API so that the program is able to interact with the pin pad device,” the F-Secure researchers said in a blog post, noting that Microsoft doesn’t provide any official documentation for this library’s functions. “It’s a valid question because the pin pad service name used in the code is quite unique and it is very unlikely one can figure out the service name without documentation.

Now allow me to bring us down from the lala wonderland of AV blog posts.

First things first: Microsoft does not provide any official documentation for this library's functions ... because it is not a Microsoft library. The library is a result from the CEN Workshop on eXtensions for Financial Services (WS/XFS).

The fundamental aims of the XFS Workshop are to promote a clear and unambiguous specification for both service providers and application developers. This has been achieved to date by sub groups working electronically and quarterly meetings. 

You can find their website here : http://www.cen.eu/work/areas/ict/ebusiness/pages/ws-xfs.aspx

On it you will find both the documentation of the API as well as the MSI package to install msxfs.dll on your system. Granted that most ATM vendors will integrate this into their product, it's not hard to analyze the DLL itself ... if you want to (I'm not gonna do it here for you, magazines have ads to sell and AV vendors have products to sell so I'll give them the opportunity to do just that).

Now, there is indeed little documentation available for this version of the API beyond what you need as a programmer but there is more for the Java version. To be found here : http://www.cen.eu/work/areas/ICT/eBusiness/Pages/WS-J-XFS.aspx.

The latest version of the documentation for the "base architecture" (2009has some interesting paragraphs that you can ponder on from a security point of view, specifically under point 2.17:

The access control for the device (i.e. the authorization to access a specific function in the J/XFS API) has to be controlled by the calling application and the network software. In the current CWA 12345 no support for login and user rights administration is supported. Also, it may be desirable to encrypt all data which is send over the LAN between the workstations and the server, as well as between the peer-workstations sharing a device using J/XFS. 

This is, however, also not a task defined in the CWA 12345. It is rather left to the TCP/IP installation and add-on security products to ensure that the data transfer is secure. We assume that a solution to this is or will be available for use without the necessity to change the J/XFS structure. One possible option here would be to use RMI over SSL. 

TL;DR : the main API allowing ANY application running on a box connected to an ATM machine provides NO authentication, authorization and encryption. Rather, it offloads that responsibility to the "TCP/IP installation and add-on security products".

Maybe this post can help us narrow down where the work to protect our ATMs should start and maybe ... we don't need to do weird searches on Baidu to understand what we're looking at.

Cheers,
Wim

PS : Oh, instead of vendor-specific programming guides, maybe the Kaspersky guys want to look at the official Pin Keypad Device Interface ... it's not that hard of a read once you found it ;-)