How do I go about hacking FTP? Part III

Oh boy, this whole series about FTP hacking is really getting long. There's just too much information to cover in just one article. In fact, if you ever have to analyze FTP, I hope that this series will serve as a small compendium on the subject.

• https://resources.infosecinstitute.com/hacking-file-transfer-protocol-part-i/
• https://resources.infosecinstitute.com/hacking-file-transfer-protocol-part-ii/

Now we're nearing the end of the series, so we will be looking at what's really going on in an FTP connection. Then, we will study all the possible places where you can carry out a successful attack on an FTP session. It makes no sense to write a longer introduction so let's get to work.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

How do we determine which port is connected to the FTP?

Why is the specific port important? Because if you determine the connection mode and its type, the port number is the last thing that you need to perform a successful attack.

We have always known that a port is opened for a data connection. If we didn't have a clue, you may be under the impression that it's actually a very difficult thing to discover. But if we look at it practically, it turns out that this is not an insurmountable barrier.

Theoretically, we need to consider only two cases. Sometimes, it so happens that the FTP software is running with administrator privileges. If so, the data connection will always be listed on port 20. However, in any other case, the FTP software uses a temporary port. In case the FTP software is running with administrator rights, you can usually immediately know which port is used to connect the data. However, in the case where the connection uses a temporary port, it's a little more difficult. What can we then do to find it? If we know the mechanism by which they are granted temporary ports, we are really in a position to determine the correct port for the data connection with high probability. Remember those three situations that were presented previously? Following these scenarios, let's try to determine the port number on which the working data connection is.

In the case of web browsers, it is definitely very simplified. After all, the software always uses temporary ports when uploading and downloading web pages. In fact, each of the files that make up a particular web page, no matter whether it is HTML, ,image or sound, it is always downloaded to your computer using separate TCP connections. In this case, it suffices to follow the intruder only from ports which are set to another HTTP connection. Do you know how this turns out in practice? The port that will be used for the data connection will really only be a slightly larger number of the port that was recently used to complete the HTTP connection.

It's a bit more difficult to determine the port number if you're attacking software used to build computational clusters. But as I have often said, there really is no hopeless situation. In fact, the software of this type requires that each computer that's part of a cluster should always share FTP service. This makes things simple. In fact, if an intruder has access to the service and is able to log in, for example, through an anonymous user account, he would then be able to download any file from the server and verify the port that is actually assigned to a data connection. Because of this, he will be able to determine practically 100%, what the next port to be allocated for the data connection will be. Of course, in this case, there is also another method. If we are dealing with an environment in which all FTP connections are assigned very hard, you can try connecting to a random port. In this case, there is really a very good chance that an intruder can still manage to find the actual port.

The third option is, as usual, automatic updates. Here we give you an example that's extremely dangerous, especially for Microsoft users. Now, if the client is a workstation, which practically does not have any services running and very rarely uses the FTP to connect, then as the intruder, your goal should always be to find the server from which the victim will actually download files from automatic updates. Do you know how to do it in practice? The intruder connects briefly, before it gets to the victim, where he is then connected to the update server and can check shortly after which port has been assigned to complete the data connection. If an intruder has this information, you will be able to easily determine which port will be assigned to the victim's data connection.

Of course, all of the examples will be true only for certain circumstances in which a sample can play an attack on the FTP. In fact, for each method listed in this and the previous article, we can safely draw some conclusions and prevent a real DDoS attack. Sometimes, you can just turn on the firewall, or otherwise install software that would prevent port scans or perform changes to the default configuration of the software. In fact, the aim of this series is to show the universal method of attack on the FTP, but each user should be aware that when it comes to practical solutions, we are able to carry out a successful attack on the FTP in any environment in which it is used. It also shows that any intruder is able to get all possible information that's required to perform a successful attack.

How do you start an attack on the FTP?

Finally, we were able to determine when the victim actually uses FTP, what mode is used and which port is used for the data connection. If you have this knowledge, we can now start an attack on the FTP. In fact, the success of this type of attack depends primarily on whether the attackers actually manage to connect with the open port meant for data connection before the actual machine that will participate in the FTP session. That means the aim is to connect to a victim's computer where the FTP service is installed and try to download any file from it. By the way, we need to determine how much time really elapsed since the opening of the port, to the point where the given machine will connect to the other computer.

