Estaba yo liado con mi PFC y más en concreto con temás de Virtualización (Xen y KVM), cuando me encontré con un "inconveniente", al trabajar con las VM's en modo bridge con una tarjeta ethernet no hay problemas, pero... que pasa si queremos hacer esto con una tarjeta inalámbrica?

Realmente podemos pasar de líos y hacerlo con la ethernet, pero si tienes un portatil y estás conectado por wifi al router de tu casa, da bastante pereza tener que moverte y "enchufarte" al router.

• KernelSpace Rootkits

• UserSpace Rootkits

Con este primer post, vamos a introducir una serie de artículos en los que trataremos en profundidad los rootkits, desde un repaso histórico, pasando pos los fundamentos, los distintos tipos, hasta un análisis profundo de una serie de rootkits.

Los posts corren a cargo de Hendrix y de un servidor, esperemos que sean de vuestro agrado, y sin más dilación...

Muchos usuarios habrán oído hablar de los rootkits... Tienen ya una dilatada historia, aunque en sus orígenes provienen del entorno de los Sistemas Operativos Unix y sus derivados.

Originalmente los rootkits fueron diseñados para realizar funciones en beneficio del usuario, aunque posteriormente, y de ahí su actual “popularidad”, pasaron a ser usados por los hackers para diversos propósitos.

Alrededor del 2004 empezaron a aparecer los primeros ejemplares para los Sistemas Operativos Windows, creciendo exponencialmente el número de estos. Fue en este momento cuando el término “rootkit” saltó a la palestra y empezaron a refinarse enormemente hasta llegar a los ejemplares que tenemos hoy en día.

En este artículo vamos a tratar de definir un poco más técnicamente que es un rootkit, como actúa, y porque puede ser tan potencialmente peligroso.

En el presente artículo se va a tratar la detección de API Hooking en procesos mediante un módulo de Kernel. Un breve índice sobre los puntos que voy a tratar:

1. Diferencia entre manejo de direcciones en modo Kernel y modo Usuario
2. Trabajando sobre el proceso en modo Kernel
3. Leyendo memoria y código final

Diferencia entre manejo de direcciones en modo Kernel y modo Usuario:
-->
Como ya saben, no es lo mismo trabajar con memorias en un módulo de Kernel que en un proceso corriendo en modo usuario. La principal diferencia es que un módulo Kernel trabaja con direcciones físicas y los procesos con memoria virtual. Vamos a ver mas detalladamente que es cada cosa.

El otro día estaba platicando con Kamsky, hablando de proyectos pendientes y cosas similares. Después de un rato le digo "Una pizza si me dices que canción estoy escuchando" ya previamente le había hecho un usuario para que se conecte mediante ssh a mi equipo, y pues resulta él entró a ver algunas cosas testeó algunos archivos y demás lo que haría cualquier persona tratando de obtener privilegios que no le corresponden, bueno resulta que no logró nada en ese momento ya que el estaba ocupado en otras cosas.

En ese momento yo tenia un poquito des-actualizado FreeBSD en el sistema de ports había unos 65 bugs y en kernel tenia unos 15 de los cuales creo que ya había por ahí un que otro exploit.

Lo más normal hubiese sido convertirse en mi usuario y leer el archivo del xmms con el plugin de InfoPipe

Anon@localhost % cat /tmp/xmms-info_Anon.0
XMMS protocol version: 2467
InfoPipe Plugin version: 1.3
Status: Playing
Tunes in playlist: 2483
Currently playing: 2414
uSecPosition: 3715
Position: 0:03
uSecTime: 275069
Time: 4:35
Current bitrate: 128000
Samping Frequency: 44100
Channels: 2
Title: Interpol - Obstacle 1

El quería convertirse en root y hacerle un:

hexdump -C /dev/mem | grep xmms

o algo similar, sin embargo es un proceso algo lento y con pocas probabilidades de éxito, yo lo intente y no di con nada

Pues me puse a pensar en como era posible ver lo que yo estaba escuchando, y después de pensar en las cosas mas raras y extravagantes sobre ingeniería social, hacking y demás, recordé un dicho que dice "la solución siempre es mas sencilla de lo que parece". Me dije a mi mismo, "algo entre tanto sistema operativo, no debe de estar implementando bien la seguridad" y recordé que cuando implementé el torneo shell misteriosamente aparecían xterm de otros usuarios en mi X, en ese entonces lo asocié eso a que estaban siguiendo alguna sección del texto smashing the stack for fun and profit ellos pensaban que todavía tener un xterm vulnerable como el que se describió en el texto, ellos realizaban algo como:

