Study puts POS cybersecurity under the spotlight
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 minimise the risk posed to their attack surface. Vulnerabilities often represent unpredictable changes of an organisation’s attack surface that increase the risk of breach and compromise where the organisation 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 Cybersecurity Investigation
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.
Another 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.
From 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.
While proceeding with the research, we realised 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).
In 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):
This 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):
For the same 24 hours mentioned above we’ve seen the below country distribution (Fig. 7):
As 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.
Streamline Vendor Cybersecurity Risk Assessment with Security Ratings
As your vendor network grows, so does your attack surface. In order to protect the assets in your expanding digital ecosystem, it’s critical for you to ensure that all of your third-party partners meet your security standards and conduct the necessary due diligence.
With a standard KPI-style security ratings, it’s easier than ever for you to assess a potential vendor’s cybersecurity posture throughout your business partnership — saving you valuable time and resources.
Ready to learn more about creating a faster, less costly and more scalable vendor onboarding and cybersecurity risk assessment program with ease?
Download the latest BitSight Vendor Onboarding White Paper
Pressed for Time? Then read the Quick Guide
4 Ways to Optimise Your Vendor Onboarding Process With BitSight
You’re Only As Strong As Your Weakest Link
There’s never a more vital time to start thinking seriously about the security posture of your organisation and the cyber supply chain you rely on. DVV Solutions are here to help with a range of services and solutions proven to improve your ability to assess, analyse and manage more Third-Party cyber and data privacy risk domains. For more advice and information on any Third-Party risk challenge you have:
Call Us: +44 (0) 161 476 8700
Contact Us: Complete our Contact Form, or
Learn more about What We Do
This article was originally published by BitSight and is shared with their kind permission.