¿Cómo corrijo / soluciono la vulnerabilidad SSLV3 POODLE (CVE-2014-3566)?

158

Después del ataque BEAST y Error Heartbleed , ahora he escuchado sobre una nueva vulnerabilidad en SSL / TLS llamada POODLE . ¿Cómo me protejo contra ser explotado?

  • ¿Solo se ven afectados los servidores o los clientes?
  • ¿Es este OpenSSL / GnuTLS específico?
  • ¿Qué tipo de servicios se ven afectados? ¿Solo HTTPS o también IMAPS, SMTPS, OpenVPN, etc.?

Por favor, muéstrame ejemplos sobre cómo evitar esta vulnerabilidad.

    
pregunta gertvdijk 15.10.2014 - 01:49

4 respuestas

210

Información de fondo

SSL está diseñado para asegurar el nivel de transporte en Internet. Para 'la web' alias HTTP, sabrá esto como HTTPS, pero también se usa para otros protocolos de aplicaciones. SSLv2 fue el primer protocolo de seguridad de transporte ampliamente utilizado, pero se encontró inseguro no mucho después. Los sucesores SSLv3 y TLSv1 son ampliamente compatibles ahora. TLSv1.1 y TLSv1.2 son más nuevos y también obtienen mucho apoyo. La mayoría, si no todos, los navegadores web lanzados desde 2014 tienen soporte para eso.

El reciente descubrimiento de los ingenieros de Google señala que SSLv3 no se debería usar por más tiempo (como que SSLv2 ha quedado obsoleto hace mucho tiempo). Los clientes que no podrán conectarse a su sitio / servicio probablemente sean muy muy limitados. CloudFlare anunció que menos del 0.09% de sus visitantes todavía confían en SSLv3.

Solución simple: deshabilite SSLv3.

¿Ubuntu proporciona alguna actualización?

Sí, a través de usn-2385-1 con la función SCSV, pero no atenúa completamente el problema , ya que no desactiva SSLv3 y el parche solo funcionará si se han aplicado parches a ambos lados de la conexión. Lo recibirá a través de sus actualizaciones de seguridad habituales en su administrador de paquetes.

Entonces, aún TÚ tienes que tomar medidas tú mismo para deshabilitar SSLv3 (es configurable). Las versiones futuras de clientes / navegadores deshabilitarán SSLv3 lo más probable. P.ej. Firefox 34 lo hará.

Deshabilitar SSLv3 completamente de forma predeterminada en Ubuntu en el nivel de implementación probablemente también romperá algunas cosas para el uso de SSL no HTTPS que no es tan vulnerable, así que supongo que los mantenedores no harán eso y solo este parche SCSV será aplicado.

¿Por qué la actualización de SCSV en OpenSSL a través de usn-2385-1 no mitiga el problema?

Realmente, deja de hacer tales preguntas y solo salta algunos párrafos y deshabilita SSLv3. Pero oye, si no estás convencido, aquí tienes:

POODLE muestra que SSLv3 con cifrado CBC está roto, implementar SCSV no cambia eso. SCSV solo se asegura de que no cambie de un protocolo TLS a un protocolo TLS / SSL inferior según sea necesario con el ataque Man-in-the-Middle requerido para los casos habituales.

Si tiene que acceder a un servidor que no ofrece TLS en absoluto, pero solo SSLv3, entonces su navegador realmente no tiene otra opción y debe hablar con el servidor usando SSLv3, que entonces es vulnerable sin ningún ataque de degradación .

Si tiene que acceder a algún servidor que también ofrezca TLSv1 + y SSLv3 (lo cual no se recomienda) y desea asegurarse de que su conexión no se degradará a SSLv3 por un atacante, entonces ambos el servidor y el cliente necesita este parche SCSV.

Para mitigar por completo el problema, la inhabilitación de SSLv3 es suficiente y puede estar seguro de que no lo degradarán. Y no podrá hablar con servidores SSLv3.

Bien, entonces, ¿cómo desactivo SSLv3?

Consulte a continuación en las secciones específicas de la aplicación: Firefox, Chrome, Apache, Nginx y Postfix están cubiertos por ahora.

¿Solo se ven afectados los servidores o los clientes?

La vulnerabilidad existe si tanto el servidor como el cliente aceptan SSLv3 (incluso si ambos son capaces de TLSv1 / TLSv1.1 / TLS1.2 debido a un ataque de degradación).

