Switch to full style
Todo lo que tengas que decir sobre Gnu/Linux y SSOO alternativos.
Publicar una respuesta

Modificar la salida del comando uname -a

Lun Nov 10, 2008 9:13 pm

Buenas Wadalbertitas!

Tengo un pequeño "reto" para vosotros (que también a mi me lo plantearon):

Sabéis algún modo de modificar la versión del kernel que te da el comando uname?


Las especificaciones del "reto" son las siguientes:
- No recompilar el kernel
- No añadir un ejecutable llamado uname a /bin/ que haga lo que quieras


He estado buscando en google, pero la verdad es que es complicado de buscar algo que no te hable de recompilar el kernel!

Gracias!

Lun Nov 10, 2008 9:21 pm

Ahora mismo conforme tengo las cosas, casi que no me la voy a jugar. Pero vamos, supongo que modificando directamente el fichero que contiene el núcleo no creo que haya demasiados problemas.


Si comparas el resultado de la salida de estos comandos, se ve que no hay mucha diferencia:

Código:
root@server:~# uname -a
Linux kagate 2.6.18-6-amd64 #1 SMP Mon Jun 16 22:30:01 UTC 2008 x86_64 GNU/Linux


Código:
root@server:~# strings -n 10 /boot/vmlinuz-2.6.18-6-amd64 | grep -i 2.6.18
2.6.18-6-amd64 (unknown@Debian) #1 SMP Mon Jun 16 22:30:01 UTC 2008



Supongo que irá por ahí la cosa

Lun Nov 10, 2008 11:51 pm

Respuesta rápida: LKM, hooking de la función sys_uname, llamada a la original y modificación del contenido ;)

Un poco más elaborado: Programas un módulo para el kernel que al cargarlo busque la syscall table (hay varias técnicas para ello... antes se exportaba el símbolo pero prácticamente solo lo usaban rootkits 8-) ), y 'apunte' la dirección de la syscall correspondiente a uname. Luego se modifica esa entrada en la syscall table por una nueva dentro de tu módulo.

Esta función tendrá que llamar a la función original, obtener sus datos y cambiar lo que le plazca. Luego se devuelven al espacio de usuario et voilá.

Si la encuentro, en un rato subo a algún sitio una presentación sobre rootkits para linux básica que hice hace un tiempo para un cursillo de administración y seguridad de servers linux :)

EDIT: Aquí está... es muy cutre pero da una idea de cómo van jejeje

Mar Nov 11, 2008 12:13 am

Mmm,supongo que será trampa, pero qué tal un alias?;)

Mar Nov 11, 2008 1:48 am

TuXeD escribió:Respuesta rápida: LKM, hooking de la función sys_uname, llamada a la original y modificación del contenido ;)

Un poco más elaborado: Programas un módulo para el kernel que al cargarlo busque la syscall table (hay varias técnicas para ello... antes se exportaba el símbolo pero prácticamente solo lo usaban rootkits 8-) ), y 'apunte' la dirección de la syscall correspondiente a uname. Luego se modifica esa entrada en la syscall table por una nueva dentro de tu módulo.

Esta función tendrá que llamar a la función original, obtener sus datos y cambiar lo que le plazca. Luego se devuelven al espacio de usuario et voilá.

Si la encuentro, en un rato subo a algún sitio una presentación sobre rootkits para linux básica que hice hace un tiempo para un cursillo de administración y seguridad de servers linux :)

EDIT: Aquí está... es muy cutre pero da una idea de cómo van jejeje


Joder con el TuXeD... diría que se me ha adelantado... pero varios años-luz... :lol:

Yo me había bajado los sources de coreutils para ver el código del uname, luego he visto que se sirve de una estructura utsname para mostrar todos los datos, he estado mirando bits/utsname.h y sys/utsname.h, y quería ver si llegaba a algo en claro, pero parece que TuXeD conoce las syscalls tan bien como yo la alineación de Victoria's Secret... :lol:

Mar Nov 11, 2008 2:00 am

Y yo retiro todo lo que he dicho :lol: :lol:

Mar Nov 11, 2008 10:07 am

Sor, no hace falta que retires nada :)

Tu opcion creo que es perfectamente valida... vendria a ser algo asi como modificar la cadena LINUX_VERSION en los sources y recompilar. El problema es que tendrias que reiniciar y ademas seria estatico.

Con la solucion del LKM puedes basarlo en el PID, en el UID, hacerlo cambiar cada vez, activarlo y desactivarlo on-the-fly... Eso si, requiere un poco mas de trabajo.

Respecto a conocerme las syscalls... man y strace son tus amigos ;) Con strace supe que uname usa la syscall uname, con ldd que es un 'static binary', asi que no vale parchear la libc o usar LD_PRELOAD con una a nuestra eleccion.

Saludetes :P

Mar Nov 11, 2008 3:03 pm

Por todos los embudos!!

Vamos por pasos ^^

Primero, Sor_Zitroën, lo que comentas implicaría recompilar el kernel? Si no lo requiere, probaré tu opción. Gracias!

