Inner Conflict

Inner Conflict: How Smart Device Components Can Cause Harm Omer Shwartz, Amir Cohen, Asaf Shabtai, Yossi Oren Ben-Gurion University of the Negev, P.O.B. 653, Beer-Sheva, 8410501 Israel. Abstract Mobile smart devices are built of smaller components that are often fabricated by third-parties, and not by the device manufacturers themselves. Components such as sensors, radio transceivers, and touchscreen controllers are generally supplied to the manufacturers, along with driver software that facilitates communication between the component and the host device. Driver software is normally embedded within the operating system kernel, where it is trusted to behave within defined parameters. Since the hardware of the smart device is expected not to change frequently, the device driver source code implicitly assumes that the hardware of the component is authentic and trustworthy. Such trust permits driver designs with a lax approach towards the integrity and security of data exchanged between the main processor and the hardware component. In this paper, we question this trust in hardware components. Smart devices such as phones are often repaired with replacement components. Identifying and authenticating the source of these components is usually very difficult. We assume the threat consists of a malicious replacement touchscreen procured from an untrusted vendor. We construct two standalone attacks based on malicious touchscreen hardware. Our experiments demonstrate that these attacks allow an adversary to impersonate and eavesdrop on a user, exfiltrate data, and exploit the operating system, enabling the execution of privileged commands. For mitigating these and other similar attacks, we build and evaluate a machine-learning, hardware-based countermeasure capable of detecting abnormal communications with hardware components. Keywords: Computer security, Privacy, Reverse engineering, Smart devices. 1. Introduction and Maxim Integrated provide these components, as well as the device driver source code, to phone manufacturers Smart devices and gadgets can break or malfunction who integrate the components into their phones. The man- and often require repair. A common example is the smart- ufacturers then integrate this device driver source code phone which is easily dropped, resulting in a shattered into their own source code, making slight adjustments to touchscreen. According to a 2015 study, over 50% of global account for minor differences between device models, such smartphone owners have damaged their phone screen at as memory locations, I/O bus identifiers, etc. These minor least once, and 21% of global smartphone owners are cur- tweaks and modifications make the process of creating and rently using a phone with a cracked or shattered screen [1]. deploying patches for such device drivers a very difficult While phones with broken touchscreens may be repaired at endeavor, as we discuss further in Section 2. The example phone vendor-operated facilities such as Apple Stores, it in Figure 1 illustrates this setting. The smartphone’s main is often more convenient and cost-effective for phone users logic board runs a specific OEM code (the device driver) to use third-party repair shops. Some technically savvy that communicates with the touchscreen over the internal users may even purchase touchscreen replacement kits from bus using a common, simple interface. Even hardened, online marketplaces such as eBay and perform the repair secure, or encrypted phones, such as those used by govern- themselves. These types of unofficial repairs tend to include mental and law enforcement agencies, often use commercial the cheapest possible components, and thus may introduce, operating systems and a driver architecture that follows knowingly or unknowingly, counterfeit components into the the same paradigm [2]. phone. An important observation we make is that the device Replaceable components, including phone touchscreens, drivers (written by the OEMs and slightly modified by batteries or various sensors, are seldom produced by the the phone manufacturers) exist inside the phone’s trust phone manufacturers themselves. Instead, original equip- boundary. In contrast to drivers for “pluggable” peripherals ment manufacturers (OEMs) such as Synaptics, MediaTek such as USB accessories, these OEM drivers assume that the internal components they communicate with are also Email address: [email protected], inside the phone’s trust boundary. We observe, however, [email protected], [email protected], [email protected]. that these internal components actually belong outside (Omer Shwartz, Amir Cohen, Asaf Shabtai, Yossi Oren) Preprint submitted to Elsevier October 26, 2019 of the smartphone’s trust boundary. Indeed, there are a series of end-to-end attacks that can severely some hundreds of millions of smartphones with untrusted compromise a stock Android phone with standard replacement screens. This inherent dissonance underlies firmware. We implement and evaluate three different our research questions: How might a malicious replacement attacks, using an experimental setup based on a low- peripheral abuse the trust given to it by its device driver? cost microcontroller embedded in-line with the touch How can we defend against this form of abuse? controller communication bus. These attacks can: Hardware replacement is traditionally considered a Impersonate the user - By injecting touch events strong attack model, under which almost any attack is into the communication bus, an attacker can perform possible. However, in our case, we add an important re- any activity representing the user. This includes in- striction to this model: we assume that only a specific stalling software, granting permissions and modifying component, with an extremely limited hardware interface, the device configuration; Compromise the user - is malicious. Furthermore, we assume that the repair tech- An attacker can log touch events related to sensitive nician installing the component is uninvolved. One can as- operations such as lock screen patterns, credentials or sume that these limitations make this attack vector weaker passwords. An attacker can also cause the phone to than complete hardware replacement; we show that it is enter a different state than the one expected by the not. Given the hundreds of millions of devices satisfying user by injecting touch events. For example, we show these assumptions in the wild [1], this form of abuse poses an attack that waits until a user enters a URL for a a significant danger. website and then stealthily modifies the touch events While composing this paper, we have searched for alle- to enter a URL of a phishing website, thereby caus- gations or reports of hardware implants in smartphones in ing the user surrender his or her private information; public news sources. Despite our efforts could find none. Compromise the phone - By sending crafted data This is unsurprising, and can be attributed to the highly to the phone over the touch controller interface, an directed and covert nature of these attacks, which are attacker can exploit vulnerabilities within the device most likely to be mounted by nation-state attackers against driver and gain kernel execution capabilities. targets who are either unaware of the attacks, or highly 5. We make a case for a hardware-based countermea- interested in suppressing reports about them. sure that listens to or intercepts communications In this work we highlight the risk of counterfeit or over a hardware interface and monitors for anoma- malicious components in the consumer setting, where the lies. We implement such a countermeasure using target is the user’s privacy, personal assets, and trust. machine learning techniques, and evaluate it against We show how a malicious touchscreen can record user the attacks demonstrated. The evaluation shows a activity, take control of the phone and install apps, direct true-positive rate of 100% with a false-positive rate the user to phishing websites and exploit vulnerabilities of 0% over a detection period of 0.2 seconds. in the operating system kernel in order to gain privileged control of the device. Since the attack is carried out by The rest of this paper is structured as follows. Section 2 malicious code running from the CPU’s main code space, reviews related work on smart device malware and hard- the result is a fileless attack, which cannot be detected by ware attacks. We summarize some of the current state anti-virus software, leaves no lasting footprint and survives of malicious hardware implants in Section 3. We explore firmware updates and factory resets. We also propose a the attack model in detail in Section 4, including a sur- method for designing a flexible and generic countermeasure vey of the attack surface along with the reasoning behind that may help protect against such attacks. the proposed countermeasure. In Sections 5, 6, and 7, Our paper makes the following contributions: we demonstrate the attacks described above. Section 8 describes the implemented countermeasure and its effec- 1. We explore the risk of malicious peripheral attacks tiveness against the attacks. Finally, our work is concluded on consumer devices and argue that this avenue of in Section 9. attack is both practical and effective. 2. We detail recent events and analyses in regard to 2. Related Work allegations of malicious hardware implants discovered in deployed severs and investigate the similarities to Throughout the relatively short history of smartphones, the attack model described in this paper. both

Load more