Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
920
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
394
)
privacidad
(
363
)
google
(
345
)
ransomware
(
336
)
vulnerabilidad
(
293
)
Malware
(
257
)
android
(
238
)
Windows
(
237
)
cve
(
231
)
tutorial
(
223
)
manual
(
208
)
software
(
201
)
hardware
(
189
)
linux
(
123
)
twitter
(
115
)
ddos
(
92
)
WhatsApp
(
89
)
Wifi
(
84
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
app
(
65
)
sysadmin
(
62
)
Networking
(
52
)
nvidia
(
52
)
ssd
(
50
)
youtube
(
50
)
adobe
(
43
)
firmware
(
41
)
office
(
41
)
hack
(
40
)
firefox
(
35
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
MAC
(
25
)
programación
(
25
)
apache
(
23
)
exploit
(
23
)
javascript
(
22
)
multimedia
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Desde 2016, todas las conversaciones de WhatsApp están cifradas de extremo a extremo, lo cual está considerado el modo más seguro para evita...
-
Tal vez no conozcas Medicat USB , aquí aprenderás qué es si ya no lo sabías, y si ya lo conocías, aprenderás cómo utilizar esta poderosa c...
-
Cómo activar y utilizar la herramienta MSRT de Windows , que pese a llevar en todas las versiones del sistema operativo desde Windows XP, ...
Rootkits (I)
jueves, 11 de marzo de 2010
|
Publicado por
Antonio Sánchez
|
Editar entrada
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.
Un poco de historia y definición
El origen del término “rootkit” se encuadra dentro de los Sistemas Operativos Unix, en donde el usuario con mayor privilegio dentro del árbol jerárquico del Sistema es el superusuario o usuario root (raíz), si a esto le añadimos el término “kit”, tenemos una serie de herramientas que ayudan al atacante a mantener los privilegios administrativos. Es importante destacar esto, mantener, ya que si previamente no hemos conseguido privilegios de root nuestras posibilidades se verán mermadas enormemente.
Si un intruso fuese capaz de reemplazar los binarios básicos para la administración del Sistema Operativo mediante el uso de un rootkit, este se garantizaría el acceso como superusuario de una forma en la que no levantaría sospechas y sería bastante difícil de de descubrir.
Los rootkits conocidos de más antigüedad datan de principio de los 90, en concreto uno escrito por Lane Davis y Stecen Dake para SunOS, aunque también se conoce una especie de exploit equivalente a un rootkit hecho por Ken Thompson de Laboratorios Bell contra un laboratorio naval en California para ganar una apuesta.
Es importante no confundir los rootkits con virus o gusanos. La principal diferencia reside en el método de propagación y en la ocultación. Como los rootkits, los virus también alteran componentes Software del sistema, sin embargo, un virus está diseñado para dañar y en algún caso proveer servicios adicionales al atacante, de forma que será más fácil detectarlo por sus efectos. Un gusano está diseñado normalmente para escanear vulnerabilidades y aprovecharse de ellas para propagarse a otros hosts conectados, siguiendo una especie de bucle infinito. De nuevo, esto modifica el estado del host lo suficiente como para que haya indicios de que algo anormal está sucediendo, pudiéndose detectar y mitigar. Finalmente, un rootik está diseñado para mantener su propia integridad y permanecer oculto de cara al usuario y así poder proveer al atacante un acceso seguro y en muchas ocasiones de larga duración.
Un rootkit diseñado e implementado adecuadamente puede permanecer fácilmente oculto y operativo durante años sin dar ningún signo de su presencia al usuario final o a los administradores, esto suele suceder en redes empresariales donde la ingente cantidad de hosts y sistemas en general hace bastante difícil su detección si no se da mucho “el cante”.
A continuación pongo algunos datos históricos relacionados con los rootkits:
• 1989: Encontrados primeros “Zappers” en sistemas hackeados.
• 1994: Primeros rootkits para SunOS
• 1996: Primeros rootkits para Linux
• 1997: Aparición de LKM's (Loadable Kernel Module) en "Phrack"
• 1998: “Non-LKM kernel patching” propuesto por Silvio Cesare
• 1999: Adore LKM kit lanzado por TESO
• 2000: Lanzamiento de T0rnkit v8
• 2001: Primeras muestras de KIS y SucKit
• 2002: “Sniffer backdoors” empiezan a integrarse en los rootkits
Funcionalidades:
Aunque hay que tener en cuenta el cambio de escenario que supone trabajar en un Sistema Operativo o en otro, hay una serie de funcionalidades básicas que todo rootkit implemente (o debería) y que pasamos a comentar brevemente:
Un escaneo desde fuera indicará puertos altos abiertos.
La ventaja es que este tipo de shells no abren ningún puerto, simplemente usan técnicas de “piggibacking” en conexiones existentes.
En cuanto a los backdoors locales, trabajan de diversas formas, por ejemplo troyanizado herramientas administrativas que requieren privilegios de root. Muchas herramientras estandar de Unix SetUidadas son reemplazadas por los atacantes con el fin de obtener privilegios de root “bajo demanda”. Ping, xterm y la mayoría de los demonios de red pueden ser usados para ese propósito. Algunos kernel-rootkits simplemente dan privilegios de root a algún usuario especificado que no aparece con UID 0 en el /etc/passwd.
Mientras que los rootkits normalmente requieren privilegios de root para su instalación, ofrecen muchas formas y muy diversas de mantener estos privilegios, de forma que si por ejemplo el “principal” backdoor que era un SSH troyanizado es descubierto, tenemos otras 5 formas más de seguir entrando al sistema!.
La escalada local de privilegios se provee en forma de binarios SetUidados modificados, /bin/login troyanizados, copias de /bin/bash/ SetUidados en lugares raros, etc.
El borrar las evidencias existentes implica hacerlo en varios logs del sistema, registros de auditoría (como sucede en los BSD al procesar las cuentas), logs de aplicación, históricos de la shell, etc. Hay decenas de herramientas dedicadas a esto. Los métodos más comunes consisten en el borrado y la edición de dichos ficheros, aunque no suelen ser muy fiables y uno acaba haciéndolo a mano.
Matando y/o modificando el demonio del syslog suele significar saltarnos los procesos de auditoría. La mayoría de los scripts de instalación de rootkits llevan a cabo de manera automática esta tarea y algunos incluso notifican al usuario del descubrimiento de algunas trazas de logueo remoto (entradas del tipo @loghost en /etc/syslog.conf). Otras operaciones incluyen el prevenir la creación de nuevos registros que guarden las sesiones del atacante.
Ocultar la evidencia de la intrusión es uno de los puntos fuertes de los LKM rootkits (luego se verá en que consisten). En contra de la mayoría de los rootkits que se dedican a reemplazar los binarios del sistema, los LKM rootkits se introducen en el kernel del sistema y reemplazan o modifican las llamadas al sistema usadas para interactuar entre el contexto de usuario y el del núcleo. En este caso, el núcleo mismo del Sistema se ve comprometido, con lo que consecuentemente los componentes del sistema que usen las llamadas corruptas se verán afectadas a beneficio del atacante.
En la mayoría de los casos un rootkit tratará de esconder:
- Sus propios ficheros
- Otros ficheros generados a posteriori por el atacante
- Procesos del atacante (sniffers, backdoors, etc.)
- Conexiones de red “comprometidas”
En ocasiones puede llegar a ser muy jugoso cierto tipo de información, así que un rootkit debe de proveer algún mecanismo (normalmente sniffers) para capturar toda la información que se genere y se mueva a nuestro alrededor, para después analizarla off-line.
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.
Un poco de historia y definición
El origen del término “rootkit” se encuadra dentro de los Sistemas Operativos Unix, en donde el usuario con mayor privilegio dentro del árbol jerárquico del Sistema es el superusuario o usuario root (raíz), si a esto le añadimos el término “kit”, tenemos una serie de herramientas que ayudan al atacante a mantener los privilegios administrativos. Es importante destacar esto, mantener, ya que si previamente no hemos conseguido privilegios de root nuestras posibilidades se verán mermadas enormemente.
Si un intruso fuese capaz de reemplazar los binarios básicos para la administración del Sistema Operativo mediante el uso de un rootkit, este se garantizaría el acceso como superusuario de una forma en la que no levantaría sospechas y sería bastante difícil de de descubrir.
Los rootkits conocidos de más antigüedad datan de principio de los 90, en concreto uno escrito por Lane Davis y Stecen Dake para SunOS, aunque también se conoce una especie de exploit equivalente a un rootkit hecho por Ken Thompson de Laboratorios Bell contra un laboratorio naval en California para ganar una apuesta.
Es importante no confundir los rootkits con virus o gusanos. La principal diferencia reside en el método de propagación y en la ocultación. Como los rootkits, los virus también alteran componentes Software del sistema, sin embargo, un virus está diseñado para dañar y en algún caso proveer servicios adicionales al atacante, de forma que será más fácil detectarlo por sus efectos. Un gusano está diseñado normalmente para escanear vulnerabilidades y aprovecharse de ellas para propagarse a otros hosts conectados, siguiendo una especie de bucle infinito. De nuevo, esto modifica el estado del host lo suficiente como para que haya indicios de que algo anormal está sucediendo, pudiéndose detectar y mitigar. Finalmente, un rootik está diseñado para mantener su propia integridad y permanecer oculto de cara al usuario y así poder proveer al atacante un acceso seguro y en muchas ocasiones de larga duración.
Un rootkit diseñado e implementado adecuadamente puede permanecer fácilmente oculto y operativo durante años sin dar ningún signo de su presencia al usuario final o a los administradores, esto suele suceder en redes empresariales donde la ingente cantidad de hosts y sistemas en general hace bastante difícil su detección si no se da mucho “el cante”.
A continuación pongo algunos datos históricos relacionados con los rootkits:
• 1989: Encontrados primeros “Zappers” en sistemas hackeados.
• 1994: Primeros rootkits para SunOS
• 1996: Primeros rootkits para Linux
• 1997: Aparición de LKM's (Loadable Kernel Module) en "Phrack"
• 1998: “Non-LKM kernel patching” propuesto por Silvio Cesare
• 1999: Adore LKM kit lanzado por TESO
• 2000: Lanzamiento de T0rnkit v8
• 2001: Primeras muestras de KIS y SucKit
• 2002: “Sniffer backdoors” empiezan a integrarse en los rootkits
Funcionalidades:
Aunque hay que tener en cuenta el cambio de escenario que supone trabajar en un Sistema Operativo o en otro, hay una serie de funcionalidades básicas que todo rootkit implemente (o debería) y que pasamos a comentar brevemente:
- Mantenimiento del acceso
- Destruir/ocultar evidencias
- Recopilación de información
- Mantenimiento del acceso
- Telnet o Shell en un puerto TCP
- SSH (el normal, o troyanizado en un puerto alto)
Un escaneo desde fuera indicará puertos altos abiertos.
- CGI Shell
La ventaja es que este tipo de shells no abren ningún puerto, simplemente usan técnicas de “piggibacking” en conexiones existentes.
- UDP Listener
- Reverse Shell/Telnet
- ICMP “telnet”
- Reverse tunneled shell
- Backdoor activado por paquetes “mágicos”
- “No-listener” backdoors (basados en sniffar)
- Covert channel backdoor:
En cuanto a los backdoors locales, trabajan de diversas formas, por ejemplo troyanizado herramientas administrativas que requieren privilegios de root. Muchas herramientras estandar de Unix SetUidadas son reemplazadas por los atacantes con el fin de obtener privilegios de root “bajo demanda”. Ping, xterm y la mayoría de los demonios de red pueden ser usados para ese propósito. Algunos kernel-rootkits simplemente dan privilegios de root a algún usuario especificado que no aparece con UID 0 en el /etc/passwd.
Mientras que los rootkits normalmente requieren privilegios de root para su instalación, ofrecen muchas formas y muy diversas de mantener estos privilegios, de forma que si por ejemplo el “principal” backdoor que era un SSH troyanizado es descubierto, tenemos otras 5 formas más de seguir entrando al sistema!.
La escalada local de privilegios se provee en forma de binarios SetUidados modificados, /bin/login troyanizados, copias de /bin/bash/ SetUidados en lugares raros, etc.
- Destruir/ocultar evidencias
El borrar las evidencias existentes implica hacerlo en varios logs del sistema, registros de auditoría (como sucede en los BSD al procesar las cuentas), logs de aplicación, históricos de la shell, etc. Hay decenas de herramientas dedicadas a esto. Los métodos más comunes consisten en el borrado y la edición de dichos ficheros, aunque no suelen ser muy fiables y uno acaba haciéndolo a mano.
Matando y/o modificando el demonio del syslog suele significar saltarnos los procesos de auditoría. La mayoría de los scripts de instalación de rootkits llevan a cabo de manera automática esta tarea y algunos incluso notifican al usuario del descubrimiento de algunas trazas de logueo remoto (entradas del tipo @loghost en /etc/syslog.conf). Otras operaciones incluyen el prevenir la creación de nuevos registros que guarden las sesiones del atacante.
Ocultar la evidencia de la intrusión es uno de los puntos fuertes de los LKM rootkits (luego se verá en que consisten). En contra de la mayoría de los rootkits que se dedican a reemplazar los binarios del sistema, los LKM rootkits se introducen en el kernel del sistema y reemplazan o modifican las llamadas al sistema usadas para interactuar entre el contexto de usuario y el del núcleo. En este caso, el núcleo mismo del Sistema se ve comprometido, con lo que consecuentemente los componentes del sistema que usen las llamadas corruptas se verán afectadas a beneficio del atacante.
En la mayoría de los casos un rootkit tratará de esconder:
- Sus propios ficheros
- Otros ficheros generados a posteriori por el atacante
- Procesos del atacante (sniffers, backdoors, etc.)
- Conexiones de red “comprometidas”
- Recopilación de información
En ocasiones puede llegar a ser muy jugoso cierto tipo de información, así que un rootkit debe de proveer algún mecanismo (normalmente sniffers) para capturar toda la información que se genere y se mueva a nuestro alrededor, para después analizarla off-line.
Enviar por correo electrónico
Escribe un blog
Compartir con Twitter
Compartir con Facebook
Compartir en Pinterest
1 comentarios :
Buena intro, no te has dejado ni un solo tipo de ataque fuera (creo, mi memoria ya no es lo q era xD). Espero impaciente la segunda entrega ^^
Publicar un comentario
Los comentarios pueden ser revisados en cualquier momento por los moderadores.
Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.
Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.