[A]ndroid [A]pplication [P]entest [G]uide
  • AAPG
  • 1. MANUAL STATIC ANALYSIS
    • 1.1 Decompile APK
    • 1.2 Check certificate
    • 1.3 Analyze AndroidManifest.xml
    • 1.4 Source Code Analysis
  • 2. AUTOMATED STATIC ANALYSIS
  • 3. MANUAL DYNAMIC ANALYSIS
    • 3.1 Install application & use it
    • 3.2 Bypass detections
    • 3.3 Analyze local storage
    • 3.4 Attack surface
      • 3.4.1 Activities
      • 3.4.2 ContentProvider
      • 3.4.3 Services
    • 3.5 Log analysis
    • 3.6 More HOW and WHAT! (still work in progress)
  • 4. APK TAMPERING
    • 4.1 DIY - Simple Reverse Meterpreter (Non-Xamarin)
    • 4.2 Quick Proof-of-Concept (Meterpreter)
Powered by GitBook
On this page
  • User Login & Session Management
  • How to test?
  • What to report?
  • Access Control
  • How to test?
  • What to report?

Was this helpful?

  1. 3. MANUAL DYNAMIC ANALYSIS

3.6 More HOW and WHAT! (still work in progress)

TBD soon! (But those are things you should already know and do during other pentests)

User Login & Session Management

How to test?

For each penetration test, ALWAYS demand at least two user accounts. If different levels of privileges (read-only, write permissions or full admin) exist - at least one user per level.

  • Login with the provided user credentials

    • Have a look at the request (what parameters are transmitted, ...).

      • Tweak around with them (i.e. SQLi against the backend)

      • Is the connection to the backend encrypted (SSL in place)?

      • Do they get stored?

        • Where do they get stored?

        • How do they get stored? (Clear-text vs. encoding vs. encryption)

          • At want point do they get decrypted/-coded?

  • Switch tokens or other session values with other logged in users

    • Are the tokens bound to the session or do they need to be valid only?

    • Decode the token and check what kind of sensitive information is stored within

  • Logout

    • Reuse old tokens and test if they are still valid as well

What to report?

  • No SSL (https) used while authenticating against the backend.

  • Any request-misuse you were able to identify

  • Improper session / user-credential storage (stored in clear-text or weakly encrypted)

  • Improper storage location (i.e. config.txt with credentials will be stored on the SD card)

  • Token is not bound to user-session

  • Token contains sensitive information

    • In combination with no SSL (https) in place? Even worse.

    • Is it necessary to store this kind (SSN, living address, ...) of information in an encoded token

      • Don't laugh - unfortunately this really happens out there

  • Token is still valid - even after a used logged out

  • Access activities (revealing sensitive information) without authentication

Access Control

How to test?

  • Observe the activity-flow

    • What activity will start after logging in?

    • Can you open this activity even without being logged in?

      • Only worth reporting if you are able to see sensitive information without any authentication

    • Can you access this activity without necessary permissions? (i.e. admin interface)

      • Are you even able to perform any admin actions?

  • Access content of other users

    • Images, Videos, Messages, ...

What to report?

  • Access activities (revealing sensitive information) without authentication

  • Perform actions without necessary privileges.

    • If functionality is bound to the UI and not the user (w/ the needed permissions)

Previous3.5 Log analysisNext4. APK TAMPERING

Last updated 5 years ago

Was this helpful?