Como administrador del servidor, debe deshabilitar SSLv3 ahora para la seguridad de sus usuarios.

Como usuario, debe deshabilitar SSLv3 en su navegador ahora para protegerse al visitar sitios web que aún son compatibles con SSLv3.

¿Es este OpenSSL / GnuTLS / navegador específico?

No. Es un error de protocolo (diseño), no un error de implementación. Esto significa que no puede parchearlo (a menos que esté cambiando el diseño de la antigua SSLv3).

Y sí, hay una nueva versión de seguridad de OpenSSL , pero lea a continuación ( Pero de verdad necesita soporte SSLv3 ... por la razón X, Y, Z! ) sobre por qué es mejor centrarse en deshabilitar SSLv3 por completo.

¿Puedo matar SSLv3 en el nivel de red (firewall)?

Bueno, sí, probablemente. Puse esto en una publicación de blog por separado para más ideas y trabajo. ¡Podemos tener alguna regla mágica iptables que puedas usar!

La publicación de mi blog: ¿Cómo eliminar SSLv3 en su red utilizando iptables para POODLE?

¿Es relevante solo para HTTPS o también para IMAP / SMTP / OpenVPN y otros protocolos con soporte SSL?

El vector de ataque actual, como lo muestran los investigadores, funciona con el control del texto sin formato enviado al servidor utilizando JavaScript que se ejecuta en la máquina de la víctima. Este vector no se aplica a escenarios que no sean de HTTPS sin usar un navegador.

Además, normalmente un cliente SSL no permite degradar la sesión a SSLv3 (teniendo a TLSv1 + visto en las capacidades de handshake), pero los navegadores quieren ser muy compatibles con versiones anteriores y lo hacen. La combinación con el control de texto sin formato y la forma específica en que se crea un encabezado HTTP lo hace explotable.

Conclusión: deshabilite SSLv3 para HTTPS ahora , deshabilite SSLv3 para otros servicios en su próxima ventana de servicio.

¿Cuál es el impacto? ¿Debo revocar y regenerar mi certificado de servidor? (Al igual que con Heartbleed)

No, no necesita rotar sus certificados para esto. La vulnerabilidad expone la recuperación de texto sin formato a partir de los datos de la sesión, no proporciona acceso a ningún secreto (ni la clave de sesión ni la de certificado).

Es muy probable que un atacante solo sea capaz de robar los encabezados de texto sin formato, como las cookies de sesión, para poder realizar el secuestro de sesión . Una restricción adicional es la necesidad de un ataque MitM completo (activo) .

¿Hay algo más que pueda hacer para mejorar mi configuración de SSL en general?

Como usuario, además de deshabilitar SSLv3 en su navegador, realmente no. Bueno, solo instale siempre las últimas actualizaciones de seguridad.

Para los servidores, siga la guía del servidor TLS de Mozilla . Y prueba con prueba de Qualys 'SSL Labs . Realmente no es tan difícil obtener una calificación A + en su sitio. Simplemente actualice sus paquetes e implemente las recomendaciones de la guía de Mozilla.

Pero realmente necesito el soporte de SSLv3 ... por la razón X, Y, Z! ¿Ahora qué?

Bueno, hay un parche que elude el ataque de degradación de los clientes con capacidad TLSv1, llamado SSLv3 Fallback Protection. Por cierto, también mejorará la seguridad de TLSv1 + (el ataque de degradación es más difícil / imposible). Se ofrece como respaldo de una versión más reciente de OpenSSL en el aviso de seguridad de Ubuntu usn-2385-1 .

Big catch: tanto los clientes como los servidores necesitan este parche para funcionar. Por lo tanto, en mi opinión, mientras actualiza tanto clientes como servidores, simplemente debería actualizarse a TLSv1 + de todos modos.

Sin embargo, por favor, solo retire SSLv3 en su red por el momento. Haga un esfuerzo para actualizar los estándares de seguridad y simplemente abandone SSLv3.

Escuché sobre el soporte de SCSV para eliminar el ataque de degradación del protocolo. ¿Lo necesito?

Solo si realmente necesita SSLv3 por algún motivo extraño, pero también mejora la seguridad en TLSv1 +, entonces sí, le recomendaría que lo instale. Ubuntu proporciona una actualización para esta función en usn-2385-1 . Lo recibirá a través de sus actualizaciones de seguridad habituales en su administrador de paquetes.

