7

I'm looking to do a vulnerability research on products running on a variety of devices by intercepting their HTTPS traffic, but I don't want to modify the devices aside from installing a custom cert.

It seems SSLsplit does what I want, as it allows for "connections [to be] transparently intercepted through a network address translation engine and redirected to SSLsplit". From what I understand, these NAT rules don't have to be defined on the device that is running the application being MITM-ed, and I can customize iptables to redirect router traffic through SSLsplit on a device running Fruity Wifi or OpenWRT.

Is SSLsplit with modified iptables rules sufficient and a reasonable way to go about this, or would I have to modify other parts of the Linux networking system, as well?

NOTE : The system I am trying to build requires devices to have a cert installed to the trusted root store to "opt in" to this interception. I am not trying to build a system to intercept arbitrary traffic from unwilling devices.

Anubioz
  • 3,597
  • 17
  • 23
Andrey Fedorov
  • 2,079
  • 4
  • 16
  • 12
  • 1
    This is the wrong forum for this question - should be asked on Security.stackexchange.com however there it would be closed because either A) you are trying to build a weaponized system or B) don't understand the difference between SSLstripping and MITMing. – symcbean Mar 18 '17 at 20:56
  • 2
    @symcbean indeed, but SSLstripping is a type of MITMing itself. –  Mar 19 '17 at 11:42
  • @symcbean definitely not trying to SSLstrip, nor am I trying to build a system that could target folks who have not given you admin access to their device as most operating systems (e.g. macOS, Windows) require administrator privileges to install new certificates. – Andrey Fedorov Mar 19 '17 at 17:38

3 Answers3

5

In short, yes it can be the right tool, but in fact it makes no odds if you are using SSLStrip, SSLSplit, mitmproxy or any other tool that can do your job, you should only beware of the way it works.

As @Quantim mentioned, this is not possible without installing/having custom cert/CA in device behind the router since it needs custom CA to act as a man-in-the-middle for SSL connections and it needs to be able to generate and sign certificates that the victim trusts. Thereby the victim must have the attacker’s root CA certificate in its trust store. Explaining how CAs work and how you can achieve your desirable result using the mentioned tools is beyond the scope of this answer, but depending on the type of client - desktop browser or mobile phone - you should note that installing the root certificates differs a bit.

SSLsplit works quite similar to other transparent SSL proxy tools - like mitmproxy which has more features and is more complex. It acts as a man-in-the-middle between the client and the actual server. Provided that traffic is being redirected to the server on which SSLsplit is running and listening by changing the default gateway, ARP spoofing, forging DNS entries or any other means. In other words, as you might have guessed, SSLsplit picks up SSL connections in a way that pretends to be the actual server that the client is connecting to and is willing to communicate with. In fact it dynamically generates a certificate and signs it with the private key of a CA certificate that the client must - is going to - trust.

So to answer your question "Is SSLsplit the right tool to intercept and re-encrypt HTTPS traffic on a wifi router?", yes it can be, but do you know enough to do so? If yes so, go and hit the jackpot with your research.

And to answer "Is SSLsplit with modified iptables rules sufficient and a reasonable way to go about this, or would I have to modify other parts of the Linux networking system, as well?", I should say that if you have correctly configured your IPTables rule-sets, and NAT/DNAT rules, and if your clients can consider the CA cert as trusted, yes that'll be sufficient - with modified iptables rule-sets and redirecting clients' traffic to the server you are going to intercept the clients' traffic on, as mentioned before. By the way, you need to note that the word "transparent" in computing means (of a process or interface) functioning without the user being aware of its presence.

Excerpt from the original documentation :

SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit generates and signs forged X509v3 certificates on-the-fly, based on the original server certificate subject DN and subjectAltName extension. SSLsplit fully supports Server Name Indication (SNI) and is able to work with RSA, DSA and ECDSA keys and DHE and ECDHE cipher suites. Depending on the version of OpenSSL, SSLsplit supports SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, and optionally SSL 2.0 as well. SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way. For HTTP and HTTPS connections, SSLsplit removes response headers for HPKP in order to prevent public key pinning, for HSTS to allow the user to accept untrusted certificates, and Alternate Protocols to prevent switching to QUIC/SPDY. As an experimental feature, SSLsplit supports STARTTLS mechanisms in a generic manner.

Redirection

Since the OP needs to know how to redirect requests to SSLsplit but doesn't want to set up a proxy - as mentioned in comments - I am going to give a quick insight into doing this and I hope it will help :

