Now Loading ...
-
Android Static Analysis
Static Analysis
It’s about examining the code without executing the program
We are going to see the important files within the android application and how can we benefit from them
Android Manifest.xml
It contains the basic info about the application
minSDKVersion : which will give us info about the version and then we can detect vulnerability depending on just the version
package name : It’s a unique identifier for the application on the device
As an attacker we address the application through this identifier in our tools and scripts, so it’s important information for us
Permissions
What data & HW components the app needs access to: (camera, BT, internet, etc..)
You can see list of permissions here
Permissions other than uses-permission are more interesting for us. These permissions are defined by the application and if you perform specific task and want to share it with other application then they can request this permission to exchange the data between each other.
Queries
It may contain application we want to exchange data with and to do that we need to be visible to it
```xml
In this example we became visible to `sieve` application so we can exchange data with it.
We can use that when we write our attacking app to bypass login screen as example.
- application
We can see many entries like:
- `allow backup="true"` : This means that the data can be backed up (may be senstive or not)
- `debuggable="true"` : we are allowed to debug this process of the application
- `extractNativeLibs="false"` : If we have native libs included they can't be compressed (not important for us), we will need it to be false when we inject frida
- `neworkSecurityConfig=".."` : Important in dealing with ssl pinning and if it's not included we can define it (we will talk more about it later)
In the appliction we have many components (what the app has in the background)
- Activities
UI element that represents screens in the application (some of them need to be protected)
protection is done using **intent-filters** which says (before you go to this screen you need to go to through this screen based on factors like cookies)
`exported="True"` means that this activity is exposed and can be accessed from outside the app
- Intent-Filter
They are filters listening to specific intents and we will discuss them later
- service
It gots executed in the background as it may be resource intensive and not allowed to be done on UI
- broadcast receiver
It receive info to the application like receiving sms or any data from other application
It's an important attack surface
- Content Providers
serve data from ur app to other apps
most of the time it's related to database
exported content provider can be very dangerous and expose data to any user or app
the xml tag is `provider`
You may find API keys defined
At the top of the manifest you can see `backup` option
We will discuss these parts in more details
## permissions
---
Each app in android system is sandboxed which means that app1 can't access the data of app2
This is implemented by making use of the linux core of android by creating user for each application, so each app can't access the others because it willnot have the privileges by default.
- `/etc/permission/platform.xml` : this file defines the users' IDs which are individual for each app
But what if app wants to access another app or utility like photos, etc....
- this is defined in `/etc/system/packages.xml`
There are users who should be active before the system starts (hardcoded in kernel) like adb shell.
- this is defined in `android_filesystem_config.h`
Now we need to know how can we **ask** for permission ???
we knew that we can see that defined permissions in `AndroidManifest.xml` file
and these permission will be added to `/etc/system/packages.xml`
What about **custom permissions** ??
It makes the apps exchange data between each others
- This permission is defined not used directly
as example
```xml
<permission
android:label="Allows reading of the key in Sieve"
android:name="com.mwr.example.sieve.READ_KEYS"
android:protectionLevel="dangerous"
/>
This permission allows reading keys table in sieve application
When we go to content provider we will understand this more
and this defined permission can be used in another app like this
<uses-permission ns0:name="com.mwr.example.sieve.READ_KEYS"/>
protection of data is depending on choosing the suitable protection level
We have levels:
dangerous : The user is informed about this and the user decides to allow or deny (depending on user decision isn’t the best case)
normal : You won’t be informed and this isn’t considered a protection for senstive data, but it’s important for things like internet which doesn’t need to be decision before being used
signature : Each apps signed with the same key can access the data (to access database as example which is protected by signtature level then we need the private key of the sieve to access it) This isn’t practicle approach as private key can’t be shared.
activity
basically they are the screens of the application.
as example we may have login activity, profile activity, settings activity, code activity
There are activities like profile as example who need us to login first before accessing it
We see that the only visible activity or the frontline of our app is login page as example, so what if we want to reach the code activity directly by scanning QR code from QR scanner app directly?
The QR scanner must be able to see the code activity and this moves us to exported: which means that the activity is reachable by outside world (dangerous and handled by intents which will be discussed later)
We can know if the activity is exported or not from AndroidManifest.xml file and exported can be implicit and explicit:
explicit : occures when the activity has the attribute exported="true"
implicit : occurs if the activity has intent-filter so it’s also reachable from outside world
Exported scheme doesn’t only affect activities
we can make access exported activity using malicious app or adb shell
after getting adb shell we use the command am which is activity manager but we need to identify the activity to be opened
the activity is identified to be <package name>/<activity name(keep the dot)> so the command becomes am start-activity -n <package name>/<activity name(keep the dot)>
intents
It’s a messaging object and it can be implict and explicit
implicit : We don’t know the exact destination application like we know it’s email app but we don’t know which app exactly
explicit : We know the destination we want to call and the destination can be in the same app or in a different app
It doesn’t work with activities only but also services and BroadcastReceivers
Explicit Intents
Consider you have login activity and you want to login to reach profile activity, this can be implemented like this in login activity source code
Intent myIntent = new Intent(this,ProfileActivity.class); // defining the intent by passing the source and the target
this.startActivity(myIntent);
If we want to start the new activity with parameters
Intent myIntent = new Intent(this,ProfileActivity.class); // defining the intent by passing the source and the target
myIntent.putExtra("username","admin"); // passing username parameter with value = "admin"
this.startActivity(myIntent);
and the parameter is used in the profile activity like this
@Override
Protected void onCreate(Bundle savedInstanceState){
Intent intent = getIntent();
String user = intent.getStringExtra("username"); // get the passed parameter username
}
Implicit Intents
Here we said that we don’t know the destination exactly as example we did an action that send mail and the exact mail app isn’t choosed.
The system sends out this intent and we want to open mail app to do this action (gmail app may be opened as example) but we will know more details in BroadcastReceiver.
If parameters are passed with the intent then there’s an attack vectorif the passed data are sensitive as we can create malicious app that listens to this type of intents (mail as example) and it will sniff the system for this information and this is called Intent - Sniffing
Intent-Filter
As example the main activity will have an intent-filter with action:MAIN and category:LAUNCHER.
It’s just listening to bus system and filtering out the info related to the app we need to react with and ignore the others
It has certain tags : action, category and data
we can know more about them and the possible values here
Note: if you want to interact with intent-filter which is considered implicit use this command am start-activity -a <action> -c <category> --es <key> <value>
–es is to pass key value pair data as string
If there’s many apps with the same action, category the user will choose which app to use
BroadcastReceiver
They are a kind of notification system for ur applications.
There’s a specific events like connecting the headphone, connecting to wifi, etc…. these events are sent as broadcast to all apps
Not all apps react to this, some of them ignore it and the other can react to it through onReceive method.
ordered priority
It was an issue at android 4.3
each app is assigned a specific priority (as example sms has the highest priority = 200)
So it will be the first app to receive the msg and can decide to leave it to the next app with lower priority or not
The problem that in android <= 4.3 The attacker was able to assign it’s app a priority up to 999.
This is fixed in android 4.4 and the priority assignment is limited now.
To find which event each app is listening to, There are 2 approaches:
old approach (until Android version 8): in AndroidManifest.xml
new approach: Finding onReceive function within the Java code
In some broadcast events important data are passed so if we could receive them we may be able to move forward in the target.
Local broadcast manager can’t be exploited because we can’t interact with it, It’s just a messages bewtween classes as example.
adb.exe logcat: to show logging of the app
to open local console we use adb.exe local => this is console at which we can get the output of print function
Sending broadcast through adb: am broadcast -a <action in the intent filter or from the source code depending on android version>
we may not have the permission, so make sure u r root
pm -U: List packages with uid so we can broadcast to specific uid and replcace a with 10, so the broadcast command can be am broadcast --user <uid> -a <action>
If there’s string info to be sent with the Intent filter we can use --es option as we know.
Services
Consider you have a game and it needs some processes like rendering the game and organization of objects (in UI) and we also need network requesting as example.
If all these components are in the main activity we will have a problem: The network request may stop the UI thread until the request is done which may result in closing the app (the app in android is closed if the UI thread isn’t working for some seconds).
The solution is to make the components which isn’t in the UI to be services in background
We have 2 types of services: start service & bound service
start : very simple just the service started when we need it to do some task then close it.
bound : binding client to service (we may have client interacting with the app) then we need to wait for the clients to disconnect to shutdown this service
The services can’t make UI updates as they work in the background
If we want to do so we may make use of BroadcastReceiver and make them trigger the service via onReceive()
This was the common behvior till android 8 cause this background execution isn’t allowed any more.
What to look for ?
start : here you will look into intent
bound : look into the message object
to attack the service it needs to be Exported and Permissions to interact with this one.
ContentProvider
It’s simply provide a content and usually it’s used with databases, we can interact with them via content URI.
as example The Contacts they are stored in db and there’s content provider for this data base.
content URI is used to interact with them and in consists of:
prefix : which is content:// and it’s a good keyword to search for when reversing the app
authorty : It’s a unique identifier for the content provider
table entry
row in table
Content provider are excluded from intents so interaction with them is done in different way like using adb shell and then the command will be $ content query --uri content://com.android.contacts/contacts/1
What if we don’t have adb shell access, so we will write our malicious app.
in our app we want to define ContentResolver that asks the content provider to provide the content to us
we need 2 use cases:
Having permissions
Exported: True
Then after asking, thew content provider returns a Cursor(pointer to data in db) to our app
The content provider must include query, update, insert and delete methods and we will use them in the resolver for interaction with the provider
The data base of custom content provider are stored in data/data/<package>/db
Here we see the structure of query function and how it’s mapped to sql query.
and here we see a basic application of sqli.
content providers aren’t invoked by intents so to interact with it, it must be exported.
ContentProvider can also read and write files this moves us to path traversal vulenerability.
Let’s look in accessing file using content provider
we see that the file is vulenrable to path traversal so the app can get pin.xml file in this example
The content provider is exported if we have read or write permissions, but the protection level may prevent us from exploitation if it’s signature.
protection level dangerous can be ok if the data is encrypted.
from the source code we can reach the implementation information of db like the database.db file and the tables’ names.
note: if table name is db structure source code = key and it’s refrenced in the manifest as keys we will use key in sqli.
interaction with content provider using adb shell is done using content query|insert|... --uri <content provider uri>
OFC the table must be accessable (we should have Read or write permissions), but we have another accessable table we can make use of it to reach the protected table.
Example: passwords table is accessable but key isn’t and we have this command content query --uri content://.....DBContentProvider/passwords we can make use of projection for sqli like this content query --uri content://.....DBContentProvider/passwords --projection "* from key--" so the query became select * from key -- from passwords ... but all after the – is commented so we can ignore it now and celebrate with the key data we got.
If the protected uri isn’t defined in regex we can query it directly like this content query --uri content://.....DBContentProvider/keys/
Insertion in DB: we can see its syntax from the help of adb shell content.
signing
It’s needed in many things like keeping track if there’s an update for the app in the store
package name isn’t enough because it’s unique on the phone only but we can create apps with the same package name of other apps in the store.
So the developer signs the application with a private key and the signature with the package name are used to know that the app on our phone is the one on the store and this update is for it.
Private keys used for signing applications must be super safe.
This process is for verifing the author of the app.
we can sign 2 different apps with the same signature so they can share data together without the need of exported components so the components are no longer exposed to the whole world, but the app we need to exchange the data with only.
If we want to modify app.
use apktool to decompile the apk using apktool d game.apk
you will get the decompiled files and you can modify what you want
build the apk again apktool b game.apk
We can’t install the apk if it isn’t signed so we sign it using zipalign for preparing offset for the certificate to be placed in the correct place and apksigner for signing the app
before android 11 we could use jarsigner directly for signing
Let’s see the process in more details
generation the key
keytool -genkey -v -keystore <path/to/keystore file> -alias alias_name -keyalg RSA -keysize 2048 -validity 365
-getkey for generating the private key
-v make the certificate human readable
keystore is a file which is the place at which the key will be stored
alias it’s the way we will define the key
note that many keys can be saved in the same keystore but of course the alias will be different
for signing
zipalign -v 4 base.apk out.apk
apksigner sign --ks-key-alias <alias name> -ks <path/to/keystore file> out.apk
alias is needed if there are more than a key in the keystore
METAINF dir contains all signing information so it must exist after signing
Common Application Strings
We may find useful strings to get more info
Hardcoded Strings
can be found in: resources/strings.xml, activity source code
we may find: login creds, api key, exposed url, firebase URLs
-
-
Android Basics
Android Architecture
Android is based on linux OS, so the android phone can take commands like any linux device ls, cd, rm, etc..
Folders and Apps depend on the linux os permission model
The figure below shows the main components of Android platform
System Apps
This layer includes both the pre-installed applications like Camera & Calender and the 3rd pary apps which is installed by the user like facebook.
The apps run within the Android runtime
Java API Framework
Allows the app to interact with other apps and it also provides abstraction for HW access
It also manages the UI
consists of many things like:
Content Provider: helps in sharing data to other apps via specific directory which should be exported content://<app-URI>/directory
View System: Making the UI of the application
Managers:
Activity => the single activity is a single UI screen of the app
Notification => application’s reminders and popups
etc….
Android Runtime
The base of the app and it powers the app with the help of core libraries
Virtual Machine to generate .dex file as a result of compliation and optmization
Native C/C++ libraries
In the same layer of Android runtime
Contains core libraries like sqlite for db, openssl for secure connection, etc…
Hardward Abstraction Layer (HAL)
Allows apps to access HW components irrespective of the type or manufacturer of the device like camera, bluetooth, GPS, etc…
New HAL types like IOT devices, gaming peripherals, etc..
Linux Kernel
Supp multiple CPU types (ARM, SoC, 32 bit, 64 bit)
The version of the Android Runtime/ API version is determined in Manifest => min SDK version
The higher the better but there’s a trade of between using higher version and serving as many customers as possible because not all phones supports the higher versions
Low version means more danger (more vulnerable)
The kernel also controls the available drivers by which the access to the devices during runtime occurs
Application Journey
Source Code (written in Java or Kotlin) + lib + resources ==compile==> DEX
The source code is compiled but lib just helps in compilation which is done by virtual machine giving DEX file
DEX ==build==> APK
APK ==sign==> signed APK
The APK must be signed using a certificate exist at the developer
The signed APK is uploaded to google play and now can be installed on user’s device
Android Security Model
Android consists of 2 security layers: DAC-Discretionary Access Control & MAC-Mandatory Access Control
Each application has its on user who is the oner of the app.
users have UID between 10000 and 999999
the username u0_a188 has UID 10188
Apps can’t interact ith each other unless explicitly granted permissions or Content Provider/Broadcast Receiver is exposed.
Application components
Activity
It’s the UI with which the user interacts
Each activity in the app is a single screen
login page is an activity and register page is another activity
Services
It handles the background processes the works behind the UI like downloading or any process
Broadcast Reciever
It handles communication between the apps with the OS of Android.
When you connect ur phone to internet the system broadcasts a message saying that the phone is connected to the internet then the apps do their work depending on getting connected to internet
Local Storage
How the app is stored in the system
consists of
Shared Preferences: Sometimes to improve the application’s performance some data is stored on the device locally
DB (content provider): data is saved in SQlite db, The app reached the data through the content provider which must be configured properly to avoid local sqli vulnerability
Files: stored for each app and isolated from other app and sometimes stored on SDcard this was vulnerable in android 4.4 and the SDcard could be accessed by other apps
Additional components
Fragments: part of activity
Views
Layouts
Intents: method by which the components communicate (discussed later)
Resources
Manifest: The most important file in the app as it contains all the components of the application (discussed later)
Developer Options
It offers you a collection of great tools that we will use in the upcoming sections like
USB-Debugging
Select mock location app
Select debug app/ Wait for debugger
Pointer Location
Bluetooth HCI Snoop Log
Enabling Developer Options
Go to System
About Phone
Go to build number and click it, then you will see if you are developer and if not it will tell you how many clicks you should do to be developer
ADB (Android Debug Bridge)
Let’s look on Its components and how it works.
ADB Components
The components are:
adb server on your machine
adbd (the daemon on the mobile) running by default on the device, so you don’t need to install it or somehink like that
adb client (binary) (in platform-tools and it comes with sdk)
adb protocol is text based protocol and we will look into it in the future
ADB process
How it works:
adb client sends command to adb server
adb server sends the command to the mobile
The command is executed on the mobile then sends it back the server
The response is forwarded back to the client
if we have single device connected we can use adb shell command, but if there are multiple devices we will use abd -s <serial> shell
ABD-Fowarding
consider there’s a service on port 31415 on the mobile, but it’s accessed locally only.
to access it through our localhost we use port forwarding
by using adb forward tcp:1337 tcp:31415 we will be able to access port 31415 on the mobile by accessing localhost:1337
Forwarding can also be reverse, but it’s not popular
by using adb reverse tcp:80 tcp:8080 we will be able to access port 8080 on our localhost through the mobile on port 80
Additional Notes
sdcard and tmp directory are both accessible from our local device to the mobile without root privileges so we can use adb push file path_on_mobile and the path can be /sdcard/
adb push to uplaod file to the mobile
adb pull to download file from the mobile
logcat is a great command you can run when u run app and the logs will be stored and you can get interesting info
adb kill server then start again this will resolve many issues if occured with the server
Android Application Structure
assets : contains resources used in the app like images, music, etc…
com : no interesting data for us
lib : contains .so files which are compiled c/cpp files because they are better than java in specific task like rendering 3d effects. (sometimes developer hide data in c/cpp code instead of java code)
armeabi : compiled for the platform of the original device
x86 : compiled for our vm as example
META-INF : related to signing the application
res : maybe considered like assets directory as it contains images, etc..
AndroidManifest.xml: We will dive into it later as it very important
classes.dex : The most important file for us as it contains the JAVA source code.
and java is compiled in dex format
resources.arsc : contains resources like resources used in the application.
Let’s recap this
DEX/ODEX files
We are going to discuss it a very high view
You have an app and it is got compiled using Java Virtual Machine
For Java app on your PC : It’s got compiled to Java Bytecode (main.class) and it is not good for smart phone as it need more resources which won’t fit with mobile battery
For mobile app : IT’s got compiled to dalvik executable (classes.dex) which is suitable for smart phones
Note: classes.dex contains at most 65535 methods and if we have more than this number we will have many .dex files which is called MultiDexing
Decompilation
To decompile an apk we need to get it first
And to get an apk
$ adb shell
$ pm list packages
$ pm path
$ adb pull <path>
to compile the app we use
apktool d <APK>
to build the app again
apktool b <APP PATH>
There are options like:
-r to not decode resources like android manifest as it will cuz problems if decoded in this case
-s to not decode source code as it will cuz problems if decoded in this case
--force-manifest this is good if the problems in resources other than manifest so it will decode manifest even if decoding resources is set to false
When we compile we will get these files (let’s compare them to unzipping we saw before)
The identical files:
assets
lib
META-INF and AndroidManifest.xml = original
res and resources.arsc = res and note that it contains values dir which contains resources.arsc data
com = in unknown
Different
smali which contains .dex files so we have java src code and we have .smali files
Touch background to close
