Welcome back.
In this chapter, we talk about men in the middle attacks, especially for Android devices.
And this one is absolutely essential because most of the vulnerabilities we encounter in mobile applications,
they are not within the activities, content providers or broadcast receivers.
They are within the network services of the application itself.
There are a lot of different setups on how to perform a man in the middle attack regarding to an Android
device.
But many of them have huge weaknesses.
They act just like a proxy for HTTP and HTTPS requests.
For example, if you go into your Wi-Fi settings, you can define a proxy over here.
And if you insert the IP and listening part of your burp instance, yes, then you have established
a man in the middle connection regarding to your web services.
But you will miss a lot of stuff.
For example, if this application uses age, SQL or MQTT or CIP, you do not see this traffic.
This traffic will be not forwarded to your work and therefore you definitely will miss it.
And this is something we do not want to have.
We want to see all but beside the fact that we miss a lot of stuff, we also do not have control over
the network traffic itself, for example.
We do not have control over DHCP and DNS.
So this is the reason why I choose the different setup and the setup I'm using provides a full control
over DNS, the HCP, and it can also intercept and manipulate every connection the the device is establishing,
for example, if it's using zip, MQTT, S-H, SQL or whatever else.
So this is why I choose this type of setup.
But before we dive into the setup and let's first talk about men in the middle attacks itself.
So what is the man in the middle attack?
And to be honest, I do not have an official description for this right now, but this attack simply
means we are the man in the middle of a connection.
So in between two devices.
In most cases it means we are in between the connect.
In most cases it simply means we are in the connection of a router and a network device, for example,
a smartphone.
If we are in between this connection, we can analyze, sniff and also manipulate these packages if
they are not being encrypted.
We talk about SSL later on, but for now let's focus on main in the middle itself.
So now we know what the man in the middle attack is, but how can we establish such a connection?
There are a lot of different setups out there, but we focus now on the most basic one the app cache
poisoning attack.
But don't worry, app cache poisoning is not part of our menu in the middle set up later on.
This is just a good example to get familiar what an men in the middle attack is and how it works.
This is why I picked it as an as an example out here.
All right, so before we can understand how an app cache poisoning attack works, we need to understand
how client A is communicating with client B.
So what is happening on the line that these two can communicate with each other?
There has to be some exchange of information, and this is something we take a look on right now.
But don't worry, we do this on a very high level and we do not go too deep into detail.
All righty.
So let's switch back to the slides.
All right.
So here we have our basic network setup.
We've got the router, we've got two laptops and a mobile device which is connected via wi fi.
Every device has a network card and this network card has a mac address.
This is a unique identifier which is branded into your card.
So this MAC address only exists once.
There will be no duplicate of this number over here.
A mac address consists of six bytes and the first three are regarding to the vendor ID and the last
three are regarding to make this make this MAC address unique.
So this means we can theoretically run out of Mac addresses.
We have a number from two square six times eight, which is.
Well, it's quite a lot.
So even by having now all these Iot devices, connected cars and all this kind of stuff, we do not
run out of Mac addresses very soon.
This is something we do not need to worry about right now.
Besides this Mac address, there's also an IP address, and this is something that is being assigned
by a HCP or STATICALLY.
So in our case, we have a router which is running an DHCP service and this router is providing IP addresses
to every connected client.
In our case over here we have a class unit, which means we've got 192.168.1 and then we can provide
IP addresses to connecting hosts from two up to 245.
The rest is being reserved for broadcast and gateway and other stuff.
All righty.
So this is a recap of networking on a high level.
Now, let's say decline over here.
This one, this is client eight.
And Klein A wants to send a message to Klein.
Be over here.
Client eight knows the IP address of Plan B and this one is dot 14.
But what client does not know is the Mac address, and this is also absolutely essential to prepare
this package.
We have an Ethernet frame, and this Ethernet frame needs to have the MAC address of the destination.
Host So how can we get this MAC address?
And this is where OP kicks into app is the address or resolution protocol and it has different type
of codes.
One is, for example, the app request and app request is simply a network package which is asking for
who has this address.
And this kind of package is now being crafted by client eight and it's being sent into the whole network.
So to the router and the router is broadcasting this into the whole network.
This package is now being broadcasted and it receives the smartphone via wi fi.
The smartphone is taking a look into this package and replies with, No, this is not me.
Klein B also receives this package and is also extracting these information and realizes, Oh, that's
me.
So Client B is now preparing an app reply package.
This app reply package contains the IP address and also the MAC address of this client of Client B packed
with these information.
This package is now being sent back to Client A.
Planned every assistance package takes a look into this and now checks out.
I've got the IP address, but now also the MAC address of client B and client A is also very lazy.
So Client A do not want to ask for this over and over again.
Therefore, Client A is saving these information in something called app cache.
This is the resolution of IP address and MAC address.
So the next time client A is sending a message to client B, client A does not have to ask for this
once again.
So Client A is simply taking a look into its internal app cache and realizes, okay, this is to make
up of client B and this is the address I have to use in my Ethernet frame to to wrap this around my
package.
Okay.
So this is how the exchange of information works on a very high level.
After getting those information, client A is now able to communicate with Client B and can simply prepare
a message and send it to client B.
This package is now being wrapped into an Ethernet frame, and this Ethernet frame contains the destination
IP and also the destination MAC address, which is now known by client A.
Okay.
So far so good.
But what if your PC breaks?
For example, you have been caught cheating on a huge LAN party and your PC will be thrown out of the
LAN and completely breaks into single pieces.
Your network had absolutely gone.
This means your network card is not available anymore.
The client still has this reference in its app cache.
So regarding to this IP address and this MAC address.
And now let's also imagine a new client is joining the network and the router is recycling the IP address
of the other client.
So the new client has of course also a mac address.
But this is not different from the other one because Mac addresses are unique and the client now receives
the IP address from the previous client.
So in this case the app cache is now invalid.
How can we fix this issue?
Well, after Client A has tried several times to connect to Client B and it's not available anymore,
Client A is performing the same approach once again.
So Client A is preparing an app request and sends it out into the network.
Client A is asking for who has this IP address.
Please tell me your Mac address and this package gets broadcasted into the network.
The smartphone still responds with No, it's not me, but it actually sends no package.
This is just information for us that it's not the smartphone right now.
There will be no no package regarding to an app request but client see who has notice.
IP address responds with the MAC address of its own.
So client C is responding with an app reply package and this one now contains the IP address and also
the new Mac address of the client.
Right now, this package will be sent to client a.
Client receives this package and also updates its internal application.
So the old address will be deleted and the new one will be inserted.
And this is how an app cache gets updated.
And this is a very, very important step regarding to a man in the middle attack, regarding to app
cache poisoning, because the address or resolution protocol has been developed in 1980 something.
So I'm absolutely not sure when exactly.
But during this time, no one has thought about security in the protocol like this.
And this is where the vulnerability relies in the app protocol itself.
And this is something we are going to investigate right now.
So how can we take advantage of this of this type of tech on updating an app cache?
Well, we will find out right now.
All right.
So now is the question, how can we abuse this as an attacker?
How can we get into this connection in between the smartphone and the router right now based on our
packages?
So here we have the smartphone with the top ten address and we also got the router which has the DOT
one.
So the router also acts as a gateway.
This connection has been established and both devices have created their own app cache.
So the smartphone has the app cache for this router with this mega press.
And also the router has created its own app cache for the smartphone.
So with the MAC address of the smartphone, okay.
Now the attacker exited, the app cache has been set up and he is the attacker right now.
The attacker also joins the network and receives an IP address.
But this is not the most important part.
The most important part is that the attacker is now creating an app reply package.
Yes, you are absolutely right.
And app reply package not on request in reply.
And this package contains now the address of the router and now they are sticking to the attacker is
filling this package with the Mac address of the attacker itself.
So not with the MAC address of your router and this package will be now forwarded to the client.
So to the smartphone, the smartphone is now receiving this package, but the smartphone says, well,
I didn't ask for this, so please don't bother me with this, but we keep sending it over and over again.
And based on the protocol itself, there is no kind of authorization or authentication or whatever.
So by replying this package over and over again, after a while, the smartphone accepts it and will
update the app cache for this entry.
The device now thinks that the attacker is the real gateway for the traffic from the smartphone is now
being forwarded to the attacker, and that's all the attacker has to do.
The attacker simply has to flood the mobile device with a lot of app reply packages.
And this is the, let's call it vulnerability in this protocol because in reply package doesn't require
a request before and this means we can simply create in reply package without having a request from
this client over here and by replying this package over and over again, the app cache entry in this
device gets updated regarding to the present Mac address.
For, right?
And that's all.
This is how we can establish a man in the middle connection.
So as an example, the smartphone right now is opening a Web page, for example, let's say example
dot org.
We will learn how to deal with this later on.
So how we can create our own certificates, apply them to the device and also intercept SSL traffic.
But for now we want to focus on men in the middle, a text regarding to OP cash poisoning and therefore
we do not need to make it more complex than it really is.
All right.
So the client is now opening or trying to open the website example dot org.
And this is now being crafted as a package.
So as an HTTP package, the client, the smartphone in this case is forwarding this to the router,
but not to the real one, to the attacker, because the smartphone thinks that this is the gateway right
now.
The attacker receives this package and can now analyze and also manipulate it.
So, for example, if there are some user credentials in there or the attacker can also send a different
type of request to the original systems, stuff like this.
So we are now within a man in the middle position.
Right now, all you need to do is to forward this to the real router and update the Ethernet frame.
We skip this part right now, but yeah, this is not a big deal.
Okay, so the package has been arrived at the router and the route has now forwarding this into the
internet.
Two example dot org.
Example dot org is now replying to this package and it's sending the response regarding to this HTTP
request.
The router now checks the package and the package is now for our attacker machine because the attacker
has replaced all the necessary frames, for example, the Ethernet frame.
So the router is forwarding this package right now to the attacker.
The attacker can then inspect that once again and also manipulate the response.
For example.
Yeah, insert some hidden form fields and check JavaScript keyloggers stuff like this.
After performing this type of action, the attacker now only needs to forward this package to the original
source, the smartphone itself.
But the smartphone doesn't even realize that this one has been not routed through the original gateway.
It has been routed to the machine of the attacker.
So the smartphone takes this package and renders it in its browser because it's the response of the
original HTTP request.
Therefore, for the smartphone, everything is fine.
The attacker is also happy.
And the gateway, I mean, the gateway also didn't realize that this package has been originally sent
from the smartphone itself.
So for every device in this connection over here, it seems to be fine how this request has been handled.
All right.
So this is how men in the middle attack works.
But as already mentioned, this attack also has a lot of weaknesses.
For example, we need to plot the entry of the smartphone permanently because it could happen that the
the original gateway gets back into the app cache by providing new packages.
Therefore, we have to permanently send these app reply packages, which causes an overload and we will
definitely miss some packets of the smartphone itself.
So therefore, if you do not have control over device in this network over here, then yes, this might
be the only solution.
There are some other possibilities, for example, like DNS spoofing where we just answer faster than
the original name server and things like this.
But most of the time it's the same approach.
But yeah, all of them are not super reliable.
So it might be the case that the device changed back the connection, and this might be just for some
few requests until we get it back again.
But these few requests will be missed in our traffic and this is something we do not want to have if
we analyze the system.
Therefore, we have a different setup and this is something we take a look into in the next video.
If you have any questions regarding to app cache poisoning, then spoofing or other type of man in the
middle attacks, then please write me a message.
I'm super happy if I receive feedback on certain topics.
And yeah, if you stuck at the point, I try my best to help you out on this.
All right.
Okay.
In the next video, we take a look at a different type of setup.
And this setup gives us full control over the whole network and also the traffic in this device without
permanently flooding this device with malicious packages.
Therefore, I'm really looking forward to see you in the next video.