Potencials atacs a HTTPS i com protegir-los

La meitat dels llocs utilitza HTTPS, i el seu nombre augmenta constantment. El protocol redueix el risc d'intercepció del trànsit, però no elimina els intents d'atac com a tal. Parlarem d'alguns d'ells -CANICHE, BÈSTIA, OFEGAMENT i d'altres- i mètodes de protecció en el nostre material.

Potencials atacs a HTTPS i com protegir-los
/flickr/ Sven Graeme / CC BY-SA

poodle

Per primera vegada sobre l'atac poodle es va donar a conèixer el 2014. L'especialista en seguretat de la informació Bodo Möller i els seus col·legues de Google van descobrir una vulnerabilitat en el protocol SSL 3.0.

La seva essència és la següent: el pirata informàtic obliga el client a connectar-se mitjançant SSL 3.0, emulant les interrupcions de la connexió. Llavors cerca en el xifrat CBC- missatges d'etiquetes especials en mode de trànsit. Mitjançant una sèrie de sol·licituds falsificades, un atacant és capaç de reconstruir el contingut de les dades d'interès, com ara les galetes.

SSL 3.0 és un protocol obsolet. Però la qüestió de la seva seguretat encara és rellevant. Els clients l'utilitzen per evitar problemes de compatibilitat amb els servidors. Segons algunes dades, gairebé el 7% dels 100 mil llocs més populars encara és compatible amb SSL 3.0. També existeix modificacions a POODLE que s'orienten als TLS 1.0 i TLS 1.1 més moderns. Aquest any va aparèixer nous atacs Zombie POODLE i GOLDENDOODLE que obvien la protecció TLS 1.2 (encara estan associats amb el xifratge CBC).

Com defensar-se. En el cas del POODLE original, heu de desactivar el suport SSL 3.0. Tanmateix, en aquest cas hi ha el risc de problemes de compatibilitat. Una solució alternativa podria ser el mecanisme TLS_FALLBACK_SCSV: assegura que l'intercanvi de dades mitjançant SSL 3.0 només es durà a terme amb sistemes antics. Els atacants ja no podran iniciar rebaixes de protocol. Una manera de protegir-se contra Zombie POODLE i GOLDENDOODLE és desactivar el suport CBC a les aplicacions basades en TLS 1.2. La solució cardinal serà la transició a TLS 1.3: la nova versió del protocol no utilitza xifratge CBC. En canvi, s'utilitzen AES i ChaCha20 més duradors.

BESTIA

Un dels primers atacs a SSL i TLS 1.0, descobert el 2011. Com POODLE, BEAST usos característiques del xifratge CBC. Els atacants instal·len un agent JavaScript o una miniaplicació Java a la màquina client, que substitueix els missatges quan transmeten dades mitjançant TLS o SSL. Com que els atacants coneixen el contingut dels paquets "fictícies", poden utilitzar-los per desxifrar el vector d'inicialització i llegir altres missatges al servidor, com ara galetes d'autenticació.

A partir d'avui, les vulnerabilitats BEAST continuen una sèrie d'eines de xarxa són susceptibles: Servidors intermediaris i aplicacions per protegir les passarel·les d'Internet locals.

Com defensar-se. L'atacant ha d'enviar sol·licituds periòdiques per desxifrar les dades. En VMware recomanar reduir la durada de SSLSessionCacheTimeout de cinc minuts (recomanació per defecte) a 30 segons. Aquest enfocament farà que sigui més difícil que els atacants implementin els seus plans, tot i que tindrà algun impacte negatiu en el rendiment. A més, heu d'entendre que la vulnerabilitat BEAST aviat pot convertir-se en cosa del passat per si sola: des del 2020, els navegadors més grans Atura suport per a TLS 1.0 i 1.1. En qualsevol cas, menys de l'1,5% de tots els usuaris del navegador treballen amb aquests protocols.

OFEGAR

Aquest és un atac entre protocols que explota errors en la implementació de SSLv2 amb claus RSA de 40 bits. L'atacant escolta centenars de connexions TLS de l'objectiu i envia paquets especials a un servidor SSLv2 utilitzant la mateixa clau privada. Utilitzant Atac de Bleichenbacher, un pirata informàtic pot desxifrar una de les mil sessions TLS de clients.

DROWN es va conèixer per primera vegada el 2016, després va resultar ser un terç dels servidors es veuen afectats en el món. Avui no ha perdut la seva rellevància. Dels 150 mil llocs més populars, el 2% encara ho són suport SSLv2 i mecanismes de xifratge vulnerables.

Com defensar-se. Cal instal·lar pedaços proposats pels desenvolupadors de biblioteques criptogràfiques que inhabilitin el suport SSLv2. Per exemple, es van presentar dos pedaços d'aquest tipus per a OpenSSL (el 2016 aquestes eren actualitzacions 1.0.1s i 1.0.2g). Així mateix, es van publicar actualitzacions i instruccions per desactivar el protocol vulnerable a Red Hat, Apache, Debian.

"Un recurs pot ser vulnerable a DROWN si les seves claus són utilitzades per un servidor de tercers amb SSLv2, com un servidor de correu", assenyala el cap del departament de desenvolupament. Proveïdor d'IaaS 1cloud.ru Serguei Belkin. — Aquesta situació es produeix si diversos servidors utilitzen un certificat SSL comú. En aquest cas, heu de desactivar el suport SSLv2 a totes les màquines".

