All righty, guys.
Welcome back.
In the last video we have seen how we can establish a man in the middle attack and this setup.
This is really awesome because we are not only intercepting https traffic, we can see every connection
the client is making.
Freaking awesome, right?
It's also being reestablished within seconds, which is even more amazing.
But for now we are having one problem.
The problem we are having is the following.
We've got our smartphone over here.
And if the smartphone is now connecting to a web page, for example, example dot org, then the package
will rush through our network.
So we yeah, we can see this in Wireshark, but we are not able to stop, intercept, manipulate or
redirected.
And this is definitely something we want to have also for the response of the server.
I mean, yeah, we see the packages and the website is loading on the smartphone.
We can see the whole content regarding to http.
Okay.
We will later see how to deal with https.
But for now, let's stick to the connection.
We can see this connection, but we yeah, I mean, we cannot manipulate it right now and this is something
we definitely want to have.
Right?
At least I would like to have this feature and therefore let's tune our setup even more.
So how can we establish this right now instead of rushing through this whole network?
If you're opening a web page, we want to have the following.
The package should arrive at our interface.
Then we also see it in Wireshark absolutely perfect.
But afterwards, we don't want that this package automatically passed this interface and goes out into
the Internet.
The kind of magic we are establishing right now is a local proxy.
So it looks like this one freaking awesome.
Right?
So we are having a local service listening on a certain port and what we're doing right now is the following
Instead of passing this package through, this whole interface, be redirected, be redirected to our
local service.
Instead of going through this, it gets redirected to our proxy.
Here it stops and we can analyze, manipulate and also forwarded afterwards to the Internet.
By having this, we can now inspect and manipulate packages, which is it's really awesome.
This also automatically happens for response packages.
So if the response package arrives, it doesn't automatically get the routed through our network interface.
Also, the response packages will stop.
At this point we can inspect, manipulate and forward them to the original smartphone.
So this gives us a lot of possibilities.
I mean, we could also try injecting JavaScript code or other stuff into these packages which might
have some side effect on the smartphone itself regarding to pictures or text.
I mean, it can be super funny to yet to manipulate or interact with this one, but we can also use
this to exploit certain features in this mobile application over there.
So now the question, how can we do this?
How can we stop these packages and reroute them through our interface?
The answer for this one to establish this kind of magic in the background requires only two steps.
The first one is we need to enable IP forwarding in our kernel.
This can be done with the following command.
Enabling this feature simply means if you have a package and multiple interfaces, the package gets
automatically rerouted through that.
For example, our package arrives at our interface point, which is 10.40 2.0.1, our gateway of our
USB to Ethernet adapter.
But the destination is regarding to the outside world.
Therefore it needs to be rerouted through our NAT adapter of this virtual machine.
Our interface to this is our internet access and by enabling this feature, this package can now be
rerouted through this interface.
So this is a core feature that needs to be enabled in our Ubuntu VM, but it doesn't perform the rerouting
for our package to our local proxy listener.
And this this type of magic can be done with IP tables.
IP tables are freaking awesome.
They are some kind of package filters, but it doesn't mean that we are just dropping packages.
We can also define a certain ruleset to reroute packages based on some certain conditions so we can
do a lot of stuff with IP tables.
So you should definitely check out IP tables if you have some spare time.
Alrighty.
Okay.
For now, we only need to deal with one command.
This command over here.
This command performs the metric for port ID, so it looks absolutely ridiculous, but it makes sense.
I mean, IP tables always make sense, but it's hard to read if you're doing this for the first time.
Therefore, let's go through this together right now.
All right.
So here we are back on the graphic tablet.
And this is our setup we already got.
This is our basic man in the middle setup in this video right now we have added the burp suite, a proxy
listener on 1040 20.1.88.
So what does a change in this setup over here?
Well, first of all, not much, but nevertheless, let's insert it.
So here we have now our proxy listener.
The perfect speed on 1040 20. 1.80.
And this is our burp suite.
Sweet proxy.
All right.
This simply means on this network in the face over here, we have now a proxy listener on Pod 88.
But we do not reroute any traffic right now to this proxy.
We just have it running on this on this part over here.
Okay.
So let's get into this huge IP table rule and figure out what it does.
We do this a step by step, so we split it up into single pieces.
And then we will apply this on our our drawing underneath to figure out what it changes in the package.
Alrighty, let's go.
Okay.
So our command starts with IP tables that RT not.
So that means we want to apply our IP table rule for the table nut.
We also got two different tables.
We've got filtering and we've also got mangle, but we can ignore them for now.
Nut means network address translation.
And in the context of IP type rules, it simply means change or give us the possibility to change IP
addresses in a package.
So if we have here our package, this one over here.
And this is our HTTP package, for example, dot org.
Then we want to change the IP addresses in this package over here.
So we want to be able to swap them.
And changing the IP addresses of the package gives us the possibility to redraft this package.
So in our case, what this means is the following.
Instead of going directly through this from here to here, we want to reroute this package from here
to the burp suite.
And yeah, we have to define a lot of more parameters that the IP table rule exactly knows what to do.
But this is our channel really table and this is where we where we add our entry right now.
So not simply means network address translation.
And this is the table where we want to add a new rule right now.
Next, we've got this capital dash eight.
And this simply means appending a new rule.
We also got capital dash DX, which means deleting an existing rule based on the configuration parameters
afterwards.
In our case, we want to append a new rule.
Therefore we use the dash a command, and now we have some chain.
A change simply means some some kind of action which we want to perform.
In this case we have Dash A and we want to add a new pre routing.
We've got pre routing, we've got post routing and we've got other stuff, but pre routing and post
routing, these are the most important ones.
Pre routing simply means if an package arrives at an interface no matter what interface.
So it could be this interface over here or also this interface over here.
Then we are now defining a new rule where we want to route this package.
So this example dot org now arrives at our interface.
This is for example, the USB two Ethernet adapter.
Over here you will see two Ethernet, let's call it let's let's write it in this way.
If it arrives at this interface, we want to change the routing of this package right now.
And this is exactly what we want to have, because instead of going this way, we want to change the
routing to go this way.
Upgrades to our burp suite.
This is the new routing we want to change.
All righty.
So the next parameters are regarding to the package itself.
So we need to be very precise on what type of package we want to reform, what otherwise we will forward
all of them from a specific type, for example, all TCP packages.
And this will be a completely mess.
We only want to forward HTTP packages.
So let's also write this down over here HTP.
Pickett says.
All right.
So these are the only type of packages we want to forewarn.
Alrighty.
Therefore the next parameters regarding to the protocol.
So there's p and then we've got different protocols.
We've got TCP, we've got UDP.
We've got ICMP.
And a lot of more.
Repeated requests are regarding to TCP.
So therefore we only want to forward packages which has the protocol of which are from the protocol
type TCP.
All right.
But by writing it in this way now, every package, every TCP package will be affected by this rule.
This means if the smart phone is making an H connection, internet connection and FTP connection.
Whatever connection the smartphone is making regarding to the TCP protocol, these packages will be
now forwarded.
Therefore, we need to be a little bit more precise on what type of package.
Now we have the protocol TCP.
That's good.
And now we need to define only HTTP packages.
And we can do this by applying a destination port.
So this is the next parameter.
Dash.
Dash de port 80.
So what does this mean?
Our package example dot org.
This one over here.
This has some destination address, which is example dot org.
I mean, that's the that's the DNS name.
But this DNS name gets translated into an IP address.
Beside this IP address.
This package also has a destination port and if you're are performing an HTTP request, the destination
port is most of the time port 80.
Otherwise we have to include this port in our UL.
So for example, like this one over here.
Hmm.
Let's let's clean this up a little bit.
So if you want to make an HTTP request regarding to another port, we have to append this port at the
end.
For example, let's say the HTTP server is not running on port ID, it's running on port 8010.
Then we need to append dot or colon.
Sorry, colon 8010.
Now the destination port is 8010 instead of 80.
But we have to do this manually.
So if we if we do an HTTP request, the destination port will be a default port 80.
All right.
Therefore, by applying this rule over here in destination port 80, we only forward packages which
are regarding to HTTP requests.
So exactly what we want to have here in case if the smart phone is making in request to in different
ports on the port eight for example port 1020.
I mean it can be every port.
It's just the the default behavior for HTTP requests that they run on Port eight.
But let's say the smartphone is making a request to this one over here, and it's also an HTTP request.
Then we need to also at this port to our destination port, and we can do this by simply copy pasting
this rule.
So we copy paste every command in here and instead of destination port eight, we change this to 1020.
Then we also forward all these requests regarding to yea to this destination port to our proxy in later
on.
We can observe this with Wireshark.
So if you run Wireshark, then you sniff the whole traffic the smartphone is generating regarding to
the setup over here.
So you can see every request regarding to at least the IP and the port.
I mean if these packages are being encrypted regarding to sell so hpe's request these are being encrypted
but the IP and port these are unknown to you.
These will be not encrypted in the package.
And by observing the Wireshark traffic, we can simply summarize all this information and then we can
apply all our IP table rules that we forward all these strange, obscure whatever ports you want to
call them to our proxy listener later on.
All right, so now we've got the destination port, and the last thing we need to do is the package
now arrives at this interface.
Let's draw it over here.
So this one arrives now at this interface, which is this one, for example, or also this interface.
And now if it's an HTTP package from type TCP destination Port 80, we want to forward it instead of
going this way.
We want to forward it going this way into our Brexit proxy and then from there also backwards into our
second knot interface and into the Internet over here.
This is the route we want to take.
Maybe let's let's do it a little bit more clearly.
So.
All righty.
And this is exactly what the last parameters in our IP table rules here does.
So we've got the less parameters.
We've got the chain, the net.
The net simply stands for Destination Network Address translation, which simply means switch out the
destination address of this package.
And this is exactly what we want to have if the package arrives at the network interface.
So for example, this one over here, let's say we've got the package regarding to the destination example
dot org.
On TCP port 80.
Now, instead of going this way over here, we want to change the destination address to 1042 0.1.
So it should go the way upwards.
This one over here.
And this is the last parameter we have to provide.
We want to change the destination address to the nation.
1042 and zero one.
And now we also need to provide the port, because this is also included in the destination of this
package over here.
And the port is 80, 80.
And by doing this, we have achieved everything we wanted over here.
So now every HDPE package that arrives at any interface, no matter if it's this or this interface,
they will be now rerouted or the destination address will be changed to the address of our proxy list.
Now over here, which means they will be rerouted to our proxy here, which is listening on 1040 to
0 .1. 88.
All right.
At this point, we are done with our IP tab rules over here.
So we have figured out exactly what this one does.
Maybe let's do one last recap of everything right now.
All righty.
Let's make this a little bit more messy than it already is.
So let's pick.
A good color.
Let's see.
I guess this one is good to notice.
So now let's recap this.
If you're making an HPE request from our smartphone regarding to this address, for example, the package
will be now routed through the router into the USB to Ethernet adapter.
And here we have now our network interface and our IP tab rule established.
Every package that arrives, we have now a pre routing rule, this one over here.
So this means if this package is from type TCP.
Yes, it is.
It is TCP.
And if this package has the destination part 80, it's also true.
Then change the destination address from whatever it is in this package and this one over here to this
destination address.
So to this one over here, which means the package arrives at this interface and it now be it will be
now forwarded to our proxy list now.
I mean, is it still possible to draw here?
Yes.
So we've got this this huge redirection through this proxy list.
But now we've got one problem.
This proxy list now here is not automatically forwarding it back to this one over here, but this is
very burp suite come super handy.
We do not have to change anything in the IP table over here.
This one, it's completely ready.
We can do this within the purpose feed the so it has a mode which is called invisible.
And this mode acts like the burbs with this proxy.
Lesnar is not here, which means the package gets rerouted to the burp suite.
Yes, exactly what we want to have.
But afterwards, the burp suite is rerouting this package automatically to the destination which has
been provided before.
So that's the feature of having an invisible proxy like the burp suite.
We therefore do not have to configure or change or modify anything right now.
The only thing we need to do is we need to set a burp to act as an invisible proxy.
And then we also got the route backwards.
Alrighty, that's all for now.
In the next video, we will set up this proxy list now, which is the burp suite.
It's a super amazing proxy if you want to deal with burp services.
And there we will also take once again a look into this IP table rule over here.
Alrighty.
So I'm looking forward to see you in the next video.