setenv DISPLAY ":0.0" o export DISPLAY=":0.0"

dependiendo del shell que estén usando en ese momento, en lo que visualice el :0.0 se disparo una idea en mi mente, con la utilidad ffmpeg la cual tengo instalada y es con la cual grabo los vídeos que he subido a youtube, la herramienta en cuestión utiliza una sintaxis así para grabar:

ffmpeg -f x11grab -r 30 -sameq -s 854×480 -i :0.0 /path/to/file.avi

Entré inmediatamente con un usuario sin privilegios previamente creado en el torneo shell, y puse el comando, en lo que vi que si estaba grabando, reajuste el tamaño a capturar y si, ahí estaba la sección perteneciente al xmms mostrando la canción que estoy escuchando.

En conclusión kamsky se perdió de una pizza
Aprendí que se puede espiar el X de cualquier usuario, incluso el de root

Trate de reportar eso al bugtrack de FreeBSD, pero al parecer no piensan que sea un bug. Esto fue lo que me respondieron:

Dear Anon,

We have received your message. However I do not feel this is a security issue
within FreeBSD. X, where the display is being set, is reponsible for sharing the
desktop etc. ffmpeg is an additional third party port that has access to this.

It might be best to ask around on the ports@ mailinglist or even x11@ (might
be better now that I think of it) on how to tune down display access from local users.

Cheers and thanks for trying to help and make FreeBSD better, it's appreciated!

Y con su consejo lo he mando al maillist de X11 en FreeBSD y resulta que hasta ahora sigo sin respuesta.

http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009359.html

- Introducción

En esta entrada vamos a hablar un poco de las bondades y los defectos que tienen las "jaulas chroot" usadas en diferentes sistemas Unix y derivados, centrándonos en este caso en Linux. Antes de meternos en el fregado, vamos a ver un poco las necesidades que nos llevan a usar este u otros métodos que deberían de mostrarse eficaces en cuanto a la securización de nuestros sistemas.

Sin duda, cuando en un Servidor se instala algún Servicio, ya sea Http, Ftp, Smtp, etc., es obligatorio invertir nuestro esfuerzo en tener un sistema lo más funcional y flexible posible, pero a la vez seguro (necesidades que suelen chocar). Hay muchas medidas, como el uso de IDS, los mecanismos de securización propios que nos brinda el servicio, firewalls, etc... Y es aquí donde entran en juego las "jaulas chroot", las cuales serán definidas más tarde apropiadamente, que son una especia de caja, donde metemos un "mini-sistema" sobre el que correrá nuestro Servicio.

¿Qué nos brinda esto?, bueno pues varias cosas, en primer lugar tenemos nuestro Servicio, que es un posible foco de entrada de "personal ajeno a la organización", en una especie de bunquer aislado (luego veremos que no es tan bunquer) que no tiene acceso al resto del sistema, ya que para ese Servicio y para todo lo que haya dentro de la jaula ESE ES EL SISTEMA. Pero... y si alguien consigue acceder mediante alguna vulnerabilidad del Servicio a nuestro Server y además con privilegios de root?, bueno, en principio no debería de preocuparnos la integridad de nuestro Sistema en conjunto (más allá de ese Servicio en específico), ya que el atacante no va a ver más allá de ese "mini-sistema".

Tiene buena pinta, no?, pues a continuación vamos a entrar un poco más en detalle sobre el tema, viendo que efectivamente las "jaulas chroot" son una buena medida de Seguridad si se implementan adecuadamente, pero que no es la panacea y que los chicos malos pueden traspasar los muros de nuestro bunquer.

De antemano os damos las gracias, ya que sois vosotros los que haceis de elhacker.net una de las comunidades de habla hispana más grande relacionada con la seguridad informática.

Nuestra filosofía es la de apoyar, enseñar y educar a todo aquel que esté interesado en este apasionante mundo, así que esperamos que el blog llegue a ser un punto de encuentro para toda la gente con curiosidad y ganas de aprender.

Bienvenidos!

- El staff de elhacker.net -