Android Security
[Disclaimer: Only for educational purposes]
Hola,
In this post we are going to talk about an interesting vulnerability that exists on present day android devices and can be exploited by hackers.
The vulnerability is called Strandhogg and was released by Promon in December first week. What all a hacker can do using this vulnerability?
Be ready to be amazed, here’s the list:
They can listen to the user through the microphone
Take photos through the camera
Read and send SMS messages
Make and/or record phone conversations
Phish login credentials/ hijack social media accounts
Get access to all private photos and files on the device
Get location and GPS information
Get access to the contacts list
Access phone logs
To top this information, this vulnerability exist on all Android versions, including Android 10, the latest one.
So what is this vulnerability exactly and how is it being exploited?
To answer this question, let’s dig into the Android system details a bit.
Any typical Android app is made up of multiple Activities. In layman terms, whenever you click on any app icon, the screen that appears on device is one activity usually. There can be more activities, depending on the functionality of app, but for simplicity sake, let’s say every new UI of the app is a new activity (it’s not always the case though, Android supports other things like Fragments etc). Every activity has set of defined attributes which one can find defined in an XML file called AndroidManifest. Here’s what it looks like:
You see, every <Activity> tag has multiple attributes such as name, label etc. The one which is of interest in this case is taskAffinity. Now how is that tag being used? Before understanding that, let’s go one level deeper and understand a bit about Android Tasks.
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack — the back stack) — in the order in which each activity is opened. For example, an email app might have one activity to show a list of new messages. When the user selects a message, a new activity opens to view that message. This new activity is added to the back stack. If the user presses the Back button, that new activity is finished and popped off the stack.
So, usually all the activities of one app are associated with one task. As they are opened, they are being pushed on the back-stack pertaining to this task. Whenever you launch an app by clicking on icon or notification or pressing back, this stack for the task is referred and accordingly the right view in brought in foreground by the Android system.
By default, all activities in an application have the same affinity which implies they belong together and hence placed in the same stack. However, you can set the “taskAffinity” attribute to group them differently, and even place activities defined in different applications within the same task. Using taskAffinity one can change the app the activity has affinity for. So if for my calculator app, for one of the activities I set the taskAffinity to Facebook app rather than my app, this particular activity can possibly sit in the stack for Facebook app and not the calculator app. Do you see the problem here?
If you see it, that’s the catch. So the hacker codes an app with different activities. Say one of them has taskAffinity for Facebook app. Now when this malicious app is launched, the activity with taskAffinity for Facebook app already starts a stack for the Facebook App, now if you click on Facebook app icon from the launcher, Android system checks this stack and shows the activity by malicious app instead of actual Facebook app.
Combining taskAffinity with other flags like FLAG_ACTIVITY_CLEAR_TASK, FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_MULTIPLE_TASK ends up giving even more control to the hacker in the flow.
The exploits one can design on top of this behaviour is limited only by imagination.
So does this actually work?
Yes, I tried testing this out by creating an app which has affinity for another legit app and it works on most devices including Pixel. However, for system apps or particular Google apps, I found that the behaviour was not very reliable.
How will it look like to you?
Why do we have it still on Android?
As Android OS is designed to support multi-tasking, this attribute comes into significance. It provides users with a seamless experience and interaction within the apps. It’s just a guess, but getting rid of this might demand major redesigns on OS level.
So, that’s all for this post.
Hope the post helped bring clarity on the existing vulnerability on Android device. If you liked it please leave comments/claps. For more such interesting posts, hit that follow button!
I’ll see you in next post soon, till then be safe and keep an eye out on odd behaviours on your phone.
Stay aware!
References:
Comments