2023/12/13 Council Agenda Packet

tended period of time. Delivery. Rootkits can be delivered to smart phones using many of the same techniques as used for malware delivery on desktop ma- chines. A study by FA -Secure showed that nearly 79.8% of mobile phones infections in 2007 were as a result of content downloaded from malicious websites Bluetooth connections and text messages were among the other major contributors to malware delivery on smart phones. Rootkits can also be delivered via email attachments, spam, illegal content obtained from peer -to -peer applications, or by exploitmg vulnerabilities in existing applications. The Neo Freerunner phone used in our experiments ran the Open- moko Linux distribution which directly executes applications with root privileges. Therefore, unsafe content downloaded on this phone automatically obtains root privileges Smart phone operating sys- tems that do not run applications with root privileges can also have vulnerabilities (just as in desktop machines). Such vulnerabilities are not uncommon even in carefully engineered systems. For ex- ample a recent vulnerability in Google's Android platform allowed command -line instructions to execute with root privileges [2]. Rootk- its can exploit these vulnerabilities and infect the operating system kernel, e.g., by installing malicious kernel modules. Persistence. To be effective, rootkits must retain long-term control over infected machines Rootkits typically achieve this goal by re- placing critical operating system modules, such as device drivers, with infected versions. While this approach ensures that the rootkit will get control even if the operating system is rebooted, it also has the disadvantage of leaving a disk footprint, which can be detected by malware scanners. Rootkits can avoid detection by directly modifying the contents of kernel memory, thereby avoiding a disk footprint. Although such rootkits are disabled when the operating system is rebooted, they can still retain long-term control over server -class machines, which are rarely rebooted. However, this technique is not as effective on smart phones because phones are powered off more often (or may die because the battery runs out of charge). Consequently, footle - its that directly modify kernel memory can only persist on smart phones for a few days In such cases, an attacker can re -infect the phone. For example, a rootkit that spreads via Bluetooth can re - infect victims in the vicinity of an infected phone. However, the social consequences of smart phone rootkits mean that they can seriously affect end -user security even if they are ef- fective only for short periods of time. 4. DETECTING PHONE ROOTKITS Rootkits vary in the sophistication of the attack techniques that they use. Rootkits that modify system utilities and some kernel modules often leave a disk footprint, and cat possibly be detected using user -space malware detection tools ' However, these tools rely on the operating system to provide critical services, such as access to files, and rootkits can easily bypass them using more so- phisticated techniques The rootkits in Section 3.1 and Section 3.2, for instance, modify function pointers in memory, and can there- fore evade detection tools that check the integrity of system util- ities. More sophisticated rootkits operate by modifying arbitrary data structures on the kernel's heap [10, 12] It is therefore well - accepted that rootkit detection mechanisms must reside outside the control of the operating systems that they monitor. Rootkit detection tools typically operate by directly accessing and scanning kernel memory (i.e., without the intervention of the operating system being monitored) for rootkits. Prior work has developed two mechanisms to access kernel memory: hardware support and virtual machine monitors (VMM). While these mech- anisms suffice to detect rootkits on server -class machines, several challenges must be overcome to adapt them to smart phones, as discussed below. Hardware -supported Rootkit e c 'o Hardware -assisted rootkit detectors operate by using special pur- pose hardware to directly access kernel memory via bMA. For ex- ample, such rootkit detectors can use secure co -processors [18, 26] or PCI cards [10] to access kernel memory, and ensure the integrity of kernel data structures. In this approach, the machine being mon- itored is equipped with the above hardware, and is physically con- nected to another machine, which fetches and scans its memory. While this approach may be practical for server -class machines, it is not applicable to smart phones First, commodity smart phones are not currently equipped with special-purpose hardware, such as co -processors and PCI cards with access to kernel memory. Sec- ond, because the approach requires the smart phone to be physi- cally connected to a momtor machine, it is not practical for use with mobile devices, such as smart phones. One option would be to trigger rootkit detection when a smart phone is physically con- nected to a desktop machine, e.g., for charging, via an interface such as USB. However, the USB interface does not allow direct memory access to attached devices, and therefore cannot be used to externally monitor the memory contents of the smart phone. To our knowledge, only the FireWire (IEEE 1394) interface allows ac- cess to the contents of memory [19], but commodity smart phones are not commonly equipped with this interface. An alternative approach is to use trusted hardware on the smart phone to attest the software stack running on the phone. In this ap- proach, a trusted platform module (TPM) chip on the phone takes integrity measurements (e g., SHA-1 hashes) of the software loaded on the phone, and stores these measurements in tamper -resistant hardware A remote verification authority (e g , the service provider) could then engage in a challenge -response protocol (e g., IMA [23]) with the phone, and receive a digitally -signed copy of the integrity measurements from the phone. The verification authority would certify the software stack by verifying the hash values of the soft- ware loaded on the phone. Prior. work has explored the use of the TPM in combination with an integrity verification protocol to detect rootkits [23] It may be practical to adapt this approach to detect rootkits on smart phones, because an increasing number vendors are beginning to deploy TPMs on their products (this chip is called the mobile trust module, or MTM) [24]. Now that the MTM is beginning to be de- ployed on commercial smart phones, using the TPM detection ap- proach is a possibility. However, three key challenges must be over- come in order to implement integrity verification for smart phones; the first two challenges discussed below also apply to integrity ver- ification on desktop computers. (1) Reasoning about dynamic data structures Current integrity measurement protocols can only measure the integrity of the code and static data (e g, configuration files) [23]. In particular, these protocols cannot attest the integrity of dynamic data structures in kernel memory. Consequently, they cannot detect rootkits that mod- ify the system call table and other critical kernel data structures To be effective against the kind of rootkits demonstrated in this paper, integrity measurement protocols must be adapted to additionally attest the integrity of dynamic data structures in kernel memory. (2) Continuous integrity measurement. Integrity measurement pro- tocols are vulnerable to time -of -check to time -of -measurement ex- ploits, in which the rootkit installs itself after integrity measure- ments are taken and the software stack has been attested. To be ef- fective against such rootkits, integrity measurement protocols must be adapted to provide continuous guarantees [25]. (3) Resource efficiency. Finally, integrity measurement and attes- tation involves a challenge/response protocol between the smart phone and remote attestation authority. Each execution of the pro- tocol requires the smart phone to transfer integrity measurements to the attestation authority Although the size of the integrity mea- 5