Terminally Bad Credit

Terminally Bad Credit

Speakers: Connor Du Plooy, Head of Mobile Team, MWR Cyber Security

Conference: BruCON

YouTube: https://www.youtube.com/watch?v=CqVGGnr-0So

Overview

In "Terminally Bad Credit," Connor Du Plooy, Head of Mobile Team at MWR Cyber Security, delivers a sobering assessment of the security landscape surrounding modern Android-based Point of Sale (POS) terminals. The talk meticulously details a wide array of vulnerabilities, ranging from fundamental physical access exploits to sophisticated bootloader bypasses and critical flaws within backend Terminal Management Systems (TMS). Du Plooy's research, initially sparked by a "gag gift" POS device, reveals that these ubiquitous payment terminals, which handle sensitive card data in various form factors (from retail to toll gates), are often alarmingly insecure, presenting a high-value, low-effort target for attackers.

The presentation underscores a pervasive lack of robust security controls across the entire POS ecosystem, encompassing hardware, software, and backend infrastructure. Du Plooy demonstrates how physical access can rapidly escalate to full device compromise, how critical backend systems designed to manage fleets of devices are susceptible to trivial enumeration and authentication bypasses, and how outdated Android versions leave devices vulnerable to well-known exploits. This comprehensive exposé is a critical wake-up call for OEMs, merchants, and the broader payment industry, highlighting the severe implications for data breaches, financial fraud, and reputational damage.

The significance of this research cannot be overstated. With millions of these devices deployed globally, processing countless transactions daily, the vulnerabilities uncovered expose a systemic risk to consumer financial data. Du Plooy’s findings illustrate that even PCI-compliant systems can harbor profound security weaknesses that are not adequately addressed by current auditing standards. The talk serves as a stark reminder that the perceived security of payment systems often belies a fragile reality, where basic security hygiene is frequently overlooked, creating fertile ground for exploitation.

Background

▶ Watch: Introduction to POS Terminal Vulnerabilities (0:00)

The genesis of this extensive research began with a seemingly innocuous purchase: a cheap Android-based Point of Sale (POS) system acquired as a gag gift. What started as a casual inquiry into potential vulnerabilities quickly evolved into a dedicated research project, revealing a widespread and concerning lack of security across numerous devices. These modern POS terminals, running Android, are pervasive, supporting tap, swipe, and digital payment methods like Apple Pay, and are even found in critical infrastructure like highway toll gates. However, the security posture of these devices varies wildly; some are easily compromised within days, while others present a more challenging, albeit not insurmountable, defense.

Du Plooy acknowledged that initial research often involves reviewing existing work, a step he humorously admitted to largely ignoring at first. Nevertheless, the team did encounter prior findings. For instance, a PAX A920 device was found to have a CVE (though the specific number was not given, the description was clear) related to OS command injection. The speaker noted that this CVE was somewhat mischaracterized, as it stated root access could be gained if shell access was present. In reality, physical access to many of these devices inherently grants shell access due to the absence of ADB authorization. This means the barrier to entry for exploitation is significantly lower than initially suggested by the CVE description.

Other external actors had also explored these devices. Hungarian students had conducted some research a year prior, though their findings were not deemed particularly concerning. More alarmingly, a "dangerous hobbyist" managed to unlock a device's bootloader—a critical step that essentially prefaces rooting the device—within a day of acquiring it. This demonstrated the relative ease with which determined individuals could bypass fundamental security mechanisms. Further, Du Plooy investigated groups potentially selling access or exploits for these devices, akin to services offered for unlocking carrier-locked 5G routers via mobile app-based OS command injection vulnerabilities. While direct contact with such groups proved elusive, the presence of installed games on some devices, as seen in Telegram groups, highlighted how easily arbitrary software could be loaded.

A significant hurdle in acquiring these devices for research is the Know Your Customer (KYC) process. Many manufacturers require a photo ID, a photo of the applicant, and business details. Du Plooy's team successfully bypassed these stringent checks using a completely fraudulent identity (a screenshot of a South African Department of Home Affairs ID template, humorously featuring a "signature" that literally said "signature"). This demonstrated a critical weakness in the onboarding process, allowing malicious actors to acquire devices under false pretenses.

Central to the ecosystem's security is the Terminal Management System (TMS). These systems, analogous to Mobile Device Management (MDM) solutions, control entire fleets of POS devices. They can push software, lock, wipe, and geofence devices, making them incredibly attractive targets. Du Plooy revealed that a very easy vulnerability allowed enumeration of serial numbers and the pulling of applications from manufacturers' private app stores. The multi-tenant nature of these TMS solutions means that compromising one TMS can grant control over an OEM's entire fleet, not just a single merchant's devices, amplifying the potential impact of any breach. This background sets the stage for the deep technical dives into the specific vulnerabilities and exploitation techniques that follow.