Podeu comprovar si el vostre sistema s'ha d'actualitzar mitjançant un especial serveis públics — va ser desenvolupat per especialistes en seguretat de la informació que van descobrir DROWN. Podeu llegir més sobre recomanacions relacionades amb la protecció contra aquest tipus d'atac a publicar al lloc web d'OpenSSL.

Dolorós

Una de les vulnerabilitats més grans del programari és Dolorós. Va ser descobert l'any 2014 a la biblioteca OpenSSL. En el moment de l'anunci de l'error, el nombre de llocs web vulnerables s'estimava en mig milió - això és aproximadament el 17% dels recursos protegits de la xarxa.

L'atac s'implementa mitjançant el petit mòdul d'extensió Heartbeat TLS. El protocol TLS requereix que les dades es transmetin contínuament. En cas d'inactivitat prolongada, es produeix una interrupció i s'ha de restablir la connexió. Per fer front al problema, els servidors i els clients fan "soroll" artificial al canal (RFC 6520, pàg.5), transmetent un paquet de longitud aleatòria. Si era més gran que tot el paquet, les versions vulnerables d'OpenSSL llegeixen la memòria més enllà del buffer assignat. Aquesta àrea pot contenir qualsevol dada, incloses claus de xifratge privades i informació sobre altres connexions.

La vulnerabilitat estava present en totes les versions de la biblioteca entre 1.0.1 i 1.0.1f incloses, així com en diversos sistemes operatius: Ubuntu fins a 12.04.4, CentOS anterior a 6.5, OpenBSD 5.3 i altres. Hi ha una llista completa en un lloc web dedicat a Heartbleed. Tot i que els pegats contra aquesta vulnerabilitat es van publicar gairebé immediatament després del seu descobriment, el problema continua sent rellevant fins avui. Torna al 2017 gairebé 200 mil llocs funcionaven, susceptible a Heartbleed.

Com defensar-se. És necessari actualitzar OpenSSL fins a la versió 1.0.1g o superior. També podeu desactivar manualment les sol·licituds de batecs cardíacs mitjançant l'opció DOPENSSL_NO_HEARTBEATS. Després de l'actualització, especialistes en seguretat de la informació recomanar tornar a emetre certificats SSL. Cal un reemplaçament en cas que les dades de les claus de xifratge acabin en mans dels pirates informàtics.

Substitució de certificats

S'instal·la un node gestionat amb un certificat SSL legítim entre l'usuari i el servidor, interceptant el trànsit activament. Aquest node suplanta un servidor legítim presentant un certificat vàlid i és possible dur a terme un atac MITM.

Segons investigació equips de Mozilla, Google i diverses universitats, aproximadament l'11% de les connexions segures a la xarxa estan escoltades. Aquest és el resultat de la instal·lació de certificats arrel sospitosos als ordinadors dels usuaris.

Com defensar-se. Utilitzeu els serveis de confiança Proveïdors SSL. Podeu comprovar la "qualitat" dels certificats mitjançant el servei Certificat de transparència (CT). Els proveïdors de núvol també poden ajudar a detectar escoltes; algunes grans empreses ja ofereixen eines especialitzades per controlar les connexions TLS.

Un altre mètode de protecció serà un nou estàndard ACME, que automatitza la recepció de certificats SSL. Al mateix temps, afegirà mecanismes addicionals per verificar el propietari del lloc. Més sobre això vam escriure en un dels nostres materials anteriors.

Potencials atacs a HTTPS i com protegir-los
/flickr/ Yuri Samoilov / CC BY

Perspectives per a HTTPS

Malgrat una sèrie de vulnerabilitats, els gegants informàtics i els experts en seguretat de la informació confien en el futur del protocol. Per a la implementació activa d'HTTPS favors El creador de WWW Tim Berners-Lee. Segons ell, amb el temps TLS es tornarà més segur, la qual cosa millorarà significativament la seguretat de les connexions. Berners-Lee fins i tot ho va suggerir apareixerà en el futur certificats de client per a l'autenticació d'identitat. Ajudaran a millorar la protecció del servidor davant dels atacants.

També està previst desenvolupar la tecnologia SSL/TLS mitjançant l'aprenentatge automàtic: els algorismes intel·ligents seran els responsables de filtrar el trànsit maliciós. Amb les connexions HTTPS, els administradors no tenen manera d'esbrinar el contingut dels missatges xifrats, inclosa la detecció de sol·licituds de programari maliciós. Actualment, les xarxes neuronals són capaces de filtrar paquets potencialment perillosos amb un 90% de precisió. (Diapositiva de presentació 23).

Troballes

La majoria dels atacs a HTTPS no estan relacionats amb problemes amb el protocol en si, sinó amb el suport de mecanismes de xifratge obsolets. El sector informàtic comença a abandonar progressivament els protocols de generació anterior i ofereix noves eines per a la recerca de vulnerabilitats. En el futur, aquestes eines seran cada cop més intel·ligents.

Enllaços addicionals sobre el tema:

Font: www.habr.com

Afegeix comentari