Hello. Today I would like to talk with you about Point of Sale (hereinafter POS) systems, their architecture and security. Probably, the post-holiday shock from the long lines in the shops has passed, and it's time to see what is behind this veil of social communications. The study described below was conducted by @chipik and me.

Modern POS systems are a combination of software and hardware solutions that enable payment transactions and facilitate daily business processes. Speaking about POS, usually refer to cash registers, payment terminals and other customary components of trade stores. However, the POS architecture is not limited to these elements only. As for security, it would seem that this topic is not new: since 2012, at almost every BlackHat USA conference there was a report on payment systems ( here , here , here , here ). But all these reports, being very close to the topic under discussion, are still a little bit about something else.

To make it clearer, let's consider the payment procedure in a regular store:

First, the buyer spends the card on the reader of the terminal to pay for their purchases. Credit card details are sent to the terminal, from where they are sent to the POS system. Next, the POS system contacts the PSP (Payment Service Provider), which, depending on the type of credit card, contacts the bank to complete the transaction authorization procedure. Just at this moment, the buyer is asked to enter a PIN to confirm the transaction. If everything went well, the authorization code is returned from the banking network to the PSP and transmitted to the POS system and the terminal. All the above communications occur within a couple of seconds.

Research and attacks, which were mentioned at the beginning, are mainly aimed at payment terminals, at customer interaction with them. Today, another part will be considered - POS-systems through which transaction data passes.

We have already spoken several times about various business processes, what are they? Consider, for example, the classic online store. The store has a manager, most likely there are several of them. Every morning, the manager needs to open a store, and then POS terminals. I would like to note that POS-terminals are not the same as payment terminals. The first image is the payment terminal, and the second is the POS terminal.

During startup, POS terminals synchronize time and receive updated parameters from the store server, including product prices, information on their availability and other service data. After that, cashiers can log in for their jobs and start work. Obviously, every action at the checkout is logged.

At the end of the day, the manager needs to repeat the procedure in the reverse order: first close the cash registers and then the store. After this action, no transaction can be carried out until the store opens. During closing, POS-terminals send their logs to the server. These are the business processes mentioned above. It is their POS-systems that make it easier and easier.

There are quite a few solutions on the POS systems market, and they are divided into product groups for small, medium and large organizations.

For the most part, they have similar architecture. In this article we will look at the SAP solution in detail: "SAP Point of Sale". We also investigated the company's Oracle product MICROS, which found similar vulnerabilities closed in January 2018 (CVE-2018-2636).

You can learn more about SAP at the official site . In a nutshell: SAP is developing large ERP solutions for large companies. POS-systems as a product appeared at SAP in 2005, when it swallowed up another company - Triversity Transactionware GM, which deals exclusively with POS-solutions.

SAP POS Architecture

The architecture of this system consists of three parts: Front Office, Back Office and Head office. The first part includes the client part, i.e. POS client and Mobile POS Client, which are the POS terminals that cashiers work at. Front Office is connected to Back Office, where the local store server (Xpress Server), the Database and the solution for the local POS system management (Store manager) are located, using which the manager opens and closes the store and terminals.

Speaking of a local solution, we mean a specific store, since SAP POS is a product for large organizations, and it was designed for a network of stores with central management. In other words, in this case, the local solution is the POS system of one of the stores in the network.

The global management of the store network is carried out from the head office, using Store Configurator, which is connected to all store servers.

The general review is made, now let's look at how it all works in more detail. And we will move in the following order:

Head office

Store Configurator is an application that allows you to configure everything in POS systems. No, not so, ABSOLUTELY everything, starting with the users and the appearance of the cashier's screen and ending with encryption and other security settings.

How is all this implemented? After making changes in Store Configurator, the administrator needs to click "convert", and special files with these parameters will be created on the file system in the "Store Configurator / data / parm /" folder.

There are a lot of files, as well as parameters, the extensions are also different. Let's give an example:

• cnummask.cmk - contains information about the "mask" of the buyer's card number, i.e. about how many and what numbers will be on the check;
• rcptlogo.rcp - here is the data on the logo of the company, which is printed on the check;
• cashier.clg - contains information about users of the POS system (cashiers, managers and others), including personal data (name, birth date, phone number) and authorization data (login, password hash);
• layout.ui0 - contains information about the appearance of the POS terminal, the location of the keys, the background image, etc.

The content of the files is a textual representation of the parameters specified in Store Configurator. The image below is the rcptlogo.rcp file.

