#include 
#include 
#include 
#include 
#include 

#define BANNER \
  "Welcome to " LEVELNAME ", brought to you by https://exploit.education"

struct auth {
  char name[32];
  int auth;
};

struct auth *auth;
char *service;

int main(int argc, char **argv) {
  char line[128];

  printf("%s\n", BANNER);

  while (1) {
    printf("[ auth = %p, service = %p ]\n", auth, service);

    if (fgets(line, sizeof(line), stdin) == NULL) break;

    if (strncmp(line, "auth ", 5) == 0) {
      auth = malloc(sizeof(struct auth));
      memset(auth, 0, sizeof(struct auth));
      if (strlen(line + 5) < 31) {
        strcpy(auth->name, line + 5);
      }
    }
    if (strncmp(line, "reset", 5) == 0) {
      free(auth);
    }
    if (strncmp(line, "service", 6) == 0) {
      service = strdup(line + 7);
    }
    if (strncmp(line, "login", 5) == 0) {
      if (auth && auth->auth) {
        printf("you have logged in already!\n");
      } else {
        printf("please enter your password\n");
      }
    }
  }
}

Esta prueba muestra la vulnerabilidad que puede haber en memoria.

Nota importante: Cada vez que hago esto, coloco intrucciones a gdb que creo son muy necesarios, ya que cada que el debugger abre una aplicación, lo hace en un espacio de memoria relativa y al colocarle, unset env LINES y unset env COLUMNS, GDB muestra el uso de memoria real o muy cercano al que usa realmente la aplicación, facilitando la explotación de la vulnerabilidad.

Ejecutamos la aplicación para ver que hace.

Hagamos un prueba rápida con los datos que ahí menciona.

Al parecer al escribir auth junto con un dato, muestra una modificación, veamos como esta en código máquina.

Al parecer malloc abre un espacio en memoría, después lo llena de ceros com memset, si lo verificamos en el código de arriba, podemos ver que en efecto, eso hace, pero además analiza la longitud y verifica que sea menos de 31, después mete en la estructura lo que fgets recibio y aumentan en 5 para eliminar auth y solo guardar la información recibida.

Veamos que pasa si metemos más datos.

Al parecer nada cambio, eso significa que no importa la longitud, pero hay algo interesante, al final encontramos un 0x0000000a, así que pongamoslo a prueba.

En la primera prueba solo encontramos un camino hacia un petición de contraseña.

Pongamos los datos exactamente igual, pero con B, unicamente para diferenciar al analizar la prueba.

Bien, se logró, pero... ¿porqué?, veamos que pasó.

Como pueden observar, reset usa free, el cual no borra de memoría los datos inmediatamente, los guarda en la pila para liberar el espacio, por esa razón, cuando observamos el debuger, la comparativa de la cantidad de bytes más el ultimo byte que es un 0x0000000a es igual a los nuevos datos que metimos después, y en está ocasión la vulnerabilidad está en que la comparativa detecta los nuevos datos con los que free guardó en memoría y por esa razón nos da acceso

Listo.