Confianza

Para nuestro ultimo topico de vulnerabilidad, nos desviaremos de la estrategia practica que hemos seguido previamente para meternos un poco mas en la parte teorica, y discutir brevemente la nocion de la confianza. Las cuestiones e implicaciones de la vulnerabilidad aquí, son un poco mas sutiles y lejanas de alcanzar que las que hemos apuntado anteriormente; en el contexto de este texto usamos la palabra confianza siempre que se da la situacion de que un servidor (siempre que un host permite acceso remoto se le puede llamar servidor) permita que un recurso local sea usado por un cliente sin autentificacion de password cuando dicha autentificacion es normalmente requerida. En otras palabras, limitamos arbitrariamente la discusion a los clientes "disfrazados".

Hay muchas maneras de un host pueda confiar: los ficheros .rhosts y hosts.equiv que permiten el acceso sin verificacion de password; servidores basados en ventanas que permiten a los sistemas remotos el uso y abuso de privilegios; archivos exportados que controlan el acceso via NFS, y mas.

Casi todos estos dependen de la conversion del IP del cliente al nombre del host para determinar si se concede el servicio o no. El metodo mas simple usa el archivo /etc/hosts para una busqueda directa. Sin embargo, hoy en dia la mayoria de hosts usan o bien DNS (Domain Name Service), NIS, o ambos para el servicio de busqueda del nombre. Una busqueda inversa ocurre cuando un servidor tiene una direccion IP (de una conexión de un cliente) y desea coger el correspondiente nombre del host del cliente.

Auqnue el concepto de como funciona la confianza del host es bien sabido por muchos administradores de sistema, los peligros de la confianza, y el problema practico que representa, sin tomar en consideracion la interpretacion del nombre del host, es uno de los problemas menos entendidos que conocemos en Internet. Esto va mas alla de los obvios ficheros hosts.equiv y .rhosts; NFS, NIS, sistemas de ventanas - de hecho, muchos de los utiles servicios en UNIX estan basados en el concepto de que sites bien conocidos (para un administrador o ususario) son de alguna manera de confianza. Lo que no se entiende es como las redes atan de forma tan estrecha la seguridad entre lo que normalmente se consideran hosts inconexos.

Cualquier forma de confianza puede ser engañada, burlada, o derribada, especialmente cuando la autoridad que tiene la responsabilidad de chequear los credenciales de un cliente esta o bien fuera del dominio administrativo del servidor, o cuendo el mecanismo de confianza esta basado de alguna forma en metodo que tiene una forma debil de autentificacion; normalmente ambos son el caso.

Obviamente, si el host que contiene la base de datos (bien NIS, DNS, o o lo que sea) ha sido comprometido, el intruso puede convencer al host victima de que el viene de cualquier host de confianza; ahora es suficiente con encontrar que hosts son de confianza para la victima. Esta tarea es en gran medida facilitada examinado de donde los administradores de sistema y las cuentas del sistema (tales como root, etc.) se conectaron por ultima vez. Volviendo a nuestra victima, victim.com, puedes ver que la cuenta root asi como otras cuentas del sistema se conectaron desde big.victim.com. Cambias el registro PTR para evil.com de forma que cuando intentes hacer un rlogin (login remoto) desde evil.com a victim.com, evil.com intentara buscar tu nombre de host y encontrara lo que pusistes en el registro. Si el registro en la base de datos DNS es asi:

1.192.192.192.in-addr.arpa IN PTR evil.com

y lo cambias por:

1.192.192.192.in-addr.arpa IN PTR big.victim.com

entonces, dependiendo de como sea de ingenuo el software de victim.com, victim.com creera que el acceso proviene de big.victim.com, y, asumiendo que big.victim.com este en los ficheros /etc/hosts.equiv o /.rhosts, te sera posible aceder sin tener que proporcionar un password. Con NIS, es cuestion de o bien editar la base de datos del host en el NIS maestro (si es que este esta controlado por el intruso) o de burlar o forzar el NIS (ver discusion sobre la seguridad del NIS arriba) para proporcionar a la victima cualquier informacion que desees. Aunque mas complejos, dañinos e interesantes ataques pueden ser realizados por medio del DNS, el tiempo y el espacio no permiten cubrir dichos metodos aquí.

