The majority of electronic devices in reality are interactive, and increasingly, public places are installing more touchscreen interactive devices. These devices vary in complexity and function, deployed in different settings and applications. Almost any large public venue now features such devices, including restaurants, retail stores, and ticketing counters, offering consumers self-service convenience. Even more, some of these devices connect to the internet for centralized management purposes.
Therefore, this article pertains to the security risks of touchscreen interactive devices, specifically those requiring touch or click operations.
By the way, the following discussion categorizes, describes, and speculates on the origins of these security risks based on the author’s understanding, and no actions were taken to harm public safety in practice.
Current types of interactive device applications can roughly be divided into three categories: Flash (yes, some devices still use this outdated technology), web pages (many interactive devices use this), and apps (most devices based on Android use this method). Correspondingly, operating systems fall into three categories: Windows, Android, and Ubuntu.
The security risks of touchscreen interactive devices mainly stem from the escape or bypass of applications displayed on physically accessible devices. After escaping an application, attackers can access the native system’s operations or configuration interface, potentially causing security hazards depending on the device’s application and internet connectivity. These hazards may include but are not limited to:
- Manipulating displayed content, including text, images, and links.
- Preventing the device from connecting to the internet for updates.
- Remotely downloading and implanting backdoors or trojans.
- Further attacking other interactive devices through the device’s internet connectivity.
- Accessing information from centralized management platforms through the device’s management functions.
- Using the device as a pivot point to attack centralized management platforms.
- Stealing device-specific data, including files, images, and text.
First: Hidden Virtual Keyboards
Windows system interactive screens often conceal virtual keyboards positioned in the top left corner of the screen. Careful observation reveals a protruding keyboard border; swiping right reveals the full virtual keyboard. Operating the system’s virtual keyboard allows executing system commands (based on the current user’s permissions) or viewing system files.
This feature may be designed by device developers to facilitate the normal use of virtual keyboards during system maintenance or debugging, avoiding the hassle of external device connections and associated interfaces.
Second: Mischievous Context Menus
In applications using Flash or web formats, a touchscreen cursor appears as a circular dot. While single-tap (left-click) interactions are sufficient for functionality, long-pressing can bring up context menus. Some menu items, like Help or Print, provide enough functionality to escape application restrictions, such as accessing resource browsers and exiting or closing applications to enter system interfaces.
During development, manufacturers typically focus on developing forward-facing features, often overlooking or not shielding native or application-provided functionalities. This oversight occurs because normal developers do not anticipate “unconventional” usage scenarios. Therefore, in product design, product managers need to consider not only normal use cases but also abuse cases or sad path (compaired with happy path).
Third: Overlooked System Menus
In Windows application development, system menus are default in the title bar, accessible via right-click. The complete menu includes a “Close” option. This risk is similar to the previous one, where developers may neglect handling built-in menu functionalities, such as selecting Close or removing related menu codes.
Fourth: Neglected Input Methods
In designs involving input interactions, some applications customize input methods like a nine-square grid, while others use native system keyboards or third-party input methods. Third-party input methods, with their enhanced functionalities, provide ample escape routes. While this usage is acceptable on personal terminals with system ownership, it poses problems in single-application interactions.
This indicates that when introducing third-party functional components, manufacturers or system providers need to carefully assess all features and security capabilities of these components. For users, product issues often intuitively link to product manufacturers. For instance, the recent revelation of bypassing Windows lock screens through Sogou input methods illustrates this — individually, both software are normal but combined, they lead to vulnerabilities, akin to the toxic combination of toilet bowl cleaner and disinfectant.
Moreover, in determining whether a phenomenon is a vulnerability, analysis based on the CIA triad (confidentiality, integrity, and availability) suffices. Using Sogou input methods to bypass Windows lock screens and access Windows Explorer clearly breaches the confidentiality of Windows lock screen functionality (preventing access to system resources when users are not logged in), confirming this as an undeniable vulnerability.
Fifth: Untimely Application Response
This situation is rare but occurs in older devices with poorer performance. During touchscreen operations, inadequate system performance causes applications to fail to respond to rapid or concurrent user actions. Rapid touchscreen operations can crash related processes, leading to error report pop-ups and potential escape to the operating system interface.
This issue is easily resolved by timely device updates. However, not all devices in every location receive timely updates, as evidenced by fingerprint residue on ATM buttons pre-2013, eventually replaced by stainless steel brushed keyboards to address this issue. Nevertheless, not all ATMs in every location can be updated promptly, contingent on local financial capability, willingness, and impact.
Sixth: Other Specific Interactions
These interactions include multi-touch or repeated rubbing, each revealing suspicious conditions through interaction points and methods. For instance, in a large shopping mall’s toy vending machine, sliding three fingers downward from the top reveals a fleeting “Exit Full Screen” button, requiring considerable patience.
Depending on the system type, different operational trials explore device hidden functionalities or insecure functions within specific scenarios.
It is worth noting that the fifth category of security risks mentioned above can also be termed a Bug, while the recent Windows lock screen bypass is a result of functional overlay.
In most cases, to differentiate between a Bug and a vulnerability, consider this analogy:
A Bug is something that should have happened but didn’t, like Joe and his wife not having children despite years of marriage, they should make a appointment with doctor.
A vulnerability is something that shouldn’t have happened but did, like Jos’s wife was found unexpectedly pregnant without seeing her husband for a long time, probably they would go to see a divoce lawyer.