Key Findings

▶ Watch: USB Debugging for Device Impersonation (7:00)

The research uncovered a comprehensive array of vulnerabilities across Android POS terminals, categorized into several critical areas:

1. Physical Access and Debugging:

• Many devices lack ADB authorization, making physical access equivalent to shell access.
• USB debugging could often be enabled directly through device settings, volume button bypasses, or by rapidly tapping invisible buttons to reveal debug menus.
• A critical finding was the ability to reverse-engineer time-derived debug PINs, which were generated using the device's serial number, current date, and time, then CRC'd. This allowed bypassing OEM controls to force production devices into debug mode.
• ADB authorization pop-up bypass was achieved by continuously rebooting the device and spamming adb shell to click "accept" during the brief window before the kiosk application launched.

1. Terminal Management System (TMS) Vulnerabilities:

• Serial number-based authentication was universally observed for TMS client-device communication, rather than more secure methods like mTLS. This allowed device impersonation by simply altering a serial number.
• Private application stores lacked the rigorous vetting of platforms like Google Play, leading to the distribution of debuggable applications, or even pirated software (e.g., a TeamViewer-like remote control app with an unlicensed core).
• Trivial enumeration vulnerabilities allowed researchers to pull hundreds of applications from manufacturers' private stores by incrementing serial numbers.
• Embedded credentials in APKs were frequently found, often duplicated across all devices and over-scoped, granting broad access to TMS queues or cloud resources (e.g., AWS keys for development environments).

1. Transport Layer Security (TLS) and Network Issues:

• Widespread cleartext communication was identified for sensitive data, including payment server interactions (HTTP as default) and MQTT traffic to manufacturer TMS.
• Insufficient certificate chain validation and hostname validation issues allowed for trivial Man-in-the-Middle (MITM) attacks. This was demonstrated by manipulating payment amounts displayed versus actual charged amounts, or redirecting payments to different entities.
• Replay attacks were possible on payment requests captured over cleartext HTTP, allowing fraudulent charges for up to two hours.

1. Device Software and Firmware Vulnerabilities:

• A significant number of devices ran outdated Android versions (e.g., Android 11, which reached end-of-life in 2024), leaving them susceptible to publicly known CVEs.
• OEMs often provided misleading information about patch status; devices with recent security patch dates were still vulnerable to older exploits.
• Zygote injection was used to modify running processes (e.g., removing watermarks from payment applications or obtaining private keys from other apps like WireGuard).
• Inter-process communication (IPC) mechanisms lacked proper authentication (e.g., signature-based authentication), allowing a compromised device to bypass OEM remote lock/wipe functionalities.
• File system encryption bypasses were achieved on MediaTek devices using MTK client, allowing direct dumping and modification of the user data partition, even when a lock screen was present. This uncovered SSH keys for logging servers, revealing multi-tenant transaction data.

1. Bootloader and Root Access:

• MTK client was successfully used to unlock the preloader on MediaTek devices, patch the boot image (with Magisk or KernelSU), and achieve root access.
• Sophisticated little kernel analysis was performed to bypass OEM-implemented signature checks during the boot process, enabling the booting of arbitrary, unsigned images.
• Some devices exhibited a "yellow boot state" capability, allowing them to boot custom ROMs signed with arbitrary keys, a severe security oversight for a payment terminal.

These findings collectively paint a picture of an ecosystem riddled with fundamental security flaws, where basic best practices are frequently ignored, and the integrity of sensitive card data is severely compromised.

Technical Deep Dive

▶ Watch: Authentication via Serial Number Only (TMS) (17:30)

The technical depth of Du Plooy's research spans multiple layers of the Android POS ecosystem, from low-level boot processes to high-level application and backend vulnerabilities.

Physical Access and ADB Exploitation:

The foundation of many attacks relies on initial physical access. The speaker highlighted a CVE for the PAX A920 that suggested root access via OS command injection if shell access was obtained. However, Du Plooy clarified that for many devices, physical access directly grants shell access due to the absence of ADB authorization. This means an attacker simply needs to plug in a USB cable.

For devices with more robust controls, several techniques were employed to gain USB debugging access:

