I would like to be able to read traffic of my Android phone to see what data it's sending. It is running Android 9.
I have been able to use Charles but it can only read traffic that doesn't have SSL. It seems that if I was testing my own application there is something that I can set so it trusts the certificate, but I'm trying to get all traffic (all apps etc). I also have used the apps Packet Capture and NetCapture but they have the same limitation.
Is this video the guy is able to do it, but it appears to be an older version of Android where all apps would've trusted a user installed certificate.
Anyone got any ideas?
On Android 9 installing a custom root certificate usually does not affect the apps, therefore HTTPS connections performed by apps don't trust the certificate from Charles that you have installed. To change this you would have to manipulate every app or modify the Android system itself. Additionally some apps (e.g. Google services and PlayStore) perform certificate/key pinning which totally prevents breaking the HTTPS traffic unless the system is heavily modified:
You have to root your device and install XPosed + multiple modules to allow SSL/TLS interception like TrustMeAlready (or the older projects Just Trust Me and SSL Unpinning).
Another possibility is using Frida in combination with some anti-TLS checking/pinning script(s).
More possibilities are described in this Answer.
WARNING: Doing so totally eliminates the security of each and every SSL/TLS/HTTPS connections on your device Therefore not only you but everybody can intercept the connections made by a device modified this way!
To answer simply... No.
There are ways to look into the traffic but it won't show you much of anything worthwhile. You might be able to take a guess here and there but nothing will satisfy what you are after. I would not waste your time TBH.
Source: Had to do this for my job. Analyzed our app as well as many many others.
Check this out:
https://security.stackexchange.com/questions/83028/possibility-to-sniff-https-traffic-on-devices-without-installing-a-certificate/83039
Related
I have an Android mobile app, and I can't see some requests of it's, when trying to sniffing (this mobile app doesn't require any type of auth from user)
I've tried to use Proxyman on iOS and I've catched requests and responses (even HTTPs), but I can't see all of them. For example, I can't see request with the details of product, or with list of them. Proxyman developer answered me:
Maybe the app doesn't use URLSession (Apple Framework) to make a networking request. If it's an online app, it can be a React Native, Flutter app, which (by default) doesn't go through the VPN.
Thus, Proxyman could not capture it.
I've tried Wideshark / Charles / Mitmproxy on my Android emulator (tried Android versions 5.1 - 11.0) but it also didn't work
I've tried decompile APK of this application (with apktool) and I've found many .java files, but it's too hard to find API paths there, because all names are unreadable (but I've found some, but it's not enough)
Can you tell me, what can I do, to get API of this mobile app?
I really don't know, how it can be so hard, why can't I get a simple API calls, because my app somehow knows, where should it go and which type of data it should get (in browser it so much easier!)
Do you have root access? To intercept an Android app really your only options really are root access (and changing the device system configuration) or modifying the app APK. For most apps (all apps that aren't specifically configured to allow user certificates/be debuggable) there is no other possible way to intercept the traffic.
I've written a detailed breakdown of how android HTTPS trust works, and the low-level details of how to intercept it, here: https://httptoolkit.com/blog/intercepting-android-https/. That might provide more context, but the conclusion is the same: you need to modify the system, or modify the app.
If you don't have root access, so you can't modify the system, apk-mitm is usually your best option, and if that doesn't work then you will have to manually investigate the Java code yourself.
Be aware though that you can always use an emulator to run the app, and most emulators (all except the official 'Google Play' emulator versions - e.g. the official 'Google API Services' & vanilla images are root-accessible) will allow root access, so this is normally possible. You can also use emulators like Genymotion which has a free personal use edition.
If that's practical for you, I'd go that way - I've written a full walkthrough to emulator setup & 3rd party app interception here: https://httptoolkit.tech/blog/inspect-any-android-apps-http/
Last possibility: if interception for most HTTPS is working, but just some requests are failing, then you need to disable certificate pinning. You can do this using Frida, I've written a general-purpose certificate unpinning script for Android you can use Frida here: https://github.com/httptoolkit/frida-android-unpinning
I get this question when I was looking in any banking,
payment-related apps show a specific icon that indicates a secure environment.
I search on google but I didn't find anything on there.
please check the below screenshot to better understand.
I come across similar question as well, there is no much information about this, firstly I saw this in Samsung S-pay website saying:
A Secure Environment is a physically segregated chip in the phone
which only allows access to highly sensitive operations/information
such as fingerprint and payment information. Normal applications and
malware have no access to the information in a Secure Environment.
If you search more with the keyword Trusted Execution Environment, then you can realize it is a security standard specified in mobile environment. Like this.
So when your Android code are being executed in Trusted Execution Environment, then the "Secure Environment" sign will appear in the app bar to inform you that you are in secure transaction. As per my observation, it is mostly appear when we are using our fingerprint, that actually make sense as accessing fingerprint (or pin) require higher security standard.
I have an Android application on Play Store and I want to detect if a user is using the original version of the app downloaded from play store or a mod apk from other sources.
Your Question
I have an Android application on Play Store and I want to detect if a user is using the original version of the app downloaded from play store or a mod apk from other sources.
A very simple question that embraces so many things to be fully answered, but from an high level view you can tackle this from within you mobile app or doing it from the outside.
Detecting from Within the Mobile app
Doing it from inside is known as RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
One thing that I observe often is that many developers are not aware that any protection they may add to the mobile app code to try to secure it can can be bypassed during runtime with an instrumentation framework, even when the code itself is strongly obfuscated. A well known instrumentation framework used to manipulate code at runtime is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
In the case a developer adds a function to their code to detect if the app is the original one, the attacker will eventually find it through static analysis of the binary or through dynamic analysis at runtime, and then use Frida to hook on it to change the outcome, like returning always a result that says it's the original one. Another alternative for the attacker is to recompile the binary without said function, thus removing the protection.
So, Am I saying for you to not use self protecting code or RASP solutions on your mobile app?
No, I recommend you to use all the mechanisms you can afford in order to stop the bad actors, but you also need to be aware that they can bypass them, and try to make as hard as possible to overcome your defences, to the point that it will be time consuming for them and they will just prefer to go elsewhere to look for easier targets.
Detecting from outside the Mobile App
A better alternative is to delegate to outside the app the detection when it's running or not an original version of the binary, and if it doing in a device that is not rooted or jail-broken, and this can be done by using the Mobile App attestation concept, that I explain on this answer I gave to the question How to secure an API REST for mobile app? in the section about A Possible Better Solution.
In a nutshell the Mobile App Attestion is a solution that when full implemented attests if your mobile app is the genuine and untampered version you have uploaded to the play store, and that is running in a trusted device, not jail-broken or rooted.
The Mobile App Attestation solution differs from RASP solutions in the fact that the decisions are made outside the mobile device, therefore cannot be manipulated by instrumentation frameworks, and they also issue a JWT token that allows the backend for the mobile app to know when it can trust in requests is receiving from it.
Summary
RASP solutions fall short, because usually they don't let the mobile api backend know if the request is from a genuine version of the mobile that is running in a trusted environment, aka a device not rooted or jail-broken, but even if they do that, once the logic for doing so is running inside the mobile app, it can be manipulated by the attacker with Frida or similar tools.
On the other hand a Mobile App Attestation solution will make decisions outside the mobile device and allow the mobile api backend to be aware when it can trust or not in the incoming requests.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
This is possible if your app is using an external server under your control providing some important functionalities to make the app useful. This might be some cloud database or an enrollment feature. For offline or device only apps the following approach will not work.
When using the SafetyNet API the SafetyNet is returning as part of the response to the server under your control a apkCertificateDigestSha256 from the app executing the call. This can be checked if it is matching your app.
Note, that the evaluationType from the response is also important. Newer devices and versions of SafetyNet are supporting here HARDWARE_BACKED making shielding frameworks like MagiskHide useless.
I'm creating an Android App which connects to a server through an API. I'm worried about a security issue, as far as I'm concerned, anyone can decompile your .apk and take a look or modify your code.
Knowing that, where do I need to save the API Keys inside the app in order to avoid some bad guy stealing it and access the server, for example, to modify my database?
Thanks
Understand how an attacker will go after your application, 95% of the time in this order:
Inspect traffic between your application and the server by using an intercepting proxy like Burp -- very easy to do. See how I did it on Words With Friends here (this was for iOS device but same concept works with Android).
You can stop traffic inspection with certificate pinning, but they can break that by rooting the device and using some hacker tools on Android. So you need Android root detection.
The other attack is scanning your binary. You will need to obfuscate it with a tool like DexGuard.
None of these methods are bullet-proof: generally trying to hide secrets in client code is a losing game. Don't put more effort into it than it is worth.
Variants of this question exist, but I can't seem to understand something.
If you read at the end of the features in ICS / 4.0, there is mention of
Enterprises can also take advantage of a standard VPN client built into the platform that provides access to L2TP and IPSec protocols.
My assumption here is that since it's not under the "Developer" section, that we didn't get a developer API access other than the VpnService API. I've looked at ToyVPN and this is just useless, since I need a REAL IPSec IKEv1 XAuth connection to connect to enterprise firewalls.
I've found several solutions which require root and VPNCilla which apparently doesn't though I haven't been able to successfully have it establish the connection.
Does this mean that there really is no way to PROGRAMMATICALLY create a profile for or connect to an IPSec IKEv1 XAuth gateway/firewall unless we implement the protocol in Java or using the NDK (like StrongSwan did with IKEv2) ?
It's extremely unlikely that there is a way to create a VPN profile without root or system app privileges. You can take a look at how this is implemented in AOSP settings here.