If you look at how it really is, you can figure out a certain thing. Well, you should be able to see very clearly that in between the opening of the port, to the point where it connects to the server or the client machine, both computers must do a lot of operations. In fact, determining the exact time needed to complete all of these steps is usually a very difficult task, because the final result affects a lot of factors. Of course, in the next section we try to determine the next steps that both machines take when establishing a data connection. Also, we will try to determine how these will affect the intruder and how they can affect the speed of the whole process.

However, remember one thing here. Most of the time in order to manipulate the connection, you have to select only the correct type of denial of service techniques and extended the time period in which the port is open. Note that, in fact, it is possible to extend this period such that the moment will come when the client decides that the server is unreachable and closes the port for the data connection. Also, the possibility of a successful attack increases accordingly with the distance between the data communication machines. This implies one essential fact. An attack on the local network is not really much more complicated than running the same attack in a wide area network.

An in-depth analysis of all the possible places where we can make an attack on the FTP session

Now it's time for the final step, which is preparing for the attack on the FTP session. During the few moments of the FTP transmission period, we are able to affect the duration of the FTP session. We can impersonate a data connection in between this sensitive time.

The first event is the point at which the client sends to the server a PORT command. Everything then depends on the computing power and the actual load of the computer system. The computation takes an average of about 1 - 5 milliseconds. Because the intruder can generate additional burden on a computer system, for example, through intensive use of system resources that are available in the computer, we are able to extend this by almost a hundred times.

Next, the packet travels from the client to the server. This factor is mainly influenced by the network bandwidth, which depends on the speed of connections and productivity devices that mediate the exchange of packets. This takes typically 20 to 2,000 milliseconds. What can an attacker do? Well, you could try to extend the time by trying to overload the connections and all devices that are involved in the transmission, along with an attempt to immobilize them completely by Denial of Service. Then simply extend this time by more than 2,000 milliseconds.

The next event is the server accepts and confirms acceptance of the PORT command. As in the previous case, everything depends on the computing power and the current load on the computer system. This activity lasts from 3 to 10 milliseconds. Here again, the attacker can again try to generate additional load on the computer by very intensive use of available system resources. This time we are able to extend to about 500 milliseconds.

After that, the package starts its journey from the server to the client. Affecting the timing of this trip is the network bandwidth, which combines the speed and performance of all network devices that mediate the exchange of packets. This again takes typically 20 to 2,000 milliseconds. The intruder can then re-start generating additional burden to links and all devices that mediate the transmission of data, including their complete immobilization. If this takes more than 2000 milliseconds, everything starts to fall apart.

After the PORT command is received and responded to, the client sends to our server the command RETR. The rate of response in this case also depends on the computing power and the influence of current load on the computer system. On average, it should take 3 to 10 milliseconds. Here again, an attacker can perform the additional burden of a computer system and extend it accordingly.

Package now begins its journey back from the client to the server, and again it all depends on the speed and efficiency combined of all the devices that mediate the exchange of packets. Average time for this type of connection is 20 - 2000 milliseconds. Attackers may try again to generate additional load that should burden the transmission of data, along with their complete immobilization.

Now it's time for the next action. Our server now will have to check the user's rights to the file. In this case, the storage server's computing power is mostly used as well as the current load on the computer system. The time of the request will usually take from 10 to 1000 milliseconds. A hacker can try to start several transactions in the meantime. Then the response time will be longer for a lot more than 1000 milliseconds. As you can see this is another example of a Denial of Service.

The last stepthat we have to do is to re-connect to the server and connect to the port that the client previously reported using the PORT command. Now we have to deal with typical data connection. Its speed depends on the capacity of the network and at an average of 20 - 2000 milliseconds. The attacker again puts additional strain on the link and device that mediate the transmission of data. In this way it is able to wait for longer than the time the data connection in which it should be connected.

Summary

Become a Certified Ethical Hacker, guaranteed!

Get training from anywhere to earn your Certified Ethical Hacker (CEH) Certification — backed with an Exam Pass Guarantee.

Learn More

After today's article, you should have gained another dose of knowledge about the possible types of attacks on the File Transfer Protocol. You should also have more information about the points at which we can try to attack the FTP session. I do not really want to write an extensive summary of this article, so I will write only of what we have to do in the next part of the series. In the last part, we simulate a real attack on an FTP session. See you then!