• Direct Settings Access: Some devices allowed straightforward enabling of USB debugging from the settings menu.
• Volume Button Bypass: Abusing Android's accessibility settings via the volume button menu could lead to audio settings, from which navigating to "About device" allowed enabling debugging.
• Invisible Buttons: OEMs sometimes implement "security through obscurity" with invisible buttons that, when tapped multiple times, reveal a debug menu. These could be discovered by furiously tapping the screen or by connecting a physical keyboard and tabbing through hidden UI elements.

A particularly ingenious bypass involved time-derived debug PINs. For one OEM, a third party could provide a PIN valid for two hours to enable debug mode. Reverse engineering revealed this PIN was generated by concatenating the device's serial number, current date, and time, then calculating a CRC of this value. Knowing this algorithm allowed researchers to generate valid debug PINs for any production device, bypassing OEM remote controls. Even after enabling debug mode, accepting the ADB authorization prompt could be blocked by the kiosk application. This was circumvented by continuously rebooting the device and spamming adb shell, exploiting a 1-2 second window before the kiosk app fully launched to click the "accept" button.

Terminal Management System (TMS) Compromise:

The TMS, acting as the central control for device fleets, proved to be a critical single point of failure. Du Plooy demonstrated a trivial vulnerability to enumerate devices and applications from private app stores. By obtaining a single device's serial number and simply incrementing it (serial_number + 1), researchers could access applications belonging to other merchants or even the OEM's internal debug applications. This was possible because TMS client authentication almost exclusively relied on the serial number alone, rather than more secure mechanisms like mTLS (mutual TLS), allowing for easy device impersonation.

The private app stores hosted by OEMs were found to be severely lacking in security vetting. Unlike Google Play, which prevents shipping debuggable production apps, these private stores distributed applications with android:debuggable="true" in their manifest, including a "hardware manager process" handling card data. One specific OEM was even found to be shipping a pirated remote control application, having embedded its own license key in the APK, which upon decompilation, revealed it was not paying the original developer.

Case Studies of TMS Vulnerabilities:

1. Case 1: Embedded Credentials and Queue Exploitation: One OEM embedded duplicated credentials in the APK used to authenticate to an Amazon Message Queue (likely SQS or MQ). These credentials, intended for reading instructions, were over-scoped and also allowed writing to the queue. This meant compromising one device granted the ability to push signed software, change APN/Wi-Fi credentials, and control any device from that OEM. Further, a SQL injection payload thrown at the Amazon MQ endpoint resulted in thousands of Burp Collaborator callbacks, indicating a severe backend vulnerability, with some callback IPs even tracing back to the US military.
2. Case 2: Cleartext MQTT and Shadow TMS: A client, distrusting the OEM's TMS, implemented their own. However, the OEM's devices were still silently communicating with the manufacturer's TMS in the background via cleartext MQTT. This allowed MITM attacks to tamper with specific devices, even if not the entire fleet.
3. Case 3: TLS Host Invalidation and Signaling Protocol Hijack: This case involved TLS implementation flaws, specifically host invalidation issues. The client would not perform host validation, meaning a certificate trusted by a general PKI could be presented to MITM the connection. This allowed intercepting a "signaling protocol" that connected devices to an OEM-controlled peer for screen control, audio, and clicks. By redirecting this signaling protocol to a custom attacker-controlled peer, full remote control over the device screen, audio, and input was achieved. The speaker explicitly stated this vulnerability was fixed before the talk but declined to demo it due to its severity.

Device Software and Firmware Security:

