fallo en una distribución de Linux (debian)

Vie Mayo 30 16:22:51 BST 2008

Mauricio José Adonis Carrasco escribió:
> El jue, 29-05-2008 a las 16:05 -0300, walter escribió:
>   
>> llegue a esta noticia,  por  la lista de Opensuse..
>> alguien sabe algo mas?
>> tengo algunos servidores  Funcionando......
>>
>> http://www.elpais.com/articulo/red/fallo/distribucion/Linux/pone/peligro/millones/maquinas/Internet/elpeputeccib/20080529elpcibenr_2/Tes
>>
>>
>>
>>
>> -- 
>> Walter
>> www.infoquil.com.ar
>>
>>
>>     
>
> El problema y SUS CONSECUENCIAS	lo explica claramente el sitio de hispasec...
>
>
> El problema encontrado en OpenSSL de Debian puede ser considerado,
> lamentablemente, un verdadero acontecimiento criptográfico. La
> criptografía es una ciencia compleja, y con el ánimo de aclarar las
> graves y extensas consecuencias del fallo, hemos redactado una serie
> de preguntas frecuentas para intentar, aun tratándose de un tema tan
> complejo, arrojar algo de luz.
>
> ¿Qué ha pasado exactamente?
>
> Alguien (por error) del equipo de Debian eliminó una línea de código
> en el paquete OpenSSL de Debian que ayudaba a generar la entropía al
> calcular el par de claves pública y privada. Las claves sólo se
> calculaban tomando como semilla el PID del proceso. Al estar limitado
> a 32.768 semillas (tantos como PIDs de proceso son posibles) para la
> generación de números seudoaleatorios, el número de claves posibles es
> pequeño. Se han estado generando las mismas claves dentro de este número
> limitado de posibilidades desde septiembre de 2006. Como son pocas y de
> entropía pobre, se puede deducir la clave privada a partir de la pública
> porque el espacio de primos es muy pequeño y está precalculado. Ya se
> han generado listas disponibles para todos con la clave pública (del
> espacio a que han quedado limitado después del fallo) y su
> correspondiente privada. Para los usuarios de este OpenSSL de Debian
> sin entropía suficiente, se han roto las reglas de la criptografía
> asimétrica en la que por ahora confiamos todos y que sustentan las bases
> de la (poca) seguridad y confianza que pueda existir en Internet.
>
> ¿Es tan grave como parece?
>
> Es más grave. Mucho más grave. Podríamos considerar que la criptografía
> de Debian en los últimos dos años ha sido una pantomima. Y es grave
> además porque no se resuelve por completo parcheando. Esa no es la
> solución definitiva. Hay que regenerar claves, revocar las antiguas,
> certificarlas en el caso de SSL, comprobar dónde fueron a parar claves
> generadas con Debian... No es un bug en un programa que eventualmente
> quedará obsoleto porque todo el mundo estará parcheado. Habrá
> administradores que no comprueben la debilidad sus claves, servidores
> SSL que jamás certifiquen de nuevo sus claves, claves perdidas de
> usuarios que dejen la puerta abierta a servidores SSH... También es
> grave porque arrastra a decenas de programas y sistemas que se valen de
> claves generadas con OpenSSL. SSL, SSH, OpenVPN, DNSSEC... Alguien lo
> ha calificado de "apocalipsis criptográfico". Además los principales
> perjudicados son los servidores que precisamente hayan buscado más
> seguridad con la criptografía de clave pública, porque contenían
> información crítica.
>
> El SANS Internet Storm Center ha elevado el nivel de alerta general a
> 'amarillo'. No ocurre a menudo.
>
> ¿Cómo ha podido ocurrir?
>
> Ha sido todo un desafortunado error. Aunque surgirán las teorías
> conspiratorias porque el código abierto ha estado ahí durante dos años,
> no ha sido hasta que Luciano Bello se ha dado cuenta que se ha corregido
> el fallo y se ha dado la voz de alarma. Pero el daño ya está hecho. Dos
> años de claves débiles generándose en cientos de miles de sistemas. Ha
> pasado desapercibido porque en general cualquier programa es complejo,
> pero la criptografía lo es aún más. Además, Bruce Schneier dijo algo así
> como 'Good security looks the same as bad security' ('La buena seguridad
> se ve igual que la mala', frase aplicable aún más a la criptografía).
>
> Kurt Roeckx fue quien planteó en un principio borrar líneas que
> consideraba problemáticas. Existe un correo de 2006 en una lista
> pública, en el que Roeckx plantea en una lista de OpenSSL qué pasaría
> si las eliminara. Pregunta si resultaría en una posible pérdida de
> aleatoriedad. La respuesta no oficial desde OpenSSL es que "no mucho" y
> que es partidario de borrarlas si ayuda en la depuración. Y era cierto,
> esas líneas no suponían problema: el problema es que en Debian se
> borraron más líneas de la cuenta, de las habladas en la conversación
> y para colmo los cambios no se enviaron a OpenSSL para que fueran
> revisados.
>
> ¿Se soluciona parcheando?
>
> No. No se trata de un fallo de seguridad al uso. Ha existido una fuente
> de claves inseguras que se han esparcido durante dos años. Hay que
> comprobar y regenerar claves. El fallo fue anunciado a la vez que el
> parche, pero hay que tener en cuenta, que las primeras versiones de los
> parches para Debian y Ubuntu contenían regresiones. Han publicado nuevas
> actualizaciones para los propios parches que es necesario aplicar
> también.
>
> ¿Qué pasa si tengo un servidor web con acceso por HTTPS?
>
> Si las claves han sido generadas con la versión de OpenSSL con el
> problema, las consecuencias son que alguien se puede hacer pasar por el
> servidor porque tendrá la privada de forma instantánea a partir de la
> pública. Además, cualquiera que haya tenido acceso a una conversación
> cifrada con el servidor, podría también descifrarla. Esto es así porque
> la clave simétrica que se utiliza para el cifrado ha sido intercambiada
> con la ayuda de claves asimétricas débiles. Un administrador debe además
> revocar la clave, generar una nueva, enviarla a la Autoridad
> Certificadora (que cobra por certificar) e instalarla. La catástrofe
> hubiese sito total, si una Autoridad Certficadora, hubiese generado
> claves y firmado certificados con estas claves débiles, pues el problema
> se extendería hacia abajo a todos sus clientes, en cuyos certificados ya
> no se podría confiar. Al parecer han comprobado que las principales
> Autoridades no se ven afectadas.
>
> ¿Qué pasa con SSH?
>
> Los administradores que controlan sus sistemas a través de SSH se suelen
> autenticar a través de su clave privada y el servidor de SSH almacena la
> pública correspondiente. Esto es más seguro que usar una sola contraseña
> simétrica para autenticarse. El servidor cifra una cadena con la clave
> pública del que pretende autenticarse y se la envía, si puede
> descifrarla le deja pasar. En este caso puede que la clave pública sea
> realmente pública o no. En el primer caso, deducir la privada es
> instantáneo, y en el segundo caso, si no se conoce la pública, se debe
> hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño,
> algo que tarda unos 20 minutos con un ordenador de hoy día. Se ha creado
> un exploit para esto.
>
> Todos los administradores que permitan a sus usuarios utilizar la clave
> privada para acceder a sus sistemas a través de SSH, deben auditar las
> claves para saber si son de las "débiles". Los administradores de SSH
> también se encuentran ante una tarea concienzuda, peligrosa, (y que
> deben emprender ya) incluso si no utilizan Debian, porque puede que sus
> claves hayan sido generadas en una distribución Debian y exportadas.
>
> Los administradores de SSH comprobarán, con total seguridad, como los
> intentos de acceso ilegítimo se multiplican en estos días.
>
> ¿A Windows le pasó lo mismo?
>
> No. Se demostró que el generador de números aleatorios de Windows era
> débil, pero la diferencia es que según el estudio, había que conocer el
> estado previo del generador para saber el siguiente cálculo. Esto podría
> permitir descifrar conversaciones SSL entre dos sistemas. Pero para
> poder llegar a tener acceso a esa información inicial de la que se
> deducirían el resto de "estados del algoritmo", un atacante necesitaría
> poder tener acceso como administrador en el sistema. Digamos que para
> poder aprovechar el problema del algoritmo y poder descifrar la
> información, necesitaría tener el total control de la máquina para
> llegar a conocer un estado, con lo que el sistema ya estaría
> comprometido en sí.
>
> Conclusiones
>
> Lo peor no está ocurriendo ahora. Lo verdaderamente grave ha podido
> ocurrir antes (en los últimos dos años si alguien ha conocido este error
> y lo hubiese mantenido en secreto) y después (lo que nos espera a medida
> que se vaya descubriendo que sistemas importantes ha generado claves
> débiles).
>
> http://www.hispasec.com/unaaldia/3492
>
> Saludos.
>   
Gracias por responder....  cuando salio el tema... yo corri parches y 
demas....
no se porque lei la noticia y para mi fue como novedad...
quizas la lei dormido.... asi que perdon, por retornar al tema

Saludos

-- 
Walter
www.infoquil.com.ar