Foro SPICE Entrevistas Archivo Descargas Acerca Contacto Aviso Legal

PCI Hispano es un proyecto cooperativo en idioma español entre profesionales de América y Europa para compartir conocimiento y
experiencias en el proceso de implementación y auditoría de estándares del PCI SSC.
¿Eres nuevo en esta área? Lee nuestro Top 10 de preguntas y respuestas más frecuentes y revisa La línea de tiempo de los estándares
del PCI Security Standards Council (PCI SSC).
¿Quieres escribir artículos y hacer parte de nuestros colaboradores? Revisa la guía para autores.
¿Tienes alguna pregunta o necesitas orientación? Pregúntale al QSA en el Foro de Discusión.

Inicio Evita que las vulnerabilidades de SSL/TLS afecten tu cumplimiento de PCI DSS con estas recomendaciones

Evita que las vulnerabilidades de SSL/TLS afecten tu cumplimiento de PCI DSS con estas recomendaciones

ACTUALIZACIÓN 08/2016: Se ha agregado el servicio «Observatory» de la Fundación Mozilla para la validación de configuración HTTPS.

ACTUALIZACIÓN 01/2016: Se ha agregado el ataque «logjam» (CVE-2015-4000) dentro del índice de vulnerabilidades críticas de SSL/TLS y diferentes páginas de
referencia para validación. Adicionalmente, se han listado nuevas URL con descripciones de configuración segura de cifrados en diferentes servicios y aplicaciones
para automatización en la elección de cifrados fuertes para Microsoft IIS.

ACTUALIZACIÓN 10/2015: Se han agregado nuevas URL de servicios de comprobación de configuración de SSL y TLS y guías de configuración para servidores
web, como parte de las tareas dentro de los planes de mitigación de riesgos y migración de SSL conforme con PCI DSS v3.1.

ACTUALIZACIÓN 03/2015: Se ha publicado una nueva vulnerabilidad denominada FREAK (Factoring Attack on RSA-EXPORT Keys) bajo el CVE-2015-0204. Esta
vulnerabilidad permite atacar los protocolos SSL/TLS y debe ser mitigada cuando antes. Este artículo ha sido actualizado con las instrucciones que se deben seguir.
Recomendamos a nuestros lectores actualizar los componentes de SSL/TLS a las últimas versiones disponibles. Más información aquí. Un análisis técnico de esta
vulnerabilidad y la explicación de su explotación se pueden encontrar aquí.

ACTUALIZACIÓN 09/03/2015: La Fundación Mozilla ha desarrollado una Wiki en la cual describe una serie de configuraciones para la implementación de TLS en
diversos servidores. Así mismo,  cuenta con una herramienta para la generación  en línea de configuraciones con base en las parametrizaciones del usuario.
Invitamos a todos nuestros lectores a revisarlo.

SSL (Secure Sockets Layer) es un protocolo criptográfico desarrollado por Netscape para proporcionar confidencialidad e integridad en la comunicación de datos
entre dos extremos. Su primera versión (SSL v1)  nunca fue publicada debido a una gran cantidad de fallos en su desarrollo, mientras que  las versiones
posteriores (que corregian dichos problemas) datan de 1995 (SSL v2) y 1996 (SSL v3 – RFC 6101).  En Enero de 1999 fue publicada la RFC 2246  que definia las
bases para el protocolo que remplazaría a SSL: Transport Layer Security (TLS) v1.0. Esta nueva especificación traía consigo múltiples mejoras en términos de
operación con primitivas criptográficas y desempeño. Siete años más tarde (en 2006) se publicó la versión 1.1 de TLS bajo la RFC 4346  y en 2008 con la RFC 5246
se vería la versión más actual de TLS, la versión 1.2. Hasta ese momento las implementaciones de SSL y TLS eran compatibles entre sí («backward compatibility»),
lo cual bloqueaba el desarrollo autónomo de algunas características de seguridad de TLS, por lo que en el 2011 con la RFC 6176 se prohibía la negociación entre TLS
y la versión 2.0 de SSL y ambas implementaciones se independizaban.