Prueba de vulnerabilidad para sitios alojados de forma privada (por ejemplo, intranet / fuera de línea).

Sus servidores son vulnerables simplemente si son compatibles con SSLv3. Varias opciones aquí:

  • Con OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Si la conexión tiene éxito, sslv3 está habilitado. Si falla, está deshabilitado. Cuando falla, debería ver algo como:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Usar nmap :

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Debería generar ' SSLv3: No supported ciphers found '. Ajuste para su nombre de host / puerto.

  • Utilizando cifrado . Clona / descarga el binario y ejecútalo:

    ./cipherscan myhostname.tld
    

    No debe no enumerar nada con SSLv3 en la columna 'protocols'.

navegador Firefox

Abra about:config , encuentre security.tls.version.min y establezca el valor en 1 . Luego, reinicie su navegador para eliminar cualquier conexión SSL abierta.

Firefox desde la versión 34 en adelante deshabilitará SSLv3 de manera predeterminada y, por lo tanto, no requiere acción ( source ). Sin embargo, en el momento de escribir, 33 acaba de ser lanzado y 34 está fijado para el 25 de noviembre.

Google Chrome (Linux)

Edite el archivo /usr/share/applications/google-chrome.desktop , por ejemplo,

sudo nano /usr/share/applications/google-chrome.desktop

Edite todas las líneas empezando por Exec= para incluir --ssl-version-min=tls1 .

E.g. una línea como

Exec=/usr/bin/google-chrome-stable %U

se convierte en

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Luego, asegúrese de cerrar completamente el navegador (¡las aplicaciones de Chrome pueden mantener su navegador activo en segundo plano!).

Nota: es posible que deba repetir esta actualización de cada paquete de google-chrome, sobrescribiendo este archivo .desktop launcher. Un buscador de Google Chrome o Chromium con SSLv3 deshabilitado de forma predeterminada aún no se ha anunciado en el momento de la redacción.

Servidor HTTPD de Apache

Si está ejecutando un servidor web Apache que actualmente permite SSLv3, deberá editar la configuración de Apache. En los sistemas Debian y Ubuntu, el archivo es /etc/apache2/mods-available/ssl.conf . En CentOS y Fedora, el archivo es /etc/httpd/conf.d/ssl.conf .Necesitará agregar la siguiente línea a su configuración de Apache con otras directivas SSL.

SSLProtocol All -SSLv2 -SSLv3

Esto permitirá todos los protocolos excepto SSLv2 y SSLv3.

Mientras lo hace, le recomendamos que mejore la configuración de la plataforma de cifrado para su servidor web, tal como se explica en El servidor TLS de Mozilla. guía . Agregar por ejemplo:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Luego verifica si la nueva configuración es correcta (sin errores tipográficos, etc.):

sudo apache2ctl configtest

Y reinicie el servidor, por ejemplo,

sudo service apache2 restart

En CentOS y Fedora:

systemctl restart httpd

Más información: documentación de Apache

Ahora pruébelo: si su sitio está disponible públicamente, pruébelo con la herramienta SSL Labs de Qualys .

Servidor Nginx

Si está ejecutando Nginx, solo incluya la siguiente línea en su configuración entre las otras directivas SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Mientras lo hace, puede considerar mejorar la configuración de la plataforma de cifrado para su servidor web como se explica en Servidor TLS de Mozilla guía . Agregar por ejemplo:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

Y reinicie el servidor, por ejemplo,

sudo service nginx restart

Referencia: documentación de Nginx

Ahora pruébelo: si su sitio es público, está disponible, pruébelo con la herramienta de SSL Labs de Qualys .

Servidor web Lighttpd

Lighttpd versions & gt; 1.4.28 admite una opción de configuración para deshabilitar SSLv2 y v3. Las versiones Lighttpd anteriores a la 1.4.28 le permiten desactivar SSLv2 SOLAMENTE. Tenga en cuenta que Ubuntu 12.04 LTS e instalaciones anteriores en lighttpd v1.4.28 y, por lo tanto, una solución simple no está disponible para esas distribuciones. Por lo tanto, esta corrección solo se debe usar para versiones de Ubuntu mayores que 12.04.

Para Ubuntu versión 12.04 o Debian 6, hay disponible un paquete lighttpd actualizado en el repositorio de openSUSE: enlace