Next, the administrator needs to copy these files to the "/ Xpress Server / parm /" folder of each server of the store. Among the files created by Store Configurator, there is one "special". It is called "newparm.trg", and contains only one character "Z". Xpress Server (store server), every 30 seconds checks the folder "/ parm /" for the presence of this file. If it finds it, it applies the updated parameters from the downloaded files and deletes the "newparm.trg". Thus, this file acts as a kind of update trigger.

Back office

Next in line is the Back Office, or rather the communications inside it. It consists, as mentioned earlier, of Xpress Server, Database and Store Manager. All these components can be installed on one machine or on different ones. Store Manager interacts with the base via standard ports and in this case is very similar to Store Configurator with limited functionality and the only difference is that it writes parameter changes to the database directly using stored procedures.

As part of the study of the system, two amusing procedures were found: ssp_insert_backdoor and ssp_delete_backdoor. Their main goal is to create a user with the name "back" and a password "door" and elevated privileges. Of course, this was done only in the event that all users in the POS system forget their authorization data.

The interaction of Store Manager and Xpress Server is carried out on port 2202, and it looks more interesting. Studying the Store Manager functionality, we found the Store Administration section, which provides interesting features:

• firstly, all connected POS terminals are displayed;
• secondly, they can be opened and closed;
• thirdly, there is a monitoring function that allows you to track everything that is displayed on the cashier's screen (information about purchases and checks).

Having looked at the packages that Store Manager sends to port 2202 Xpress Server (where to without WireShark), we saw plaint-text commands. "It`s telnet protocol used for monitoring and not critical configuration," we learned from the documentation. Okay, what if we try to connect to this port from a foreign machine?

As it turned out, no white list is provided. By default, this port is open, and there are no recommendations for closing it in the Security Guide. Naturally, you can restrict access to the ports by third-party means, but we are looking at the security of the POS system, right?

After connecting to the Xpress Server on port 2202, we are greeted with a welcome message with the POS version of the system. The "help" command returns a list of available functions:

