BitSight Research Reveals Vulnerabilities in Point of Sales Systems

Yevgen Goncharuk | May 5, 2020

When people talk about cybersecurity risks, the first area that normally comes to mind is malware. Some might even consider that it’s the worst event that can happen, as it normally indicates that a malicious actor has already bypassed the layers of security and now has free-reign to do what they want. The circumstances that led to the compromised systems, however, often tell a larger story. Issues like EternalBlue and BlueKeep require prompt response by system administrators in order to minimize the risk posed to their attack surface. Vulnerabilities often represent unpredictable changes of an organization’s attack surface that increase the risk of breach and compromise where the organization has to react accordingly based on their response plans and internal processes.

On the other hand, there are other sectors where administrators and practitioners have more pre-emptive control that can also have a major impact to reduce the risk of compromise. These include areas such as data recovery capabilities, email and web browser protections, and software and hardware asset management. With personally-owned devices and IoT devices becoming more prolific on corporate networks, this is an increasingly complex problem for administrators to properly manage. Further difficulty occurs as IoT and embedded devices often have little to no long-term support and are becoming an increasing target for malicious actors as the Mirai and Silex attacks have shown.

BitSight attempts to capture information about some of these out-of-date and deprecated platforms within our Insecure Systems risk vector. In this post we will demonstrate the importance of keeping your systems up-to-date and highlight the need to never leave any system unattended by describing a small but significant example of one of a number of IoT platforms and embedded device software applications that we monitor in our Insecure Systems risk vector. In this case we look at the issues behind a recent case of an improperly supported Point of Sale (POS) platform.


POS software is used to process customers’ payments at stores, and as one might expect, is commonly a target for criminals who infect the software with malware to steal credit card data and other personally identifiable information (PII). In our threat research we see a lot of different and curious cases; normally we focus on mainstream malware, but also happen to run across samples and telemetry that appear to be malicious yet turn out to be mistakes, improper configurations, poorly implemented device management protocols, among many other reasons. 

After the installation of the software on our test machine, we found a number of different .pdb files (Fig. 1), which are files used to store symbols that help the developers debug the code they write. They’re normally never shipped when a release occurs, but with this information, it enabled the analysis of the software to be a far easier process.

Figure 1Another interesting thing that we noticed is that the code was written in C# and having the debug symbols at hand, we knew that our research would be simplified.

In software security, the system is only as secure as its weakest part, and while still remembering what the NotPetya actors taught us, we focused on one of the easier but more significant components that might be exploitable without needing to understand much of the application itself: the application update mechanism. With NotPetya, attackers used the update mechanism of Ukrainian tax accounting package called MeDoc to spread their ransomware across the globe by just adding a small piece of code to a genuine software update. 

During this initial investigation, we also found the local database schema in the configuration files that provided us with vital context into how data was stored at rest (Fig. 2). After enumerating through all information, we were also able to draw two very important conclusions: the application does have remote update capabilities and it uses plaintext HTTP to do them. At first, it seemed implausible that the developers would allow updates over HTTP since it’s considered insecure, as it allows malicious actors to intercept and modify the information that is being sent. It’s recommended to use HTTPS, so we started exploring where and how this software uses encryption and signature verification on any downloaded files.

Figure 2From only the “using” (also known as “include” in other programming languages) statements the code is declaring, it appeared that software was attempting to adopt some levels of protection (Fig. 3) as it clearly shows that some cryptographic functions would be used. 

Figure 3While proceeding with the research, we realized that the initial versions of this software were originally developed for Windows XP. At the time there were a few noticeable issues with the Internet, such as frequent disconnects and unstable connections that developers had to overcome. So at that time, a lot of websites that allowed users to download bigger files also provided their hashes to confirm the integrity of the file was retrieved successfully. We confirmed our conclusions (Fig. 4) that the developers were only using the cryptographic functions to do checksums of the file, that is used to check if the file was not corrupted in the transfer process (for example with incomplete download). 

Figure 4-1In order to perform updates, we would only have to provide our application and its checksum, as well as indicating when we wanted that update to be done and where to save it. 

Now that we know we could do updates by intercepting http requests to a specific domain and sending any executable file to be executed, we wanted to know who was affected, so after some analysis we found the following (Fig. 5):

Figure 5This figure shows us the number of unique IP’s requesting the updates in the last 24 hours. Over a period of 25 days, the number of unique IP addresses was a bit higher (Fig. 6):

Figure 6For the same 24 hours mentioned above we’ve seen the below country distribution (Fig. 7):

Figure 7As can be seen by the country distribution, most users are from the United States, which makes sense as the company who sells it is US-based. It might be difficult to branch out to EU/Asia where there is already a well-established competitor working in this field. Even something like POS software could open an entrance into a network for the attackers, so it’s very important to understand how your network functions and keep everything updated.

BitSight Attack Surface Analytics Demo

Suggested Posts

What the Gramm-Leach-Bliley Act Means for Financial Services Cybersecurity

For obvious reasons, the financial services industry has had the unfortunate distinction of being one of the largest high value targets for threat actors. Research shows that financial services businesses experience 300 more cyber attacks...


The Big Data Breaches of 2020: What Happened and What Did We Learn?

Not to be forgotten during the chaos that was 2020 were the massive cybersecurity breaches that directly impacted some of the country’s largest businesses and their customers. Let’s take a closer look at four of the big data breaches of...


CISO's Board Report Cyber Security Toolkit

When it comes to reporting to the board, there are plenty of tools at the CISO’s disposal. Looking at the right metrics and putting them in the right context can help turn your next board meeting into a source of confidence, not stress....


Subscribe to get security news and updates in your inbox.