Dos metodos puedem ser usados para prevenir dichos ataques. El primero es el mas directo, pero quizas mas poco practico. Si tu site no usa ningun metodo de confianza, no seras tan vulnerable al engaño de host. La otra estrategia es la de usar protocolos encriptados. El usar el seguro protocolo RPC (usado en NFS, NIS+, seguros) es un metodo; aunque ha sido "roto" criptograficamente, aun da mas seguridad que los procedimientos de autentificacion RPC que no usan ningun tipo de metodo de encriptacion. 

Otras soluciones, tanto de hardware (smartcards) como de software (Kerberos), estan siendo desarroladas, pero estan o bien incompletas o requieren cambios en el software de el sistema.

El apendice B detalla los resultados de un estudio informal tomado de una variedad de hosts en Internet.

protegiendo el sistema

Es nuestra esperanza el que hallamos demostrado que incluso algunos de los 
aparentemente inocuos servicios ofrecidos (algunas veces inesperadamente) 
pueden ser "municion" para determinados crackers de sistemas. Pero, por 
supuesto, si la seguridad fuera nuestra unica preocupacion, los ordenadores 
jamas estarian encendidos, y enganchados a una red con literalmente 
millones de intrusos en potencia. Mas que dar avisos de que deberia o no 
ncenderse, ofreceremos algunas sugerencias generales:

Si no puedes quitar el servicio finger, considera el instalar un nuevo 
finger daemon. Es raramente necesario el revelar el home directory de un 
usuario y la procedencia de su ultimo acceso.

No corras NIS a menos que sea absolutamente necesario. Usalo lo menos 
posible.

Jamas exportes sistemas de archivo NFS sin restriccion, a todo el mundo. 
Trata de exportar sistemas de archivos de solo lectura cuando sea 
posible.

"Fortifica" y protege los servidores (ej, los hosts que dan un servicio 
a otros hosts - NFS, NIS, DNS, o lo que sea.). Solo permite cuentas 
administrativas en dichos hosts.

Examina cuidadosamente los servicios ofrecidos por inetd y el mapeador 
de puertos (pormapper). Elimina todos aquellos que no sean totalmente 
necesarios. Usa los inetd wrappers de Wietse Venema, no para otra 
funcion que la de tener un log de las fuentes de conexiones a tu host. 
Esto aporta grandes mejoras a las caracteristicas de verificacion 
standard de UNIX, especialmente con referencia a los ataques de red. Si 
es posible, usa los metodos loghost de syslog para obtener informacion 
relacionada con la seguridad en un host seguro.

Elimina los metodos de confianza a menos que su uso sea totalmente 
necesario. La confianza es tu enemigo.
Usa passwords shadowed y el comando passwd para rechazar passwords 
pobres, debiles. Desabilita cuentas de usuario o de sistema no usadas o 
inactivas.


Estate al tanto de la literatura actual (observa la lista de lectura y 
bibliografua sugerida al final de este documento) y de las herramientas 
de seguridad; informa a los demas acerca de problemas e incidentes de 
seguridad. Como minimo, suscribete a la lista de mail del CERT y de la 
revista PHRACK (ademas de la lista de mail de los firewalls, si tu site 
esta usando o piensa instalar firewalls) y lee los grupos de news de 
usenet acerca de seguridad para asi obtener la ultima informacion sobre 
problemas de seguridad. La ignorancia es el problema de seguridad mas 
mortal de los que estamos al tanto.

Instala todos los parches de seguridad tan pronto como sea posible, en 
todos tus hosts. Examina la informacion de los parches de seguridad de 
otras distribuciones - muchos bugs (rdist, sendmail) son comunes en 
muchas variantes UNIX.

Es interesante el ver que soluciones comunes para problemas de seguridad , 
tales como usar Kerberos o el usar passwords de usar y tirar o tokens 
digitales no son efectivas contra muchos de los ataques discutidos aquí. 
Recomendamos de verdad el uso de tales sistemas, pero alertamos que no son 
la solucion TOTAL a los problemas de seguridad - son parte de un esfuerzo 
ayor de proteger tu sistema.

Conclusiones

