Fragments-Plug the vulnerabilities in your App

Jun. 29, 2020

More Related Content


Fragments-Plug the vulnerabilities in your App

  1. Plug the Vulnerabilities! HasGeek – Fragments June 2020 AMA on Mobile Apps Security Riddhi Shree, Security Analyst, Appsecco Riyaz Walikar, Head of Research & Security Testing, Appsecco
  2. About Us • Riddhi Shree • Security Analyst @Appsecco • Breaks mobile apps and web applications for a living • Built mobile apps for CTFs and to demonstrate weaknesses • Check out VyAPI (if you haven't already!)
  3. About Us • Riyaz Walikar • Head of Research and Security Testing @Appsecco • GrayHat Hacker • Leads the team that breaks mobile, web apps, thick clients, Cloud servers and services • Not a developer but understands the pain that developers go through when dealing with security
  4. • Define mobile app security from the point of view of attackers and developers • See some weaknesses that we commonly come across in Mobile Apps during our testing • Cover things that developers do but ideally should not • Things that attackers go after when testing mobile apps • Talk about things that developers can do to harden mobile apps and backend APIs • Bonus Content – Setting up a lab to get started with Mobile App Security Testing • Open the symbolic floor for Q&A What we will cover today
  5. What is (mobile application) security?
  7. • Security is freedom from, or resilience against, potential harm caused by others • In the digital world this "harm" corresponds to loss of either Confidentiality (C), Integrity (I) or Availability (A) of a system or data contained therein • Depending on how a (presumed) violation of CIA occurred, what was affected and what was the impact of the violation, we can calculate how severe the violation was (bug severity). • The most secure system would be completely unusable
  9. Obligatory Dilbert
  10. • Your code runs in an untrusted environment • You want to do this to ensure you can utilise more client processing power • It's easier to create, store and manage data as and when required • Simplified and fast architecture, where APIs can be used for state control and mobile apps for the UI • Often business logic and decisions are made client side to increase efficiency • Examples would be file uploads from mobile apps • Multi form data stored in local caches etc. • Disconnect between developers and security testers • What kind of issues are more prevalent • Learnings from bug reports? Why is security hard with mobile apps?
  11. • We are not mobile app or API developers, but we understand their security, how they can be attacked and what could an attacker do with the access or data • Most bugs covered here are from real world mobile application assessments that our team has performed in the last couple of years • We will try and skip the why these mistakes occur as that would be a subjective opinion Full disclosure
  12. Things Developers Do (which they ideally should not)
  13. 1. (Don't) Trust 3rd Parties • Code • Libraries • APIs • Stack Overflow • etc.
  14. Zero-Day!
  15. "Sign in with Apple"
  16. Victim? • It affected those applications that used "Sign in with Apple" "Sign in with Apple" Damage? • A full account takeover of user accounts was possible on these applications irrespective of whether victim had a valid Apple ID or not
  17. 2. (Don't) Ignore API Authentication Request JWT for any Email ID Apple generated valid JWT (id_token) for arbitrary Email ID
  18. 3. (Don't) Ignore API Authorization
  19. Feature: • "Amazon Cognito supports unauthenticated identities, allowing customers to use the application without logging in Amazon Cognito: Anonymous Sign-In Flaw? • If enabled, it can possibly allow its users unauthorized access to sensitive and private information stored in AWS services
  20. With new technology ...comes new responsibilities
  21. Sensitive AWS services accessible by unauthenticated users
  22. 4. (Don't) Ignore API Rate Limiting EXPECTATION: • If rate limit is reached, requests should be blocked REALITY? • X-RateLimit-Remaining was reset to higher value repeatedly
  24. Real World Examples Instagram Hack: Facebook Hack:
  25. 5. (Don't) Leave Sensitive Files in App Bundle
  26. It's easy to extract bundled resources from APK/IPA
  27. Is it possible to find a configuration file? Takeaway: • Do not ship sensitive files in app bundles
  28. 6. (Don't) Hardcode Plaintext Secrets
  29. 7. (Don't) Save Unencrypted Data in Local Database
  30. 8. (Don't) Leave Leftovers in Cache Files
  31. 9. (Don't) Ignore Environment Checks Attacker's Motive? 1. Attempt to reverse-engineer target app 2. Intercept communication between server and the app
  32. • Root and Jailbreak detection • Emulator detection • Obfuscation • Encryption • Certificate pinning • Tamper prevention • etc. Few things that go missing...
  33. Things Developers Should Do
  34. • Perform unit test cases, especially for complex apps • Ensures some level of business logic testing is achieved • Write modular code to ensure unit testing, bug fixes and feature updates are done smoothly • Verify third party sources that are going to become a part of your project • Usage of third-party code always increases the attack surface an app has • Third party code could be in the form of libraries, external binaries, resources and even code copied from Stack Overflow • Verify the source and be aware of the security state and known issues Things to do to improve security
  35. Define your circle of trust.
  36. • Implement environment detection routines and certificate pinning • This makes it difficult for novice hackers to perform runtime analysis • Tools available with out of the box scripts to bypass standard checks so add a layer of obfuscation to the functions • Improve detection rate by using a larger list of known files. For example,with checkra1n coming out, checking for “/Applications/” is no longer enough • Similarly the default example for implementing certificate pinning using CertificatePinner of OkHttp has been scripted and can be easily bypassed using tools like Frida and Objection Things to do to improve security
  37. Incorporate Layered Defense
  38. • Ensure local caches, files and SQL storages are cleared upon user logout • More people share devices then you know • When a user’s session is terminated on the server, the mobile app should ensure that web caches, temporary document locations for the app and any SQL storages are emptied to prevent a different user from accessing them • Although, access to the sandbox of the app requires root access, it may entirely be possible to invoke an insecure Activity or a file path traversal issue within the app to read the data of a different user Things to do to improve security
  39. • Implement robust authentication and authorisation checks • Build authentication discussions into your app design • Questions like do we allow 2 users to be logged into the mobile app at the same time? • Or what happens if the user logs into the mobile app from a different device • Treat user input with caution as the same piece of data can have different meaning in different contexts • Offloading authentication to third party providers is great, but can have its own set of troubles • Ensure the authentication documentation by the provider is followed and unnecessary storage and transmission of tokens and keys is avoided • Authorisation can be tricky, especially for multi user multi role apps • Avoid passing direct references to objects on the server to clients • Use UUID identifiers to prevent attackers from doing guesswork • Create an authorisation matrix that shows exactly what a user and role is allowed access • Use the principle of default deny Things to do to improve security
  40. Follow the least privilege principle.
  41. • Treat all user input as evil (especially for APIs) • User data can originate in many places, including but not limited to forms, post body, request headers, file uploads, metadata of a file upload and even content coming in from non-human sources like databases and caches • Treat data contextually and validate user input to avoid the meaning of the data from changing • Fail safely when processing data, handle error conditions without providing too many internal details • Restrict the information that responses send. If the user doesn’t see it and the app does not operate on it, then ideally do not send it in the response Things to do to improve security
  42. A Typical Mobile Hacker Lab (Bonus Content)
  43. Items / Tool Platform Purpose Rooted Android device Android To install and run Android mobile apps for testing. Root to access memory, perform dynamic inspection and check file system for secrets. Jailbroken iOS device iOS To install and run iOS mobile apps for testing. JB to access memory, perform dynamic inspection and check file system for secrets. Android Studio Android Android Virtual Device (Emulator), Also to decompile APKs, to build code PoCs if needed XCode iOS Device logs and creating entitlements. iOS Simulator if required. MobSF Both Static and Dynamic App Security Analysis Burp / ZAP Both Interception Proxy, to test and attack the APIs Hopper / Ghidra Both Disassembly and function tracing, reverse engineering of apps jadx Android Decompile APK to java classes Frida + Objection Both Dynamic instrumentation, patch running binaries, evade JB/root detection, evade cert pinning 3uTools iOS Browse iOS file system, install IPA files, extract installed, upgrade versions Mobile Security Lab – Tools to get started
  44. Mobile Security Lab – Getting Started • Mobile Security Testing Guide - • Check iOS JB version - • XDA Developers Android Forums - • iOS App Hacking tutorials - • Guide to Building and Securing APIs - • Vyapi – vulnerable Android App - vulnerable-hybrid-android-app-ee300a9d60ed • MobSF - • OWASP API Security Top 10 RC - Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf
  45. Q&A Riyaz Walikar @riyazwalikar Riddhi Shree @_riddhishree Mobile apps security consultation with Appsecco 2nd July 2020 4 PM – 5:55 PM