Laserfiche WebLink
Battery Life For Different Smartphones <br />Verizon Touch <br />ATTTat <br />Phone Yak. and Model <br />■Normal Idle <br />()peahen <br />EAU Peripherals <br />DeofreeRunne <br />Figure 3: Sequence of steps followed in location privacy attack. <br />is achieved by modifying the corresponding entries in the system <br />call table to point to rootkit code. Consequently, the rootkit identi- <br />fies when user -space applications are accessing the GSM device by <br />checking the file descriptor that is passed into read and write. difference is that the rootkit achieves this goal by directly modify - <br />When this occurs, our rootkit scans the GSM for certain incoming ing the smart phone's operating system. <br />AT commands. Attack Description. The GPS and Bluetooth devices can be tog - <br />When an incoming message arrives, the rootkit will check whether gled on and off by writing a "1" or a ' 0," respectively, to their cor- <br />responding power device files. The rootkit therefore turns on the <br />GPS and Bluetooth devices by writing a `1" to their corresponding <br />power device files. To remain stealthy, the rootkit ensures that the <br />original state of these devices is displayed when a user attempts to <br />view their status. Most users typically turn these devices off when <br />they are not in active use because they are power -intensive. <br />When a user checks the status of a GPS or Bluetooth device, <br />the user -space application checks the power device file for a "1" <br />or "0". To do this, it calls the open system call on the file and <br />then reads it. The rootkit monitors the open calls by overwriting <br />kernel function pointer for the open system call in the system call <br />table, making it point to rootkit code. When an open system call is <br />executed, the rootkit examines if the file being opened corresponds <br />to the power device files of the GPS or Bluetooth devices If so, it <br />ensures that the original states of the devices are displayed to the <br />user. The rootkit continuously checks the status of these devices* if <br />the devices are turned off by the user, the rootkit turns them back <br />on. Consequently, the devices are always on, except when the user <br />actively queries the status of these devices. <br />Social Impact. This attack quickly depletes the battery on the smart <br />phone. In ow experiments, the rootkit depleted the battery of a fully <br />charged and infected Neo Freerunner phone in approximately two <br />hours (the phone was not in active use for the duration of this ex- <br />periment). In contrast, the battery life of an uninfected phone run- <br />ning the same services as the infected phone was approximately 44 <br />hours (see Figure 4). We also simulated the effect of such a rootkit <br />on the Verizon Touch and A'IT Tilt phones by powering their GPS <br />and Bluetooth devices. In both cases, battery lifetime reduced al- <br />most ten -fold Because users have come to rely on their phones in <br />emergency situations, this attack results in denial of service when <br />a user needs his/her phone the most. <br />Although our prototype rootkit employs mechanisms to hide it- <br />self from an end user, this attack is less stealthy than Attacks 1 <br />and 2. For example, a user with access to other Bluetooth-enabled <br />devices may notice his smart phone is "discoverable,' causing him <br />to suspect foul play Nevertheless, we hypothesize that the vast <br />majority of users will suspect that their phone's battery is defective <br />and replace the phone or its battery <br />3.4 Rootkit Delivery and Persistence <br />To effectively infect a smart phone using the rootkits discussed <br />above, attackers must also develop techmques to deliver rootkits <br />and ensure that their functionality persists on the phone for an ex - <br />this is a query from the attacker. This is done by sending the AT <br />command to read messages. An attacker's message will be a certain <br />phrase or set of words that the rootkit can check for. If the message <br />is a query from the attacker, the rootkit's malicious operation is ex- <br />ecuted. The rootkit can be written to enable different functionality <br />for different messages 1 The attacker can also enable/disable the <br />rootkit's malicious functionality via text messages, in effect allow- <br />ing the attacker to remotely control the rootkit. <br />Importantly, the rookit, must also suppress the notification of the <br />attacker's message, to ensure that the user does not learn about it. <br />The rootkit deletes the message from the SIM card by sending an- <br />other AT command to the GSM device. <br />Once the rootkit mtercepts a message to query a user's current <br />location, it attempts to obtain location information from the GPS <br />device. As before, the rootkit can easily obtain location information <br />from the buffer of the GPS device. The rootkit can obtain location <br />information even if the user has disabled the GPS. This is because <br />the rootkit operates in kernel mode, and can therefore enable the <br />device to obtain location information, and disable the device once it <br />has this information. If the user checks to see if the GPS is enabled <br />during this tune, it will appear that the GPS device is off. <br />Having obtained location information, the rootkit constructs a <br />text message and sends the message by sendmg an AT command <br />to the GSM device. The attacker will now receive a user's current <br />location. <br />Social' Impact. Protecting location privacy is an important problem <br />that has received considerable recent attention in the research com- <br />munity. By compromising the kernel to obtain user location via <br />GPS, this rootkit defeats most existing defenses to protect location <br />privacy. Further the attack is stealthy. Text messages received from <br />and sent to the attacker are not displayed immediately to the victim. <br />The only visible trace of the attack is the record of text messages <br />sent by the victim's phone, as recorded by the service provider. <br />• <br />3.3 Denial of Service via Battery Exhaustion <br />Goal. This attack exploits power -intensive smart phone services, <br />such as GPS and Bluetooth, to exhaust the battery on the phone. <br />This rootkit was motivated by and is similar in its intent to a previ- <br />ously proposed attack that stealthily drains a smart phone's battery <br />by exploiting bugs in the MMS interface [22] However, the key <br />IL This mechanism is also useful in Attack 1—instead of hard - <br />coding the number that the rootkit must dial, an attacker can trans- <br />mit the number that the infected phone must dial via a text message. <br />Figure 4: Denial of service via battery exhaustion. This figure <br />shows how the battery life d des in t erent phone models <br />when the GPS and Bluetooth devices are powered on. <br />4 <br />