( started from 2.6) kernel. • This layer is core of android architecture. It provides service like power management, memory management, security etc. • It helps in software or hardware binding for better communication.
• It is this layer that enables the device to handle different types of data. • The WebKit library is responsible for browser support, SQLite is for database, FreeType for font support, Media for playing and recording audio and video formats
Android devices • It's fast, even on weak CPUs • it will run on systems with little memory • it will run in an energy-efficient way • Provides application portability and runtime consistency • Runs optimized file format (.dex) and Dalvik bytecode • Java .class / .jar files converted to .dex at build time
applications Content Providers: Manage the data sharing between applications Telephony Manager: Manages all voice calls. Location Manager: Location management, using GPS or cell tower Resource Manager: Manage the various types of resources we use in our Application
Application Sandbox. • An application framework with robust implementations of common security functionality such as cryptography, permissions. • An encrypted file system that can be enabled to protect data on lost or stolen devices. • User-granted permissions to restrict access to system features and user data. • Application-defined permissions to control application data on a per-app basis.
works and what kind of interaction between components and outer world is possible. Permissions are set there, too. • Activities – <activity> • Services – <service> • Content providers – <provider> • Broadcast receivers – <receiver>
that is created and communicated to an intended application component. It includes all relevant information about calling application, desired application component and request actions/data Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse("http://www.google.com")); String pack = "com.android.browser"; ComponentName comp = new ComponentName(pack, pack + ".BrowserActivity"); intent.setComponent(comp); startActivity(intent);
write your apps to interact with other apps :) dz> run app.activity.start --action android.intent.action.VIEW --data-uri http://www.google.com --component com.android.browser com.android.browser.BrowserActivity
by other apps (by an attacker), it can be abused! • Launching by intents, it’s possible to achieve the following: – Modify data in background – Tricking the user – Leaking sensitive information Activities
an attack: – Malicious Activity could read the data in the Intent and then immediately relay it to a legitimate one – Spoofing the expected Activity’s user interface to steal user-supplied data (phishing) Activities
and does not provide a user interface. Other components can bind to a Service, which lets the binder invoke methods that are declared in the target Service’s interface. Intents are used to start and bind to Services Example: playing music or downloading a file. Services
as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process. Example: using content providers, any app can read SMS from inbuilt SMS app’s repository in our device. Content providers
Just query it! * – run app.provider.query content://settings/secure • SQL injection • Path traversal * Other attack vectors on auth might include altering data e.g. by using app.provider.insert command Content providers dz> run scanner.provider.injection -a com.mwr.example.sieve
to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts. Broadcast receivers
context = arg0; SmsManager sms = SmsManager.getDefault(); Bundle bundle = arg1.getExtras(); sms.sendTextMessage(bundle.getString("phoneNumber"), null, bundle.getString("message"), null, null); Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT, Toast.LENGTH_LONG); } The following is the code that determines how the receiver handles the org.owasp.goatdroid.fourgoats.SOCIAL_SMS actions: Broadcast receivers
• Setting "android:exported" attribute to "false" (only this user ID as the current app will be able to access the activity) • Limiting access with custom permissions for an activity (RECEIVE_SMS and others)
provide you a basic knowledge about mobile risks and easy methodology to find those risks in your applications. • If you want to add anything important/interesting and related to the topic – feel free to interrupt me ;).
it’s absolutely necessarry. • Use encryption for local storage (use method setStorageEncryption). • For databases consider using SQLcipher for Sqlite data encryption. • Ensure any shared preferences properties are NOT MODE_WORLD_READABLE.
tested 100 apps and… • 21 apps trust all certificates • 20 apps accept all hostnames • And in the end they asked developers why it happened… More: https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf
with Wireshark/Burp (to check if all traffic is encrypted) • Use Mallodroid: ./mallodroid.py –f AppToCheck.apk –d ./javaout • Look for end point implementation flaws using SSLyze (or https://www.ssllabs.com/ssltest/ for public domain): sslyze --regular www.example.com:443
to the FireEye research from July 17 2014, among 1000 most-downloaded free applications in the Google Play store: Source: https://www.fireeye.com/blog/threat-research/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html
definition: OS/frameworks puts sensitive information in an insecure location in the device. • Important note: insecure data storage talks about developer conscious efforts to store data in insecure manner, while unintended data leakage refers to OS/framework specific quirks which can cause data leakages.
from leaking content providers using Drozer: dz> run app.provider.finduri <package_name> • Use logcat to verify what is being logged using ADB: adb logcat [output filter] • Use listener (Burp/Wireshark) to monitor what is being sent to 3rd parties. • Use Intent Sniffer to see if any confidential data is sent via Intents.
to bypass authentication by accessing exported activities using Drozer: dz> run app.activity.start –component <component_name> • Intercept traffic with Burp and modify parameter to login as other user/see unauthorized content (e.g. by manipulating device ID). • Test account lockout policy • Test strong password policy
authorization and authentication controls can be bypassed - they must be re-enforced on the server-side whenever possible! • Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device. It should be optional and not be enabled by default.
using dex2jar (or luyten for more verbose result) and review jar file in JD-GUI. • Look for decryption keys (in attacker-readable folder or hardcoded within binary). • Try to break encryption algorithm if an application uses custom encryption. • Look for usage of insecure and/or deprecated algorithms (e.g. RC4, MD4/5, SHA1 etc.).
definition: malicious code can be provided as an input and executed by the application (on the client side). • The malicious code can come from: – Other application via intent/content provider – Shared file – Server response – Third party website
can talk (Inter-Process- Communication) to any other component (e.g. other application, system service, running new activity etc.) via special objects called Intents. Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse(„https://owasp.org”)); Intent i = new Intent(android.provider.MediaStore.Action_IMAGE_CAPTURE);
application Samsung KNOX – a security feature to seperate personal and professional activities). • Crafted URI with „smdm://” prefix allows for remote installation of ANY application, while a user thinks he’s installing an update for UniversalMDMClient. • How it works in practice? https://www.youtube.com/watch?time_continue=56&v=6O9OBmsv-CM
server side any user input! • For internal communication use only explicit Intents. • Avoid using Intent-filter. Even if the Activity has atribute „exported=false” another application can define the same filter and a system displays a dialog, so the user can pick which app to use.
with proxy (e.g. Burp) and verify if: – Verify if a session expires (copy a cookie and try to use it after 30 minutes) – Verify if a session is destroyed after authentication state changes (e.g. switching from any logged in user to another logged in user) – Verify if you are able to guess any other session (e.g. it’s easy to impersonate other user when application uses device ID as a session token).
we know is that „sessions have to expire”… • …but how long should it REALLY last? • According to experiment* the average application session (counted from opening an app to closing it) lasts… 71.56 seconds. * - http://www.mendeley.com/research/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/
has the functionalities like • Record call • Block SMS • Take video/photo • Send text • Send contacts • Get user account • Call Number • Update App • Delete files • Get browser history • Get call history • Get inbox SMS