A comprehensive OWASP-aligned security assessment of InsecureBankv2. Static + dynamic analysis. 6 vulnerabilities found. All confirmed exploitable.
Isolated virtual environment built for this assessment.
The application stores sensitive data in three insecure locations accessible via ADB shell with root access:
1. mySharedPreferences.xml — Stores superSecurePassword and EncryptedUsername. Values appear Base64-encoded (e.g. ZGl1ZXhNO...), not encrypted. Base64 is encoding, not a security control — instantly reversible.
2. com.android.insecurebankv2_preferences.xml — Exposes serverip and serverport in plain text, revealing internal infrastructure details.
3. databases/mydb — An unencrypted SQLite database file containing core application data.
| Vulnerability Found | Insecure Practice | Prevention |
|---|---|---|
| Exposed SharedPreferences | Storing credentials in plain XML with Base64 encoding | Use EncryptedSharedPreferences (AndroidX Security — AES-256-GCM for keys and values) |
| Unencrypted Databases | Standard SQLiteOpenHelper / Room in plain .db files | Use SQLCipher — transparent 256-bit AES encryption for entire database file |
| Fake Encryption (Encoding) | Base64/Hex/XOR obfuscation treated as encryption | Only use AES-GCM or ChaCha20 via the Android Cipher API |
| Insecure Key Storage | Hardcoded keys in Java/Kotlin or stored alongside data | Use the Android Keystore — hardware-backed, keys cannot be extracted even on rooted devices |
| Over-Retention of Data | Storing actual passwords permanently on device | Store short-lived OAuth/JWT tokens — never actual passwords |
The application transmits all user data over unencrypted http:// — no TLS. With Burp Suite configured as a proxy listener on 192.168.0.139:8090, and the Android device routing its traffic through it, every request is intercepted in full plain text.
The intercepted URL: http://192.168.0.139:8888/getaccounts Full credentials (username: dinesh, password) visible in the POST body without any encryption.
| Vulnerability | Prevention Strategy | Implementation |
|---|---|---|
| Plaintext HTTP Traffic | Enforce HTTPS / TLS | Migrate all endpoints to HTTPS. Use TLS 1.2 or 1.3. Block SSLv3, TLS 1.0/1.1. |
| Cleartext Allowed in OS | Network Security Configuration | Configure res/xml/network_security_config.xml to globally restrict cleartext traffic |
| Custom CA Trust (MitM) | SSL / Certificate Pinning | Pin server's public key (SPKI) using OkHttp's CertificatePinner |
| Ignoring SSL Errors | Strict Hostname Verification | Never override TrustManager or HostnameVerifier — common developer shortcut during testing |
| Sensitive Data in URLs | Use POST/PUT Bodies | URLs are logged by routers and servers — never put tokens or passwords in query params |
The login endpoint returns verbose, differentiated error messages. When an existing username is entered with a wrong password, the response explicitly confirms the user exists:
{"message": "Wrong Password", "user": "jack"}
This enables username enumeration — an attacker can compile a list of valid usernames, then launch targeted brute-force or credential-stuffing attacks with precision.
| Vulnerability | Prevention | Implementation |
|---|---|---|
| Username Enumeration | Generic Error Messages | Return identical string (e.g. "Invalid credentials") and same HTTP status for all failure types |
| Timing-Based Enumeration | Consistent Response Times | Simulate password hashing time even for non-existent users to prevent timing attacks |
| Brute-Force Attacks | Rate Limiting & Lockouts | Cap login attempts per IP per minute; lock accounts after 5–10 failures |
| Weak Passwords | Strict Password Policies | Minimum 12 characters, complexity required, check against Pwned Passwords API (Troy Hunt) |
| Credential Stuffing | Multi-Factor Authentication | Require TOTP, push notification, or hardware key — especially for admin accounts |
By intercepting a money transfer request and URL-encoding a different target username into the username parameter, it is possible to transfer funds to any account without any server-side ownership verification. The server trusts client-supplied parameters for determining who to act on behalf of — a classic Broken Object Level Authorization (BOLA / IDOR) vulnerability.
| Vulnerability | Prevention | Implementation |
|---|---|---|
| Direct Credential Transmission | Token/Session-Based Auth | Authenticate once → issue secure HttpOnly, Secure cookie or JWT; use for all subsequent checks |
| IDOR / BOLA | Object-Level Authorization | Before acting, verify logged-in user is the strict owner of the requested data object |
| Predictable Resource IDs | Use UUIDs | Replace sequential DB IDs in APIs with UUIDv4 — makes guessing other users' resources infeasible |
| Missing Function-Level Access Control | RBAC / Deny by Default | Implement explicit permission checks (e.g. @RequireRole('ADMIN')) on all sensitive routes |
| Parameter Tampering | Server-Side Trust Only | Never trust username=jack or role=admin from request body/URL — extract from validated session token only |
Using Frida — a dynamic instrumentation toolkit — it is possible to hook directly into the running InsecureBankv2 process and execute arbitrary JavaScript against live application memory. The app has no anti-debugging, no root/jailbreak detection, and no Frida detection in place.
| Defense Level | Technique | Impact |
|---|---|---|
| Basic | Disable Debugging | Prevents easy discovery — remove debuggable: true from manifest |
| Intermediate | Root / Jailbreak Detection | Blocks the environment Frida needs to operate in |
| Advanced | Native Memory / Pipe Scanning | Actively scans for and detects the Frida agent at runtime |
| Expert | Custom LLVM Obfuscation | Control-flow obfuscation makes manual hooking nearly impossible |
The APK can be pulled directly from the device using ADB and decompiled to near-original Java source code using jadx-gui. No obfuscation, no minification. All application logic — including the ChangePassword class, cryptographic methods, and hardcoded encryption keys — is fully readable. The encryption key extracted here was then used to decrypt intercepted Burp Suite traffic.
| Phase | Defense Strategy | Key Action |
|---|---|---|
| Immediate | Basic Obfuscation | Enable minifyEnabled true + shrinkResources true to activate R8 |
| Immediate | Secret Removal | Audit and remove all hardcoded API keys, passwords, salts from source |
| Short-Term | String Encryption | Encrypt strings at compile time, decrypt dynamically via XOR/AES |
| Short-Term | Runtime Protection | Signature verification — crash app if APK is modified and repackaged |
| Long-Term | Native Code (JNI/NDK) | Migrate crypto/proprietary logic from Java/Kotlin to C/C++ .so libraries |
| Long-Term | Commercial Obfuscation | Upgrade from R8 to DexGuard or DashO for control-flow obfuscation |
| Architectural | Backend Migration | Refactor to thin-client — all sensitive logic lives on secure server only |
Every vulnerability, tool, evidence, and fix in one place.
| # | Vulnerability | Tool Used | Status | Mitigation Summary |
|---|---|---|---|---|
| 01 | Insecure Data Storage | ADB | VULNERABLE | EncryptedSharedPreferences, SQLCipher, Android Keystore, token-based auth |
| 02 | Insecure Communication | Burp Suite | VULNERABLE | HTTPS/TLS 1.2+, network_security_config.xml, Certificate Pinning |
| 03 | Insecure Authentication | Burp Suite Intruder | VULNERABLE | Generic errors, rate limiting, MFA, Pwned Passwords API |
| 04 | Insecure Authorization | Burp Suite Repeater | VULNERABLE | JWT/session auth, BOLA prevention, UUIDs, RBAC, server-side trust |
| 05 | Code Injection | Frida, ADB | VULNERABLE | Anti-debug, root detection, memory scanning, LLVM obfuscation |
| 06 | Reverse Engineering | jadx, ADB | VULNERABLE | R8 obfuscation, secret removal, native code migration, DexGuard |