999 *** XPRESS SERVER MOST COMMON COMMAND HELP *** 999 MONXPS [ON|OFF]  999 [SHOWTERM|TERMINAL-STATUS] [ALL|Term#]  999 [MONTERM|MONITOR-TERMINAL] [ALL|XPS|Term#] [START|STOP|ON|OFF]  999 OPEN-TERMINAL [ALL|Term#]  999 OPEN-STORE [TODAY|NumberOfSecsSinceJan1-1970]  999 CLOSE-TERMINAL [ALL|Term#] [FORCE|NO-FORCE|ABORT]  999 TERMINAL-BALANCE [Term#] [BAL|UNBAL]  999 CASHIER-BALANCE [Cashier#] [1|2|3] [ShortOver Amount] [netTenderTotal] <-- 1=BALANCED 2=UNBALANCED 3=PREVIOUS BALANCE NOW OUT OF DATE  999 UPDATE-CASHIER [Cashier#]  999 DELETE-CASHIER [Cashier#]  999 END-OF-DAY [FORCE|NO-FORCE|ABORT]  999 STORE-TOTALS [CLOSE-DAY|CLOSE-WEEK|CLOSE-PERIOD|DONE-END-OF-DAY|...]  999 STORE-TOTALS CONSOL-DAY [RTOT|SRTOT|CTOT|SPROD|...]  999 COMMS-RESET [1|2|3] <-- 1=ALL 2=REMOTE 3=MODEMS  999 FLUSH-PLUCACHE  999 TRIGGER-NEWPROMOS  999 SHUTDOWN  999 . <-- Use to repeat previous command 

From the names of these functions is quite clear their purpose. The absence of any verification allows you to anonymously open and close POS terminals, monitor everything that happens on them (for example, when you buy the contents of the check on the console) or simply turn off the Xpress Server.

It became very interesting how these functions are implemented in the code, and whether all the commands are displayed in the "help" output. The process that processes incoming requests is xps.exe. A little reverse, and was found a list of possible commands. They turned out to be a little more than 17 ... 74 of them. 74 teams receive and process Xpress Server from port 2202. It would take too long to describe everything, let's focus on the most interesting ones.

APM-VALIDATE-PASSWD - allows you to check the authorization data entered by the user. This command returns three different codes: 0 - if the password is entered correctly, 1 - if the password is incorrect, 10 - if there is no user with such login. Obviously, nothing prevents a potential intruder from being in the local network of the store, sorting through all possible combinations of usernames and passwords (a username can consist only of numbers) and obtain data for accessing POS terminals.

But brute-force is not very cool, so there is another command, Reset password , which changes the user's password to a new one. All you need to know is the login, which can be obtained by brute force. And one more small clarification. In this POS system, a login can consist only of numbers, which greatly facilitates a hypothetical search.

The FILE-FIND , FILE-OPEN and FILE-READ commands allow you to find, open and read data on the Xpress Server file system. You still remember that all this happens without registration and SMS, anonymously? It is curious that the parameters of the FILE-OPEN command are passed directly to the C ++ fopen () function, and if the mode is specified incorrectly, then the Xpress Server application receives an error and terminates.

We turn to the last part of the review.

Front office

POS-client, also known as POS-terminal, connects to the server on port 2200. All information, all transactions and all communications take place on this port and only in this direction: the initiator is the client, and the server simply accepts and responds to requests. If we recall business processes, then everything happens as follows. At the beginning of the day, when the manager opens the POS terminal, he sends the packet to the server: "Server, I am terminal number 5, I am open, send me new parameters and let's synchronize the date and time." At the end of the day, when the manager closes the POS terminal, he sends his logs to the server. And, of course, after each transaction, data about it and about the change in the quantity of goods is also sent to the server. Looking at the traffic between the POS terminal and the Xpress Server, we found that the packets to receive and download files have a certain structure:

Len is the length of the packet being sent. Where - the place where we write the data. What - the place where we get the data. End - a pair of NULL-bytes. Type - type of the package, depending on which with the package certain actions will be performed. Packages can be:

So, for example, in order to receive a file with settings from a server, POS-client sends a packet of type R to port 2200:

 {R0059}C:\\local_directory\poc.txt,C:\remote_directory\poc.txt,0,0; 

In this package:

• R is a type;
• 0059 - data length;
• C: \ local_directory \ poc.txt - where the file is written to;
• C: \ remote_directory \ poc.txt - where the file is stored on the server;
• 0,0 - the end of the package.

In the answer, POS-client receives the contents of the requested file and writes it to itself in a special directory. When trying to duplicate a package sent by POS-client from another machine, the response also received the contents of a file on the server. As we see, there are also no checks here: the port 2200 Xpress Server accepts and processes packets from any machine.

It seemed funny, but you will not go far to read files. Let's try to build a set of packages to upload your file to the server. After all, POS-client somehow writes the logs to the server, right?

First, we send a packet of type S. The Where field contains the path on the server where we will write data, the What field is optional, since we do everything manually, but the Size size is very important, in which we specify the size of the next, second packet. It will be of type F - FILE_DATA and will consist of its size and data (contents) that we want to write to the server. Well, the third and last C type package is the end of the file. After that, Xpress Server writes the file to the specified directory and returns a package of type G - GOOD. Curiously, if you send a packet with the wrong Size field, Xpress Server will delete the file on the server. Below you can see a POC video of anonymous recording, reading and deleting a file:

Thus, due to the absence of any checks, any person who can connect to this port can read, write and delete files on the server.

And what of all this can be obtained? Let's see what can be achieved by combining the above features.

So, the attacker must have access to the local network of the store. Usually it is not difficult to get it, because Peripherals, including scales, are regularly in the halls, and access to them is unlimited.

Let's summarize our knowledge of the system:

1. Store Configurator creates special files with system parameters, copies them to Xpress Server, which applies parameters when it finds the file "newparm.trg".
2. The attacker can write any data to any file in any directory on Xpress Server using port 2200.
3. POS terminals receive updated parameters from the Xpress Server and apply them after opening.
4. An attacker can anonymously disable and enable POS clients using port 2202.

The combination of these features allows you to change any parameter in the SAP POS system.

Suppose an attacker wants to buy a product, say, for a dollar.

1. The attacker writes configuration files to the parma folder on the Xpress Server, indicating the new price of the product.
2. The attacker writes the trigger file "newparm.trg" to the Xpress Server folder in the parm folder, activating the update of parameters on the server.
3. The server updates the parameters.
4. Some of them are written to the database.
5. The attacker sends a command to close the terminal.
6. Xpress server closes terminals, terminals send their logs to the server. The process takes from 10 to 30 seconds.
7. The attacker sends a command to open terminals.
8. Terminals open.
9. Terminals download new parameters from the server and apply them.

That's all. But something is still missing, namely, the ability to remotely execute commands on the server. And she, in general, is.

Every time the Xpress Server updates the settings, i.e. finds the trigger file "newparm.trg", it searches for and launches two .bat files: XPSPARM.BAT and StopTN.BAT. And this means only one thing - the attacker can overwrite them and execute the reverse-shell script on itself.

It will look something like this: the attacker replaces the file "XPSPARM.BAT" with his own using port 2200; writes the file "newparm.trg", thereby causing the parameters to be updated and the "* .bat" file launched.

Encryption

Yes, SAP POS uses encryption, but by default, out of the box, it is disabled. If encryption is configured, all important data is transmitted as a ciphertext. It should be clarified that it is the data that is encrypted, not the communication between the elements of the system. For example, if you monitor transactions on the terminal with encryption enabled, we will receive in the response ciphertext only instead of the credit card number, the rest of the data will be transmitted in the clear.

This table lists the names of the tables and the fields that must undergo an encryption procedure. At the same time, there is an additional table "CryptoRegister", which lists the same, but with an indication of the "level" of encryption. For example, user passwords are stored as hash values ​​and have an encryption level of 4, and credit card numbers are encrypted with 3DES and have a level of 3.

SAP POS uses the TWSecurity tool for storing and generating keys. When it is launched, a special "container" is created, and access to it is possible only with a password in which the encryption key is stored. Since 3DES is a symmetric algorithm, the key must be the same on all elements of the system: Front Office, Back office and Head office. Those. After creating the container, it must be exported to all parts of the POS system. Access to the key is carried out only by a token that is registered in the registry. And everything would be cool, but there is one "BUT".

The key (or rather its token), which is used to encrypt data, is set in Store Configurator ... and this means that it is converted, like other parameters, into a special file, and can be changed by the attacker to a blank value to disable encryption in SAP POS.

"We patchili, patchili and finally patched!" ... or what to do in this situation

At the moment, the vulnerabilities described in this article are closed. Yes, not the first time, it turned out almost from the second. So, the first SAP Note 2476601 was released on July 11, 2017, it had a CVSS 8.1 and was called "Retail Xpress Server". It was patched access to port 2202 (telnet). This was done by adding a new parameter "BACKOFFICEIPADDRESS", which defaults to "localhost". But, at the same time, there was not a single mention of the second vulnerability on port 2200, which worked perfectly and allowed attackers to remotely execute commands, making it possible to “bypass” the fresh July patch, simply by changing this parameter. Our team reported this flaw to the SAP Product Security Response Team, which released as many as two SAP Note - 2520064 and 2520232, on August 18, 2017. SAP Note 2520232 removes two stored procedure: "ssp_insert_backdoor" and "ssp_delete_backdoor". SAP Note 2520064 brought more changes. This patch added 3DES encryption to almost all the packets exchanged between the various elements of the SAP POS: POS-client, Xpress Server, Store Configurator, Store Manager. Those. now, even having the ability to connect to open ports without knowing the key, we have no opportunity to influence the POS system: the server does not understand the unencrypted packets coming to it and simply discards them.

This is a really interesting decision, but it was not without incidents. Almost immediately after the release of SAP Note, many messages appeared on the forums that Store Manager is not working. The fact is that SAP has forgotten about Store Manager, or rather, that this component interacts not only with Xpress Server, but also with the database. When the Store Manager sends an encrypted package to the Database, it returns an error in clear text that the Store Manager cannot decrypt and just crash. In this regard, the final patch was released, which corrects the error of the previous patch. Nevertheless, the best solution to protect against possible attacks on your infrastructure is, though not always successful, but regular updates.

True story

And here is the curious news from the west: Forever 21, a California company, "US fashion retailer", which has been selling clothes all over the world since 1984 (815 stores, 57 countries, USA, Australia, Brazil, China, France, etc. ), December 28, 2017 confirmed the information that part of its POS-systems was coordinated from April 3 to November 18 (!!!). Experts claim that the attackers had anonymous access to the network of POS systems and used it to install malware to collect information about customers' credit cards (card number, expiration date, owner, authentication code). It's funny that the encryption of critical data in these systems was disabled (yes, did not work) exactly from April 3 to November 18. Apparently, encryption is not a big problem not only in SAP systems. Unfortunately, it was not possible to find exact information about which POS systems were compromised. If you believe the news , then on June 28, 2017, Forever 21 signed a contract with Toshiba Global Commerce Solutions for the supply of its systems, but by this time the current systems have already been compromised.