Resumen

  • COPS convirtió fallos Unix conocidos —contraseñas débiles, permisos demasiado abiertos y archivos de inicio expuestos— en comprobaciones repetibles en un host local.
  • Sus programas configurables informaban de posibles problemas, pero no los reparaban. La mayoría no precisaba root; la búsqueda más amplia de archivos SUID iba aparte y necesitaba privilegios.
  • Un informe sin alertas describía las comprobaciones configuradas y lo que alcanzaron en ese momento. No certificaba seguridad completa ni ausencia de cambios posteriores.

Encontrar una y otra vez los fallos corrientes

El artículo de 1990 parte de una observación práctica: la literatura sobre Unix volvía a los mismos defectos. Los programas SUID, los permisos excesivos y las contraseñas débiles a menudo eran fáciles de corregir una vez descubiertos. Lo difícil era buscarlos de nuevo mientras cambiaban las instalaciones. Farmer y Spafford quisieron hacer rutinaria esa inspección.

COPS —“Computerized Oracle and Password System”— no era un escáner de red. Un script principal reunía la salida de alrededor de una docena de subprogramas y la enviaba al administrador local o la guardaba en un archivo. La mayoría usaba Bourne shell y herramientas habituales de Unix; algunos programas pequeños en C completaban el conjunto. Los componentes podían ajustarse o sustituirse para cada sitio.

Las pruebas se dirigían a elementos concretos: archivos y directorios configurados como escribibles por cualquiera; contraseñas iguales al nombre de usuario o basadas en palabras comunes; errores en las bases de cuentas y grupos; archivos modificables invocados por cron o por scripts de inicio; permisos de ciertos dispositivos; directorios personales y archivos de inicialización; umask de root y rutas de búsqueda que incluyeran el directorio actual. suidchk comparaba el conjunto de archivos SUID con el de una ejecución anterior. Kuang aplicaba reglas para analizar si un usuario podía llegar a comprometer la cuenta objetivo según ellas.

Ese alcance explica mejor COPS que la frase “escáner de seguridad”. Reducía el coste de repetir una serie conocida de comprobaciones locales; no cubría todos los fallos posibles ni decidía si cada permiso infringía la política del sitio.

La herramienta se detenía antes de reparar

Los autores decidieron que COPS informara sin modificar el host. Dos instalaciones similares pueden atender tareas, datos y necesidades de acceso distintos. Un ajuste aceptable en una puede ser inadmisible en otra. La reparación automática habría convertido un hallazgo técnico en una decisión de política para la que el programa no tenía contexto.

La misma cautela se aplicaba a los privilegios. El artículo dice que las herramientas, salvo la búsqueda SUID, no estaban pensadas para ejecutarse como root. Esa búsqueda solía separarse: podía tardar más y necesitaba acceder a directorios que no estaban disponibles para cuentas normales. Así se reducían los privilegios de la inspección habitual, aunque el alcance del informe dependía de cómo se ejecutara cada componente.

Los autores recomendaban programar ejecuciones con at o cron, ya que un problema ausente hoy podría surgir después. La periodicidad no garantizaba exhaustividad. Cambiar el verificador o la lista de rutas podía inducir a error; un atacante podía leer los informes o modificar la herramienta; varias ejecuciones limpias podían generar complacencia. Los cambios en el funcionamiento del sistema también podían crear defectos fuera de las pruebas existentes.

Qué permite afirmar la evidencia

Farmer y Spafford recibieron comentarios de centros académicos, gubernamentales y comerciales. Dijeron que más de la mitad de los sistemas probados o descritos en esos comentarios tenían condiciones que podían comprometer root. Aclararon que no sabían si esa observación limitada era generalizable a una población mayor: no es una estimación para todos los sistemas Unix.

COPS y el SATAN posterior de Farmer observaban superficies distintas: COPS revisaba cuentas, archivos, permisos e inicio locales; SATAN examinaba servicios de red y la exposición visible desde otros hosts. Compartir autor no vuelve intercambiables sus informes.

La Nota 65 de Heng Lu se usa solo como lente editorial: las afirmaciones sobre un sistema en marcha no deben exceder lo observado por las pruebas ejecutadas. Para COPS, eso exige preguntar qué comprobaciones corrieron, con qué acceso, sobre qué rutas y cuándo. La automatización facilita repetir una lista; el operador conserva la responsabilidad del alcance, la protección de los informes, su interpretación y las correcciones.

Fuentes