Nowadays, Bluetooth is an integral part of mobile devices. Smartphones interconnect with smartwatches and wireless headphones. By default, most devices are configured to accept Bluetooth connections from any
nearby unauthenticated device. Bluetooth packets are processed by the Bluetooth chip (also called a controller), and then passed to the host (Android, Linux, etc.). Both, the firmware on the chip and the host Bluetooth subsystem, are a target for Remote Code Execution (RCE) attacks.
One feature that is available on most classic Bluetooth implementations is answering over Bluetooth pings. Everything an attacker needs to know is the device’s Bluetooth address. Even if the target is not discoverable, it typically accepts connections if it gets addressed. For example, an attacker can run l2ping, which establishes an L2CAP connection and sends echo requests to the remote target.
In the following, we describe a Bluetooth zero-click short-distance RCE exploit against Android 9, which got assigned CVE-2020-0022 . We go through all steps required to establish a remote shell on a Samsung Galaxy S10e, which was working on an up-to-date Android 9 when reporting the issue on November 3 2019. The initial flaw used for this exploit is still present in Android 10, but we utilize an additional bug in Bionic (Android’s libc implementation), which makes exploitation way easier. The bug was finally fixed in the security patch from 1.2.2020 in A-143894715. Here is a demo of the full proof of concept:
When you are working in the area of mobile security, you sooner or later receive requests from clients asking you to test specific ‘Mobile Device Management’ (MDM) solutions which they (plan to) use, the corresponding mobile apps, as well as different environment setups and device policy sets.
The expectations are often high, not only for the MDM solutions ability to massively reduce the administrative workload of keeping track, updating and managing the often hundreds or thousands of devices within a company but also regarding the improvements towards the level of security that an MDM solution is regularly advertised to provide.
With this very blog post you are reading and a small series of future blog posts, I would like to provide some insight from my day-to-day practical experience with some of the most often used MDM solutions from a testers perspective.
If you attack someone, they will defend themselves, but if you tickle them, they will eventually crack open. This surprisingly applies to Android apps as well! Therefore, I created AndroTickler, not to test apps against certain attacks or examine them for specific vulnerabilities, which developers would learn to avoid. However, it helps pentesters to analyze and test apps in their own style, but in a faster, easier and more flexible way. AndroTickler is a Swiss-Army-Knife pentesting tool for Android apps. It provides information gathering, static and dynamic analysis features, and also automates actions that pentesters frequently do and highly need during their pentests. In addition, it makes use of the powerful Frida to hook to the app and manipulate it in real-time.
It summarized five presentations of the 6th Annual Workshop on Security and Privacy in Smartphones (SPSM’16). In short, it contained presentations on: over-the-top and phone number abuse, smartphone fingerprinting, apps privacy increase and protection/security, and apps privacy ranking. Continue reading “CCS’16 – Day 2 – 25th October 2016”
We’re using our smart phones every day to manage contacts, calendar entries, e-mail, and social communication (please note that we at ERNW still have a strict “no company data on smartphones/tablets” – which includes email). Everything is easy to use and automated syncing provides access to our data from anywhere. Data is stored in most cases on premises of a cloud service provided by the OS vendor of your smart phone – mostly Google, Apple or Microsoft. You don’t need to pay for this service – and the cloud provider could use your data for personalization and service improvements.
But from a security point of view (or just because you don’t want to share your personal information with the cloud provider) one probably wants to use all those features with a service on your own infrastructure.
a few weeks ago I held a talk at UnFUCK, a small University con from students for students. I had decided to give a short talk on “Owning Stuff via USB” aka how to use our TR14 Badge! During the preparations and while building my demos, I tested my new USB RubberDucky. One rather “trivial” demo was actually to use it as a keyboard on an Android phone.
Our new workshop about mobile application testing, held for the 1st time at the Troopers conference 2013, is coming closer. So I would like to take the opportunity and post an appetizer for those who are still undetermined if they should attend the workshop ;-).
While the topic of mobile application testing is a wide field that may contain reverse engineering, secure storage analysis, vulnerability research, network traffic analysis and so forth, in the end of the day you have to answer one question: Can I trust this application and run it on my enterprise devices? So first you have to define some criteria, which kind of behavior and characteristics of an application you regard as trustworthy (or not). Let us peek at malware … besides harming your devices and data, malware is typically:
obfuscated and/or encrypted
contains anti-debugging features
contains anti-reverse engineering features
This makes the analysis process a difficult task and comparing these characteristics especially to ordinary iOS applications from the AppStore, at least one is also true for these apps: Those are encrypted and are only decrypted at runtime on your Apple gadget ;-).
Lately there have been some rumors on the full-disclosure mailing list referring to a blogpost of Hatforce about a new method to bypass the PIN/password lock on Android Gingerbread phones.
The approach was to boot into the Recovery Mode and execute a reset to factory state. The ideal result should be a reliable wipe of the /data partition. However, the author managed to recover data after the wiping process. This has been stated as a method on extracting sensitive date without knowing the actual pin or passcode.
This approach was tested on a Nexus S smartphone with Android 2.3.6 assuming the problem could be present on other devices too.
As of our experience this actually affects all Android devices without device encryption. Meanwhile we had more than ten different Android 2.3.x devices from four different vendors. All of them need less than a minute for a factory reset. An actual example is the HTC Desire HD with a 1,1GB /data partition excluding the /cache partition. The factory reset procedure took about 40 seconds, which can hold as an advice to question if this time is actually sufficient to wipe the whole storage. Finally we have been able to recover data after factory-reset devices as part of previous studies.
Besides mentioning that the source code indicates Android devices runnig Android Honeycomb and later effectively wipe data. After looking up in the source code of Android Ice Cream Sandwich we found that the FileWriter class is used for the wipe of the /cache and /data partition. So no indication on overwriting the data here. We assume, that by mentioning the issue as resolved, he was referring to Android Honeycomb device encryption being use, which indeed resolves this issue. This feature has been announced as a new feature anyway.
The fact about getting the data without knowing the PIN however does not really fit the case. From our opinion that’s not a new thought anyway. As long as the storage is not encrypted there always ways to access and read it. My favorite way is to flash the recovery mode with a custom one, e.g. ClockWorkMod By this means it’s possible to run Android Debugging Bridge, su and dd binaries which in return can be used to connect to the device via USB cable and create a raw copy of the storage. Additionally it becomes available to follow the loudness principle and acquire data on a forensic level.
However there is one important aspect mentioned in the blogpost, which we fully agree with: lost device means lost data!