SSL traffic manipulation through ettercap MitM and iptables

Question

I am trying to understand the relation between some tools and concepts used for MitM on a wifi network and how https transaction (over this wifi network) between an android app and the respective server can be intercepted and modified . I am new to this domain, so please bear with me.

So I want to CAPTURE and MANIPULATE all the HTTPS traffic between an android app and the server it is communicating with. The user using the app is on a WPA/WPA2 PSK network. I have already captured the intitial WPA handshake and have been able to successfully brute-force the PSK through the handshake and now I am a part of the same network as the user using the target app.

Now to be able to capture the traffic I need to gain an MitM position. There are a bunch of ways of doing this. There are a couple I know, including Cain APR and ettercap.

I choose to use ettercap to ARP poison the victim. Now since the mobile device communicates over SSL and I want to intercept this SSL communication, I make the required changes to etter.conf and turn on ip forwarding on my system to do ettercap certificate impersonation, where ettercap actually generates imposter server and CA certificates on the fly.

The above technique would still present the victim with a certificate error warning and if the user accepts that the fake cert is added as a trusted root CA on the victim's device. I could have used SSL Strip here but again, if the user connects to the server directly over https (without a redirect), SSL Strip may not be the best solution.

Now although I can sniff SSL traffic now, but it would be relatively tougher to manipulate this SSL traffic using ettercap. So instead I try to use iptables to redirect traffic to an alternate port number on a second port on the local system where I have another software running that would allow me to manipulate the data in the redirected traffic.

Now let's say the software I am running on this port is BURP Suite, which is something I would want to use to fiddle around with the data.

Now the thing I am getting confused with is:

BURP has it's own Portswigger certificate. However, using ettercap I have already done a certificate impersonation earlier. So now, when I forward all of this traffic (using IP Tables and setting up BURP to use Transparent Proxy) to BURP, will I need to get the Portswigger certificate also trusted on the client's device ? Please explain either yes or no.

1. As a real world attacker the above would probably be one of the methods I might just use to launch an attack. Is the above understanding correct ?

2. As a pen tester another way of achieving this that I can think of is if I install an SSH server on the test device and also install Shark(in the case of Android)/some other tcp dump like tool and then monitor/analyze (using Wireshark maybe)all the traffic remotely through an SSH client on my local system ? Will this let me do the intended job ?

3. What could be some other ways of doing this ?

Answer 1

The best solution is when ettercap does not MiTM the SSL connection, just forwards it to Burp, and Burp can be set up as a transparent SSL MiTM proxy. In this case, the client will see Burp's server certificate, which has to be trusted by the client. As you can see on the following, only 2 SSL connection is set up.

           SSL1            SSL2 
Client <--Ettercap--> Burp <--> SSL Website

Although both ettercap and Burp can be set up as SSL MiTM, it makes things only more complicated. In this case, the client will see ettercap server certificate only, so you don't have to add the Burp's certificate to the store. In this case we will have 3 different SSL connections, but it does not have any advantage compared to the previous one.

       SSL1          SSL2      SSL3
Client <--> Ettercap <--> Burp <--> SSL Website

To answer your questions: Yes, as a real world attacker the above would probably be one of the methods you might just use to launch an attack.

SSH-ing into the Android device and using Shark won't be enough. You won't be able to manipulate the traffic. You will be only able to decrypt the traffic if you have the TLS/SSL server keys (which is usally not the case) and perfect forward secrecy is not used.