Week 6 - Understanding the Security Model Flashcards
Security Model
To prevent unauthorized access to an application’s data by other applications running on the same device.
One application cannot negatively impact the operation of another without proper consent, creating what is known as the application sandbox.
Verifying an application’s identity is essential to maintain trust boundaries and prevent unauthorized claims of identity, such as impersonating Google. This identity verification is managed through code signing
Code Signing
A cryptographic process using digital certificates.
Private keys of these certificates are held by application developers.I
It helps prove the identity of an application’s author and establish trust in the security model.
All Android packages, or APK files, must be signed, even during development using a default debug certificate.
Certificate Creation
Developers can create their own certificates for signing.
$ keytool -genkey -v -keystore mykey.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
Signing Process
Sign an unsigned application using your certificate.
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore application.apk alias_name
Certificate Information
Stored in the CERT.RSA file within the META-INF folder of the Android package.
Absence of Central Authority Verification
Android OS doesn’t verify application certificates against a central authority.
Self-signed certificates are commonly used.
Importance of Keeping Signing Certificate Safe
Safeguarding the signing certificate is crucial.
Losing the certificate prevents issuing updates and may require publishing new applications.
Inspecting Permissions
Applications need to request permissions for device access.
Users see abstracted permission information in the Play Store.
Permissions are defined in XML using <permission> and <uses-permission> tags.</uses-permission></permission>
Finding Requested Permissions
Use the app.package.info module in drozer to find permissions for a specific app.
dz> run app.package.info -a com.android.browser.
Search for Permissions
Use app.package.list with permission filtering.
dz> run app.package.list -p android.permission.READ_SMS.
Permission Implications
Requesting permissions can add the app’s user identifier to a Linux group.
Some permissions are purely for access control, not groups.
Check /system/etc/permissions/platform.xml for permission mappings.
Content Providers and Permissions
Content providers require permissions for access.
Android checks if an app has the required permission before granting access.
Query content providers to see which permissions are needed.
Common Malware Tactics
Most Android malware relies on users not reading permissions.
They request permissions to access sensitive data.
No technical security flaw; exploits lack of user awareness.
Some malware bypasses security using kernel exploits for root access.
Signature-based protection restricts inter-app access.
Protection Levels
Permissions have associated protection levels.
Levels determine conditions for permission requests.
Differentiate between normal, dangerous, signature, and system levels.
Correct protection level selection is crucial for security.
normal - Protection Level
Default value.
0x0
Any app may request a permission with this protection level.
dangerous - Protection Level
Indicates that this permission has the ability to access some potentially sensitive information or perform actions on the device.
0x1
Any application may request a permission with this protection level.
signature - Protection Level
Indicates that this permission can only be granted to another application that was signed with the same certificate as the application that defined the permission.
0x2
signatureOrSystem - Protection Level
This is the same as the signature protection level, except that the permission can also be granted to an application that came with the Android system image or any other application that is installed on the /system partition.
0x3
system - Protection Level
This permission can only be granted to an application that came with the Android system image or any other application that is installed in particular folders on the /system partition.
0x10
development - Protection Level
This permission can be granted from a privileged context to an application at runtime.
0x20
Android Application Sandbox
Measures to prevent one app from harming others or accessing their data without permission.
Apps run as separate users in a Unix-like security model.
Private data directories are protected with user-specific file permissions.
Example: drwxr-x–x u0_a59 u0_a59 2014-05-11 18:49 com.mwr.dz.
World-executable directories can expose data if subfolders have lax permissions.
SharedUserId Exception
Apps can share the same user identifier via android:sharedUserId in the manifest.
Granted only if signed with the same certificate.
Apps under the same UID share access, even with configurations to run in the same process.
Example: dz> run app.package.shareduid -u 10005.
Binder and IPC Control
Binder is used for communication between apps.
Specialized IPC parcels check app permissions for tasks.
Android API calls to app components strictly enforce permissions.
Linux groups may enforce certain permissions instead of binder.
Full Disk Encryption (FDE)
Encrypts the entire drive or volume.
Protects against lost or stolen disks.
Defeats common forensics techniques.
FDE Implementation on Android
Uses dm-crypt in the kernel.
Encryption suite: aes-cbc-essiv:sha256.
Requires user activation before Android 5.0 (Lollipop).
Key Derivation and User Password
User’s PIN/password encrypts FDE password.
Key derived from the user’s PIN/password.
KitKat onwards uses scrypt for stronger security.
Data Encryption and SD Card Considerations
Encrypts the /data partition.
SD card encryption may vary among manufacturers.
Protection and Limitations of FDE
Protects data at rest.
Transparent decryption during code execution.
Limits unauthorized access to stolen devices.
