Security Vulnerabilities in Mobile Applications (Kristaps Felzenbergs)
1 like892 views
The document discusses security vulnerabilities in mobile applications, emphasizing that a significant majority of apps contain at least one vulnerability due to developers' focus on features over security. It outlines strategies for testing mobile apps, including reverse engineering and dynamic runtime analysis for both Android and iOS platforms, and highlights the need for effective security measures such as proper app signing and SSL pinning. The presentation urges developers to thoroughly examine app security, especially in relation to sensitive data management and user education about security risks.
Security Vulnerabilities in Mobile Applications (Kristaps Felzenbergs)
- 1. SECURITY VULNERABILITIES IN MOBILE APPLICATIONS Kristaps Felzenbergs Lead Security and Test Automation Engineer
- 2. ABOUT ME - Lead Security and Test Automation Engineer at TestDevLab Ltd - Certified Ethical Hacker - DSS 2016 Speaker
- 3. IN THIS TALK • Mobile apps in media • The situation • How do we test? (from outside to inside) • Android apps • iOS apps • Conclusions testdevlab.com
- 4. MOBILE APPS IN MEDIA
- 5. testdevlab.com MOBILE APPS IN MEDIA PICTURE SLIDE http://www.zdnet.com/article/this-android-infecting-trojan-malware-uses-your-phone-to-attack-your-router/ http://www.techrepublic.com/article/1-2-million-infected-android-malware-hummer-could-be-biggest-trojan-ever/
- 6. testdevlab.com Apple CEO Tim Cook released a statement arguing against the FBI's recent order to hack into the San Bernardino shooter's iPhone 5c. (Jhaan Elker/The Washington Post) By Ellen Nakashima February 17, 2016 https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/69b903ee-d4d9-11e5-9823-02b905009f99_story.html
- 8. testdevlab.com STATISTICS From Trustwave Global Security Report 2017: • 99.7% of tested apps displayed at least one vulnerability • 10% of vulnerabilities Trustwave detected and classified as high-risk critical • 67% of breaches targeted payment card data
- 9. testdevlab.com WHY THE SITUATION IS BAD? • Developers are focused on features and not security • Relying on your custom encryption might not be the best choice (reinventing the wheel) • Users are not well educated about security • Users are easy targets for social engineering attacks
- 10. ATTACK GLOALS Credentials (To the services that you use) Personal data • Name • Location • Contacts Credit card data Access to your device (Use your device for botnets and spamming) testdevlab.com
- 11. testdevlab.com HOW TO TEST APPS? move from outside to inside
- 12. LET’S START WITH ANDROID
- 13. APPLICATION PERMISSIONS • Check when installing the app • Additional security added since Android 6.0 (API level 23) testdevlab.com
- 15. testdevlab.com ANDROID DEBUG BRIDGE • A command-line utility • Can control device over USB • Copy files back and forth • Install and uninstall apps • Run shell commands • …
- 16. testdevlab.com LOGCAT • A command-line utility • Dumps: • a log of system messages • stack traces when the device throws and error • messages written in the app with Log class.
- 17. EXTRACT THE APP Extract the app for further investigation Who knows what you might find.. testdevlab.com
- 18. testdevlab.com HOW DO I EXTRACT? Two ways: 1. Extract using ADB 2. Use an app to extract the app
- 19. STEP 1 DETERMINE THE PACKAGE NAME Determine the package name of the app, e.g. “com.example.app”. testdevlab.com adb shell pm list packages
- 20. STEP 2 DETERMINE THE PATH Get the full path of the APK file for the desired package. testdevlab.com adb pm path com.example.app
- 21. STEP 3 PULL IT FROM DEVICE Pull the APK file from the Android device to your computer. testdevlab.com adb pull /data/app/com.example.app-1a.apk path/to/destination
- 22. OR EXTRACT USING AN APP FROM GOOGLE PLAY Might be faster if you don’t have ADB in your toolset testdevlab.com
- 23. NOW WHEN YOU HAVE THE APP.. several things can be discovered.. testdevlab.com
- 24. SIGNATURE Two application signing schemes • JAR signing (v1 scheme) • APK Signature Scheme v2 (v2 scheme) testdevlab.com
- 25. testdevlab.com JAR SIGNING ( v1 scheme ) • Does not protect some parts of the APK (such as ZIP metadata) • Offers a sizeable attack surface • Consumes more time and memory while verifying the signature
- 26. testdevlab.com APK SIGNATURE SCHEME V2 ( v2 scheme ) • Introduced in Android 7.0 Nougat • Contents of the entire APK are hashed and signed • Signature check across the entire file • Any modification to the APK invalidates the signature
- 27. HOW SHOULD I SIGN? v1 scheme + v2 scheme = good • v2 scheme speeds up the installation process in Android 7.0+ • Older platforms will ignore v2 signatures and will relay on v1 scheme instead testdevlab.com
- 28. testdevlab.com KNOW HOW IT IS SIGNED
- 32. testdevlab.com • You should know that APK is actually a valid ZIP archive • FIRST – UNZIP IT • NEXT – disassemble or decompile REVERSE ENGINEERING
- 33. testdevlab.com • The code decompiled will be in short form (i.e., how it’s interpreted by the JVM) • Might not be readable and won’t contain any comments • Tools: • Classy Shark by Google - https://github.com/google/android-classyshark • Dex2jar - https://github.com/pxb1988/dex2jar • JD-GUI - http://jd.benow.ca/ TO JAVA
- 34. testdevlab.com .dex <------------------> .smali <--------------------- java source code Smali is the most common human readable format for dex • Gives a readable code in smali language • Can be modified and repackaged to APK • Tools: • Apktool - https://ibotpeaches.github.io/Apktool/ TO SMALI
- 36. testdevlab.com take a closer look.. ONCE DISASSEMBLED..
- 37. testdevlab.com • HTTP Endpoints • Evaluate obfuscation • Authentication strings • Certificates PERFORM A STATIC ANALYSIS
- 38. testdevlab.com SEARCH FOR PLAIN HTTP ENDPOINTS
- 39. testdevlab.com Things to check for: • Developers code • Third party libs • Obfuscation level OBFUSCATION the action of making something obscure, unclear or unintelligible
- 42. testdevlab.com • BASE64 strings • Tokens AUTHENTICATION SECRETS https://github.com/dxa4481/truffleHog
- 43. testdevlab.com Focus on: • HTTP Endpoints • Obfuscation • Authentication secrets STATIC ANALYSIS RECAP Try to look for: • Certificates • Misconfigurations in Android Manifest
- 44. LET’S GET TO THE ACTION
- 45. DYNAMIC RUNTIME ANALYSIS • STORAGE • NETWORK testdevlab.com
- 47. STORAGE Where to look for things?.. • What data stores are available for an application? • Where secrets should not be stored? testdevlab.com
- 48. testdevlab.com • By default, files that are created on internal storage are accessible only to that application • Android implements this protection, and it’s sufficient for most applications USING INTERNAL STORAGE
- 49. testdevlab.com • Files created on external storage, such as SD cards, are globally readable and writable • External storage can be removed by the user and modified by any application USING EXTERNAL STORAGE this is not a place for sensitive data
- 50. USING CONTENT PROVIDERS An interface for sharing data between applications Exposes URI starting with “content://” testdevlab.com
- 52. NETWORK What to look for?.. • Plain data in transit • SSL Pinning testdevlab.com
- 53. testdevlab.com Techniques: • A tool: mitmproxy • Creating MiTM environment • Applying SSL stripping TECHNIQUES TO CATCH PLAIN DATA IN TRANSIT
- 55. testdevlab.com USE A PROXY SERVICE https://mitmproxy.org/
- 58. testdevlab.com Assures that the app talks to what you think it talks to Prevents MiTM attacks SSL PINNING
- 59. testdevlab.com The process of associating a host with their expected X509 certificate or public key SSL PINNING https://drive.google.com
- 60. testdevlab.com Focus on: • Storage and what is stored • Network and data flowing RUNTIME ANALYSIS RECAP Try to look for: • Advanced measures like SSL pinning
- 61. testdevlab.com • Evaluate the app before installing ( check permissions ) • Prepare your environment • Get familiar with ADB • Use logcat to observe device activity • Decompile and get into source code, check misconfigurations • Run the app and check what is stored and transmitted over network SUMMARY FOR ANDROID
- 63. testdevlab.com • iOS strictly enforces application boundaries and sandboxing • Apps cannot communicate directly • Written in native ObjectiveC or Swift A MUCH HARDER NUT TO CRACK
- 64. testdevlab.com • Involves finding an exploit in the kernel allowing to run unsigned code • Can be tethered, meaning you have to boot it while connected to a laptop and running the jailbreak code every time you restart • Untethered, meaning once its jail-broken, it will remain so after reboots JAIL-BREAKING IS JUST THE BEGINNING
- 65. testdevlab.com IPA is a valid zip file as well Might contain sensitive data outside the binary in case of poor programming STATIC ANALYSIS
- 67. testdevlab.com Apps are native ARM Tools: • IDA Pro • Otool • Nm • Class-dump REVERSE ENGINEERING IOS APPS
- 69. testdevlab.com • SSH into a jail-broken device • Find the target application’s install folder and look for the Library/caches directory INVESTIGATE CACHES
- 70. testdevlab.com CHECK DATA IN KEYCHAIN
- 71. testdevlab.com • Most of the iOS apps are written in ObjectiveC and link to the ObjectiveC runtime • ObjectiveC is a superset of C, with macros to make a Smalltalk-like syntax • Its also a “reflective” language – it can alter itself at runtime • Harder to reverse, but WAY easier to hook • “Method Swizzling” is a feature of the ObjectiveC runtime • Allows to swap method implementations at runtime • What could possibly go wrong? RUNTIME ANALYSIS POSSIBLE? https://www.owasp.org/images/c/cf/ASDC12-Mobile_Application_Security_Who_how_and_why.pdf
- 72. testdevlab.com • Get familiar with contents of IPA archive • Setup tools and get familiar with debuggers and disassemblers • Hook into active running process • Run the app and check what is stored and transmitted over network SUMMARY FOR iOS
- 73. testdevlab.com FINAL THOUGHTS • Test the app on a jail-broken or rooted device to see what can be seen • Examine app package contents thoroughly • Get a clear view of what is stored and what is transmitted
Editor's Notes
- #2: Hi! My name is Kristaps and today I am going to talk about security vulnerabilities in mobile applications and things that you need to know to reveal them.
- #3: I am currently employed by TestDevLab Ltd, the quality assurance company and I am working as Lead Security and Test Automation Engineer. My day-to-day work is related to test and test infrastructure development. I am Certified Ethical Hacker and Certified Security Analyst. I am Data Security Solutions 2016 speaker. I gave a speech about Security Risks and Common Mistakes in Mobile Application Development Besides that I am passionate about security so whenever there is a new product in my hands I am trying to evaluate its functionality in terms of security to see if I can find something interesting there by digging deeper. So today I am going to present you some ways to dig deeper and look under the hood of mobile applications.
- #4: First we will have a short look at reported vulnerabilities for mobile applications in daily news. Then I am going to talk a bit about statistics of known and reported vulnerabilities After that I am going to dig into the main part where I will try to cover tips and tricks on how to test Android and iOS mobile applications for security vulnerabilities. Just please don’t mind if there will be a much more information on android apps compared to iOS as most of the experience that I am carrying is with Android. However, I will try to cover some interesting things that you can do with iOS as well so bear with me. And finally I will present my final thoughts about vulnerabilities and test strategies for Android and iOS mobile apps. So let’s get started.
- #5: As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
- #6: So after a really quick search it came up with some pretty interesting articles related to Android vulnerabilities. In the upper picture we see a Trojan which was infecting your Android phone to attack your router. OK. This seems pretty major. It was released on January 2017, so early this year. The lower picture shows article about Android malware named “Hummer” infecting 1.2 million devices. Was it the biggest Trojan ever? Could be! Release date is June 2016. What about iOS? Is it save and secured?
- #7: Year 2015, San Bernardio shooting. FBI requested Apple to unlock terrorists iPhone. Of course Apple resisted to do so because if they do – would Apple users still trust them their data?
- #8: Anyway, a short time later FBI claimed that they have gained access to the terrorist’s iPhone without Apple’s help. I don’t know more insights into this and cannot explain how they do it. It just makes me think that nothing is safe and everything can be hacked. It is just the matter of time and resources that you are willing to spend.
- #9: So here are a few statistics which I extracted while reading Trustwave Global Security Report 2017. Trustwave issues such a report yearly so I consider this a good resource for security vulnerability and threats statistics. So it seems that almost 100% of their tested applications displayed at least one vulnerability 10% of vulnerabilities that they detected were classified as high-risk meaning that they might harm your personal data 67% of data breaches actually targeted payment card data
- #10: Why the situation is as it is? Mostly because we always think new features first and only then security. Besides that there might be cases that you want to build something on your own that already exists. - I suggest that your never do that with encryption related things. Do not reinvent the wheel.. of course - if you don’t know exactly what are you doing. The other thing is that that users are still not well educated about security and they are easy targets for social engineering attacks.
- #11: Let’s have a look at attack goals Top #1 – credentials. Everyone wants your credentials to the services that you use. Personal data – your name, your location, your daily directions, places you visit, your contacts and relationship. Credit card data - card number, expiration date and card verification value. That’s all that is needed to use your card in online purchases. And finally access to your device. Once it’s possible your device can be part of a botnet, spamming networks. And everything of this can be achieved by installing a single harmful mobile applications which fights it way through the system and infects your phone.
- #12: So how do we test applications against security vulnerabilities? My suggestions is that you move from outside to inside. Meaning that – first evaluate what can be evaluated even before installing the app. Then proceed with installing, then dig deeper and proceed with next things.
- #13: As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
- #14: So first security check that can be performed is to see what kind of permissions are asked for user to accept prior installing the app. Android 6.0 implements additional security checks where developer needs to explicitly ask for user to accept given permission during the runtime of the application. Previous versions of Android will ask to accept all the required permissions before the installation of the app. On the right you can see the app which I always like to show as a bright example where the app asks for every possible permission but it’s just a flashlight and your personal data harvester. Don’t install it. OK. Before we move further let’s have a look at a couple of tools which you definitely want to use to dig deeper into investigating Android apps.
- #15: As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
- #16: ADB – Android debug bridge I hope that everyone of you know it and you are using it already. It’s a command line utility, you can install the apps, control your android device over USB, perform file transfers, run different shell commands and send keyboard inputs. You can get it by installing Android SDK from Google
- #17: Logcat – another command line utility which is built into your Android operating system. You can access it via adb or once you are connected to your Android shell. It provides very verbose logging of different kinds of processes running on the Android device. Some of the important things that you might want to see are stack traces when the device throws and error or when the app crashes and messages that are written in the app code using the Log class.
- #18: So the next thing that you want to do when you are familiar with the common android tools like adb and logcat is to extract the actual app from your Android device. The reason is that it might not be so effective to work with the app on the phone than on your computer. So let’s have a look into the strategies extracting the app from the phone
- #19: Basically two very common ways of doing it First – extract using command line utility – android debug bridge Second – use an Android app to extract the Android App
- #26: dsdsdsds
- #27: dsdsdsds
- #29: dsdsdsds
- #32: As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
- #33: dsdsdsds
- #34: dsdsdsdshttp://jd.benow.ca/
- #35: dsdsdsdshttp://jd.benow.ca/
- #36: dsdsdsdshttp://jd.benow.ca/
- #37: dsdsdsds
- #38: dsdsdsdshttp://jd.benow.ca/
- #39: dsdsdsdshttp://jd.benow.ca/
- #40: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #41: dsdsdsdshttp://jd.benow.ca/
- #42: dsdsdsdshttp://jd.benow.ca/
- #43: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #44: dsdsdsdshttp://jd.benow.ca/
- #45: now let’s move to the part where you are actually running the app
- #47: dsdsdsdshttp://jd.benow.ca/
- #49: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #50: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #52: dsdsdsdshttp://jd.benow.ca/
- #54: dsdsdsdshttp://jd.benow.ca/
- #55: dsdsdsdshttp://jd.benow.ca/
- #56: dsdsdsdshttp://jd.benow.ca/
- #57: dsdsdsdshttp://jd.benow.ca/
- #58: dsdsdsdshttp://jd.benow.ca/
- #59: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #60: dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
- #61: dsdsdsdshttp://jd.benow.ca/
- #62: dsdsdsdshttp://jd.benow.ca/
- #63: dsdsdsdshttp://jd.benow.ca/
- #64: dsdsdsdshttp://jd.benow.ca/
- #65: dsdsdsdshttp://jd.benow.ca/
- #66: dsdsdsdshttp://jd.benow.ca/
- #67: As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
- #68: dsdsdsdshttp://jd.benow.ca/
- #69: dsdsdsdshttp://jd.benow.ca/
- #70: dsdsdsdshttp://jd.benow.ca/
- #71: dsdsdsdshttp://jd.benow.ca/
- #72: dsdsdsdshttp://jd.benow.ca/
- #73: dsdsdsdshttp://jd.benow.ca/