The communication that we send from our computer
to other devices on the network will very often
have information that a crafty hacker can use against us.
This might be a session ID, it might be login credentials,
but they want to be able to find the information
in those network flows and be able to use it as an advantage
during an attack.
This means the attacker needs to find a way to gather
that network information.
If they have physical access to the network,
they can physically install a network tap
that will redirect or send a copy of all network traffic
to their workstation.
If they don't have physical access to the network,
then they need to find some logical way
to redirect that information.
And one way they might do that is through something
like ARP poisoning.
Or they might just simply add their own code
or malware onto your computer and they'll
use your computer to gather that information
and then send it back to the attacker.
If the attacker can capture information that can then
be replayed across the network to make
it seem as if it was coming from you,
this is called a replay attack.
And they want to be able to gather session IDs
or credentials and be able to use those credentials later
on across the network.
Although the initial gathering of the information
may involve the attacker being on the path between the two
devices, that's not a requirement
for the actual replay attack.
The replay attack can be done afterwards.
The original user does not even need
to be on the network at that time.
One very simple kind of replay attack is called pass the hash.
This is referring to the hash value that
is associated with a password that is sent across the network
during the authentication process.
If the attacker can gain access to the hash,
they may be able to replay that hash back to the server
and pretend that they are the original workstation.
In our network here, we have three devices.
We have the client device that will be the victim,
we have an attacker that's on the network,
and we have the server that is communicating
back and forth with the client.
During the initial authentication process
where the client sends username and password information
to the server, what's usually sent across the network
is the username and a password hash.
As that information is being sent to the server,
the attacker puts something in the middle of the network.
This might be a redirection of the network
or an ARP poisoning of some kind,
and redirects that hash down to their device as well.
That means that they're going to have a copy
of that hash on their computer.
Now that the attacker has that hash,
they can pretend to be the original user
by sending the username and hash information off to the server
as if they were doing this from the original client's
workstation.
From the perspective of the server,
this looks like a normal authentication
coming from a legitimate user.
And that means that the attacker would then
have access to that user's account on that server.
One way that developers can avoid
this type of pass the hash attack
is to make sure that the client and the server
are always communicating over an encrypted channel such as SSL
or TLS.
If that channel is sending encrypted data,
it doesn't matter what the attacker gathers.
They won't be able to find any of the hash or anything else
inside of that encrypted information.
Another technique developers use is to salt the hash.
They might salt it with the session ID.
And when that session idea is sent across
to the server to authenticate, it's a one time authentication
process.
Even if somebody was to gather that information
across the network as it was being sent originally,
they would not be able to reuse it.
And the replay attack of this kind would not be successful.
This is also why we want to be sure
that the cookies saved in our browser configuration
on our computers are secure.
The browser cookies that are on your computer
may contain information that an attacker
might be able to use for a replay attack.
These browser cookies often have information
that's specific to you.
It may have personalization details or session management
information.
And it usually is something that's
very unique to your sessions that you're
using in the browser.
Not only is there personal or private information that
might be in these cookies, these cookies
can often contain session IDs as well.
And if somebody was to gain access to an active session ID,
they could pose as you when communicating
with another service.
The key to a session hijack or sidejack,
is for the attacker to somehow gain access to the session ID.
When the client first logs into the server,
they are assigned a session ID.
And from that point going forward,
the victim is including that session ID when
communicating with the service.
This means that the user doesn't have to constantly keep logging
in with their username and password
every time they communicate back to that website server.
Instead, they'll simply send the session ID
and that will confirm that the user that's
communicating to the web server has already been authenticated.
If that attacker gains access to that session ID,
they could have used that information
to pose as the victim and communicate directly
to that service without requiring a username
or password.
This is why it's important to use an encrypted protocol
such as SSL or TLS when communicating
across the network, which means that the attackers would
have no way to gather that session ID off of the network
flows.
For this session ID attack to work,
the attacker needs to first get the session information.
They might gather that directly from the network using
Wireshark or Kismet to gather it from the wired
or the wireless networks.
If the server has a cross site scripting vulnerability,
the attacker could use the server
to have session IDs sent directly to the attacker
instead of gathering them from the network.
Once the attacker has the session ID information,
they need to modify the headers that
are being sent to the server and they
might use a third party utility to be
able to do that in real time.
The attacker could also modify their browser cookies
to make them look identical to those that would come
from the victim's computer.
One way to prevent these types of replay and session attacks
is to make sure that all of the communication
between both sides is always encrypted.
They can't capture session IDs if it
happens to be in this encrypted traffic flow.
Turning on encryption on a web server
adds some additional overhead.
But is going to protect all of the data that's
being sent back and forth.
There are some browser extensions
you can get that will force communication
to be HTTPS or TLS, but many sites these days
will only operate as an HTTPS or encrypted channel.
So if you were to go to professormesser.com
you will always be connected over HTTPS.
If you're communicating to a service that doesn't support
HTTPS, or it's using a different type of communication
mechanism, then you may want to use something
like an encrypted tunnel to at least have
part of the communication flow be in this encrypted channel.
That way, if anybody does gather that information
on that encrypted flow, they would not
be able to use any of the information
inside of that network traffic.