#include "../common/common.c"    

int fix_path(char *path)
{
  char resolved[128];
  
  if(realpath(path, resolved) == NULL) return 1; 
  // can't access path. will error trying to open

  strcpy(path, resolved);
}

char *parse_http_request()
{
  char buffer[1024];
  char *path;
  char *q;

  printf("[debug] buffer is at 0x%08x :-)\n", buffer);

  if(read(0, buffer, sizeof(buffer)) <= 0)
    errx(0, "Failed to read from remote host");
  if(memcmp(buffer, "GET ", 4) != 0) errx(0, "Not a GET request");

  path = &buffer[4];
  q = strchr(path, ' ');
  if(! q) errx(0, "No protocol version specified");
  *q++ = 0;
  if(strncmp(q, "HTTP/1.1", 8) != 0) errx(0, "Invalid protocol");

  fix_path(path);

  printf("trying to access %s\n", path);

  return path;
}

int main(int argc, char **argv, char **envp)
{
  int fd;
  char *p;

  background_process(NAME, UID, GID); 
  fd = serve_forever(PORT);
  set_io(fd);

  parse_http_request(); 
}

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.

Lo primero es ver el código, de igual forma se puede intentar crashear el programa, por primera información, es peticiones HTTP y aqu hay detalles que hay que poner atención para poder mandar un exploit.

*Petición

*Datos

*Protocolo

Una petición general sería GET /index.html HTTP/1.1

Podríamos hacer un escaneo a los puertos, pero tenemos un acceso al servidor, así que verifiquemos los procesos y busquemos level00 junto con aux para detallar la información y usemos grep para solo mostrar la información más exacta.

Dato interesante, puerto 20000, proceso para atacar 1378, esto puede cambiar dependiendo los intentos de acceso, lo que significa que utiliza un fork o threads para funcionar.

Mandemos una petición para ver si todo funciona bien, de preferencia con python2.

Pues bien, configuremos a GDB para que se vea en modo intel, haga un seguimiendo a los procesos child y ataquemos el proceso, recordar que esto puede cambiar dependiendo los intentos fallidos, lo recomendable es solo atacar el proceso, darle seguir con la tecla c y volver a atacar el mismo PID del proceso, sino, solo es cuestion de abrir otro tty y volver a buscar el proceso con ps.

Mandemos datos al azar, es recomendable usar metasploit para hacer más sencillo la busqueda del overflow, pero no lo tengo instalado, así que mande datos hasta atinarle al fallo.

Ahora busquemos en donde inicia el buffer.

Podemos ver donde inicia el overflow, veamos que pasa, hay que recordar agregarle al final \xcc para que se detenga la ejecución y nos muestre un SIGTRAP, al azar le puse *90... cometí el error de cerrar gdb, así que cambío un poco el buffer, pero no es mucho, solo una pequeña diferencia, no hay problema con la ubicación.

Sin embargo, solo nos aparece un error de segmento, pero no lo que buscamos

Pero, ¿cómo lo arreglamos?, sencillo, hay que recordar que mandamos datos que pueden sacar del buffer a \xcc, si quitamos los datos de "GET " son 4, porque es GET+espacio, menos los 139 A's, menos el offset, menos "HTTP/1.1 " que son 9... HTTP/1.1+espacio.

156 en hexadecimal es = 9C.

Volvamos a intentarlo.

Listo.

Como detalle extra, se puede usar una shell remota en x86