A lo largo de 20 años después de la primera implementación oficial de SSL se han identificado una serie de vulnerabilidades que afectan seriamente a los niveles de
seguridad provistos por estos protocolos, siendo algunas de las más notables las siguientes (en orden de aparición):

BEAST («Browser Exploit Against SSL/TLS») – CVE-2011-3389

CRIME («Compression Ratio Info-leak Made Easy») – CVE-2012-4929
BREACH («Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext»)
HEARTBLEED – CVE-2014-0160
POODLE («Padding Oracle On Downgraded Legacy Encryption») – CVE-2014-3566
FREAK («Factoring Attack on RSA-EXPORT Keys») – CVE-2015-0204
logjam – CVE-2015-4000

Una línea de tiempo de la historia y vulnerabilidades de SSL y TLS se puede encontrar en la página «SSL/TLS and PKI History«.

No obstante – y a pesar de estas vulnerabilidades – el estándar PCI DSS v3.0 cita de forma explícita el uso de SSL como un protocolo «seguro» para la protección
durante el transporte de datos de tarjetas de pago en los requerimientos 1.1.6.a,  2.2.3, 2.3 y 4.1. A pesar de ello, es muy importante que se tenga presente la
necesidad de actualizar las guías de configuración seguras (req. 2.2.b) y la actualización/configuración continua de componentes con base en las vulnerabilidades de
seguridad publicadas (req. 6.1) con el fin de gestionar de forma correcta los potenciales riesgos derivados de estos problemas que podrían afectar seriamente tanto
el cumplimiento con PCI DSS así como la seguridad de los datos de tarjeta transmitidos. Por otro lado, todas estas vulnerabilidades al ser detectadas son
reportadas como PCI FAIL en escaneos ASV (req. 11.2.2), justificación adicional para proceder de forma inmediata con la corrección de estos problemas.

Para ello, a continuación se enumeran una serie de acciones recomendables para mitigar estos problemas:

Actualizar a la versión más reciente todos los componentes de SSL o TLS existentes en el entorno (prestar especial atención a OpenSSL, cuyas versiones
desde la 1.0.1 hasta la 1.0.1f (inclusive) son afectadas por la vulnerabilidad HeartBleed)
Emplear algoritmos robustos en las configuraciones de cifrado de SSL/TLS (evitar el uso de Triple-DES CBC, RC4, MD5 y SHA-1)
En aquellos servicios que lo soporten, activar TLS Fallback Signaling Cipher Suite Value (SCSV) para prevenir la renegociación con protocolos débiles
Habilitar el soporte de HTTP Strict Transport Security (HSTS) en los servicios que lo soporten
Configurar Perfect Forward Secrecy (PFS) en donde sea soportado (ver aquí)
Habilitar el soporte para Elliptic-Curve Diffie-Hellman (ECDH) en el intercambio de claves y utilizar grupos de Diffie-Hellman como mínimo de 2048-bit
para evitar ataques de logjam.
Configurar los browsers de usuarios para deshabilitar el soporte de SSL (ver https://zmap.io/sslv3/browsers.html  y https://www.digicert.com/ssl-
support/disabling-browser-support-ssl-v3.htm)

Así mismo, una acción altamente recomendable es deshabilitar completamente el soporte de SSL en los servidores, habilitar TLS y configurarlo de forma
segura. Esta acción debe ser analizada detalladamente en cada caso, ya que puede afectar la conectividad de browsers de clientes que no tengan soporte de TLS. La
forma de deshabilitar SSL en diferentes servicios se detalla a continuación:

Apache Web Server

Para Apache httpd version 2.2.23 y superiores, se requiere especificar el uso de TLS y deshabilitar SSL v2 y SSL v3:

1 SSLProtocol All -SSLv2 -SSLv3