Tal vez ninguno de los metodos expuestos aquí sean sorprendentes; cuando se escribio este documento, no aprendimos mucho sobre como irrumpir en sistemas. Lo que aprendimos fue, testeando estos metodos en nuestros propios sistemas y en sites amigos, lo efectivos que son estos metodos a la hora de ganar acceso a un tipico host Unix de Internet. Cansado de tratar de teclear todo esto a mano, y deseando mantener nuestros propios sistemas mas seguros, decidimos poner en practica una herramienta de seguridad (SATAN) que trata de chequear hosts remotos al menos para alguno de los problemas discutidos aquí. La tipica respuesta, cuando informabamos a la gente acerca de nuestro documento y nuestra herramienta, era algo del estilo de "eso suena bastante peligroso - espero que no vayas a darlo a todo cristo. Pero ya que tu confias en mi, podria tener una copia?"

Jamas pensamos en crear un cookbook o una herramienta de metodos y programas soobre/para irrumpir en sistemas - en vez de eso, vemos que estos mismos metodos fueron usados, todos los dias, contra nosotros y contra administradores de sistema amigos. Creemos que el propagar la informacion que normalmente no era accesible para aquellos que estuvieran fuera del underworld, podemos aumentar la seguridad incrementando la conciancia del peligro.. El intentar restringir el acceso a informacion "peligrosa" sobre seguridad nunca ha sido un metodo muy util para incrementar la seguridad; de hecho, lo contrario parece ser el caso, ya que los crackers de sistemas han sido reticentes a la hora de compartir informacion con otros.

Mientras es casi seguro que alguna de la informacion aquí presentada es material nuevo para aspirantes a crackers de sistemas, y que algunos la usaran para ganarse accesos no autorizados en hosts, la evidencia presentada por nuestros tests muestra que hay un monton de sites inseguros, simplemente por que el administrador de sistema no sabe mucho mas - no son estupidos o lentos, simplemente no son capaces de pasar el poco tiempo que tienen libre explorando todas las materias de seguridad pertenecientes a sus sistemas. Combinado esto con el hecho de que no tienen un acceso facil a este tipo de informacion da como resultado sistemas pobremente defendidos. 

Esperamos (modetamente) que este documento provea de datos muy necesarios sobre como los sistemas son crackeados, y mas aun, explique por que se 
deben de dar ciertos pasos para proteger un sistema. El saber por que algo es un problema es, en nuestra opinion, la clave para aprender y hacer una eleccion informada e inteleginte para lo que la seguridad de tu sistema significa de verdad.
-----

Apendice A:

SATAN (Security Analysis Tool for Auditing Networks)

Concebido originalmente hace unos años, SATAN es actualmente el prototipo 
de una vision mas amplia y comprensible de una herramineta de seguridad. En 
su encarnacion actual, SATAN prueba e informa remotamente acerca de varios 
bugs y debilidades en servicios de red y sistemas basados en ventanas, asi 
como tambien detalla tanta informacion util sobre la victima como le es 
posible. Entonces procesa los datos con un filtro y con lo que se 
calificaria como un sistema experto para al final generar el analisis de 
seguridad. A pesar de no ser particularmente rapido, es extremadamente 
adaptable y facil de modificar.


SATAN consiste en varios sub-programas, cada uno de los cuales es un 
fichero ejecutable (perl, shell, binario compilado en C, lo que sea) que 
testea un host para una debilidad potencial dada. El añadir futuros 
programas de testeo es tan facil como poner un ejecutable en el directorio 
principal con la extension ".sat"; el programa principal lo ejecutara 
automaticamente. Este genera una serie de blancos (usando DNS y una version 
rapida de ping a la vez para llegar a los blancos en directo), y despues 
ejecuta cada uno de los programas sobre cada uno de los blancos. Un 
programa de interpretacion/filtrado de datos analiza despues el resultado, 
y finalmente un programa de informes digiere todo para ponerlo en un 
formato mas leible.

El paquete entero, incluyendo el codigo fuente y la documentacion, estara 
disponible libremente al publico, via ftp anonimo y postenadolo a uno de 
los numerosos foros sobre codigo fuente de Usenet.

Apendice B

Un estudio informal llevado a cabo en al menos una docena de sites en 
Internet (educacionales, militares, y comerciales, con unos 200 hosts y 
4000 cuentas) revelo que como media, alrededor del 10% de las cuentas de un 
site tenian archivos .rhosts. Cada uno de estos archivos promediaba 6 hosts 
confiados; sin embargo, no era raro el tener unas 100 entradas en el 
archivo .rhosts de una cuenta, y en algunas ocasiones, esta cifra estaba 
alrededor de 500! (Este no es un record del que uno deberia estar orgulloso 
de poseer). Adicionalmente, cada uno de los sites directamente en Internet 
(un site estaba practicamente tras un firewall) confiaba en un usuario o 
host en otro site - asi que, la seguridad del site no estaba bajo el 
control directo del administrador de sistema. Los sites mas grandes, con 
mas usuarios y hosts, tenian un porcentaje mas bajo de usuarios con 
archivos .rhosts, pero el tamaño de estos archivos era mayor, asi como el 
numero de hosts remotos de confianza.