Scenario 1 : If SSLsplit is on the OpenWRT which you are using - i.e. if SSLsplit is set on the GateWay which victims (clients) are connecting to :


                        |
         VICTIMS        |       ATTACKER
                        |
        +-------~+      |       (GATEWAY)       If SSLsplit is set on the Gateway users are gonna connect to, you only need to redirect some ports to those SSLsplit is listening on
        |        |      |                       SSLsplit will be running on two ports: 8080 for non-SSL TCP connections and 8443 for SSL connections.
        |        | ---> |
        |        |      |                       sysctl -w net.ipv4.ip_forward=1
        +~~~~~~~~+      |                       iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
                        | \                     iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443    (HTTPS)
        +-------~+      |  \    +~~~~~~~~+      iptables -t nat -A PREROUTING -p tcp --dport 636 -j REDIRECT --to-ports 8443    (LDAPS)
        |        |      |   \   |        |      iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443    (MSA)      Encryption = StartTLS
        |        | ---> | ===➤  |        |      iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443    (SMTPS)    Encryption = SSL
        |        |      |   /   |        |      iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443    (IMAPS)    Encryption = StartTLS
        +~~~~~~~~+      |  /    +~~~~~~~~+      iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080   (XMPP)
                        | /                     ...
        +-------~+      |
        |        |      |
        |        | ---> |
        |        |      |
        +~~~~~~~~+      |
                        |
                        |

Scenario 2 : AND IF SSLsplit is not set on the GateWay whic clients are connecting to - You will be in need of setting DNAT as the following :



         VICTIMS        |        GATEWAY
                        |
        +-------~+      |
        |        |      |
        |        | ---> |                                                       IPTables will be like this :
        |        |      |
        +~~~~~~~~+      |                                SSLsplit               iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 443 -j DNAT --to-destination z.z.z.z:8443
                        | \                                                     iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 465 -j DNAT --to-destination z.z.z.z:8443
        +-------~+      |  \    +~~~~~~~~+              +~~~~~~~~+              ...
        |        |      |   \   |        |              |        |        
        |        | ---> | ===➤  |        |  --------->  |        |              In this scenario, all packets arriving on the router with a destination of x.x.x.x/CIDR will
        |        |      |   /   |        |              |        |              depart from the router with a destination of z.z.z.z
        +~~~~~~~~+      |  /    +~~~~~~~~+              +~~~~~~~~+
                        | /
        +-------~+      |       Redirects desired connection from somewhere
        |        |      |       to somewhere else to desired ports.
        |        | ---> |
        |        |      |
        +~~~~~~~~+      |
                        |
                        |

Pay attention about setting the value of net.ipv4.ip_forward to 1. The command I used above by using sysctl -w is not permanent. If you want to set it permanently, you should edit the file /etc/sysctl.conf where you can add a line containing net.ipv4.ip_forward = 1.

By default most Linux distributions will have IP Forwarding disabled. And IMHO this is a good idea, as most peoples won't be in need of using it, but since you are setting up a Linux router/gateway - useful for VPN server (pptp or ipsec) either - you need to enable forwarding. This can be done in several ways as I have showed you some.

Community
  • 1
  • thanks for the thorough answer. I understand how certs work. my question more specifically if running SSLsplit and modifying iptables rules will be enough, or if there is some other part of linux networking I should be aware of / read up on. – Andrey Fedorov Mar 19 '17 at 17:41
  • 2
    The client should ignore the error and accept the risk of getting access through your self-signed cert, or you will be in need of having physical access to install the CA cert. If you can have all of them, you can step in the middle of the client and the actual server, and nothing else is needed. –  Mar 19 '17 at 17:46
  • 1
    I believe [this link](https://blog.heckel.xyz/2013/08/04/use-sslsplit-to-transparently-sniff-tls-ssl-connections/) can help you a lot. I said, it's beyond the scope of this answer, but you need to know how to step in the middle of client and server, and how to circumvent the rules - if you want so. But generally, you cannot achieve your goal without CA cert, or you should ask the client to accept the security risk that the browser will show, but this is not a professional way, at least this is not what a penetration tester will do! –  Mar 19 '17 at 17:50
  • Thanks. I saw that article but ignored it since it didn't mention running software on a router specifically. I'll take another look now. – Andrey Fedorov Mar 19 '17 at 17:55
  • (to clarify — I am looking to install a trusted root cert on the device that's running the applications I'm targeting. unless the app has a cert store built in, i.e. "pins" certain certs, I should be able to debug it) – Andrey Fedorov Mar 19 '17 at 17:56
  • Doesn't matter where you are running the tool, you should only consider networking/system concepts. If your clients can consider the CA cert as trusted, nothing else you need. –  Mar 19 '17 at 17:59
  • Thanks. The outstanding part of my question is how to redirect traffic on an OpenWRT device or an RPi acting as a router through SSLsplit. SSLsplit seems to have [proxyspecs] as an args including IPs and ports, but I don't want to set up a proxy, rather redirect all traffic through it. I'm still spending time on this every day, will accept the most helpful answer when I finish it. – Andrey Fedorov Mar 21 '17 at 19:41
  • @AndreyFedorov first of all, that'd be another question and you should have posted another question for what you just asked. Anyway, no problem, let me give you an answer. You should note that for what you asked, you have multiple options, but the easiest one is to change default gateway and also use NAT rules. So let me see, do you know how to redirect requests by using IPTables? Do you know what `prerouting` & `postrouting` are used for? Do you know how to use `-t nat` and what it exactly is? Do you know what IP-Forwarding is? Remember to set the value of `net.ipv4.ip_forward` to 1. –  Mar 22 '17 at 06:38
  • Changin default gateway on victim's machines, is easy, and setting IPTables rule-sets, easy too. BUT IF, you don't wanna change default gateway on victim's machine, and you have access to the router which it might be the OpenWRT you're using, just set the correct NAT rules and redirect them as you may want. If you couldn't achieve your goal, open a chat session and I will explain you how to do so. –  Mar 22 '17 at 06:43
  • 1
    @AndreyFedorov I have updated my answer, I guess you can understand what to do now. Good luck mate. –  Mar 22 '17 at 07:38
  • Thanks, I'm trying :-) reading up on `prerounting` and `postrouting` is helping a lot, thanks. Might edit your answer down a bit before accepting. – Andrey Fedorov Mar 24 '17 at 02:57
  • Hey, sorry -- Tero's is a lot more succinct and super close to what I was looking for. I wish I could split the bounty between you two... really appreciate the effort, it was helpful, just not as precise as is probably best for folks to get when they visit the page. – Andrey Fedorov Mar 24 '17 at 15:43
  • 1
    @AndreyFedorov No problem mate, we're not looking for points, I just wanted to help and I'm so happy that your problem is solved. Good luck mate ;) –  Mar 24 '17 at 15:44
