{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Posibles ataques a HTTPS y c\u00f3mo protegerse de ellos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La mitad de los sitios web utiliza HTTPS<\/a><\/noindex>, y su n\u00famero sigue aumentando de manera constante. El protocolo reduce el riesgo de interceptaci\u00f3n del tr\u00e1fico, pero no excluye los intentos de ataque como tales. Hablaremos sobre algunos de ellos \u2014 POODLE, BEAST, DROWN y otros \u2014 y las formas de protecci\u00f3n en nuestro material.<\/p>\n

\"Posibles <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nLa primera noticia sobre el ataque POODLE<\/a><\/noindex> se conoci\u00f3 en 2014. La vulnerabilidad en el protocolo SSL 3.0 fue descubierta por el especialista en seguridad Bodo M\u00f6ller y sus colegas de Google.<\/p>\n

Su esencia consiste en lo siguiente: un hacker obliga al cliente a realizar una conexi\u00f3n mediante SSL 3.0, emulando interrupciones de la conexi\u00f3n. Luego busca en el tr\u00e1fico cifrado en CBC<\/a><\/noindex>-modo mensajes especiales etiquetados. Mediante una serie de solicitudes falsas, el delincuente obtiene la capacidad de reconstruir el contenido de los datos que le interesan, como cookies.<\/p>\n

SSL 3.0 es un protocolo obsoleto. Pero la cuesti\u00f3n de su seguridad sigue siendo relevante. Los clientes lo utilizan para evitar problemas de compatibilidad con los servidores. Seg\u00fan algunas estimaciones, casi el 7% de 100,000 de los sitios web m\u00e1s populares todav\u00eda admite SSL 3.0<\/a><\/noindex>. Tambi\u00e9n existen<\/a><\/noindex> modificaciones de POODLE, que tienen como objetivo las m\u00e1s modernas TLS 1.0 y TLS 1.1. Este a\u00f1o se han a\u00f1adido<\/a><\/noindex> se han reportado nuevos ataques Zombie POODLE y GOLDENDOODLE, que evaden la protecci\u00f3n de TLS 1.2 (a\u00fan est\u00e1n relacionados con el cifrado CBC).<\/p>\n

C\u00f3mo protegerse.<\/b> En el caso del POODLE original, es necesario desactivar el soporte para SSL 3.0. Sin embargo, en este caso hay un riesgo de encontrar problemas de compatibilidad. Una soluci\u00f3n alternativa puede ser el mecanismo TLS_FALLBACK_SCSV: garantiza que el intercambio de datos mediante SSL 3.0 se realice solo con sistemas antiguos. Los delincuentes ya no podr\u00e1n iniciar la degradaci\u00f3n de la versi\u00f3n del protocolo. La forma de protegerse contra Zombie POODLE y GOLDENDOODLE es desactivar el soporte para CBC en las aplicaciones basadas en TLS 1.2. Una soluci\u00f3n radical ser\u00eda pasar a TLS 1.3: en la nueva versi\u00f3n del protocolo no se utiliza cifrado CBC. En su lugar, se utilizan AES y ChaCha20 m\u00e1s resistentes.<\/p>\n

BEAST<\/h2>\n

\nUno de los primeros ataques a SSL y TLS 1.0, descubierto en 2011. Al igual que POODLE, BEAST utiliza<\/a><\/noindex> Caracter\u00edsticas de la encriptaci\u00f3n CBC. Los atacantes insertan un agente de JavaScript o un applet de Java en la m\u00e1quina del cliente, que reemplaza los mensajes durante la transmisi\u00f3n de datos a trav\u00e9s de TLS o SSL. Dado que los atacantes conocen el contenido de los paquetes \"falsos\", pueden utilizar esa informaci\u00f3n para descifrar el vector de inicializaci\u00f3n y leer los dem\u00e1s mensajes al servidor, como las cookies de autenticaci\u00f3n.<\/p>\n

A d\u00eda de hoy, la vulnerabilidad BEAST sigue afectando a una serie de herramientas de red<\/a><\/noindex>: servidores proxy y aplicaciones para proteger gateways de Internet locales.<\/p>\n

C\u00f3mo protegerse.<\/b> El atacante necesita enviar solicitudes regularmente para descifrar los datos. En VMware recomiendan<\/a><\/noindex> se recomienda reducir la duraci\u00f3n de SSLSessionCacheTimeout, de cinco minutos (recomendaci\u00f3n por defecto) a 30 segundos. Este enfoque dificultar\u00e1 la implementaci\u00f3n de los planes de los atacantes, aunque tendr\u00e1 un efecto negativo en el rendimiento. Adem\u00e1s, hay que entender que pronto la vulnerabilidad BEAST podr\u00eda volverse obsoleta por s\u00ed misma: a partir de 2020, los principales navegadores dejar\u00e1n<\/a><\/noindex> de soportar TLS 1.0 y 1.1. En cualquier caso, menos del 1,5 % de todos los usuarios de navegadores utilizan estos protocolos.<\/p>\n

DROWN<\/h2>\n

\nSe trata de un ataque de tipo cross-protocol que utiliza errores en la implementaci\u00f3n de SSLv2 con claves RSA de 40 bits. El atacante escucha cientos de conexiones TLS objetivo y env\u00eda paquetes especiales al servidor que utiliza SSLv2 y la misma clave privada. Utilizando el ataque de Bleichenbacher<\/a><\/noindex>, el hacker puede descifrar una de aproximadamente mil sesiones TLS del cliente.<\/p>\n

DROWN se hizo conocido por primera vez en 2016, cuando se descubri\u00f3 que estaba afectando a un tercio de los servidores<\/a><\/noindex> en el mundo. Hasta hoy, sigue siendo relevante. De las 150,000 p\u00e1ginas m\u00e1s populares, el 2% a\u00fan utiliza soportan<\/a><\/noindex> SSLv2 y mecanismos de cifrado vulnerables.<\/p>\n

C\u00f3mo protegerse.<\/b> Es necesario aplicar los parches recomendados por los desarrolladores de bibliotecas criptogr\u00e1ficas que deshabilitan el soporte para SSLv2. Por ejemplo, se proporcionaron dos parches para OpenSSL (en 2016 fueron las actualizaciones<\/a><\/noindex> 1.0.1s y 1.0.2g). Tambi\u00e9n se publicaron actualizaciones e instrucciones para deshabilitar el protocolo vulnerable en Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\"El recurso puede ser vulnerable a DROWN si sus claves son utilizadas por un servidor externo con SSLv2, por ejemplo, un servidor de correo,\" se\u00f1ala el jefe del departamento de desarrollo del proveedor de IaaS 1cloud.ru<\/a><\/noindex> Sergio Belkin. \u2014 Esta situaci\u00f3n ocurre si varios servidores utilizan un certificado SSL compartido. En este caso, es necesario deshabilitar el soporte para SSLv2 en todas las m\u00e1quinas.<\/i><\/p><\/blockquote>\n

\nSe puede comprobar si es necesario actualizar el sistema mediante un consultor especializado. utilidad<\/a><\/noindex> \u2014 Este fue desarrollado por expertos en seguridad de la informaci\u00f3n que descubrieron DROWN. M\u00e1s sobre las recomendaciones relacionadas con la protecci\u00f3n contra este tipo de ataques se puede leer en una publicaci\u00f3n en el sitio de OpenSSL.<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nUna de las vulnerabilidades m\u00e1s grandes en el software \u2014 Heartbleed<\/a><\/noindex>. Se descubri\u00f3 en 2014 en la biblioteca de OpenSSL. En el momento del anuncio del error, se estimaba que el n\u00famero de sitios web vulnerables era de medio mill\u00f3n.<\/a><\/noindex> \u2014 esto representa aproximadamente el 17% de los recursos protegidos en la red.<\/p>\n

El ataque se lleva a cabo a trav\u00e9s de un peque\u00f1o m\u00f3dulo de la extensi\u00f3n Heartbeat del protocolo TLS. Este protocolo requiere que los datos se transmitan de manera continua. En caso de un largo per\u00edodo de inactividad, se produce una desconexi\u00f3n y es necesario restablecer la conexi\u00f3n. Para manejar este problema, los servidores y clientes \"ensucian\" artificialmente el canal (RFC 6520, p.5<\/a><\/noindex>), enviando un paquete de longitud aleatoria. Si era m\u00e1s grande que el paquete permitida, las versiones vulnerables de OpenSSL le\u00edan la memoria m\u00e1s all\u00e1 del b\u00fafer asignado. En esta \u00e1rea pod\u00edan encontrarse datos sensibles, incluidas las claves de cifrado y la informaci\u00f3n sobre otras conexiones.<\/p>\n

La vulnerabilidad estaba presente en todas las versiones de la biblioteca entre 1.0.1 y 1.0.1f, as\u00ed como en varios sistemas operativos: Ubuntu antes de 12.04.4, CentOS posteriores a 6.5, OpenBSD 5.3 y otros. La lista completa est\u00e1 disponible en el sitio dedicado a Heartbleed.<\/a><\/noindex>. Aunque se lanzaron parches contra esta vulnerabilidad pr\u00e1cticamente de inmediato despu\u00e9s de su descubrimiento, el problema sigue vigente hasta hoy. En 2017, casi 200.000 sitios web<\/a><\/noindex>, todav\u00eda eran vulnerables a Heartbleed.<\/p>\n

C\u00f3mo protegerse.<\/b> Es necesario actualizar OpenSSL<\/a><\/noindex> a la versi\u00f3n 1.0.1g o superior. Tambi\u00e9n se pueden desactivar manualmente las solicitudes Heartbeat utilizando la opci\u00f3n DOPENSSL_NO_HEARTBEATS. Despu\u00e9s de la actualizaci\u00f3n, los especialistas en seguridad de la informaci\u00f3n recomiendan<\/a><\/noindex> deben volver a emitir los certificados SSL. La sustituci\u00f3n es necesaria en caso de que los datos sobre las claves de cifrado hayan ca\u00eddo en manos de los hackers.<\/p>\n

Suplantaci\u00f3n del certificado<\/h2>\n

\nSe establece un nodo gestionado entre el usuario y el servidor con un certificado SSL leg\u00edtimo que intercepta activamente el tr\u00e1fico. Este nodo se presenta como un servidor leg\u00edtimo, mostrando un certificado v\u00e1lido, lo que permite llevar a cabo un ataque MITM.<\/p>\n

Seg\u00fan un estudio<\/a><\/noindex> comandos de Mozilla, Google y varias universidades han encontrado que aproximadamente el 11% de las conexiones protegidas en la red est\u00e1n \"escuchadas\". Esto es el resultado de la instalaci\u00f3n de certificados ra\u00edz sospechosos en las computadoras de los usuarios.<\/p>\n

C\u00f3mo protegerse.<\/b> Utilizar los servicios de proveedores SSL confiables.<\/a><\/noindex>Se puede verificar la \"calidad\" de los certificados utilizando el servicio Certificate Transparency<\/a><\/noindex> (CT). Los proveedores de la nube tambi\u00e9n pueden ayudar en la detecci\u00f3n de \"escuchas\"; ya hoy en d\u00eda, algunas grandes empresas ofrecen herramientas especializadas para monitorear conexiones a trav\u00e9s de TLS.<\/p>\n

Otra forma de protecci\u00f3n ser\u00e1 el nuevo est\u00e1ndar<\/a><\/noindex> ACME, que automatiza la obtenci\u00f3n de certificados SSL. Al mismo tiempo, a\u00f1adir\u00e1 mecanismos adicionales para verificar la propiedad del sitio. M\u00e1s informaci\u00f3n sobre ello la hemos proporcionado en uno de nuestros materiales anteriores.<\/a><\/noindex>.<\/p>\n

\"Posibles
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

Perspectivas de HTTPS<\/h2>\n

\nA pesar de varias vulnerabilidades, los gigantes de TI y los expertos en seguridad inform\u00e1tica est\u00e1n seguros del futuro del protocolo. Gracias a la implementaci\u00f3n activa de HTTPS, es<\/a><\/noindex> el creador de la WWW, Tim Berners-Lee. Seg\u00fan \u00e9l, con el tiempo el TLS se volver\u00e1 m\u00e1s seguro, lo que aumentar\u00e1 significativamente la seguridad de las conexiones. Berners-Lee incluso sugiri\u00f3 que en el futuro aparecer\u00e1n<\/a><\/noindex> certificados de cliente para la autenticaci\u00f3n de identidad. Estos ayudar\u00e1n a mejorar la protecci\u00f3n de los servidores contra atacantes.<\/p>\n

Tambi\u00e9n se planea desarrollar la tecnolog\u00eda SSL\/TLS con la ayuda de aprendizaje autom\u00e1tico; algoritmos inteligentes se encargar\u00e1n de filtrar el tr\u00e1fico malicioso. En las conexiones HTTPS, los administradores no tienen la posibilidad de conocer el contenido de los mensajes cifrados, incluido el descubrimiento de solicitudes de software malicioso. Hoy en d\u00eda, las redes neuronales pueden filtrar paquetes potencialmente peligrosos con una precisi\u00f3n del 90%. (diapositiva 23 de la presentaci\u00f3n<\/a><\/noindex>).<\/p>\n

Conclusiones<\/h2>\n

\nLos ataques a HTTPS est\u00e1n mayormente relacionados no con problemas en el propio protocolo, sino con el soporte de mecanismos de cifrado obsoletos. La industria de TI comienza a renunciar gradualmente a los protocolos de la generaci\u00f3n anterior y ofrece nuevas herramientas para la b\u00fasqueda de vulnerabilidades. En el futuro, estas herramientas se volver\u00e1n cada vez m\u00e1s inteligentes.<\/p>\n

Enlaces adicionales sobre el tema:<\/h5>\n

<\/p>\n