Denegación de servicio: un favorito para la inseguridad del software

En este artículo, analizaremos los ataques de denegación de servicio , que son susceptibles en la programación C. Además, cubriremos las estrategias defensivas, la perspectiva del atacante con la ayuda de ejemplos y finalmente concluiremos con la conclusión. Discutámoslo uno por uno. 

Resumen:
En el mundo de hoy, la tecnología está jugando un papel vital en nuestra vida. Y puede ver cómo está cambiando el mundo, ya que todas las personas pueden conectarse fácilmente en cualquier parte del mundo. Pero también debemos centrarnos en las partes de seguridad al considerar que la actividad se realiza en línea, como transacciones, chat personal, uso de cuentas sociales. El software desarrollado para uso público nunca está lejos de la amenaza de ser explotado. Ya sea un sistema de inicio de sesión o una sesión de usuario, que posiblemente puede ser el eslabón más débil del software y está correctamente dirigido, lo que provoca el cierre de la aplicación, un comportamiento no deseado o simplemente el robo de las credenciales del cliente.

Creación no intencionada de objetivos de ataque:
como programador, un programa se construye desde cero y tiende a que el usuario defina estructuras de datos y sus tamaños, que se utilizan para atender el almacenamiento y procesamiento de datos. Los tamaños se establecen implícitamente, lo que indica que una estructura de datos no puede contener más bytes de datos de los que se le indica que contenga.

Ejemplo:
por ejemplo, analicemos el fragmento de código a continuación de la siguiente manera.

//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;
}

Analizando el programa:
En esto, discutiremos el análisis del programa anterior. El programador le indica a la array A que contenga 15 bytes de datos para cumplir con los requisitos de entrada. Esto se hace de buena fe, con el programador sabiendo que nadie querría perder el tiempo con los mecanismos en su lugar. Él / ella no puede ser considerado responsable, moralmente. Un usuario normal simplemente seguiría las pautas, ingresaría las credenciales, obtendría acceso y continuaría con su día.

Comprender la perspectiva del atacante:
Un atacante, por otro lado, no podrá filtrar el código fuente del sistema de inicio de sesión de antemano, pero puede sentir que existen posibles puntos vulnerables que podrían aprovecharse. Dichos actores de amenazas están buscando una pequeña ventana que se abra, a través de la cual podrían aplicar sus exploits y hacer que un sistema esté más paralizado de lo que ya estaba. Con intención, el campo de entrada de la contraseña se envía como spam, ya que el atacante sabe muy bien que no podrá contener tantos bytes. Aquí es donde los compiladores deben ser responsables. Antes del tiempo de ejecución, los compiladores no tienen controles de desbordamiento de búfer para escanear el código. Irónicamente, el compilador no se detiene para detectar errores con las estructuras de datos vulnerables. Se pueden usar herramientas de código abierto como StackGaurd y StackSmash para evitar errores.

Post-explotación:
Post-explotación, podría haber algunas posibilidades que podrían observarse de la siguiente manera.

• Cierre de la aplicación: no puede manejar el desbordamiento.
• Comportamiento indeseable: bucles infinitos, estado estático y que no responde mostrado por el software.
• Denegación de Servicio-Descrito en el Punto 2.

¿Cómo afecta un servicio basado en transacciones?
En este, verá cómo un atacante puede jugar con su debilidad debido a la memoria limitada, el procesamiento, la cantidad de puertos, etc. que usará para brindar el servicio. A nivel de servidor, su principal preocupación debería ser evitar un bloqueo imponiendo límites de autoconservación. Por ejemplo, establezca un número máximo de conexiones que sepa que puede manejar y simplemente rechace cualquier otra.

Estrategias defensivas:
hacer todo lo posible mediante el uso de materiales especializados, como firewalls, puede resistir los ataques hasta cierto punto, pero siempre hay una forma de evitarlos. En esto, debemos seguir la práctica estándar, como que la seguridad de una cuenta debe estar habilitada para evitar el descubrimiento por fuerza bruta de las contraseñas de los usuarios, es bloquear una cuenta para que no se use después, si alguien ingresa una contraseña incorrecta de 3 a 5 veces. Esto significa que incluso si un usuario legítimo proporcionara su contraseña válida, no podría iniciar sesión en el sistema hasta que su cuenta haya sido desbloqueada. Este mecanismo de defensa puede convertirse en un ataque DoS contra una aplicación si existe una forma de predecir cuentas de inicio de sesión válidas.

Conclusión:
las mejores prácticas de codificación se enseñan a los desarrolladores durante la fase de capacitación y se recomienda encarecidamente que se apliquen al desarrollo de software, pero no todas pueden ser efectivas y prevenir el método de ataque que discutimos. Este es uno de los fracasos del Desarrollo de Software. Como se mencionó anteriormente, los atacantes juegan contigo, en función de tu debilidad. Depende del desarrollador hacer que los sistemas sean más resistentes a los ataques mientras oculta las debilidades de la visibilidad y las soluciona de los ataques de día cero.