• Inter-Process Communication (IPC): Android's IPC mechanisms, used for sensitive actions like remote locking/wiping, were often found to lack signature-based authentication. This meant that if an attacker had code execution on the device, they could call these IPC endpoints directly to bypass OEM remote controls, such as unlocking a stolen device.
• Transport Security Failures: Beyond TMS, general payment communication often suffered. One senior researcher found a device configured to use HTTP to the payment server by default. This, combined with a separate finding that payment requests could be replayed for up to two hours, presented a significant fraud risk.
• Certificate Chain and Hostname Validation: A particularly egregious example involved a payment QR code where the application displayed one amount (e.g., 500 rand to Mike's Noodles) but transmitted a different, higher amount to a different entity (e.g., risk accepted trust fund). This was possible due to insufficient certificate chain validation, allowing MITM to alter parameters. Another example showed a HostnameVerifier function that simply ignored its SSLSesssion parameter, effectively nullifying any hostname checks and allowing trivial MITM.

Low-Level Firmware Exploitation:

The talk delved into bootloader vulnerabilities on MediaTek devices using MTK client, a powerful tool by Benjamin Curler. This tool leverages multiple exploits to gain root access. The process involved:

1. Plugging the device into a live boot Linux distribution (due to kernel patches required).
2. Unlocking the preloader with mtk client --preloader unlock.
3. Pulling the boot image.
4. Patching the boot image with tools like Magisk or KernelSU.
5. Writing the patched boot image back to the device.
6. Booting the device.

One device, however, would enter an "orange boot state" followed by a "red boot state" and then boot loop. Du Plooy explained the Android boot states: Green (safe), Red (bootloader locked, unsigned image), Orange (bootloader unlocked, unsigned image), and Yellow (bootloader unlocked, custom image signed with custom key). The "yellow boot state" was a particular concern, as it meant the device would accept and boot any custom ROM if signed with a provided public key, a massive security hole for a POS terminal.

Through little kernel source code analysis (found publicly for the chipset), Du Plooy mapped decompiled code to source. He discovered that the device's unusual boot looping from orange to red was due to an OEM-implemented signature check function within the little kernel. This function would detect an unsigned boot image (even with an unlocked bootloader) and jump to the "red boot state" flow, preventing boot. The bypass was simple: knop out the entire signature check function in the little kernel, allowing the device to happily boot the modified image in the orange state, granting full control over the boot chain and thus root access.

Finally, file system encryption was bypassed. Even with Android's default encryption, MTK client allowed dumping the entire user data partition directly from the device. This dump contained valuable data, including SSH keys that granted access to a multi-tenant logging server, exposing transaction data from various businesses. This highlighted that even platform-level security features like FDE can be circumvented at the boot ROM level.

The sheer volume and diversity of these technical flaws underscore a systemic failure in securing these critical payment devices.

Demo / Proof of Concept

▶ Watch: Real-world SQL Injection and US Military IPs (21:50)

Connor Du Plooy presented a compelling proof of concept demonstrating how easily a card skimmer could be implemented on a compromised Android POS terminal. This particular demo did not leverage the more complex MTK client boot vulnerabilities but instead relied on obtaining USB debugging access, which, as highlighted in the talk, is often trivially achievable.

The demonstration flow was as follows:

1. Gaining USB Debugging Access: The initial step involved acquiring USB debugging access to the target device. This was achieved through one of the various methods discussed earlier, such as exploiting weak physical access controls or bypassing debug PINs.
2. Watermark Removal via Zygote Injection: To make the compromised device appear legitimate, a zygote injection technique was employed. This allowed the researchers to modify the running payment application to remove any visual watermarks (e.g., "debug mode" indicators) that might otherwise alert a user to the device's tampered state. The device, to all intents and purposes, looked like a production-ready, trustworthy payment terminal.
3. Serial Number Manipulation: A crucial step for the card skimmer's functionality was to change the device's serial number. This was necessary to impersonate the legitimate merchant's device, ensuring that transactions would be processed correctly through the backend systems while the skimming occurred.
4. Freda Script for Skimming: A Freda script was then deployed on the device to act as the card skimmer. This script intercepted card data as it was processed by the payment application.
5. Live Transaction and Data Capture: Du Plooy demonstrated this by tapping a physical card on the modified POS terminal. Immediately after the transaction, the terminal displayed redacted card data (with stars replacing sensitive digits), confirming that the Freda script had successfully intercepted and captured the payment information. The demo also showed a swipe transaction, further proving the skimmer's efficacy across different card input methods.

While a live demonstration of the highly sensitive screen control functionality (Case 3 from the Technical Deep Dive) was not performed due to its recency and the fact it had been fixed, Du Plooy clearly explained its mechanics and potential for abuse. The card skimmer demo, however, powerfully illustrated the practical implications of the vulnerabilities discussed, bringing to life the "low-effort, high-value" nature of attacking these devices.

Defensive Implications

▶ Watch: Live Card Skimmer Demonstration (40:30)

The findings presented in "Terminally Bad Credit" paint a stark picture of pervasive security failures in the Android POS ecosystem, necessitating immediate and comprehensive defensive measures from all stakeholders.

For Original Equipment Manufacturers (OEMs):

• Robust Physical Security: Implement stronger physical tamper detection and prevention mechanisms. Crucially, ADB authorization must be mandatory and properly enforced, preventing shell access simply by plugging in a USB cable. Debug interfaces should be disabled in production or require strong, non-guessable, non-time-derived authentication.
• Secure Terminal Management Systems (TMS):
• Authentication: Abandon serial number-only authentication. Implement mutual TLS (mTLS) for all device-to-TMS communication to ensure both client and server authenticate each other using cryptographic certificates.
• Authorization & Scoping: Review and strictly scope all embedded credentials within APKs. Credentials should be unique per device, have minimal necessary permissions, and never be duplicated across fleets.
• Vetting Private App Stores: Implement rigorous security vetting processes for applications distributed through private app stores, mirroring or exceeding Google Play's standards. This includes disallowing debuggable production applications and actively scanning for pirated or malicious software.
• Multi-tenancy: Ensure strict tenant isolation within TMS, preventing compromise of one merchant or device from impacting others or the entire OEM fleet.
• Secure Software Development Lifecycle (SSDLC):
• TLS Implementation: Enforce correct TLS implementation across all network communications, including strict certificate chain validation and hostname validation. Avoid cleartext HTTP for any sensitive traffic, especially payment-related.
• IPC Authentication: Implement signature-based authentication for all sensitive Inter-Process Communication (IPC) endpoints to prevent unauthorized applications from bypassing device controls like remote lock/wipe.
• Application-Level Cryptography: Avoid "security theater" by relying on custom, often flawed, application-level cryptography when robust TLS is available. Focus on secure defaults and proper platform security.
• Timely Updates and Patching: Commit to providing long-term security updates for Android OS and all device components. Be transparent about patch status and avoid misleading claims about vulnerability. Address the challenge of outdated Android versions by providing backported security fixes and considering device refresh cycles.
• Boot Chain Security: Implement robust bootloader and kernel integrity checks. Prevent unauthorized boot image flashing or modification. The "yellow boot state" capability, allowing custom ROMs, should be removed for payment terminals.

For Merchants:

• Due Diligence: Conduct thorough security assessments of POS devices and their associated services before deployment. Do not solely rely on PCI compliance, as it may not cover all attack vectors.
• Device Configuration: Ensure devices are configured securely. Disable USB debugging, restrict access to settings, and confirm all communications use TLS.
• Network Segmentation: Isolate POS terminals on a dedicated, segmented network to limit lateral movement in case of compromise.
• Monitoring: Implement robust logging and monitoring for unusual device behavior, network traffic, or unauthorized software installations.
• Employee Training: Educate staff on physical security of devices and awareness of social engineering tactics (e.g., fake debug code requests).
• Regular Audits: Engage independent security researchers for regular penetration testing of both devices and TMS.

For Users/Consumers:

• Vigilance: Pay attention to the physical appearance of POS terminals. Look for signs of tampering, unusual watermarks, or suspicious behavior during transactions.
• Transaction Verification: Always verify the amount and recipient displayed on the terminal screen before confirming a payment. Check bank statements for unauthorized transactions.

The limitations of PCI DSS were specifically highlighted, with Du Plooy stating that while it prevents low-hanging fruit, it often doesn't delve into the depth required to catch complex vulnerabilities like improper TLS chain validation or boot-level exploits. This implies a need for regulatory bodies to evolve their standards to address the full spectrum of modern threats to payment systems.

Key Takeaways

• Ubiquitous Vulnerability: Android-based POS terminals are a widespread, high-value target often plagued by fundamental security flaws across hardware, software, and backend infrastructure.
• Physical Access is Paramount: For many devices, physical access immediately grants shell access due to weak or absent ADB authorization, serving as a critical initial foothold for attackers.
• TMS: A Single Point of Failure: Terminal Management Systems (TMS) are frequently insecure, relying on weak authentication (e.g., serial numbers only) and containing over-scoped embedded credentials, making them prime targets for controlling entire fleets of devices.
• Outdated & Misleading Security: A significant number of devices run on end-of-life Android versions, are poorly patched, and OEMs often provide inaccurate information regarding their security posture, leaving them vulnerable to known exploits.
• Pervasive TLS Misconfigurations: Incorrect TLS implementations, including cleartext communication, insufficient certificate chain validation, and hostname validation bypasses, enable trivial Man-in-the-Middle attacks and payment manipulation.
• Trivial Card Skimming: With various attack vectors (USB debugging, bootloader exploits, TMS compromise), card skimming is demonstrably easy to achieve, highlighting severe risks to consumer financial data.

About the Speaker(s)

Connor Du Plooy is the Head of the Mobile Team at MWR Cyber Security. He began his career in application security in 2019, developing a keen interest in Android devices and, more recently, in mobile Point of Sale (POS) terminals. His research, as showcased in "Terminally Bad Credit," focuses on uncovering and understanding the vulnerabilities within these ubiquitous payment systems. He collaborated with colleagues David, Ethan, and Andre on this extensive research.