Proxying non-http protocols via BURP

This article will shortly describe the mechanisms and tools that allow the interception of any UDP or TCP traffic via Burp proxy. The main driver behind this endeavour was the ability to inject and modify the packets for various protocols via intuitive Burp interface.

 Burp is a powerful proxy for web application pentests, but only speaks http and https. So , in order to redirect traffic which is not http/https via Burp we need to configure another intermediate component that will listen for a desired traffic , direct this traffic to Burp so we can tamper with it, and Burp will forward it further to the destination server.

 This intermediate component is mitm_relay.py, a python script available at  Github. https://github.com/jrmdev/mitm_relay

 Implementation

The first step is to run mitm_relay.py. 

-l =IP address on which the local server will listen. I set it to listen on all available interfaces (0.0.0.0)
-p=where is Burp proxy running (127.0.0.1, port 8080)
-r= relay mechanism, in our case we listen on port 5300 and redirect anything from local 5300 to www.google.com , port 80. 

 Let us check that there is local listener running on 5300 

Note that the local port 5300 is referenced in relay option (-r):
-r tcp:5300:www.google.com:80
This means that connection to a local IP and port 5300 will be relayed to www.google.com port 80, but via proxy/BURP (-p 127.0.0.1:8080). If we check the Burp , requests are there, containing "CLIENT_REQUEST" and "SERVER_RESPONSE" attributes in the URL.

You can inspect the traffic to and from Burp within the mitm_relay.py console:
The example below is an example for a SIP /VOIP interception
Configure a listener (listens on port 5060, forwards to 185.91.12.103:5060, some internet SIP server I have chosen just to check the operation)
Let us select a random SIP server available on the internet.



After that, configure SIP client, in my case I use Jitsi. (Registrar is randomly selected 4.4.4.4 as I don't have a proper SIP account to actually authnticate the connection). Note the proxy is 127.0.0.1, port 5060 where mitm_relay.py is awaiting the connection. Also, I force SIP over TCP (SIP is natively a UDP-based protocol).

Checking Burp for response shows that the destination SIP server asks for authentication (Note "SERVER_RESPONSE" is outlined. This is ok  and we don't have a valid SIP, the connection is dropped.



Comments

Post a Comment

Popular posts from this blog

Signature verification bypass vulnerability in some Huawei routers

Image
This blog will describe the discovery of the digital signature bypass on some Huawei routers.  The idea of digital signature check is simple - you have a piece of code and you calculated the checksum/hash of that file. The hash or checksum can be thought of as a "signature", a mathematical value that is uniquely assigned to the code (in our case the code was a firmware file). As soon as you change anything in the file and recalculate the hash, it should be significantly different from the original value - that is the feature of the hashing algorithm. Even the small change in the code will change the hash significantly. Vendors in most cases provide the such a pre-calculated hash so that the customer or the system may check if the hash of the image is indeed the same as vendor required. What was found in this investigation was that the system command on the Huawei AR1220E router does not perform this check properly. As a consequence, the attacker might be abl
Read more

Attacking encrypted VOIP (SIP) protocols

Image
In this post I will be explaining the approach in attacking the encrypted voice over IP (VOIP) protocol, more specifically, SIP (Session Initiation Protocol).  When we are talking about the SIP encryption, it will most likely assume some kind of SSL/TLS wrapping (SIP over TLS). An example below shows the solution design that allows interception, decryption and manipulation of SIP messages. The central component consists of mitm_relay.py and BURP. It is not required that both BURP and mitm_relay run on the same machine, but my setup did run both of them on the same virtual instance. The communication chain looked like this: Client -> mitm_relay->BURP->SIP Server->Client 2 The mitm_relay.py is a python script available at https://github.com/jrmdev/mitm_relay Before we fire up the mitm_relay, we need to configure couple of things- its certificate (self signed in my case, and private key). Once this is in place, we can run it: Few details about the mitm_relay setup:
Read more

DNS insights - UDP vs TCP and EDNS

Image
In this article I will elaborate the research I did in relation to DNS (Domain Name Service). The particular issue discussed here is when and how DNS uses TCP or UDP transport layer in relation to the packet size. Normally, DNS will run queries and replies via UDP protocol unless there is a Zone Transfer , incremental or full (IXFR or AXFR , respectively). According to the original DNS specification as given in the RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt), DNS will also use TCP for packets larger than 512 bytes. However, there was another RFC issued in 2013 which is RFC 6891 (Extension Mechanism for DNS), labelled as EDNS(0). https://tools.ietf.org/html/rfc6891 I came across this issue accidentally, but as we will see in the text, some issues were noticed that are some not well documented reasons why DNS may fail to comply with EDNS. To do the proper investigation, here are some assumptions I worked with: a) I wanted to check DNS clients from both Windows and Linux b) I wan
Read more