El paquete está diseñado para Debian 6 (squeeze) pero funciona también en 12.04 (preciso)

Edite su /etc/lighttpd/lighttpd.conf para agregar las siguientes líneas después de la directiva ssl.engine = "enable"

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Luego debe reiniciar el servicio lighttpd con sudo service lighttpd restart y realizar una prueba de handshake ssl3 como se describe en secciones anteriores para asegurarse de que el cambio se implementó correctamente.

Tomado de enlace .

SMTP de Postfix

Para 'SSL oportunista' (la política de cifrado no se aplica y también es aceptable), no necesita cambiar nada. Incluso SSLv2 es mejor que simple, por lo que si necesita proteger su servidor, debe usar el modo 'SSL obligatorio' de todos modos.

Para que el modo 'SSL obligatorio' ya esté configurado, simplemente agregue / cambie la configuración de smtpd_tls_mandatory_protocols para la entrada conexiones y smtp_tls_mandatory_protocols para conexiones de salida:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Opcionalmente, si también desea deshabilitar SSLv3 para el cifrado oportunista (aunque no sea necesario como se explicó anteriormente), hágalo de la siguiente manera:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

y reiniciar Postfix:

sudo service postfix restart

Sendmail

(Edición no verificada por un usuario anónimo, no me siento cómodo con Sendmail, verifíquelo.)

Estas opciones están configuradas en la sección LOCAL_CONFIG de tu sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

En Dovecot v2.1 +, agregue lo siguiente a su /etc/dovecot/local.conf (o un nuevo archivo en /etc/dovecot/conf.d ):

ssl_protocols = !SSLv2 !SSLv3

y reiniciar Dovecot:

sudo service dovecot restart

Para las versiones anteriores, deberá aplicar el código fuente .

Courier-imap (imapd-ssl)

Courier-imap permite SSLv3 de forma predeterminada en Ubuntu 12.04 y otros. Debe desactivarlo y usar STARTTLS para forzar TLS. Edite su archivo de configuración /etc/courier/imapd-ssl para reflejar los siguientes cambios

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Servidor HAProxy

SSL es compatible con HAProxy & gt; = 1.5.

Edite el archivo /etc/haproxy.cfg y encuentre su línea bind . Agregar no-sslv3 . Por ejemplo:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Referencia: Documentación HAProxy

OpenVPN

Parece que no se ve afectado ( source ).

  

OpenVPN usa TLSv1.0, o (con & gt; = 2.3.3) opcionalmente TLSv1.2 y, por lo tanto, no se ve afectado por POODLE.

Puppet

Puppet usa SSL a través de HTTPS pero no lo utilizan los clientes de 'navegador', solo agentes de Puppet que no son vulnerables al vector de ataque que se muestra.Sin embargo, es mejor práctica desactivar SSLv3.

Mi recomendación es utilizar el módulo stephenrjohnson / puppetmodule Puppet para configurar el maestro Puppet en el que Malé SSLv3 hace algún tiempo.

    
respondido por el gertvdijk 15.10.2014 - 01:49
4

Puede no ser específico de ubuntu, pero para evitar la vulnerabilidad de Poodle en Node.js, puede establecer secureOptions en require('constants').SSL_OP_NO_SSLv3 cuando cree un servidor https o tls.

Consulte enlace para obtener información adicional

    
respondido por el 3rdEden 15.10.2014 - 10:59
0

La "solución" para el servicio de mensajería inhabilita tls 1.1 y tls 1.2. No parece haber una forma de ejecutar el servicio de mensajería con tls 1.1 o superior. Un escaneo PCI en su servidor puede regresar con la recomendación:

Configure los servidores SSL / TLS para que solo usen TLS 1.1 o TLS 1.2 si es compatible. Configure los servidores SSL / TLS para que solo admitan conjuntos de cifrado que no usan cifras de bloque.

    
respondido por el PrgWiz 27.02.2015 - 15:45
-1

Dado que la vulnerabilidad de POODLE es una falla de diseño en el protocolo en sí y no una falla de implementación, no habrá parches. La única forma de mitigar esto es deshabilitar SSLv3 en el servidor apache. Agregue las líneas siguientes en ssl.conf y realice un reinicio de apache con estilo.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
respondido por el Lal Krishna 16.10.2014 - 00:55

Lea otras preguntas en las etiquetas