Para Apache 2.2.22 y anteriores, simplemente especificar el uso de TLSv1

1 SSLProtocol TLSv1

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

1 SSLHonorCipherOrder on
2 SSLCipherSuite "ECDH+aRSA+AES256 ECDH+aRSA+AES128 AES256-SHA"

Deshabilitar el uso de compresión:

1 SSLCompression off

Activar los encabezados HSTS:

1 Header set Strict-Transport-Security "max-age=15768000"

Con el fin de evitar la exportación de suites de cifrado, se recomienda agregar esta línea en la configuración de Apache. Esta contramedida sirve para minimizar
el impacto de ataques tales como FREAK:

1 SSLCipherSuite !EXPORT

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo apache2ctl configtest && sudo service apache2 restart

NginX Web Server

Agregar o modificar la siguiente línea en el fichero de configuración:

1 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

1 ssl_prefer_server_ciphers on;
2 ssl_ciphers ECDH+aRSA+AES256:ECDH+aRSA+AES128:AES256-SHA;

Se recomienda agregar la siguiente línea en el archivo de configuración para evitar la exportación de las suites de cifrado disponibles y minimizar el efecto de
ataques como FREAK:

1 ssl_ciphers '!EXPORT';

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo nginx -t && sudo service nginx restart

Internet Information Server (IIS)

Para Internet Information Server (IIS) es necesario crear/modificar una serie de claves de registro. La forma más fácil es crear un fichero con extensión .reg con el
siguiente contenido:

1 Windows Registry Editor Version 5.00

2  
3 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
4 "Enabled"=dword:00000000
5  
6 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
7 "Enabled"=dword:00000000

Posterior a ello y con privilegios de administrador, ejecutarlo.

Para corregir la vulnerabilidad FREAK, Microsoft ha puesto a disposición una serie de instrucciones que deben ser implementadas por el administrador de la
plataforma: Vulnerability in Schannel Could Allow Security Feature Bypass

Para automatizar la configuración de algoritmos seguros en IIS se puede hacer uso de la herramienta gratuita Nartac IIS Crypto.

Más información en https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm y en https://support.microsoft.com/kb/187498/en-us

Lighttpd Web Server

Para Lighttpd versión 1.4.29 y posteriores, agregar las siguientes líneas en el fichero de configuración:

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

 Activar los encabezados HSTS:

1 add_header Strict-Transport-Security max-age=15768000;

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo service lighttpd restart

Sendmail Mail Server

Agregar las  siguientes líneas en el fichero de configuración sendmail.mc en el apartado LOCAL_CONFIG:

1 LOCAL_CONFIG
2 O CipherList=HIGH
3 O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
4 O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo service sendmail restart

Postfix Mail Server

Agregar o modificar las siguientes líneas en el fichero de configuración:

1 smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
2 smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
3 smtpd_tls_protocols=!SSLv2,!SSLv3
4 smtp_tls_protocols=!SSLv2,!SSLv3

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

1 smtpd_tls_mandatory_ciphers = high
2 tls_high_cipherlist = ECDH+aRSA+AES256:ECDH+aRSA+AES128:AES256-SHA

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo service postfix restart

Courier-imap Mail Server

Agregar o modificar las siguientes líneas en el fichero de configuración:

1 IMAPDSSLSTART=NO
2 IMAPDSTARTTLS=YES
3 IMAP_TLS_REQUIRED=1
4 TLS_PROTOCOL=TLS1
5 TLS_STARTTLS_PROTOCOL=TLS1

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

1 sudo service courier-imap restart

Otras páginas de referencia con información adicional son:

Configuración para NGINX

Configuración para Apache2
Configuración para Lighttpd
Configuración para IIS

Adicionalmente, en el sitio web Cipherli.st se encuentran ejemplos de configuraciones adicionales para diferentes servicios (Apache, Nginx, Lighttpd, Exim, MySQL,
PostgreSQL, OpenSSH, etc.)

