Seguridad de Anfitriones

Seguridad de Aplicaciones
Veamos una clase de técnicas dirigidas a los protocolos de
aplicación que corren encima de TCP/IP:
Ataques de sondeo:
• Finger: Puede revelar información “interesante” sobre un
usuario (nombre real, teléfono, oficina, etc.). Esto es útil para
montar un ataque a su contraseña. Además, una cuenta que no
ha sido usada en mucho tiempo, es un buen blanco – puede
tener una contraseña “fácil” (ej. la cuenta guest), y si se usa
probablemente nadie se va a enterar.
• TCP fingerprinting: Existen programas (ej. queso) que
pueden identificar el sistema de operación de una máquina
remota con bastante precisión. Esto le ayuda a Manuel en
evaluar qué tipo de ataque puede tener éxito, el tamaño
esperado de los buffers remotos, etc.
• Banners: El texto introductorio que aparece cuando uno se
conecta por un puerto FTP, Telnet, SMTP etc. puede revelar
bastante información, incluyendo la versión del software y
sistema de operación, quizás el verdadero nombre de la
máquina, su arquitectura, etc.
• Comandos como “showmount -e” dan información, por
ejemplo sobre volumenes exportados por NFS. Los que estan
exportados para lectura y escritura son los más interesantes . . .
March 8, 2000
Seguridad de Aplicaciones-1
Ataques Locales
Suponemos que Manuel puede interactuar con una máquina
remota, por ejemplo:
• Puede hacer login como usuario. Si no tiene cuenta, quizás
puede robarse una (escuchando contraseñas en la red).
• Se presenta como cliente de un servidor público (de FTP, Web,
correo, etc.)
El programa con el cuale él interactua en el servidor
tı́picamente ejecuta con permisos especiales. Por ejemplo, en
Unix muchos “demonios” tienen la propiedad de ser setuid, es
decir que ejecutan con los privilegios de su dueño y no de los
del usuario que los llama.
Los “bugs” en tales programas son especialmente peligrosos,
por que pueden dejar que Manuel los manipule.
March 8, 2000
Seguridad de Aplicaciones-2
Desbordaje de Buffers
El ataque favorito es aprovechar la falta de cuidado en el
chequeo de parámetros, por ejemplo:
{
char buffer[16];
printf ("Nombre: ");
gets (buffer); /* Leer nombre */
...
Nombre: unstringextremadamentelargo
El programa no chequea el tamaño de su entrada. Como esta
es más grande que el espacio reservado, se desborda el arreglo
buffer y se sobreescribe la pila. Con suficiente cuidado,
Manuel puede insertar instrucciones de máquina para que el
programa ejecute una llamada al sistema similar a:
system ("/bin/sh");
Ahora tiene un Shell corriendo en el servidor, con los
privilegios del dueño del programa. Si éste es root, mejor
todavı́a . . .
March 8, 2000
Seguridad de Aplicaciones-3
Hay varias técnicas de defensa contra este tipo de problema:
• Algunos sistemas (ej. Linux) tienen una opción en el kernel
para que el segmento de pila no sea ejecutable. En ciertos
casos (no comunes) esto puede romper algunos programas, y
en todo caso no es una solución 100% efectivo.
• Un producto llamado Stackguard (www.immunix.org)
envuelve las llamadas a funciones en código especial que
permite detectar cuando la dirección de retorno en la pila ha
sido alterada. Tampoco es 100% efectivo.
• Exhortar a los programadores a tener más cuidado cuando
crean programas setuid. Además, realizar auditorias para
que otros puedan revisar el código (por ejemplo el grupo
Open BSD se dedica a esto). En este contrxto el acceso al
código fuente es crı́tico.
March 8, 2000
Seguridad de Aplicaciones-4
Ataques de Diccionario
En el caso en que Manuel puede hacer login en la máquina
remota, puede leer el archivo /etc/passwd y montar un
ataque de búsqueda exhaustiva. Defensas:
• No guardar el hash de las contraseñas directamente en
/etc/passwd sino en otro archivo, /etc/shadow. Este
último puede ser protegido contra lectura por procesos
no-privilegiados. Todo sistema Unix moderno soporta esto
(pero el administrador tiene que habilitarlo). A veces Manuel
puede montar un contraataque: causa que el programa
privilegiado aborte, dejando una imagen de su memoria en un
archivo core que él puede leer (esto requiere algo de
preparación previa).
• Usar un algoritmo de “hashing” más fuerte que el normal. En
Linux, se puede usar MD5, con contraseñas más largas que los
tradicionales 8 caracteres. Nuevamente, el administrador tiene
que habilitar esto explı́citamente.
Nótese que a veces Manuel puede obtener una copia de
/etc/passwd sin necesidad de hacer login. Algunos
sistemas viejos de correo electrónico son tan ingénuos que
Manuel les puede convencer a que le envien cualquier archivo
en el sistema . . .
March 8, 2000
Seguridad de Aplicaciones-5
Problemas con X-Windows
X11 define un protocolo cliente-servidor, donde el servidor
maneja la pantalla del usuario y los clientes son programas de
aplicación. Puede funcionar sobre un protocolo de transporte
de red, tı́picamente TCP, para el acceso desde sistemas
remotos. Si no hay cuidado con el control de permisos, hay
varios problemas potenciales:
• Los eventos (“refrescar pantalla”, “movimiento del mouse”,
“tecla presionada”, etc.) pueden ser monitoreados
remotamente.
• En el peor caso, Manuel puede colocar una ventana
transparente que cubra toda la pantalla de su victima. Todos
los eventos le serán enviados. Puede también introducir
eventos (por ejemplo, ejecutar comandos en ventanas xterm).
• Existen programas (ej. xwd) para hacer un “screen dump” –
tomar una foto de una ventana. Con ellos Manuel puede captar
el contenido de un documento, por ejemplo.
Todo se facilita por que muchos usuarios no configuran bien
sus sesiones de X11. Es muy fácil usar “xhost +” para
quitar protecciones cuando las mismas molestan.
Hay un sistema de autenticación llamado X cookies que ayuda
en la defensa, pero a veces es fastidioso configurar. De todas
maneras, no encripta las sesiones (aunque con el programa
ssh esto también se puede hacer).
March 8, 2000
Seguridad de Aplicaciones-6
Condiciones de Carrera
Otro tipo de ataque explota pequeñas ventanas de tiempo en
que un sistema es vulnerable. Por ejemplo, es muy común en
las aplicaciones crear un archivo temporal en el directorio
/tmp, y luego borrarlo unos segundos después. Esto requiere
que se genere un nombre para dicho archivo, que no coincida
con otro ya existente:
for (;;) {
generar nombre aleatorio en /tmp
si /tmp/nombre-nuevo no existe {
crear /tmp/nombre-nuevo /* X */
break
}
}
Si Manuel es suficientemente astuto, puede predecir el valor
de nombre-nuevo y justamente en el punto “X” crear un
enlace simbólico con ese nombre, apuntando a un archivo de
su elección, por ejemplo /etc/passwd . . .
Defensa: crear nombres temporales atómicamente es
“truculento” pero hay rutinas de librerı́a que lo pueden hacer.
Uselas.
March 8, 2000
Seguridad de Aplicaciones-7
Rootkits
Si Manuel logra obtener privilegios de root, procede a
encubrir sus acciones:
• Instala nuevos binarios de comandos importantes, por ejemplo
con una “puerta trasera” para que le sea más fácil entrar la
próxima vez.
• En los sistemas que permiten cargar módulos dinámicos del
sistema de operación, puede colocar un módulo suyo para
tomar control total sobre el sistema atacado.
• Cambia el comportamiento de los utilitarios que hacen
“logging” en el sistema para que no le rastrean.
• Altera los logs existentes (/var/log/wtmp etc.) para quitar
la evidencia de su penetración, y cambia las fechas de
modificación de archivos claves (/etc/passwd etc.) para
que no se note que han cambiado.
Para facilitar estas acciones (que requieren de bastante
sofisticación) puede utilizar un “rootkit” o paquete preparado
por un experto. Disponible en los mejores sitios del Internet.
Defensa: el sistema Tripwire mantiene una base de datos con
un hash criptográficamente fuerte de todo archivo importante,
y puede detectar cualquier cambio. La base de datos debe ser
guardado en otro sitio que no sea vulnerable. Nótese que el
programa tripwire en sı́ es un punto vulnerable a ataques.
March 8, 2000
Seguridad de Aplicaciones-8
Debilidades de Aplicaciones
Veamos algunas vulnerabilidades conocidas en sistemas Unix.
Todos pueden ser tapadas, pero el administrador tiene que
saber qué está haciendo.
Los Comandos ’r’
La mayorı́a de las versiones de Unix tienen este “feature”
(bug), el cual es derivado de BSD. Es decir soportan
comandos como rsh, rexec, rlogin, etc. que consultan a
los archivos /etc/hosts.equiv y $HOME/.rhosts
para ver si “confian” en un anfitrión o usuario remoto. Si
Manuel puede alterar dichos archivos, efectivamente abre las
puertas. Más aún, tienen el efecto que la seguridad de nuestro
sistema puede ser comprometida por la inseguridad de otros
en loc cuales nuestros suarios “confian”. La mejor defensa es
prohibir a los usuarios el uso de estos archivos, pero puede ser
polı́ticamente dificil.
TFTP
El protocolo TFTP (usado para booting de estaciones de
trabajo) es muy poco cuidadoso, y puede ser convencido a
transferir cualquier archivo si no está bien configurado:
$ tftp cretino.inocente.bobo.com
tftp> get /etc/passwd /tmp/passwd
Received 1205 bytes in 0.5 seconds
tftp> quit
$ crack < /tmp/passwd
March 8, 2000
Seguridad de Aplicaciones-9
FTP
FTP usa un sistema sencillo de contraseñas, las cuales pueden
ser escuchadas. Además, el FTP Anónimo deja entrar
cualquier usuario, por lo tanto las detalles de configuración del
mismo son sumamente importantes. (Ej. tiene que correr
como root porque usa puertos privilegiados . . . ). Algunos
servidores hacen una consulta inversa a DNS para chequear el
nombre del anfitrión cliente, pero esto es vulnerable (ver
despues).
Algunas reglas para servidores FTP:
• El demonio debe hacer un chroot() para limitar su acceso
al sistema de archivos del anfitrión. Esto implica usar un
directorio /bin propio para el demonio, incluyendo copias de
las librerı́as compartidas, y también un directorio particular
de “dispositivos” (/dev).
• Proteger todo archivo y directorio en el área FTP contra
escritura. Ninguno de estos debe pertenecer al “login” FTP –
el proceso demonio corre con esta identidad.
• No dejar un archivo /etc/passwd real en el área (tiene que
existir uno falso porque se usa).
• Pensar tres veces antes de crear un directorio público
(incoming). Es un blanco favorito para software pirateado.
March 8, 2000
Seguridad de Aplicaciones-10
DNS
Tı́picamente DNS maneja mapas directos e inversos, pero no
necesariamente hay coherencia entre ellos. Si Manuel controla
parte del árbol inverso, algunos anfitriones se van a engañar
cuando usan una consulta inversa para autentificar una
máquina (ej. un cliente FTP). Cierta protección se puede
lograr si el resultado de la consulta inversa se aplica a una
consulta directa para chequear.
Si Manuel tiene acceso al cache de consultas del victima,
puede contaminarlo de tal manera que el chequeo anterior
parece confirmar la autenticidad.
Una variante es inundar el servidor DNS del victima con
respuestas falsas. Versiones recientes (de bind por ejemplo)
pueden resistir esto. En todo caso, no se debe confiar en
autentificación basada en los nombres de máquinas. Utilizar
las direcciones IP es mejor, aunque sea débil.
Algunos resolvers hacen esto: un usuario en el dominio
ldc.usb.ve trata de contactar a cd.pir.com. El resolver
intenta con cd.pir.com.ldc.usb.ve,
cd.pir.usb.com.ve, y cd.pir.com.ve, antes de
cd.pir.com. Manuel puede crear un dominio en
pir.com.ve . . .
March 8, 2000
Seguridad de Aplicaciones-11
Correo
POP (Post Office Protocol) es simplista, aunque sı́ pide una
contraseña del usuario. Hay propuestas para usar one-time
passwords, ej. con el sistema S/KEY.
El protocolo SMTP es aún más simplista por que ni siquiera
intenta autentificar el usuario (para sorpresa de muchos
usuarios). Por ejemplo, es trivial falsificar un mensaje (usando
MAIL FROM en una sesión Telnet al puerto 25).
Además, el programa sendmail es uno de los más
complejos y problemáticos en el universo Unix, y
frecuentemente corre como root. Mejoras alternativas
incluyen postfix, qmail y exim, pero ninguno es 100%
compatible con sendmail y usarlos puede implicar un
cambio no transparente para los usuarios. De todas maneras,
tampoco hacen autentificación (algunos pueden soportar un
modo “SMTP después de POP” para tratar de reducir la
vulnerabilidad, pero esto no es estandarizado).
Otros
RPC, Portmapper, NIS, NFS, IMAP, SNMP, NNTP . . .
March 8, 2000
Seguridad de Aplicaciones-12