Denial of Service: A frontrunner for software insecurity

In this article, we will be discussing Denial of Service Attacks, which are susceptible in C Programming. Also, We will cover the defensive strategies, attacker perspective with the help of examples and finally conclude with the conclusion. Let’s discuss it one by one. 

Overview :
In today’s world, technology is playing a vital role in our life. And you can see how it’s changing the world as all people can easily connect anywhere in the world. But, we need to focus on security parts also while considering activity is going online like transaction, personal chat, using social accounts. Software developed for public usage is never far away from the threat of being exploited. Be it a login system or a user session which can possibly be the weakest link of the software and is rightfully targeted, causing an application shutdown, undesirable behavior or simply stealing customer credentials.

Unintended creation of attack targets :
As a programmer, a program is built from scratch, and tend to user define data structures and their sizes, which is used to cater to data storage, and processing. The sizes are stated implicitly, indicating that a data structure cannot hold more bytes of data, than it is instructed to hold.

Example –
For example, let us analyze the snippet of code below as follows.

//Example of a login system
#include<stdio.h>

#include<string.h>

int main(void) {
  char A[15];
  int password = 0;

  printf("\n Enter the password \n");
  gets(A);

  if (strcmp(A, "p455w0rd")) {
    printf("\n Wrong Password \n");
  } else {
    printf("\n Correct Password \n");
    password = 1;
  }
  if (password) {
    //This branch gives admin privileges to user
    printf("\n Admin privileges are given to user \n");
  }
  return 0;
}

Analyzing the program :
In this, we will discuss the analysis of the above program. The programmer instructs array A to hold 15 bytes of data, to meet input requirements. This is done in good faith, with the programmer knowing that no one would ever want to fool around with the mechanisms in place. He/she cannot be held responsible, morally. A normal user would just follow the guidelines, enter credentials, gain access and go on with their day.

Understanding the Attacker’s perspective :
An attacker on the other hand won’t be able to screen through the source code of the login system beforehand but can sense that there are possible vulnerable points that could be taken advantage of. Such threat actors are looking for a slight window opening, through which they could apply their exploits and make a system more crippled than it already was. With intention, the input field for the password is spammed, the attacker knowing fully well that it won’t be able to hold so many bytes. This is where compilers should be held responsible. Prior to runtime, compilers do not have buffer overflow checks in place to scan the code. The compiler ironically does not stop to detect errors with the vulnerable data structures. Open-source tools such as StackGaurd and StackSmash can be used to prevent occurring errors

Post-exploitation :
Post-exploitation, there could be a few possibilities that could be observed as follows.

• Application shutdown-Not is able to handle the overflow.
• Undesirable behavior-Infinite Loops, unresponsive and static state displayed by the software.
• Denial of Service-Described in Point 2.

How does it affect a transaction-based service :
In this, you will see how an attacker can play on your weakness is due to limited memory, processing, number of ports, etc. that you will use to provide service. At the server level, your main worry should be to avoid a crash, by imposing self-preservation limits. For example, set a maximum number of connections that you know you can handle and simply refuse any other.

Defensive Strategies :
Going all out, by using specialized materials, like firewalls, can withstand attacks up to a certain extent, but there is always a way to play around them. In this, we must follow the standard practice like security for an account must be enabled to prevent brute-force discovery of user passwords is to lock an account from use after, if someone will input wrong password 3 to 5 times. This means that even if a legitimate user were to provide their valid password, they would be unable to log in to the system until their account has been unlocked. This defense mechanism can be turned into a DoS attack against an application if there is a way to predict valid login accounts.

Conclusion :
Best coding practices are taught to developers during the training phase and are highly encouraged to be applied to software development, but not all of them can be effective and prevent the attack method we discussed. This is one of the failures of Software Development. As mentioned before, attackers play you, based on your weakness. It is up to the developer to make the systems more attack-resistant while hiding weaknesses from visibility and remedying them, from zero-day attacks.