Mobile apps need optimal performance and responsiveness to rise amongst numerous rivals on the market. Further, some apps like media streaming or gaming apps cannot even function properly with a performance below a certain threshold. In this work, we present the first performance degradation attack on Android OS that can target rival apps using a combination of logical channel leakages and low-level architectural bottlenecks in the underlying hardware. To show the viability of the attack, we design a proof-of-concept app and test it on various mobile platforms. The attack runs covertly and brings the target to the level of unresponsiveness. With less than 10% CPU time in the worst case, it requires minimal computational effort to run as a background service, and requires only the UsageStats permission from the user. We quantify the impact of our attack using 11 popular benchmark apps, running 44 different tests.} The measured QoS degradation varies across platforms and applications, reaching a maximum of 90\% in some cases. The attack combines the leakage from logical channels with low-level architectural bottlenecks to design a malicious app that can covertly degrade Quality of Service (QoS) of any targeted app. Furthermore, our attack code has a small footprint and is not detected by the Android system as malicious. Finally, our app can pass the Google Play Store malware scanner, Google Bouncer, as well as the top malware scanners in the Play Store.

In this work we show how the Lucky 13 attack can be resurrected in the cloud by gaining access to a virtual machine co-located with the target. Our version of the attack exploits distinguishable cache access times enabled by VM deduplication to detect dummy function calls that only happen in case of an incorrectly CBC-padded TLS packet. Thereby, we gain back a new covert channel not considered in the original paper that enables the Lucky 13 attack. In fact, the new side channel is significantly more accurate, thus yielding a much more effective attack. We briefly survey prominent cryptographic libraries for this vulnerability. The attack currently succeeds to compromise PolarSSL, GnuTLS and CyaSSL on deduplication enabled platforms while the Lucky 13 patches in OpenSSL, Mozilla NSS and MatrixSSL are immune to this vulnerability. We conclude that, any program that follows secret data dependent execution flow is exploitable by side-channel attacks as shown in (but not limited to) our version of the Lucky 13 attack.

Abstract Software updates and security patches have become a standard method to fix known and recently discovered security vulnerabilities in deployed software. In server applications, outdated cryptographic libraries allow adversaries to exploit weaknesses and launch attacks with significant security results. The proposed technique exploits leakages at the hardware level to first, determine if a specific cryptographic library is running inside (or not) a co-located virtual machine (VM) and second to discover the IP of the co-located target. To this end, we use a Flush+Reload cache side-channel technique to measure the time it takes to call (load) a cryptographic library function. Shorter loading times are indicative of the library already residing in memory and shared by the VM manager through deduplication. We demonstrate the viability of the proposed technique by detecting and distinguishing various cryptographic libraries, including MatrixSSL, PolarSSL, GnuTLS, OpenSSL and CyaSSL along with the IP of the VM running these libraries. In addition, we show how to differentiate between various versions of libraries to better select an attack target as well as the applicable exploit. Our experiments show a complete attack setup scenario with single-trial success rates of up to 90% under light load and up to 50% under heavy load for libraries running in KVM.