¿Cómo validar si mi servidor web es vulnerable?

Existen múltiples sitios web que permiten validar si un servidor en particular es susceptible a alguna de las vulnerabilidades descritas anteriormente. Algunos de
ellos son:

POODLE Scan – Testing tool

HeartBleed Test
FREAK Scan – Testing tool
Logjam Server Test
Qualys SSL Labs
Entrust SSL Labs
SSL Tools Web Server Encryption (para servidores web)
SSL Tools Mail Server Encryption (para servidores de correo electrónico)
Observatory de Mozilla Fundation

Específicamente para PCI DSS, se puede hacer una evaluación de cumplimiento a través del servicio de High-Tech Bridge SSL/TLS Server Configuration, que
también ofrece resultados de alineación con otros estándares como NIST 800-52.

Por otro lado, se puede emplear alguna de las siguientes herramientas específicas para la detección de estas vulnerabilidades:

SSLScan
SSL Decoder
TestSSLServer
OWASP O-Saft
CipherScan
testssl.sh

Empleando nmap también se puede obtener la información de los algoritmos de cifrado permitidos en un puerto que soporte TLS para validar su configuración:

1 nmap --script ssl-cert,ssl-enum-ciphers -p 443 HOST

Dentro de los scripts de nmap se pueden encontrar scripts específicos para revisar si el servidor web es vulnerable a ataques como HeartBleed:

1 nmap -p 443 --script ssl-heartbleed HOST

En la página «Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)» de la OWASP se pueden encontrar múltiples
herramientas para la validación de configuración de SSL y TLS que pueden ser útiles durante la definición de planes de migración y mitigación de riesgos de
acuerdo con PCI DSS v3.1.

¿Cómo validar si browser es vulnerable?

Para validar si su browser puede ser vulnerable, puede usar alguno de los siguientes sitios web:

zmap.io SSLv3 Test

Qualys SSL for browsers

¿Le ha gustado este artículo? Compártalo con sus colegas en Twitter, LinkedIn, Facebook, Google+ y vía RSS. ¿Tiene alguna duda? Le invitamos a participar en el
foro o dejar un comentario en este artículo.

Relacionado

5 conceptos claves en el proceso de migración

de SSL y versiones anteriores de TLS
NOTA: El 18 de diciembre de 2015 el PCI SSC
extendió las fechas de migración hasta junio de
2018. Más información en el artículo "El PCI SSC
amplía la fecha para la migración de SSL y
versiones previas de TLS". En abril de 2015 el PCI
julio 19, 2015
En "PCI DSS"
Revisa si la configuración de TLS 1.2 de tu sitio El PCI SSC amplía la fecha para la migración de
web es correcta con estas herramientas SSL y versiones previas de TLS
junio 28, 2018 diciembre 20, 2015
En "PCI DSS" En "PCI DSS"

Publicado en enero 15, 2016 5:00 pm por David Acosta Promedio :

Archivado en PCI DSS
Tags: Apache, BEAST, BREACH, Courier-imap, CRIME, Su valoración: none, Promedio: 5 (1 votos)

HEARTBLEED, HSTS, https, IIS, Lighttpd, NGINX, Este artículo ha sido visto 15655 veces

observatory, OpenSSL, PFS, POODLE, postfix, Qualys, Print this page

SCSV, sendmail, ssl, SSLScan, tls
Última modificación junio 28, 2018 2:34 pm por David
Acosta

Compartir esta entrada:

 Facebook  Twitter  LinkedIn  Imprimir

« Post Anterior Siguiente Post »

1 Comentario en respuesta a "Evita que las vulnerabilidades de SSL/TLS afecten tu cumplimiento de PCI DSS con estas
recomendaciones"

Nelson Galeano #  
Muchas gracias por el valioso aporte!

marzo 19, 2018 3:00 pm RESPONDER

Deja un comentario

Introduce aquí tu comentario...

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

PCI Hispano 2019.

Contenido bajo Licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.