Traducción del texto: Know Your Enemy: Sebek2
disponible en www.honeynet.org
Última modificación: 13 de Septiembre del 2003
Se da permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia Libre de Documentación GNU, versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation (Fundación para el Software Libre); este documento no tiene secciones invariantes, textos de portada ni de contraportada. Se incluye una copia de dicha licencia en la sección titulada "Licencia de Documentación Libre GNU".
Ya en Berkeley en los años 80, Cliff Stoll ya se encontró con un problema que todavía preocupa a los investigadores en equipos trampa (N. del T: del inglés honeypot) hoy en día: ¿Cómo observar a un intruso sin que él lo note? En la situación de Cliff, él pudo monitorizar directamente las líneas serie para capturar las pulsaciones de teclas del intruso (1). Muchas cosas han cambiado desde entonces, sin embargo nuestro principal objetivo sigue siendo el mismo, ¿Cómo podemos capturar las acciones del intruso sin que lo sepa? Resulta crítico que en un equipo trampa diseñado con el propósito de observar los tipos y comportamientos de los intrusos humanos en cualquier sistema normal, podamos asegurarnos de que el intruso no pueda detectar que está siendo observado. El enfoque tradicional es capturar esas actividades registrando sus respectivos datos en la red. Este es un enfoque aconsejado ya que puede llevarse a cabo de forma invisible al intruso.
No sorprende a nadie que los Blackhats todavía no hayan parado. Es cada vez más común, incluso para los intrusos más básicos, utilizar el cifrado para proteger sus canales de comunicación. Si en la máquina víctima no hay disponibles servicios de cifrado, no es nada extraño que instalen sus propios servicios de confianza como SSH, un cliente GUI encriptado, o SSL. Sin la llave, las herramientas de captura de datos en la red son incapaces de ver este canal.
Para observar a los intrusos que usan cifrado de sesiones, los investigadores han necesitado encontrar una forma de romper el cifrado de la sesión. Para muchas organizaciones se ha probado que es extremadamente difícil. En un intento de esquivar el cifrado de sesiones en vez de romperlo, el Honeynet Project empezó a experimentar usando rootkits para el núcleo con el propósito de capturar datos de interés desde dentro del núcleo del propio equipo trampa. Estos experimentos condujeron al desarrollo de una herramienta llamada Sebek. El código de esta herramienta se aloja por completo en el espacio de memoria del núcleo (N. del T: kernel space), y registra todo o parte de los datos accedidos por los usuarios del sistema. Proporciona la capacidad de: registrar pulsaciones de teclas en una sesión cifrada, recuperar archivos copiados con SCP, capturar contraseñas utilizadas para entrar en sistemas remotos, recuperar contraseñas usadas para habilitar binarios protegidos con Burneye y cumplir con otras tareas relacionadas con el análisis forense. Este texto trata sobre la versión 2 de Sebek, a la que nos referiremos simplemente como Sebek.
Lo que sigue es una detallada descripción de Sebek, cómo trabaja y para qué nos sirve. Examinaremos la arquitectura y los componentes clave. A partir de aquí no vamos a meter en cuestiones de implementación y detalles técnicos del modo de operación. Finalmente mostraremos un ejemplo de uso, demostrando las capacidades de Sebek incluyendo su nuevo interfaz vía web.
El ciclo de desarrollo de Sebek empieza en un sistema Linux. Sebek ha sido adaptado (N. del T:ported) a otros sistemas operativos como Win32, Solaris y OpenBSD después de funcionar en Linux. Como resultado, este texto y sus ejemplos se basan en la versión de Sebek para Linux, sin embargo muchos de los conceptos aquí tratados se aplican de igual forma en las otras adaptaciones.
Sebek es una herramienta de captura de datos. Y como en todas las herramientas de captura de datos, su objetivo es capturar datos que nos ayuden a recrear de forma fiable los eventos sucedidos dentro de un equipo trampa. Queremos poder determinar información como cuándo consiguió entrar el intruso, cómo lo hizo y qué hizo después de conseguir acceso. Esta información puede decirnos quién es el intruso, cuales son sus motivos y con qué trabaja. Para determinar qué hizo el intruso después de la intrusión, también necesitamos los datos que proporcionan las pulsaciones de teclado del intruso y el impacto de su ataque.
Cuando no se usa cifrado, es posible monitorizar las pulsaciones de teclas de un intruso capturando el tráfico en la red y luego usando una herramienta como Ethereal para reensamblar el flujo TCP y examinar los contenidos de la sesión. Esta técnica no solo permite saber qué escribió el intruso, también lo que vio como salida. Las técnicas de reensamblado de flujo proporcionan un método casi ideal para capturar las acciones de un intruso cuando la sesión no va cifrada. Cuando la sesión va cifrada, el reensamblado nos deja los contenidos cifrados de la sesión. Para poder usarlos, debemos descifrarlos. Muchos han demostrado que este camino es demasiado difícil. En vez de romper el cifrado de una sesión, otros han buscado formas de esquivar el cifrado.
La información cifrada debe ser descifrada en algún punto para poder usarla. El proceso de esquivar el cifrado implica capturar los datos después del descifrado. La idea es dejar que los mecanismos habituales de descifrado hagan su trabajo, y entonces conseguir acceso a estos datos no protegidos. Los primeros intentos de esquivar el cifrado tomaron forma de binarios troyanizados. Cuando un intruso entra en un equipo trampa, él o ella accederá a la máquina comprometida usando aplicaciones de cifrado como SSH. Tal y como lo escribió en la línea de comandos, un intérprete de comandos troyanizado registrará sus acciones.
Para contrarrestar el peligro de los binarios troyanizados, los intrusos comenzaron a instalar sus propios binarios. Pareció muy evidente que el método más robusto para capturar datos era acceder a los datos desde el núcleo del sistema operativo. Cuando capturamos datos desde el núcleo, el intruso puede usar los binarios que quiera, y aún así seremos capaces de registrar sus acciones. Más aún, como el espacio de usuario y el espacio del núcleo están divididos, tenemos una forma simple de hacer la técnica más sutil, ocultando nuestras acciones de todos los usuario, incluso de root.
Las primeras versiones de Sebek fueron diseñadas para recolectar las pulsaciones de teclas directamente desde el núcleo. Esas primeras versiones eran una versión modificada del rootkit Adore, que utilizaba una llamada a sys_read troyanizada para capturar las pulsaciones de teclado. Este sistema registraba las pulsaciones en un fichero oculto y las exportaba a través de la red de forma que pareciera un tráfico UDP cualquiera, como NetBIOS. Este sistema permite a los usuarios monitorizar pulsaciones de teclas del intruso, pero era complejo, fácil de detectar a través del uso de rastreadores (N. del T: sniffers) y tenía un rendimiento limitado. Esta última cuestión hacía más difícil recolectar otro tipo de datos que no fueran pulsaciones de teclas.
La siguiente y actual versión de Sebek, la versión 2, fue diseñada no sólo para recolectar pulsaciones de teclas, sino para todos los datos que pasaran por sys_read. Recolectando todos los datos, hemos extendido la capacidad de monitorización a toda actividad dentro del equipo trampa incluyendo, aunque no limitándose a, las pulsaciones de teclas. Si se copia un fichero al equipo trampa, Sebek verá y registrará el fichero, obteniendo una copia idéntica. Si un intruso lanza un cliente de IRC o de correo, Sebek verá sus mensajes. Un objetivo secundario fue hacer a Sebek más difícil de detectar, nos centramos en ocultar el tráfico de los registros, para ocultarlos completamente de un Blackhat. Ahora cuando un Blackhat ejecuta un rastreador para detectar tráfico sospechoso es incapaz de detectar el tráfico perteneciente a Sebek.
Sebek no es sólo una alternativa al reensamblado de sesiones TCP, para usarse solo de cara al cifrado. Sebek también proporciona la habilidad de monitorizar los trabajos internos del equipo trampa de forma transparente, en comparación con las anteriores técnicas de caja negra. Si un intruso instala un software maligno (N. del T: malware), y sale del sistema, ahora podemos seguir el rastro de las acciones locales del software maligno aunque no acceda a la red.
Sebek tiene dos componentes: el cliente y el servidor. El cliente captura los datos del equipo trampa y los envía a través de la red donde son recolectados por el servidor (Figura 1). El servidor recolecta los datos de dos posibles fuentes: la primera es capturando paquetes directamente de la red, y la segunda es a través de un archivo de captura de tráfico en formato tcpdump. Una vez se han recolectado los datos, se almacenan en una base de datos relacional o se extraen inmediatamente las pulsaciones de teclas. Las comunicaciones usadas por Sebek están basadas en UDP por ser no orientadas a conexión y no fiables.
El cliente trabaja exclusivamente en espacio del núcleo del equipo trampa, y en el caso de la versión para Linux, está implementado como un módulo para el núcleo (LKM). El cliente puede registrar todos los datos a los que el usuario accede vía la llamada al sistema read. Estos datos son enviados al servidor a través de la red de manera que resulta complicado detectarlos desde el equipo trampa que está ejecutando Sebek. El servidor entonces recoge la información de todos los equipos trampa que están enviando datos. Como tenemos un formato de registro independiente de la plataforma podemos recolectar datos de cualquier equipo trampa independientemente de su sistema operativo. Vamos a echarle un vistazo más de cerca a cómo el cliente captura los datos.
La captura de datos se lleva a cabo usando un módulo para el núcleo. Con este módulo conseguimos acceso al espacio del núcleo del equipo trampa. Usando este acceso, capturamos todos los datos y/o actividades. Sebek hace esto reemplazando la función original read() en la Tabla de Llamadas al Sistema (N. del T: System Call Table) con una función nueva. La nueva función simplemente llama a la función original, copia los datos en un paquete, añade las cabeceras y lo envía al servidor. El hecho de reemplazar la función implica cambiar un puntero a función en la Tabla de Llamadas al Sistema.
Cuando un proceso llama a la función estándar read() en espacio de usuario, se realiza una llamada al sistema. Esta llamada se mapea en un desplazamiento dentro de la Tabla de Llamadas al Sistema. Como Sebek modifica el puntero a función en el desplazamiento correspondiente a read a su propia implementación, la ejecución cambia al contexto del núcleo y empieza ejecutando la nueva llamada read de Sebek. En este punto Sebek tiene una visión completa de todos los datos accedidos con esta llamada al sistema. Esta misma técnica puede usarse para cualquier llamada al sistema que se quiera monitorizar.
Los datos que permanecen cifrados se usan poco; para ver los datos o trabajar con ellos de alguna forma deben descifrarse. En el caso de una sesión SSH las pulsaciones de teclas son descifradas y enviadas al intérprete de comandos para realizar las acciones. Este hecho implica realizar una llamada al sistema. Recolectando datos en el espacio del núcleo, podemos conseguir acceso a los datos dentro de la llamada al sistema, después de que se hayan descifrado pero antes de que se pasen al proceso que los va a usar. De esta forma esquivamos el uso de cifrado y capturamos las pulsaciones de teclas, transferencias de archivos, contraseñas de Burneye, etc.
Para hacer la presencia del módulo de Sebek algo menos obvia tomamos prestadas algunas técnicas usadas en los rootkits modernos basados en LKM, como Adore. A causa de que Sebek reside por completo en el espacio del núcleo, muchas de estas técnicas no se pueden aplicar, sin embargo, ocultar la existencia del módulo de Sebek es un ejemplo de beneficio tecnológico directo. Para ocultar la existencia de Sebek, instalamos un segundo módulo, el limpiador (N. del T: cleaner). Este módulo manipula la lista enlazada de módulos instalados de forma que elimina a Sebek de la lista. Este no es un método completamente robusto de ocultación ya que existen técnicas para detectar módulos ocultados de esta forma (2).
Hay dos efectos colaterales de esta eliminación. Primero, los usuarios no pueden ver que Sebek está instalado. Segundo, una vez instalado, los usuarios no pueden ejecutar rmmod para eliminar el módulo de Sebek. Esta técnica de ocultación puede deshabilitarse estableciendo el valor de la variable "Testing" a 1 en el guión de instalación sbk_install.sh.
Una vez que el cliente de Sebek ha capturado los datos, necesita enviar los datos al servidor sin que el intruso detecte que se están enviando datos. Aunque usar una red LAN para enviar los datos al servidor no es el canal de comunicación más seguro, se decidió usarlo por su omnipresencia, para enviar los datos al servidor. Si Sebek se dedicara simplemente a enviar los datos al servidor usando tráfico UDP, un intruso tan sólo debería determinar la existencia de este tipo de tráfico en la LAN para determinar si Sebek estaba instalado. Sebek envía los datos al servidor usando UDP, sin embargo, antes de hacerlo modifica el núcleo de forma que previene que los usuarios puedan ver estos paquetes. Primero modifica el núcleo para que el sistema sea incapaz de ver los paquetes de Sebek, no todos los paquetes generados por la máquina local, sino aquellos configurados especialmente como paquetes de Sebek. Después, cuando Sebek transmite datos a la red, se asegura de que el sistema no bloqueará la transmisión ni contará los paquetes transmitidos. Más adelante entraremos en detalle en la ocultación de paquetes.
Si cada equipo trampa de la LAN tiene Sebek instalado, ninguno podrá ver datos de Sebek, en cambio el servidor tiene acceso completo a estos datos. Desarrollándolo de esta forma hemos creado un canal encubierto que permite al servidor tener acceso a los datos capturados por el cliente. Para cada llamada a read(), Sebek genera uno o varios paquetes. Cada paquete contiene un poco de información acerca del contexto donde se realizó la llamada y los datos accedidos por la misma. Cada paquete contiene un sólo registro de Sebek. El registro contiene campos que describen el proceso que hizo la llamada, una marca de tiempo de cuándo se hizo la llamada y la longitud de los datos recogidos así como los propios datos. Estos paquetes son generados completamente dentro de Sebek sin usar la pila TCP/IP para generar o enviar los paquetes. A causa de ello, el sistema es incapaz de ver o bloquear estos paquetes. Después de construir el paquete, es enviado directamente al controlador del dispositivo, sin pasar por el código de raw sockets ni el filtrado de paquetes. Como los rastreadores están basados en libpcap y libpcap utiliza la interfaz raw socket para recolectar los paquetes, los rastreadores instalados en la máquina que está ejecutando Sebek son incapaces de ver los paquetes que Sebek genera.
A causa de que Sebek genera sus propios paquetes y los envía directamente al controlador de dispositivo, no existe la posibilidad de que el usuario bloquee estos paquetes con IPTABLES o los monitorice con un rastreador. Esto previene el que un intruso detecte la presencia de Sebek examinando el tráfico en la LAN. Un problema secundario que debe ser tratado es la necesidad de evitar que el sistema trampa A detecte paquetes de Sebek originados en el sistema trampa B. El uso de la conmutación en Ethernet no resuelve el problema. A Sebek no le afecta la suplantación de direcciones ARP (N. del T: ARP spoofing) porque no usa el protocolo ARP para obtener las direcciones MAC destino que corresponden a las direcciones IP destino, sin embargo hay un par de situaciones en las cuales A puede ver los paquetes de B (3). En estas situaciones, un intruso puede detectar la presencia de paquetes de Sebek en la LAN ejecutando un rastreador en el sistema trampa A y viendo los paquetes de Sebek del sistema trampa B.
Para resolver este problema, Sebek instala su propia implementación del interfaz raw socket. Esta nueva versión está programada para que ignore de forma silenciosa los paquetes de Sebek. Los paquetes de Sebek se definen como tal los que tienen un determinado puerto UDP destino y un determinado número mágico. Si estos dos valores se corresponden con lo esperado, entonces sabemos que debemos ignorar el paquete. La implementación simplemente no hace nada con los paquetes de Sebek; los recoge, los ignora y pasa al siguiente paquete en la cola. El resultado final es que el intruso es incapaz de capturar paquetes de Sebek, aunque use un rastreador compilado de unas fuentes válidas.
Para asegurar la interoperabilidad entre todas las versiones de Sebek, se ha definido un protocolo común. El canal de comunicación entre cliente y servidor es unidireccional, con paquetes originados en el cliente y destinados al servidor. Este canal está basado en UDP siendo no orientado a conexión y no fiable. Cada paquete contiene un registro. Los registros son de longitud variable máxima igual a la MTU, y tienen una cabecera de longitud fija. Cada registro tiene una cabecera de 48 bytes:
| Campo | Tipo de datos | Descripción |
|---|---|---|
| Magic | Entero 32bits sin signo | Junto con los puertos de origen y destino, usado por Sebek para identificar paquetes que deben ser ocultados. |
| Version | Entero 16bits sin signo | Versión del protocolo de Sebek, la versión actual es "1". |
| Tipo | Entero 16bits sin signo | Tipo del registro representado. Datos leídos es tipo 0, datos escritos es el tipo 1. Actualmente sólo la lectura está implementada |
| Contador | Entero 32bits sin signo | Contador PDU, usado para identificar paquetes perdidos. Este contador se pone a 0 al instalar. |
| Marca de tiempo | Entero 32bits sin signo | Segundos desde la época UNIX en el sistema trampa. |
| Microsegundos | Entero 32bits sin signo | Microsegundos residuales. |
| PID | Entero 32bits sin signo | ID del proceso. |
| UID | Entero 32bits sin signo | ID del usuario. |
| FD | Entero 32bits sin signo | Descriptor de fichero. |
| COM | Cadena de 12 caracteres | Recoge los 12 primeros caracteres del comando. |
| Longitud | Entero 32bits sin signo | Longitud en octetos de los datos (PDU). |
Cuando Sebek intercepta la llamada al sistema read(), no sólo registra los contenidos de la lectura sino que también toma nota de su contexto. El PID, UID, FD y el campo Com están derivados de la información que el núcleo mantiene sobre el proceso que hace la petición. Los campos de la Marca de Tiempo están basados en el tiempo del sistema, así que pueden ser manipuladas.
El campo Longitud se extrae de la longitud devuelta por la petición de lectura. Si la longitud devuelta por la llamada read() es más grande que la MTU de la LAN, Sebek divide los datos en múltiples fragmentos que quepan todos en la LAN. Cada uno de esos fragmentos es un registro completo de Sebek con sus propias cabeceras.
Como cualquier herramienta, Sebek tiene el potencial de ser usado de forma involuntaria o maliciosa. Como es una buena herramienta para monitorizar intrusos, también puede ser útil para los intrusos usarla en sistemas comprometidos para recopilar contraseñas o espiar a los usuarios. Para reducir el potencial dañino de Sebek, se han tomado algunas decisiones.
En las primeras versiones de Sebek, los datos exportados se encriptaban y las cabeceras de los paquetes se suplantaban para ocultar el origen de los datos. Hemos abandonado esta forma de trabajo para facilitar el uso inapropiado de Sebek. Como el actual método de ocultación sólo funciona con sistemas trampa que tengan Sebek instalado, cualquier otro sistema en la LAN puede ver los paquetes de Sebek en claro. Esto supone que si un intruso intenta utilizar Sebek en sus propios sistemas comprometidos, las organizaciones lo detectarán fácilmente porque podrán ver los datos de Sebek exportados a la red. Para reducir más las posibilidades de abuso hemos eliminado las características estándar de rootkit que poseía Sebek. Así que un intruso no tendría un único LKM habilitando la captura de contraseñas y características de rootkit.
Ahora que ya entendemos el modo de funcionamiento del cliente de Sebek, vamos a ver como instalarlo. La instalación del cliente implica compilarlo para la versión del núcleo que tendremos en nuestro sistema trampa (4). Una vez que el cliente se ha compilado correctamente, tendremos un archivo tar preparado para copiarlo al sistema trampa. Este archivo tar incluye el fichero sbk_install.sh. Este fichero contiene tanto los comandos para instalar Sebek como las variables de configuración. Para instalar Sebek, simplemente edite las opciones que desee y ejecute el guión (N. del T: script) de instalación en el sistema trampa. Al ejecutar sbk_install.sh se instala el módulo para el núcleo con la configuración especificada. Hay seis valores configurables en el guión de instalación, y a menudo serán las mismas para todos los sistemas trampa de nuestra LAN.
Cuando se están configurando sistemas trampa en la misma LAN es importante que todos usen el mismo valor mágico. Esto impedirá que un sistema trampa pueda ver los paquetes de otro. Cuando se configuren las direcciones IP y MAC, tenga en cuenta que el valor de la MAC es el más importante. Si especifica incorrectamente la dirección IP destino pero configura la MAC correctamente, los registros de Sebek llegarán al servidor, suponiendo que el puerto UDP es correcto. Además, cuando el servidor se está ejecutando en un Honeywall Gateway, la interfaz no tiene IP configurada, así que la única forma de asegurarse que los paquetes son registrados por el servidor es configurar la dirección MAC de Destino con la puerta de enlace por defecto o la dirección MAC del Honeywall.
Si va a registrar datos de forma remota (a una máquina que no está en la LAN), entonces la dirección IP debe asignarse a la IP de dicha máquina, y la dirección MAC debe asignarse a la dirección de la puerta de enlace de la LAN. Después de la configuración, la ejecución de sbk_install.sh instalará el cliente de Sebek, y empezará a capturar y exportar datos.
Ahora trataremos como recuperar los datos del cliente Sebek, y una vez recuperados, como analizarlos. Recordando la Figura 1, es común instalar el servidor en el Honeywall Gateway.
El servidor tiene dos posibles fuentes para recuperar datos del cliente de Sebek. La primera opción es obtener los datos de la red desde un registro estándar de tcpdump, y extraer sólo los datos de Sebek de dicho registro. La segunda opción es capturar directamente el tráfico en la red. La extracción de datos desde un fichero tcpdump proporciona la capacidad de examinar datos archivados o datos a los que no se ha tenido acceso directo (como datos de un compañero que le envíe sus ficheros de datos).
El servidor está compuesto de hasta tres componentes. El primero se llama sbk_extract. Este puede capturar datos directamente desde un interfaz actuando como un rastreador, o recogerlos de un fichero tcpdump. De cualquier forma debe usar esta herramienta para recuperar los datos de Sebek. Una vez que sbk_extract extrae los datos, puede hacer dos cosas con ellos. La primera opción es enviarlos a una herramienta llamada sbk_ks_log.pl, que es un programa en Perl que recoge las pulsaciones de teclas del intruso y las envía a la salida estándar (N. del T: STDOUT). La segunda opción es usar sbk_upload.pl, que es otro programa en Perl que almacena los datos de Sebek en una base de datos mysql. Para compartir o archivar los datos, es recomendable que se trabaje con las capturas binarias de tcpdump como fuente canónica de datos. Como es común el hecho de registrar todo el tráfico que entra y sale de una red trampa, este archivado ya se realiza y la aparición del archivado para Sebek no supone un esfuerzo adicional.
sbk_extract es la aplicación que extrae los registros de Sebek de los datos de entrada. Independientemente del tipo de análisis, esta es la primera aplicación en la cadena. Esta aplicación recoge los paquetes de Sebek de la red o de un fichero, y entonces envía los registros encontrados a la utilidad especificada. Tenemos tres parámetros:
| -f | Especifica el fichero del que extraer los datos. |
| -i | Define la interfaz en la que capturar datos. |
| -p | Especifica el puerto UDP destino elegido en el cliente. |
sbk_ks_log.pl le permite visualizar la actividad de pulsaciones de teclas en la máquina donde ha instalado el cliente de Sebek desde la línea de comandos del servidor. No necesita parámetros de ejecución y toma su entrada de sbk_extract a través de la entrada estándar (N. del T: STDIN). Ejemplo:
sbk_extract -i eth0 -p 1101 | sbk_ks_log.pl
En este ejemplo, sbk_Extract está capturando datos en la interfaz eth0 y esperando los registros en el puerto UDP 1101. Entonces envía estos registros a sbk_ks_log.pl para la extracción de las pulsaciones de teclas. Un ejemplo de la salida de sbk_ks_log.pl puede verse a continuación.
[2003-07-23 20:03:45 10.0.0.13 6673 bash 500]whoami [2003-07-23 20:03:48 10.0.0.13 6673 bash 500]who [2003-07-23 20:03:50 10.0.0.13 6673 bash 500]su [2003-07-23 20:03:57 10.0.0.13 6886 bash 0]cd /var/log [2003-07-23 20:03:57 10.0.0.13 6886 bash 0]ls [2003-07-23 20:04:01 10.0.0.13 6886 bash 0]mkdir ... [2003-07-23 20:04:20 10.0.0.13 6886 bash 0]tcsh [2003-07-23 20:04:20 10.0.0.13 6921 tcsh 0]0 [2003-07-23 20:04:20 10.0.0.13 6920 tcsh 0]vt [2003-07-23 20:04:20 10.0.0.13 6920 tcsh 0]en [2003-07-23 20:04:20 10.0.0.13 6920 tcsh 0]en [2003-07-23 20:04:27 10.0.0.13 6920 tcsh 0]cd /tmp [2003-07-23 20:04:28 10.0.0.13 6920 tcsh 0]ls [2003-07-23 20:04:42 10.0.0.13 6920 tcsh 0]cd /usr/lib [2003-07-23 20:04:42 10.0.0.13 6920 tcsh 0]ls |
|---|
La salida de sbk_ks_log.pl es similar a lo que un usuario ve en su terminal. Sin embargo, sólo vemos los comandos introducidos y no la salida de dichos comandos. Los caracteres de control son escapados cuando aparecen. Por ejemplo, cuando pulsamos la tecla de borrado (N. del T: BackSpace), se reemplaza con la cadena [BS]. Cada línea visualizada tiene el siguiente formato:
sbk_upload.pl es el programa que se encarga de guardar los registros en una base de datos mysql. Hay algunas opciones disponibles para este programa:
| -u | Usuario de la base de datos |
| -s | Servidor de la base de datos, por defecto es la máquina local. |
| -d | Nombre de la base de datos. |
| -p | Contraseña. |
| -P | Puerto donde escucha la BD. |
sbk_extract -i eth0 -p 1101 | sbk_upload.pl -u Sebek -p secret -d Sebek
Al igual que en el ejemplo anterior, busca paquetes destinados al puerto UDP 1101 y está capturando datos en la interfaz eth0. Los registros extraídos se envían a sbk_upload.pl, que los guarda en una base de datos de la máquina local usando el usuario "Sebek", la contraseña "secret" y los inserta en la base de datos llamada "Sebek". Se inserta cada registro en la base de datos mysql. El esquema se define en el Apéndice A. Una vez que los registros se han insertado en la base de datos, pueden ser visualizados usando la interfaz Web o accedidos directamente a través de consultas SQL.
Ahora Sebek viene acompañado de un interfaz de análisis vía Web. Este interfaz proporciona a los usuarios la capacidad de monitorizar la actividad de pulsaciones de teclas, buscar una actividad específica, recuperar ficheros copiados con SCP y en general proporciona una mejor capacidad de acceder a los datos. La interfaz está implementada con PHP y sólo examina los datos introducidos en la BD; no usa datos de otras fuentes como capturas de paquetes o mensajes syslog. Está diseñado para soportar el trabajo que implica una investigación forense, sin embargo requiere unos conocimientos técnicos mínimos para entenderlo. La intención fue hacer esta herramienta para Sebek como Ethereal lo es para las capturas de datos. La interfaz tiene tres opciones primarias: ver las pulsaciones de teclas, búsquedas y navegación.
En vez de seguir el diseño de la interfaz, vamos a seguir un caso de ejemplo y cómo se usó la interfaz para ese ejemplo. En las figuras 5 a 10 vistas más abajo, un usuario entra a una máquina trampa con dirección IP 10.0.1.13. Después de entrar, el usuario descarga un fichero llamado 'malware'. Este fichero es un ejecutable binario protegido con Burneye. 'malware' es una herramienta utilizada para conseguir acceso no autorizado como root (5). El usuario ejecuta 'malware' y consigue acceso como root a la máquina trampa. El intruso sólo había conseguido acceso a una máquina trampa.
Sebek se había configurado en el cliente para registrar todos los datos y enviarlos a la dirección MAC de la pasarela Honeywall. En el Honeywall, se estaba ejecutando sbk_extract redirigiendo la salida a sbk_upload.pl. El resto de máquinas trampa en la LAN también tenían Sebek instalado. Para evitar que el tráfico de Sebek sea detectado por un intruso, todas las máquinas trampa usaban el mismo Valor Mágico. En el ejemplo vamos a demostrar la capacidad de la interfaz para:
Empezamos en la Figura 5 con la Vista General del Sistema. Esta proporciona una lista de todos los sistemas que estamos monitorizando y la última vez que observamos actividad en dicho sistema. Pulsando el botón de Pulsaciones de Teclas podemos obtener un resumen de lo que es probablemente actividad humana en el sistema.
El resumen de Pulsaciones de Teclas mostrado en la Figura 6 nos muestra las últimas 5 líneas de texto de cada sesión en la máquina. Las sesiones no son más que actividad en un Descriptor de Fichero específico para un proceso determinado. Las sesiones están ordenadas según el tiempo de la última actividad, con las más recientes en la parte superior. Dentro de cada resumen los registros de pulsaciones se ordenan según se produjeron. Al igual que en la herramienta sbk_ks_log.pl los caracteres especiales son escapados. Hay dos eventos interesantes que podemos ver al examinar este resumen. El primero se refiere al PID 1271; podemos ver lo que parece el primer acceso del usuario al sistema. Después de comprobar quién había en el sistema, ejecutó un comando llamado 'malware'. La segunda área de interés es sobre el PID 1264. Esta es una indicación de una transferencia de ficheros mediante SCP al sistema trampa. Observe como el fichero transferido se llama 'malware'. Cuando estamos interesados estrictamente en las pulsaciones de teclas del intruso, la mejor forma de reducir la cantidad de datos sin interés es usar el interfaz de búsqueda para buscar actividad por el nombre del intérprete de comandos utilizado. El siguiente paso será entrar en detalle con el PID 1264 para ver si podemos recuperar una copia de 'malware'.
La Vista de Detalles de la Figura 7 nos muestra toda la actividad para un determinado PID. En este caso estamos trabajando con el PID 1264. Lo que vemos es una transferencia SCP de entrada al sistema trampa. Podemos ver que la interfaz ha detectado que el Descriptor de Fichero 0 corresponde a los contenidos de la transferencia, y lo representa proporcionando un botón SCP. Accediendo a dicho botón, la parte inferior de la vista ofrece los datos del FD 0 como un fichero. Como Sebek usa UDP para exportar los datos hay posibilidades de que se pierdan datos; especialmente en transferencias entre LANs. Para advertir de esta diferencia, la interfaz ofrece los tamaños esperados y observados del fichero. Accediendo al nombre del fichero podemos descargarlo. Si descarga y ejecuta strings sobre el binario podrá ver que está protegido con Burneye. La utilidad strings es útil para extraer datos en texto llano de los ficheros binarios. En el caso de los binarios ELF protegidos con Burneye, una de las primeras cadenas en el binario nos permite identificar positivamente la existencia de Burneye. Ahora que hemos recuperado el fichero e identificado como un binario Burneye, necesitamos ver si podemos recuperar la contraseña utilizada para activar el binario.
La forma más fácil de buscar toda actividad con binarios ejecutables es usar la interfaz de búsqueda, mostrada en la Figura 8. En este ejemplo buscamos el ejecutable llamado 'malware'. Introduciendo el nombre del ejecutable en el campo Comando, podemos buscar todas las instancias de procesos ejecutados con el mismo nombre. Destacar que cuando ejecutamos un 'fork' veremos múltiples instancias de un mismo comando, aunque sólo lo llamemos una vez desde la línea de comandos. Esto es lo que ocurre en nuestro caso. Vemos dos procesos con PID 1315 y 1518, ejecutando el comando 'malware'. El siguiente paso será examinar el PID 1315 en detalle ya que este proceso terminó primero. Para examinarlo, simplemente pulsamos el correspondiente botón de Detalles.
Cuando entramos en los detalles del PID 1315 (Figura 9), sólo vemos un FD activo. Pulsando en Texto/Pulsaciones, veremos la actividad del FD 3. La primera línea parece ser texto llano; la segunda parece un binario ELF. La primera línea es interesante. Son los primeros datos leídos por cualquier instancia de 'malware' y del análisis anterior sabemos que 'malware' es un binario Burneye. Para que un binario Burneye se ejecute, lo primero que debe ocurrir es que se debe activar mediante una contraseña. Aunque la interfaz no nos muestra esto explícitamente, esta primera línea es la contraseña utilizada para activar el binario. Llegados a este punto, hemos demostrado como recuperar un fichero copiado mediante SCP, y como recuperar la contraseña de un binario protegido con Burneye. La última tarea será identificar en qué momento el intruso consiguió acceso como root. Para conseguirlo debemos examinar la otra instancia de 'malware'.
El PID 1318 corresponde a la otra instancia de 'malware' y nos ofrece mucha información. El proceso empieza a ejecutarse con el nombre de 'malware' y acaba con el de 'sh'. Más importante, empieza su ejecución con un UID 500 y acaba con UID 0, o root. Así sabemos que usando este PID el usuario consiguió acceso como root. El usuario consiguió este acceso en la fecha 23-07-2003 20:04:01 GMT.
Sebek es una herramienta de captura basada en el núcleo. Está diseñada para capturar toda la actividad en un sistema trampa de forma encubierta. Evitamos el cifrado capturando la actividad en el espacio del núcleo donde se encuentra descifrada. A causa de esto podemos capturar pulsaciones de teclas, recuperar contraseñas y monitorizar cualquier comunicación incluyendo conversaciones IRC, y actividad SSH/SCP. En general, Sebek proporciona un excelente punto de vista de las actividades internas de un sistema trampa.
La versión actual de Sebek tiene sus límites. Para un intruso hábil que tiene buen conocimiento del Sistema Operativo, hay formas de detectar la presencia de Sebek (6). Sin embargo no está claro que sea algo que podamos evitar. Una de las metas de Sebek es hacerlo suficientemente sutil como para no levantar sospechas en el intruso. Está previsto que los intrusos desarrollen programas para automatizar la detección de Sebek en un sistema. Como resultado, está previsto que el trabajo futuro requerirá reducir las posibilidades de detección.
Los futuros objetivos de Sebek no sólo incluyen aumentar la dificultad de detección sino también extender los tipos de datos que recolecta y el análisis que se pueda realizar. Continuaremos la transformación de recolector de pulsaciones a herramienta de análisis transparente de sistemas trampa. Para más información, visite la página de Sebek en:
Preguntas, comentarios, informes de fallos o sugerencias para el desarrollo de Sebek deben ser dirigidas a Edward Balas ebalas@iu.edu.
1.- Tratado en el libro "The Cuckoo's Egg, Cliff Stoll. Pocket Books Nonfiction, 1990. New York, NY.