2

This is not possible without install custom cert/CA on device behind the router. In other case you will be able act as any network service. SSLsplit only generates its own certificate or use one for which you provide private key

SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way

Source

In both cases, client without your custom cert/CA get invalid certificate issuer error

Transparent interception means, you don't need specify every host which you want intercept and can intercept all traffic, but this is still MitM attact on SSL

Quantim
  • 1,269
  • 11
  • 13
  • absolutely. that's what I meant by "installing a custom cert" in the first sentence of my question. my question is if SSLsplit / iptables configuration is enough to get this working, or if there is something else I should know about. will clarify. – Andrey Fedorov Mar 19 '17 at 17:40
2

You have two parts here: The SSLsplit which acts as the web server clients are connecting to, and NAT which swaps out destination addresses in packets to redirect them to the SSLsplit server.

NAT needs to be set up on the router that the client devices use, changing the destination address of the packets from the actual destination server to the SSLsplit server.

Then SSLsplit can pick up the connection and do its thing: connecting to the foreign host (available in the TLS handshake) and forwarding the response.

So, the only thing from networking perspective is that you need to make sure clients get such network options that their default gateway points to a router doing the NAT.

Andrey Fedorov
  • 2,079
  • 4
  • 16
  • 12
Tero Kilkanen
  • 34,499
  • 3
  • 38
  • 58
  • Thanks! This makes sense, with one caveat: if the NAT translates the destination addresses on the IP packets before forwarding them to SSLsplit, how does SSLsplit know where to connect to determine the response? – Andrey Fedorov Mar 23 '17 at 21:59
  • SSLSplit sends the response back to the NAT device IP address / port, and the NAT device then forwards the packet back to the client device after changing destination IP address. This is the basic principle of how NAT works. It is accomplished by using state tables on the NAT table, which track TCP connections passing through the device. https://en.wikipedia.org/wiki/Network_address_translation is a good explanation on how it works in detail. – Tero Kilkanen Mar 24 '17 at 00:51
  • Thanks, got that part. Do I understand correctly that to determine what the response is, the SSLsplit binary also reaches out to the external host? How does SSLsplit know what the external IP is to connect to if the NAT has removed it from the IP packet headers and replaced it with 127.0.0.1 (or wherever SSLsplit is running)? Is the address included in the TCP data, as well? – Andrey Fedorov Mar 24 '17 at 03:02
  • 1
    The destination host name is included in the TLS handshake data. – Tero Kilkanen Mar 24 '17 at 13:50
  • Thanks, I've got the general gist. Looks like this is called Server Name Identification (SNI), although SSLstrip supports something else called simply the "NAT engine". It seems to be documented well in their manua, so I'll continue my readings from there. I hope it's OK if I clean up your answer and provide a little more detail as I figure this out. – Andrey Fedorov Mar 24 '17 at 15:41
  • Yes, go ahead and update if you find room for improvement. – Tero Kilkanen Mar 24 '17 at 16:09
  • Note that while with SNI, the destination of the TLS connection is in fact available in the handshake and SSLsplit can make use of it in sni mode, SSLsplit can also ask the NAT stack for the original destination address of the connection and connect there (netfilter, pf etc modes), or connect to a statically configured upstream address. – Daniel Roethlisberger Jan 16 '18 at 19:47