Nowadays we often see that, to pentest an application first we have to connect into the client’s network and for which we have to set up the VPN connection. And only after that we can access the application and can start the pentesting. So what! this is a very common case and it’s easy to intercept the request in Burpsuite but today we are going to discuss a different scenario where VPN connection is not the only case.
Pentesting scenario
So, without roaming around the topic, it is better that we straightly come to our point, our problem statement. Let’s consider a scenario where there is a third party integration inside the application and you need to test that integration through your application. The third party integration could be anything such as payment gateway, translation library, email service, etc… and the client wants us to test that as it comes under their policies.
Now there are two things, one is the client’s parent application itself and the other one is a third party product, let’s say payment gateway. And the scenario is, the client’s application requires us to connect through VPN and a third party implements socks that means, we can only access the payment gateway if we connect through vpn socks proxy. Also one can not access your application from the payment gateway environment.
Before moving further let’s briefly discuss socks proxy.
Socks proxy
A SOCKS server is a proxy server that communicates through a TCP connection to another server on behalf of a client, then routes all the traffic back and forth between the client and the server. SOCKS is designed to route any type of traffic generated by any protocol or program.
Since SOCKS sits at layer 5, between SSL and TCP/UDP, it can handle several request types, including HTTP, HTTPS, POP3, SMTP and FTP. As a result, SOCKS can be used for email, web browsing, peer-to-peer sharing, file transfers and more.
Socks proxy is often used because clients are behind a firewall and are not permitted to establish TCP connections to servers outside the firewall. An HTTP proxy is similar, and may be used for the same purpose when clients are behind a firewall and are prevented from making outgoing TCP connections to servers outside the firewall.
But the main difference is, The SOCKS server does not interpret the network traffic between client and server in any way whereas, an HTTP proxy does understand and interpret the network traffic that passes between the client and downstream server, namely the HTTP protocol.
we will stop here as understanding socks proxy itself requires a separate blog.
Problem statement
If you understand the our pentesting scenario discussed above, then the actual problem is, How will you intercept all the requests? (requests of your application and requests of payment gateway). You can think of a solution for a few minutes to make reading interesting.
Failed test cases
Failed cases are equally important as success cases, A great quote from Thomas Alva Edison, “I haven’t failed. I’ve just found 10,000 ways that won’t work”. So, First let’s discuss our 2 failed test cases we tried and did not work.
1. Only connect through socks proxy First we have thought that lets only connect to socks proxy ( Socks Proxy settings under User options menu of BurpSuite ) but as we discussed earlier that both are totally different environment and we were not able to access our main application from the socks proxy environment so there is no reason to move further and hence failed case 1.
2. Set upstream & send direct to ssh tunnel After the failure of the first case, think of another scenario. Let’s try and set an Upstream proxy and send the network traffic direct to the ssh tunnel and see whether we are able to access the payment gateway or not. We already open a ssh tunnel using a tool called Putty. Then we set our payment gateway domain (which requires socks connection to connect) in upstream proxy as below.
- Destination host: payment gateway host
- Proxy host: 127.0.0.1
- Proxy port: 4444
What we observed here is we are able to access our main application as we are connected with VPN but failed to connect the payment gateway. The reason behind this could be because there is no HTTP server accepting our request at 127.0.0.1:4444, it is just a ssh tunnel which works at TCP layer.
Solution which saves us
Finally we got an idea, why don’t we try two different burpSuite instances and set the upstream proxy & socks proxy in them. So, we open two instance of BurpSuite (lets called burpsuiteWithUpstream & burpsuiteWithSocks), where burpsuiteWithUpstream listening on 127.0.0.1:8080 & burpsuiteWithSocks listening on 127.0.0.1:8081.
As name implies, we set upstream settings in burpsuiteWithUpstream instance as below:
- Destination host: payment.gateway.com
- Proxy host: 127.0.0.1
- Proxy port: 8081
That means, if any request has a domain like payment.gateway.com then that request will forward to the upstream server (127.0.0.1:8081) that is our burpsuiteWithSocks instance.
Then, we set socks proxy in burpsuiteWithSocks burp instance as below:
- Socks proxy host: 127.0.0.1
- Socks proxy port: 4444
That means any request coming to this burpSuite instance will use Socks proxy for further communication.
Bingo..! This works like a charm for us and we were able to pentest the third party integration that is payment gateway from the given application.
I would like to give sincere thanks to Mihir Doshi (@m1h1rd) for ideas and help.
Conclusion
There could be other ways to intercept requests in our scenario but the intention is to fulfill our requirements and not to judge which way is better. So let’s conclude this with quick brief of solution,
- Setup the SSH tunnel.
- Open two different instances of burpSuite.
- Set upstream proxy in burpsuiteWithUpstream instance.
- Set socks proxy in burpsuiteWithSocks instance.
- Don’t forget to set the proxy setting in burpsuiteWithSocks instance (listening on 8081).
- You can visit the application & payment gateway which should works smoothly and you should be able to intercetpt all the requests in burpSuite
Cheers & Happy Hacking.
