When we communicate to a web server,
we're usually assuming that our local workstation and the web
server are the only two devices involved in this conversation.
But attackers have realized that they
can get in the middle of this conversation.
They can not only see what you may be sending back and forth,
but they may be able to modify it as it's
being sent across the network.
We used to refer to this as a man-in-the-middle attack.
You'll commonly see it now referred to
as an on-path attack.
An on-path attack works by having an attacker sit-in
the middle of the conversation, and they
can redirect the traffic as you're sending it back
and forth to another device.
From your perspective, everything is working normally.
You're sending information out to the web service,
and the web service is sending information back to you.
You have no idea that in the middle of this conversation
is a third party who's intercepting
that communication.
On a local subnet, one simple way to have an on-path attack
is through the use of ARP poisoning.
ARP is the address resolution protocol.
And because there's no security built in to ARP,
we're able to manipulate where certain devices can
send traffic.
Let's look at how ARP works on a normal network configuration.
Let's say we've got a laptop, and it
needs to communicate outside of our subnet.
So it needs to find the MAC address of the local router.
The only thing this laptop knows is that the local router's IP
address is 192.168.1.1.
So your laptop will send a broadcast
to all devices on the network.
This broadcast has a single message inside of it
that says, if you happen to be 192.168.1.1, please respond
back with your MAC address.
Obviously our router is on this network.
It does have the IP address of 192.168.1.1,
so it's going to respond back to that ARP request,
saying that I am 192.168.1.1, and here is the MAC address
associated with my IP address.
When your laptop receives that message,
it makes a note of that MAC address
and stores it into a local cache.
This means that it doesn't have to keep sending out an ARP
request every time it wants to communicate to 192.168.1.1.
It simply uses the MAC address that already
exists within its cache.
On most networks, this is the process
that occurs whenever a device needs to communicate
to a third party.
And if you look at the local ARP cache on your computer,
you'll find a number of local IP addresses
and the MAC addresses associated with those.
But an enterprising attacker can also take advantage of this.
Let's say that we have an attacker on this network
of 192.168.1.14, and you can see the MAC address associated
with this device aa bb cc dd ee ff.
If this attacker would like to get
into the middle of this conversation,
it can simply pretend to be the router.
So the attacker will send out an unsolicited ARP response that
says, I am 192.168.1.1, which normally would be associated
with the router, and my MAC address
is the MAC address associated with the attacker's device
or aa bb cc dd ee ff.
When that ARP response is received by the laptop,
the laptop says the ARP has changed.
Something is different.
Let me update my ARP cache, which has the same IP address.
But you can see now that the ARP cache
has a completely incorrect or spoofed MAC address.
This attacker can perform that same ARP poisoning
to the router, and now everything
that is sent back and forth between these devices
must pass through the attacker's device.
If you want to perform an on-path attack to devices that
are not on your network, one way that you could do this
is through the use of DNS poisoning,
where you modify the entries that are inside the DNS server.
This obviously requires someone to have
the skills to be able to break into the DNS server
and make that change.
But if you can modify those DNS files,
you can redirect people to whatever IP address you'd like.
If you're trying to change where one particular device may
be communicating, you don't have to change the DNS server.
You can simply modify the local host file that's
on that particular client.
This usually causes antivirus and anti-malware systems
to throw a message saying that someone's
trying to manipulate one of these very important files that
are on your system.
But if you can find a way to modify that client's host file,
you can effectively redirect it to any IP address you'd like.
And a third way to poison a DNS conversation
is to simply send fake response to DNS requests
that are being made.
Normally, we're expecting a DNS response
to come back from the DNS server.
But if someone can sit-in the middle of the conversation,
they can block the legitimate DNS reply
and send their own DNS reply with whatever information
they'd like.
Let's take the first example where
someone modifies the configuration of an existing
DNS server.
You can see that professormesser.com
is configured in this DNS server with 162.159.246.164.
And when a user makes a DNS query to the DNS server asking
for the IP address of professormesser.com,
that information is provided back to the user,
and that IP address is saved in the local DNS
cache on that user's computer.
A skilled attacker, however, could gain access
to the DNS server and change what configurations
may be inside of that service.
So it might change the IP address of professormesser.com
to be 100.100.100.100, which by the way also matches the IP
address of the attacker.
We're assuming that the attacker would
like all of the messages that would normally
be sent to professormesser.com to be sent to the hacker's
device instead.
This means that any subsequent requests to the DNS server
will be responded back with the poisoned or spoofed IP address,
and everyone else who tries to gain their IP
address from that service will end up
getting the IP address of the attacker.
There are many different ways for an attacker
to gain access into these conversations
and perform an on-path attack.
You might see session hijacking, HTTPS spoofing, or something
as easy as eavesdropping over the Wi-Fi connection
to cause this on-path attack.
In almost all of these situations,
you can avoid these types of on-path attacks
by simply using encryption.
If the attacker can't see the information contained
within the packets, then obviously your data
will remain safe, and an encrypted connection
can't be modified so an attacker would not
have a way to inject their own data into your existing data
flows.