With this section,
we will take a look at how both direct and indirect traffic
replay can be implemented using Python and Scapy.
As noted in our previous section, our indirect example,
we'll be using FTP as our protocol of choice because it allows the
command structure to be obvious to the learner,
but the same logic can be followed with other encrypted protocols.
So let's move back into the demonstration environment for the final time and
take a look at how we can potentially use traffic replay.
The first thing we want to point out is that just to do a simple
replay as we discussed in the earlier section,
all we have to do with Scapy is use the send commands
that we reviewed on an earlier module.
So if we get into Scapy,
all we would need to do is tell it to send a specific list of
packets or tell it to pull in a capture that we've already done
and then use one of these send commands.
So if we wanted to try that, we could.
In this case,
what we're going to do is we're going to use the same exact capture file
we're going to use in our application in a minute.
We're going to load that into the a variable,
and we can see from Wireshark this is basically what's in that capture file.
So this is the authenticating information that you would use in
any of the different utilities you could create.
If we just send this raw, this is what we can expect,
and we'll see all of those packets going out,
but we won't see the remote device actually responding at all
because the session has not been set up with it,
and this is why using it in a simple way like that works really
well if we want to test different devices or appliances in the
middle of the network where you can simulate a whole bunch of TCP
sessions that were recorded live.
But if we want to use it, in our case,
for network security purposes where we want to use part of the capture
and use the authenticating information from that piece,
then we would have to wrap it in a different application
and that's what we're going to show next.
If we move over here in the code,
we'll see at the very beginning all we're doing is
loading in Scapy like we did before.
In this case,
we're also importing the netifaces module in order to format an IP address,
but we'll go through each of these different things here.
So, as our other modules have done,
we start with the main function and our main function starts right here.
We're setting the remote FTP server IP address to 10.10.10.102.
We are setting the local IP address to the IP address that's
currently configured onto the Ethernet 0 interface,
which is where we use that in our module.
We're setting the source port to a random short,
so basically we're making the ephemeral port random,
and then we're setting the initial sequence number
and acknowledgment number to 0.
We then have a variable that we set to true,
which is for debugging which we will get to in a minute,
and then we throw out to a different function,
and then what this function does,
it sets up the initial connection with the remote device.
So in this case, we're handing it the local IP,
the server IP address in the source port and it'll
throw it out to this function.
If we go up to this function,
we'll see that it sets up the sequence number to a random number,
it creates the initial syn packet from the
information that was given to the function,
specifically, to destination port 21,
and this message is where we actually send the
packet out to the remote FTP server.
In this case,
we're using sr1 because we only expect to get the syn ack back from that device.
And that syn ack that's returned is returned into the synack_packet variable.
We then increment the sequence number and the
acknowledgment number appropriately, create a new TCP layer,
we create the acknowledgement packet to the initial syn ack,
and then we send a packet out with the acknowledgement and wait
for an initial response back from that server.
And then what we do is we return that packet that we received back from the
server so it would effectively be the fourth packet total.
So we're returning that packet back to the where the initial function
was run along with the acknowledgement and sequence number information
that we were given from the remote server.
So that information is headed into these three variables.
Next,
what we do is we pull that capture file into memory
that we just reviewed in Wireshark,
which is basically just the username and password login
information into the remote server,
and then we set up a loop variable one that is the total number
of packets that exist within that capture,
which is the replay count,
and then we have a loop variable which is what we're
going to loop on here in a minute.
And here is where we alter any of the different parts of the
packet within the capture that need to be altered to make it
appropriate for our local environment.
So in this case, we're changing the IP address information,
we're changing the sequence number and acknowledgment
information and then the port information,
and then we're resetting the checksums back to nothing so Scapy will
automatically reformulate the checksums based on our new information.
So here is where we start a replay loop.
And in the interest of time,
we'll say that this logic right here is where we run through and send
the appropriate packets back and adjust the appropriate information
within these packets to send back to the server.
We also include a debugging print which shows the packet
as it is being sent to the console.
Now, once that loop has gone through here,
now once that sending piece of the logic is done,
it'll automatically reset these different fields back
to their next appropriate value,
and then we'll loop through this until we no longer
have any packets left in that loop.
And whenever we're all done with all that information,
we will kick out of that loop with the break,
and we'll print out to the screen Replay Complete.
So if we run this, we'll see we have debugging enabled.
So this is the a list of the packets that we're seeing going
through here and we're seeing sent back out.
So in this case, we show the username and the password being sent out.
We see that the server responded back with a 331 and a 230
message saying that the login was successful.
Now this same logic can be used if you are able to get a capture of
traffic from whichever different type of protocol,
and if you can isolate the authenticating piece of that information,
it is possible to use logic similar to this in order to gain access
to a remote device and then further use it as if you were the
original person authenticating into it.
So with that,
we're going to finish up this demonstration and move into our summary.