Aunque fue muy dificil el verificar cuantas de las entradas fueron validas, 
con nombres de host tales como "Makefile", "Message-Id:", and
"^Cs^A^C^M^Ci^C^MpNu^L^Z^O", asi como unas pocas entradas de wildcard, nos 
cuestionamos la sensatez de poner la seguridad de un site en manos de sus 
usuarios. Muchos usuarios (especialmente los poseedores de largos archivos 
.rhosts) intentaron poner comentarios tipo shell en sus archivos .rhosts, 
que son intentados reolver como nombre de host validos por muchos sistemas 
UNIX. Desafortunadamente, un atacante puede entonces usar las tecnicas DNS 
y NIS de engaño del nombre de host discutidas antes para fijar sus nombres 
de host como "#" y entrar libremente. Esto pone en riesgo a muchos sites 
(al menos una distribucion es dada con comentarios en sus archivos 
/etc/hosts.equiv).

Podrias pensar que estos sites no son tipicos, y, de hecho, no lo eran. 
Virtualmente todos los administradores saben un monton sobre seguridad y 
escriben programas de seguridad como hobby o como profesion, y muchos de 
los sites para los que trabajaron hicieron estudios de seguridad o crearon 
roductos de seguridad. Solo podemos suponernos como sera un site "tipico".
apendice C:

Despues de recibir mail de un site que habia sido violado desde uno de 
nuestros sistemas, se inicio una investigacion. Con el tiempo, encontramos 
que el intruso estaba haciendolo desde una lista de sites ".com" 
(comerciales), buscando hosts con ficheros de password faciles de robar. En 
este caso, "facil de robar" se refiere a sites con un nobre de dominio NIS 
facil de adivinar y un servidor NIS de facil acceso. Sin saber cuan lejos 
habia llegado el intruso, parecia una buena idea el alertar a los sites que 
eran en si vulnerables al robo de passwords. De los 656 hosts de la lista 
del intruso, 24 tenian archivos de password susceptibles de robo - 1 de 
cada 25 hosts mas o menos!!. Un tercio de estos archivos contenia al menos 
una cuenta sin password con shell interactivo. Con un total de 1594 
entradas, a una media de 10 minutos corriendo un password cracker (Crack) 
daria mas de 50 passwords, usando una estacion de trabajo Sun de gama baja.
Otros 40 mas se encontaron en los siguientes 20 minutos; y un password de 
la cuenta root se encontro en solo 1 hora. El resultado despues de unos 
dias de crackeo fue: 5 passwords root, 19 de 24 archivos de password (80%) 
con al menos un password conocido, y 259 de 1594 (1 sexto) passwords 
adivinados.

Apendice D:

Como conseguir metodos de seguridad gratis en Internet

Listas de mail:

o The CERT (Computer Emergency Response Team) advisory mailing list. Mandar e-mail a cert@cert.org, y pedir que se te ponga en su lista de mail.

o The Phrack newsletter. Mandar e-mail a phrack@well.sf.ca.us y pedir que se te añada en la lista.

o The Firewalls mailing list. majordomo@greatcircle.com 
Poner lo siguiente:

subscribe firewalls

o Computer Underground Digest. Mandar e-mail a tk0jut2@mvs.cso.niu.edu, pidiendo que te pongan en la lista.

Software gratis:


COPS (Computer Oracle and Password System) disponible via ftp anonimo fde archive.cis.ohio-state.edu, in pub/cops/1.04+.

The tcp wrappers disponibles via ftp anonimo de ftp.win.tue.nl,
in pub/security.

Crack esta disponible en ftp.uu.net, in /usenet/comp.sources.misc/volume28.

TAMU is a UNIX auditing tool that is part of a larger suite of excellent tools put out by a group at the Texas A&M University. They can be gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU.

Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources.

Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.

Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib.

The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail.

Tripwire, a UNIX filesystem integrity checker+, is available via anonymous ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire.