Seguridad de Aplicaciones-1

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... 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. 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... 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. 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... 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). 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. 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. 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 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. 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... 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... Seguridad de Aplicaciones-12