Soluciones Avanzadas No.33, 15 de Mayo 96

 

El Factor Humano


Daniel M. Germán y Alejandro López-Ortiz
dmg@csg.uwaterloo.ca y alopez-o@daisy.uwaterloo.ca

Hace algunos días, uno de nosotros (que llamaremos D a partir de aquí), pasó a formar parte del grupo de administradores de los sistemas de cómputo en la Universidad de Waterloo. Para tener acceso a los privilegios de superusuario, se utiliza el sistema de autenticación de Kerberos. Para ser dado de alta en este sistema, es necesario visitar personalmente al encargado de Kerberos, a quien llamaremos K. K requiere que cada nuevo usuario del sistema inserte su nueva contraseña. En la oficina de K, D se autopresentó y K le pidió que tecleara su nueva contraseña en un programa que verificó que ésta fuera segura (que no fuera un nombre propio, una fecha, una palabra en inglés, entre otras). Después de convencerse que la contraseña era aparentemente segura, K procedió a crear la cuenta y a dar de alta la contraseña. Minutos después K se presenta en la oficina de D y le dice: "Te he dado acceso de superusuario a nuestras máquinas y no t e pedí identificación, he deshabilitado tu cuenta".

El problema era simple, K no conocía a D y sin embargo le había dado los medios para que entrara como superusuario a algunas de las máquinas de la universidad, lo que es un riesgo de seguridad. Esto ilustra las formas tan variadas en que un sistema de cómputo puede ser penetrado por intrusos. El reciente caso del hacker Kevin Mitchner ilustra esto. A Mitchner se le acusa de haber obtenido un sinnúmero de contraseñas y privilegios en sistemas de cómputo, simplemente hablando por teléfono con los administradores de sistemas y haciéndose pasar por un usuario con derecho genuino de acceso a la contraseña. Por esto las políticas del centro de cómputo en la Universidad de Waterloo especifican que cuando se le permite cambiar la contraseña de alguna cuenta a alguna persona, se debe autenticar dicha persona con una identificación.

Hace algún tiempo se comentó ampliamente en Internet que la implementación de SSL de Netscape no era segura y que un grupo de estudiantes de la Universidad de Berkeley había logrado romper la comunicación entre Netscape Navigator y Netscape Communicacions Server. La forma en que se realizó está documentada en [1]. Cualquier implementación híbrida requiere generar llaves DES aleatorias, pero generar números realmente aleatorios no es un problema trivial. Después de hacer ingeniería en reversa ( reverse engineering), los atacantes lograron determinar parte del algoritmo para generar las llaves aleatorias y la información que se utilizaba como entrada. Al parecer, el número de proceso de Netscape, el número del proceso padre y la hora del día eran utilizados. Procedieron entonces a atacar desde dos posiciones: en la misma computadora y en otra. En ambos casos la hora del día es una cantidad accesible a cualquiera. En el primer caso el número de proceso es también disponible a cualquiera. Desde ot ra computadora, el número de proceso de un programa no se puede conocer, pero sí el número de proceso del último programa ejecutado. Así que, obteniendo este número y suponiendo que Netscape es un proceso reciente, se puede intentar adivinar, por prueba y error, el número de proceso. Al conocer ambos datos, no es necesaria una búsqueda exhaustiva para encontrar la llave DES, pues el espacio de búsqueda es considerablemente menor si se cuenta con indicios de los números pseudoaleatorios usados por Netscape.

Las instituciones que deseen utilizar criptografía de llave pública notarán que, a pesar de que pueden utilizar llaves tan grandes como deseen, siempre tendrán el problema de almacenamiento de la llave. ¿Cómo garantizar que la llave está en un lugar seguro? ¿Cómo asegurar que ninguna de las personas que la conoce la emplee mal? o, en su defecto, ¿cómo asegurar que nadie conoce la llave completa? Recordemos que la llave privada tendrá que ser utilizada cada vez que se desee descifrar o firmar electrónicamente un documento. PGP parte del supuesto que la llave será utilizada solamente por una persona y que dicha persona conservará la llave cifrada en una computadora segura. Las instituciones tendrán que seguir mecanismos complejos para asegurar que sus llaves se mantienen en secreto. El punto más débil en un sistema seguro de cómputo suele ser la chapa de la puerta donde está almacenada la computadora.

Los sistemas híbridos han mostrado que son seguros en teoría. En la práctica, las implementaciones pueden contener fallas que reduzcan notablemente su seguridad. Por otro lado, los usuarios pueden ser la principal fuente de riesgo. Para poder obtener el mayor nivel de seguridad posible es necesario utilizar implementaciones que hayan sido ampliamente probadas y, mejor aún, que su código fuente esté abierto al análisis de los expertos para detectar posibles fallas; además es necesario educar a los usuarios para que entiendan la necesidad de mantener las llaves privadas seguras. La seguridad no sirve mucho si la secretaria tiene escrita la clave de acceso en una nota amarilla en el primer cajón de su escritorio.

En conclusión, en teoría existen los medios suficientes para que a través de la Red se realicen transacciones seguras; sin embargo, los errores en las implementaciones, las restricciones de exportación desde los Estados Unidos y, sobre todo, la falta de educación de sus usuarios en cuestiones de seguridad, son sus principales obstáculos, los cuales poco a poco se sortearán y no dudamos que en pocos años Internet se convierta en un auténtico mercado electrónico.

-----------------------------------------------------------------------------------------

Fé de Erratas


En números anteriores, durante el proceso de edición se ha reemplazado la palabra autenticar por autentificar. Nosotros favorecemos el uso de la primera sobre la segunda y hemos optado por "autenticar".

En el número 31 (Marzo 96) dice "con una de 256 bits sería virtualmente imposible lograrlo aun utilizando toda la energía del universo", pero debimos agregar: "utilizando el algoritmo de fuerza bruta".
-----------------------------------------------------------------------------------------

Referencia


[1] Goldberg, I., y Wagner, D., "Randomness and the Netscape Browser", Dr. Dobb Journal, Enero, 1996, pp. 66-70