In the past, SRLabs showed how to compromise and exploit payment devices and how proprietary legacy payment protocols can be hacked. This post focuses on the next generation of such devices: “smart” point of sale (POS) devices that run on Android. They are one of the most significant trends in payment systems.
We bought a popular “smart” POS online and arranged a one-week hacking retreat in the Canary Islands to investigate the device. The POS is basically a smartphone running on Android 7 based on MediaTek hardware. Our team of seven researchers found major security issues.
A - Information gathering
Conduct information gathering passively through collection of open-source intelligence (OSINT) and actively-- be aware of tamper mechanisms -- by exploring the device.
B – Threat modeling
Use the identified insights to model the risk by hacking effort, incentive, and value. Create a classification of hacking scenarios based on the risk they pose to the system and its users and to identify possible attack paths.
C - Artifact analysis
Analyze collected artifacts to check which of the identified threats are applicable, look for potential vulnerabilities, and finally, set up tools and a test environment for the exploitation phase. This activity consists of three independent workstreams: Firmware analysis, scan of the device surface, and exploration of components.
D – Vulnerability exploitation
Most high-risk hacking incentives are linked to attacks that rely on code execution on the POS device. However, not all hacking incentives need code execution as a base requirement, as our successful attack path shows.
E – Collect and report vulnerabilities
Document at every step. Once done with our tests, we use all the collected artifacts to produce a test report. When it comes to reporting vulnerabilities to vendors a responsible vulnerability disclosure is the way to go.
Our payment terminal interface analysis showed USB as the most promising starting point for an attack path.
USB is the most promising interface for further investigations, because the bootloader is accessible via USB as this section from the lsusb output shows:
Full control of the device is possible through BootROM access, incomplete secure boot, and an outdated kernel.
During boot up, by pressing the three physical buttons on the POS in all possible combinations, we access the MediaTek bootROM mode. After identifying a suitable flashing tool, we were able to dump the full firmware of the device.
With bootROM access, we identified that the boot partition is not protected by a secure boot mechanism, allowing us to customize the initramfs image in the boot partition and configure Android Debug Bridge (adb) to be enabled all available USB modes. Via this setting, we established a system shell on the device.
With direct bootROM access and without secure boot being correctly implemented, there is no way to ensure that only authenticated software runs on the device. This is a major, but also common, flaw in the security configuration of the device.
As a next step, we tried to install custom applications using the standard shell user privilege we acquired via the adb session. Here, a custom system signature check mechanism was preventing us from installing applications. For this reason, we elevated our privileges to the root user using a well-known publicly available exploit for MediaTek systems from 2020, allowing us to install custom applications(e.g., malware). Being able to use a long-known exploit against a recently released device suggests improper patch management by the POS device vendor.
Using the outlined attack path, an attacker can intercept all data processed by the device, including credit card information and the merchant user account. This attack path could be executed in relatively short time by an attacker, for example, in a shop after getting hold of the device for a few minutes. Alternatively, this vulnerability could be exploited in the device supply chain, resulting in a stealth and persistent malware that would be able to silently steal customer data and send it to a remote cloud.
See Figure 3 for our complete attack path. The described attack path is highlighted in red.
Smart payment devices are not necessarily a smart idea. They can be made safe, but it takes effort. Smart payment devices offer convenience for merchants and vendors, but in terms of security, can be a bad choice since their expanded capabilities result in a larger attack surface.
In this case, the insecure implementation of the launcher and use of an outdated Kernel proved to be critical issues. These risks can be mitigated – at least to some extent – by a sufficient hardening during the development phase.
Another critical issue is the use of end-of-life operating systems, which is unfortunately not a rare occurrence in POS devices and can pose major security threats. Devices are being released to the market with multiple years of missing patches with no chance of receiving updates for bugs in the future. A missing patch does not automatically equal a security threat and most of them are not trivial to exploit, but the MTK-su vulnerability (CVE-2020-0069) is a high severity vulnerability. E.g., an Android 12 device would not have had this vulnerability which enabled us to gain root access and was therefore the key to reaching our hacking goals.
Keeping devices up to date can be a difficult task but is very important for critical devices like payment terminals.
Editing by: Maria Bühner
