Security Problems in the TCP/IP Protocol Suite

0
953
Security Problems in the TCP/IP Protocol Suite

There is no wonder that TCP/IP protocol has some old issues that attackers gladly exploit whenever they can. Unfortunately, these flaws are inherent to the nature of this protocol, and it is so widely used today that it’s impossible to just cure all systems from these security holes once and for all.

The least that we can do, however, is to be aware of the common problems in order to set the proper security controls and make sure we can detect when someone is trying to mess with our networks.

Below we take a brief look at the most common (and annoying) problems of TCP/IP protocol suites. Of course, all security specialists are aware of them. By using the collaborative cyber defense approach available by MITRE ATT&CK mapping at SOC Prime’s Detection as Code platform, it’s easy to maintain a constant flow of accurate detections.

And by using tools such as Uncoder.IO, it’s easy to instantly convert Sigma-based rules into vendor-specific formats, thus making sure that your detections are spread across the entire network. Nevertheless, it’s important to watch the attackers 24/7 and have some playbooks at hand that can quickly remediate these common and still so popular attacks.

Spoofing Attacks

If there is one type of attack that is attackers’ all-time-favorite, it’s spoofing. They want to create fake (aka spoofed) IP packets from fake addresses to leverage DoS and mask the addresses that they actually use. To do that, adversaries manipulate vital information in TCP headers, such as the source and destination addresses.

Security Breach Hacker Cyber Crime Privacy Policy Concept

Non-blind spoofing is performed on a victim’s subnet. In this case, the attacker can sniff the sequence and acknowledgment values, which makes it possible to calculate them and perform a session hijacking. In blind spoofing, which is a more advanced technique, those values are unreachable.

By sending test packets, the attackers are able to discover the formula for generating sequence numbers and establishing TCP sessions. If the sequence number is generated correctly, they send data to the target machine, impersonating a trusted host and enabling access to the compromised system.

The attacks described above are also known as the man-in-the-middle attacks (MITM). The goal of such an attack is to stand in between the normal communication between the server and host, thus controlling and altering the legitimate information without the awareness of two trusted parties.

If adversaries perform a DNS spoofing, they commonly use the legitimate server to reroute domain names to malicious IP addresses that contain malware or initiate the loading of worms and viruses.

TCP Denial of Service

The usual TCP handshake is quite resource-hungry because it wants the server to maintain a connection for each SYN request that comes in. So the server has to maintain tables full of rows of information: one for each client.

As a result, if the attacker initiates multiple connection requests (SYN, which stands for Synchronize, the first stage of a three-way handshake) from many clients at once, the memory will overflow with rows and fail to accept any further incoming requests. To leverage that attacks, usually, fake IP addresses are being used.

Another alternative for adversaries is to forge the reset requests of the valid connection, thus also provoking denial of service. Worse yet, the actions after sending the SYN requests make the DoS attack more likely.

If the malicious client receives the second handshake (SYN-ACK), it never returns the third handshake (ACK). Thus, the server has to wait for the acknowledgment while maintaining this probable connection that, in actuality, will never happen. Otherwise, the attacker never receives an ACK-SYN request if the IP address is spoofed.

In this situation also, the server will wait for the handshake series to close, making the half-open connections pile up and causing the denial of service. Such a type of attack may even cause the server to crash for good.

Usually, this type of DDoS is quite noisy because all the connection attempts are perfectly visible in SIEM systems. On the other hand, they might be difficult to detect because, at the network and transport layers, most malicious requests look just the same as legit ones, so servers typically don’t recognize when something is wrong with the client.

Port Scanning

An It Professional Is Striving To Safeguard a Network Against Cyberattacks

Port scanning is a preliminary phase to performing an actual attack. The initial goal of adversaries is to discover vulnerable ports which can potentially be compromised to establish an exploitable communication channel. So, how do they find out which ports are vulnerable?

The thing is, some services use variable port numbers. For example, an application server listens to an arbitrary port and assigns this port number to a specific server, which is decided by a directory service. For each client, the directory server will assign a specific port number to connect with the application server.

Asking the directory server which port number is responsible for what clients and servers is obviously a bad idea for the attacker because, as a rule, all directory services are well-protected. So they try to establish a connection with a listening TCP server.

If the port is working, the UNIX system will accept the “connect()” request. If the port is inactive, the connection will fail. Other ways of port scanning include sending SYN packets, FIN packets, and ARP scans.

By scanning the ports, attackers can potentially get access to specific information about the victim’s system. For instance, the list of currently running services, users who own those services, authentication type details, and more.

For security specialists, it’s important to notice if there are any port scanners on their network to prevent attackers from performing initial access. The latest research shows that nearly 100 vulnerabilities were found in various TCP/IP stacks over a time period of 18 months. This shows that no matter how old are TCP/IP problems and no matter how much you know about them already, there are still numerous attack vectors that you might be missing.

So it’s better to make sure that you have a continuous flow of new detection rules to always stay in the know and stay ahead of the attackers.