I can intercept packets on a device with root with tcpdump and netcat, but I encounter problems with decrypting TLS packets with wireshark.
Is there a way in my android device to share decryption keys when an https connection is established? Do you know any apps?
Is there anything that allows me to create SSLKEYLOGFILE in android like in windows? Or something that allows me to decrypt the app data of my device. I've already tried frida and proxy for SSL pinning but it doesn't work on some apps.
Thank you so much for the help and I'm sorry for my English
Related
The question asked here is quite outdated and vague, especially considering the changes with android 7.0+ and ssl. I've primarily used burp proxy to see the traffic going in and out of my device. My android is rooted and I've exported and installed burp suites root ca certificate according to this tutorial. This allows me to see httpS and wsS traffic decrypted in clear text. The only issue with burp suite is http and websocket are the only protocols it natively supports. I have an android application that uses tcp socket and ssl. I want to use Wireshark to inspect that data. I've heard suggestions on how I might go about doing this. One of them is use something called tcpdump but I'm unfamilier and confused with that and other methods and I need to make sure I can decrypt the ssl.
You can redirect the traffic from the rooted android device to a transparent TLS proxy, which decrypts and re-encrypts the TLS traffic while leaving the WebSocket data untouched. Both PolarProxy (our tool) and SSLsplit can export the proxied traffic to a PCAP file in decrypted form. This allows you to inspect the decrypted WebSocket traffic in Wireshark without having to bother with key log files.
I have installed packet capture on my android phone - Samsung Galaxy S7 edge running Android version 8.0. It is not rooted
I followed all the steps and installed the SSL cert as well.
Here is the app link
When i click on the start button to capture traffic internet connectivity for apps doesn't work. Chrome works on the phone though.
The apps that i tried which lost access to internet were Amazon, Owl Cam, Arlo
Any idea what setting or changes i am missing?
Looked up similar question on stackoverflow without any answers
1) Question1
Short answer:
There is no complete solution for your problem. And it is impossible to solve it. The reason why this problem occurs is the existence of "Certificate Pinning". Even simple rooting can not solve your problem.
Still there is a partial solution. Turn off 'SSL Capture'. Then all apps will start working. But you won't be able to decrypt the contents of packets sent over an SSL connection. But you will still be able to see the source and destination address of the packets. If your packet sniffer application does not have an option to turn off SSL packet sniffing, in that case uninstall the app, remove any custom CA certificate installed and then re-install the app.
Long answer:
How a normal packet sniffer (that do not require root) works on Android.
Android allows an app to act as a 'VPN Gateway app'. When an app tells Android that it wants to provide a VPN connection, Android will forward all IP packets destined to internet from all other apps to the VPN App. The VPN app then usually encrypt those packets and send it to the VPN server, from where the packets would go to their original destination.
Packet Sniffer packets make use of the above mentioned feature. They appear like a VPN app to Android. So, once turned on, Android will send all IP traffic to this app. But in order to forward them to a VPN server, the Packet Sniffer app would simply sent them to their original destination. This way the Packet Sniffer apps simply act like a transparent proxy. The app is able to all incoming and outgoing traffic. Those apps are essentially acting like a "man-in-the-middle".
TSL/SLL and Ccertificate Authority
SSL (and HTTPS) is built almost entirely for the purpose of preventing any kind of "man-in-the-middle" attack. SSL runs over normal TCP connection. What it does is that it encrypt all traffic that is being sent between a client and server with a secrete key that is know only to the client and server. You may read more detailed and accurate information about how SSL works here
While setting up a TLS/SSL connection, a client device will ask the server to show it's digital signature certificate (AKA SSL certificate) proving that the server is whom it is claimed to be. That is when Amazon App tries to connect to amazon.com, it will ask the server to produce a digital signature certificate proving that the server is in fact amazon.com . When the server sends the certificate back, the app will ask Android Operating System if the certificate is digitally signed by someone the Android
trusts. If the certificate is in fact signed by a CA (Certificate Authority) that the Android Operating System trusts, the connection proceeds. Otherwise app will show an error that it is unable to connect.
How Packet Sniffing apps are normally able to sniff TLS/SSL packets?
Packet Sniffer apps will ask user to install a custom CA Certificate on the system on Android. That CA(Certificate Authority) certificate will make the Packet Sniffer app be treated as legitimate and trusted TSL/SSL certificate issuer authority on that device.
Now all apps by default will accept a TSL/SSL certificate signed by the Packet Sniffer app. So if an app like Amazon App tries to make an SSL/TLS/HTTPS connection while the Packet Sniffer app is running, the PacketSniffer app will establish to TLS/SSL/HTTPS connections - one between Amazon App and the Packet Sniffer, another between the Packet Sniffer app and the amazon.com server. The Packet Sniffer will show a fake SSL certificate claiming that it is in fact amazon.com server. Since Android now trust any SSL certificate that is signed by the Packet Sniffer app, the connection proceeds fooling the Amazon App.
This way a Packet Sniffer app would normally able to capture and decrypt even those packets that are sent over an SSL connection.
Certificate Pinning
If a packet sniffer app like the one described above can decrypt information sent over an SSL connection, then same thing can be done by a malicious person too. All he needs to do is somehow convince the user to install his CA certificate on Android. Then he will be able to read all WhatsApp messages, banking passwords from Bank apps, Credit Card information that Amazon app send to amazon.com .... and what not.
So makers of some apps, particularly those which handle highly confidential data like credit card details, decided that they can no longer put trust on Android OS (or iOS, Ubuntu and Windows) in determining whether app is in fact connected the legitimate server or not.
So they started following the practice of certificate pinning.
What makers of those app do is that they may either embed a copy of server's SSL certificate itself with-in the app or embed a copy of SSL certificate of a Certificate Authority they use.
Those apps would then compare any certificate produced by the server with the certificates that is embedded with-in the app. If they do not match, the apps will simply refuse to connect. Those apps do not place the trust on Operating System. Hence the custom CA certificate that the Packet Sniffer app installed would have no effect on those apps.
There is no known way to easily bypass certificate pinning (other than decompiling each app and replace the embedded certificate, that too on a rooted device). Certificate pinning exist solely for the purpose of preventing exactly what you are trying to achieve. If you enable SSL sniffing on your Packet Sniffer app, all apps that uses certificate pinning will stop working.
Solution
Turn off SSL Capture.
If your packet sniffer application does not have an option to turn off SSL packet sniffing, in that case uninstall the app, remove any custom CA certificate installed and then re-install the app.
I want to monitor HTTPS traffic from my application to remote server. I am trying to follow this instruction and it works for HTTP (without s), but not for HTTPS.
What is wrong? Should I write some custom code in my application to use https-proxy ?
The easiest way to do this is to use CharlesProxy to proxy your device or emulator traffic for you. The only extra step you need to do is to install the CharlesProxy SSL certificate on your device/emulator which is very straight forward:
Download the certificate from Charles Proxy (it's in their help menu) and place it on your device, then install via security settings on your device.
You then configure your device or emulators network connection to use a manual proxy and set it to the Charles Proxy address and port. Enable SSL proxying and your SSL connections will be securely routed end-to-end via Charles and Charles will be able to show you the content of requests and responses in the clear.
I'm using WireShark for sniffing, it allow you to monitor and filter raw data. But because you using https and all transactions encrypted i suppose it can't help you. May be you can switch from https to http for debug, and later when all will be works fine change protocol back to https
Do you mean you can't see the traffic at all or do you get it encrypted? Is this a web application or native application? which Android version are you using? phone or emulator?
Normally, if you set up the proxy properly, you will get the traffic, but encrypted so you can't read it. In order to see the actual content in Fiddler you would need your device to trust Fiddler's root certificate (used to create fake certificates on the fly). See this:
http://www.fiddler2.com/fiddler/help/httpsdecryption.asp
Unfortunately, I have not found a way to add root certificates to an android device other than
rooting it and replacing the certificate store (like this)
https means http secure, so it obviously can't be sniffed so easily. what would be the point if it would be the same unsecure thing as normal http?
you have to learn a bit more about secure network comunications. or, long story short, at least you will have to learn how to use a specilly devised http proxy like charles http://www.charlesproxy.com/documentation/welcome/ so you will be able to monitor you own https traffic in a clear form.
I'm starting a new project in the coming weeks but I have some questions related to the "design" of the app.
The app will be a server + database that talks to an Android app that also has it's own database (for offline use).
The connection will be used to exchange strings that are encrypted with a custom "protocol" (game network protocol encapsulated in TLS). This means that the app would have two layers of security :
TLS -> against MitM attacks
Custom protocol -> against "in-game hacks", like game packet tampering
My questions are the following :
Is it possible to use TLS between node.js and Android ? Are there any good links on that subject ?
(I read there were some issues with the format of the certs that was different in java and node.js. It was related to OpenSSL and the EVP_BytesToKey function)
-- > Encrypt with Node.js Crypto module and decrypt with Java (in Android app)
--> http://olabini.com/blog/tag/evp_bytestokey/
Is there a way of obfuscating the source code of the Android app so that the custom "protocol" can be decrypted client-side safely? Or should all the magic take place server side ?
(I don't want the decryption source-code to be visible for users to dissect the custom protocol and start developing hacks.)
Any tips or links on increasing the security of my node.js server in general ?
(I heard some people talking about Nginx proxies, but since I'm not serving webpages does it still make sense ? Wouldn't it overload the server ?)
Thank you alot in advance !
(In)Security though obscurity does not solve the real security problems you face. What you are describing is not how games protect themselves from attack. SSL/TLS does prevent against MITM attacks, however your attacker isn't just a MITM, he is a user of your software. If the app can make the SSL/TLS connection, then the attacker can also make this connection and should assume that the attacker will always full access to the API you provide.
Cryptography cannot solve CWE-602: client side enforcement of server side security. A database merge between the client's offline database and the server is trusting the client's data, and there for a violation of CWE-602. In this attack the attacker doesn't need access to the API, he could just modify the sqlite database locally.
I have an application on an Android phone(emulator) which sends a https request. How I can see that request?
That is easily possible with a software such as Fiddler or Charles. They have an inbuild SSL server that will position itself in between the app and the server. It is kind of a "Man-in-the-Middle" attack, just that you are only attacking yourself.
After installing the software on your PC you will have to set the IP adress of this PC as proxy server in Android. And secondly you will have to install the Root Certificate that the software is using on your Android device.
As you are not braking any encryption and not reverse engineering any application here, I don't think this will classify as illegal. And as you need to have physical access to the device, you also cannot spy on anyone else than yourself.
If you are communicating with your own server, and you have access to its private key, you can use Wireshark to capture packets and have it decrypt the HTTPS traffic. If you are trying to reverse engineer someone else's app, this may or may not be legal and generally cannot be done.