8/16/2022
Research by:  
Stephan Zeisberg (@stze), Luca Melette, Jakob Lell, Rachna Shriwas, Robert Reith and Genco Altan Demir

Smarter is not always wiser: How we hacked a smart payment terminal

Key takeaways

  • Repurposing a mobile handset into a payment terminal is not trivial and requires hardening measures to reduce the attack surface
  • End-of-life Android versions enable attack paths based on known exploits. For critical devices regular patching is mandatory
  • Hacking a smart POS device was much easier than it should have been

A new generation of payment devices offers new hacking opportunities

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.

Our agile device hacking methodology is split into five phases

Figure 1: Overview of the five phases of our device hacking process

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.

Attack path

Our payment terminal interface analysis showed USB as the most promising starting point for an attack path.

Figure 2: Outcome of the payment terminal interface analysis

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.

Figure 3: Attack path for the Android-based smart POS

Conclusion

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

Explore more

aLL articles
EDRs decrease your enterprise security, unless properly hardened
redteam
8/24/2022
A decade of hacking – meet the people behind SRLabs
team
11/8/2020
Honeypot research shows variety of DDoS amplification methods
redteam
7/30/2021