Using Burp suite as an interception proxy with cross-site scripting and URL injection

Once I started burp suite, I was a bit lost. I am very used to a terminal, and using a GUI ‘Graphical user interface’ was nice for a change! 🙂

I am using 1 single machine, to show this in a simple format.

-I am using a web browser to request and send traffic

-And I am using burpsuite for the fun stuff!

So, we have a target IP. I configured my kali Linux setting to have a set IP and to be using port 8080 with http traffic. Right off the bat, a recipe for disaster. This will be fun!

I fired up Burpsuite and configured my target as the IP and was able to immediately intercept the target. How does this work?

Consider me (the hacker) as “literally” sitting in between the target and a server. If I want to intercept data and information between these 2. It is incredibly easy when the target is using unsecured and poorly configured security protocols.

In short, I was able to intercept, and forward the traffic ME! And eventually, edit it. Let's see. So I attempted to load my first page as the target host.

And… nothing loaded! A few refreshes later, and the same thing. Why is this? packets never got to the server. They will tho, once I release them and it gets sent back to us both.

Little does our target host know, we have burpsuite running as a proxy server and all information is being sent to my attack machine.

In simple terms- my attack machine is intercepting the browser request!

In this case, we see the attack target try and post something onto their blog!

As the target, i posted onto my blog > secure your ports from sniffers and attackers and submitted it to the page.

As the attacker, I receive this! I was able to see all data in clear text. I released it back to the target host, and I get the information sent directly back to me. A simple man-in-the-middle attack! Within the Burp suite, we can download this as a file and use it later if need be. Here you can see,  the first few attempts I released it back to the browser haha.

But in reality, hackers love to have fun! So lets manipulate the information that is being displayed on the target's host by injecting a script into the data being intercepted..

Within the same data received I ran a few simple burpsuite commands within the GUI.

I found the correct one within the HTTP history and sent this to my repeater within the burp suite.

The repeater allows me to manipulate the data and make it the new data being sent back to the user requesting that specific data!

So, I added a simple script to the value of the data.

<script>alert (“gotcha!”)</script>

A fun alert for our targets

I then confirmed it by making this script/data value able to request in the browser in the original session mode.

And whalla!!!! An alert is displayed to a user with an injection into the intercepted traffic response.

We can do this same attack with a few slight alterations to intercept important data such as emails!

Specifically, in this case, we intercepted a user's password request change. Very important information!!!

We have our attack machine preconfigured still on the same IP and ports.

The target opens a browser and sends data for a password reset to the server.

But, the data does not get to their server without us intercepting it,

Here, you can see the request under the HTTP history. I found the reset request, intercepted it, and did the same steps from before.

And, again you can see the Target is not getting any packets back and an error code is displays. This is because my Burp suite is intercepting it until I release it.  Now, we Simply send it to my repeater for alterations :) 

Within the repeater, I was able to edit the email address that will receive the password reset packets. From our targets to ME!

I released this back to the web browser. By > request in browser > in the original session

Now, refreshed the new URL and i was greeted with new data in my burp suite interception output. This data confirmed that the email address has been changed for the data being sent to my email address.

Below, you can see the email address I changed it to!!!

So, not only did I obtain the username from the initial interception, I got the email for the password request change for our target host. Within minutes as an attacker, i can have full control over the email address, change the password and have access to anything in the email

This is an amazing example of why 2FA (two-factor authentication) is not a recommendation anymore, but a must! Additional tools such as a physical security key, or authentication codes changing every 30 seconds are HIGHLY recommended for the modern day and age!