Segundo, TuXeD, llevo mucho tiempo intrigado por esto del "hooking" así que quizá este sea el momento oportuno de aprender algo sobre el tema.
Me he leído toda tu presentación y la verdad es que la teoría, más o menos, la entiendo. El problema es que en tu presentación hay poco código y teniendo en cuenta mi bajísimo nivel necessito algún que otro comentario ;)

No sabréis de algún documento que sea bueno, pero no de 300 páginas? He visto un documento de MazarD, pero juraría que es para windows (API Hooking), no? Edito: Sí que es para windows, pero tiene buena pinta, también le echaré una ojeada :D

Gracias!

P.D.: Slayer y Izengabe, gracias también ^^

Mar Nov 11, 2008 8:04 pm

Te he subido la parte de documentación que entregamos en el curso, que explica un poco más el tema y lleva enlaces al respecto (y creo que la mayoría en spanish).

Las transparencias eran más bien una guía para mí mismo para saber lo que tenía pensado comentar y lo que no ;)

También puedes echar un ojo en phrack que ha habido unos cuantos documentos sobre el tema, y en THC también tenían uno famosillo hace unos cuantos años, pero algo 'outdated' ahora mismo (aunque los conceptos siguen siendo similares, salvo que sys_call_table no se exporta y hay que buscarlo).

Mar Nov 11, 2008 8:19 pm

Respecto a conocerme las syscalls... man y strace son tus amigos Wink Con strace supe que uname usa la syscall uname, con ldd que es un 'static binary', asi que no vale parchear la libc o usar LD_PRELOAD con una a nuestra eleccion.


Ahora que conozco strace y ldd te aseguro que man me sera de mucha utilidad :badgrin:

Nos vemos!

PD: Como has sabido que era un binary static con ldd?? A mi me da esta salida:
Código:
slayer@ErhArD:~$ ldd -v /bin/uname
   linux-gate.so.1 =>  (0xb7f28000)
   libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc3000)
   /lib/ld-linux.so.2 (0xb7f29000)

   Version information:
   /bin/uname:
      libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6
      libc.so.6 (GLIBC_2.4) => /lib/tls/i686/cmov/libc.so.6
      libc.so.6 (GLIBC_2.3) => /lib/tls/i686/cmov/libc.so.6
      libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6
      libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6
      libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6
   /lib/tls/i686/cmov/libc.so.6:
      ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
      ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
      ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2



PD2: Podrias decir donde has subido ese material? estaria interesante echarle un ojito ;)

Mar Nov 11, 2008 8:35 pm

Básicamente se me ha olvidado poner el link. Aquí va:

http://tuxed.serveblog.net/docs/rk.pdf

Respecto al binario, en el sistema donde probé ldd decía que era estático. De todas formas, para saber si usa alguna librería para esas llamadas a uname (como wrapper) puedes probar a usar ltrace que es equivalente a strace pero con librerías ;)

Saludos

Mar Nov 11, 2008 10:00 pm

NewLog escribió:Por todos los embudos!!
Primero, Sor_Zitroën, lo que comentas implicaría recompilar el kernel? Si no lo requiere, probaré tu opción. Gracias!


Lo dije de buenas a primeras y por lo que veo no existe relación entre lo que pone en la imagen del núcleo con el comando uname; mejor olvídalo y ves a por el tema de hooking.


Venga, suerte!

Mar Nov 11, 2008 11:32 pm

Yo creo que existir existe, solo que tendrías que reiniciar para cargar esa imagen.

Otra opción, si /dev/kmem se puede escribir, es localizar el símbolo adecuado y hacer un programilla en C que abra /dev/(k)mem, haga lseek() a esa posición y escriba lo que queramos sobre ella.

Aunque no estoy seguro de si esto sigue funcionando o qué... yo hice una prueba rápida hace tiempo y para leer de /dev/(k)mem ningún problema, pero para escribir no pude. No recuerdo si estaba probando con algún kernel con protecciones extra (tipo grsecurity) o no, así que no puedo asegurar nada.

Pero vamos, teóricamente es otra opción.

Saludos

Mié Nov 12, 2008 4:23 pm

Bueno, visto lo visto, me voy a poner con los hooks! Ya he visto (que no leído) el nuevo documento. Que casualidad que hace un tiempo estuve visitando la web en la que se explica lo de lkm rootikits.

El link sobre hijacking syscalls está caído (en badcheksum)... parecía bueno!

He encontrado el número al que creo que te referías de phrack, tiene muy buena pinta (además traducido):
link

Mié Nov 19, 2008 12:52 pm

Escribo un nuevo post porqué al final he descubierto EL documento ^^

Es bastante bueno y útil. Te explica de manera, más o menos, básica como hacer syscalls hooks en kernels "actuales". Aquí os dejo el link

En la misma web hay programado un rootkit y me parece que es el único funcional para kernels "actuales". Hasta en rootkit.com te referencian a este código porque no tienen nada mejor. Y ahh, la gracia es que es una página en español! Como les jode a los ingleses que el código esté comentado en español, jajajaja, ale, que prueben su propia medicina :badgrin:
Publicar una respuesta