{"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\/no\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Potensielle angrep p\u00e5 HTTPS og hvordan beskytte seg mot dem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Halvparten av nettsteder bruke HTTPS<\/a><\/noindex>, og antallet \u00f8ker stabilt. Protokollen reduserer risikoen for avlytting av trafikk, men eliminerer ikke angrepsfors\u00f8k. Noen av dem - POODLE, BEAST, DROWN og andre - og m\u00e5ter \u00e5 beskytte seg mot dem, vil vi dele i v\u00e5rt materiale.<\/p>\n

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

POODLE<\/h2>\n

\nF\u00f8rste gang angrepet POODLE<\/a><\/noindex> ble kjent i 2014. S\u00e5rbarheten i SSL 3.0-protokollen ble oppdaget av sikkerhetsspesialist Bodo M\u00f6ller og kolleger fra Google.<\/p>\n

Kjernen i dette er som f\u00f8lger: En hacker tvinger en klient til \u00e5 koble til via SSL 3.0 ved \u00e5 simulere brudd p\u00e5 forbindelsen. Deretter leter han i den krypterte CBC<\/a><\/noindex>-modus trafikken etter spesielle meldingsmark\u00f8rer. Ved hjelp av en serie falske foresp\u00f8rsel f\u00e5r angriperen muligheten til \u00e5 rekonstruere innholdet av dataene han er interessert i, for eksempel informasjonskapsler.<\/p>\n

SSL 3.0 er en foreldet protokoll. Men sp\u00f8rsm\u00e5let om sikkerheten dens er fortsatt relevant. Klienter bruker det for \u00e5 unng\u00e5 kompatibilitetsproblemer med servere. If\u00f8lge noen data st\u00f8tter nesten 7% av de 100.000 mest popul\u00e6re nettstedene fortsatt SSL 3.0<\/a><\/noindex>. Ogs\u00e5 det finnes<\/a><\/noindex> modifikasjoner av POODLE, som har som m\u00e5l mer moderne TLS 1.0 og TLS 1.1. I \u00e5r har det oppst\u00e5tt<\/a><\/noindex> nye angrep Zombie POODLE og GOLDENDOODLE, som omg\u00e5r beskyttelsen av TLS 1.2 (de er fortsatt relatert til CBC-kryptering).<\/p>\n

Hvordan beskytte seg.<\/b> N\u00e5r det gjelder det originale POODLE, m\u00e5 st\u00f8tte for SSL 3.0 deaktiveres. Imidlertid er det risiko for \u00e5 f\u00e5 kompatibilitetsproblemer. En alternativ l\u00f8sning kan v\u00e6re mekanismen TLS_FALLBACK_SCSV - den garanterer at datautveksling over SSL 3.0 kun vil skje med gamle systemer. Angripere vil ikke lenger kunne initiere nedgradering av protokollen. Hvordan beskytte seg mot Zombie POODLE og GOLDENDOODLE - deaktivering av st\u00f8tte for CBC i applikasjoner basert p\u00e5 TLS 1.2. En radikal l\u00f8sning vil v\u00e6re \u00e5 g\u00e5 over til TLS 1.3 - i den nye versjonen av protokollen brukes ikke CBC-kryptering. I stedet brukes mer robuste AES og ChaCha20.<\/p>\n

BEAST<\/h2>\n

\nEt av de aller f\u00f8rste angrepene p\u00e5 SSL og TLS 1.0, oppdaget i 2011. Som med POODLE, BEAST bruker<\/a><\/noindex> egenskapene til CBC-kryptering. Angripere injiserer en JavaScript-agent eller Java-applet p\u00e5 klientmaskinen som endrer meldinger under overf\u00f8ring av data via TLS eller SSL. Siden angriperne kjenner innholdet i de 'falske' pakkene, kan de bruke dem til \u00e5 dekryptere initieringsvektoren og lese de andre meldingene til serveren, for eksempel informasjonskapsler for godkjenning.<\/p>\n

I dag er BEAST-s\u00e5rbarheten fortsatt utsatt for flere nettverksverkt\u00f8y<\/a><\/noindex>: proxy-servere og applikasjoner for beskyttelse av lokale internettporter.<\/p>\n

Hvordan beskytte seg.<\/b> Angriperen m\u00e5 regelmessig sende foresp\u00f8rsel for \u00e5 dekryptere data. I VMware \u00e5 lese b\u00f8ker \"<\/a><\/noindex> b\u00f8r man redusere varigheten p\u00e5 SSLSessionCacheTimeout \u2014 fra fem minutter (standard anbefaling) til 30 sekunder. Denne tiln\u00e6rmingen vil komplisere planene for angriperne, selv om det ogs\u00e5 vil ha en viss negativ effekt p\u00e5 ytelsen. Videre m\u00e5 man forst\u00e5 at s\u00e5rbarheten BEAST snart kan bli utdatert av seg selv \u2014 fra 2020 vil de st\u00f8rste nettleserne stoppe<\/a><\/noindex> st\u00f8tten for TLS 1.0 og 1.1. Uansett fungerer disse protokollene med mindre enn 1,5 % av alle nettleserbrukere.<\/p>\n

DROWN<\/h2>\n

\nDette er et tverrprotokollangrep som utnytter feil i implementeringen av SSLv2 med 40-biters RSA-n\u00f8kler. Angriperen overv\u00e5ker hundrevis av TLS-tilkoblinger til m\u00e5let og sender spesielle pakker til serveren med SSLv2, som bruker den samme private n\u00f8kkelen. Ved \u00e5 bruke Bleichenbacher-angrepet<\/a><\/noindex>, kan en hacker dekryptere en av omtrent tusen TLS-\u00f8kter til klienten.<\/p>\n

DROWN ble f\u00f8rst kjent i 2016 \u2014 den gang var den utsatt for en tredjedel av serverne<\/a><\/noindex> i verden. Den har ikke mistet relevans i dag. Blant de 150 000 mest popul\u00e6re nettstedene st\u00f8tter 2 % fortsatt SSLv2 og s\u00e5rbare krypteringsmekanismer.<\/a><\/noindex> Det er n\u00f8dvendig \u00e5 installere oppdateringer foresl\u00e5tt av utviklere av kryptografiske biblioteker som deaktiverer st\u00f8tten for SSLv2. For eksempel ble to slike utbedringer gjort tilgjengelig for OpenSSL (i 2016<\/p>\n

Hvordan beskytte seg.<\/b> var disse oppdateringene 1.0.1s og 1.0.2g). Oppdateringer og instruksjoner for \u00e5 deaktivere den s\u00e5rbare protokollen er ogs\u00e5 publisert i<\/a><\/noindex> Red Hat \u00abRessursen kan v\u00e6re s\u00e5rbar for DROWN hvis dens n\u00f8kler brukes av en ekstern server med SSLv2, for eksempel en e-postserver\u00bb, bemerker lederen for utviklingsavdelingen<\/a><\/noindex>, Apache.<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

IaaS-leverand\u00f8ren 1cloud.ru. IaaS-leverand\u00f8ren 1cloud.ru<\/a><\/noindex> Sergej Belkin. \u2014 Denne situasjonen oppst\u00e5r hvis flere servere bruker et felles SSL-sertifikat. I s\u00e5 fall m\u00e5 man deaktivere SSLv2-st\u00f8tte p\u00e5 alle maskinene.<\/i><\/p><\/blockquote>\n

\nDu kan sjekke om det er n\u00f8dvendig \u00e5 oppdatere systemet ditt ved hjelp av et spesialverkt\u00f8y verkt\u00f8y<\/a><\/noindex> \u2014 dette er utviklet av spesialister innen informasjonssikkerhet som oppdaget DROWN. Mer om anbefalingene knyttet til beskyttelse mot denne typen angrep kan du lese i innlegget p\u00e5 OpenSSL-nettstedet<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nEn av de mest alvorlige s\u00e5rbarhetene i programvare \u2014 Heartbleed<\/a><\/noindex>. Den ble oppdaget i 2014 i OpenSSL-biblioteket. P\u00e5 tidspunktet for kunngj\u00f8ringen ble antallet s\u00e5rbare nettsteder ansl\u00e5tt til en halv million<\/a><\/noindex> \u2014 dette er omtrent 17% av beskyttede ressurser p\u00e5 nettet.<\/p>\n

Angrepet gjennomf\u00f8res via en liten modul i TLS-utvidelsen kalt Heartbeat. TLS-protokollen krever at data overf\u00f8res kontinuerlig. Ved langvarig inaktivitet oppst\u00e5r det avbrudd, og man m\u00e5 etablere forbindelsen p\u00e5 nytt. For \u00e5 h\u00e5ndtere problemet \u00abst\u00f8ylegger\u00bb servere og klienter kanalen (RFC 6520, s. 5<\/a><\/noindex>), ved \u00e5 sende pakker av tilfeldig lengde. Hvis denne oversteg st\u00f8rrelsen p\u00e5 pakken, kunne s\u00e5rbare versjoner av OpenSSL lese minne utenfor det tildelte bufferen. I dette omr\u00e5det kunne det befinne seg hvilke som helst data, inkludert private krypteringsn\u00f8kler og informasjon om andre forbindelser.<\/p>\n

S\u00e5rbarheten var til stede i alle versjoner av biblioteket fra 1.0.1 til og med 1.0.1f, samt i en rekke operativsystemer \u2014 Ubuntu f\u00f8r 12.04.4, eldre enn 6.5 CentOS, OpenBSD 5.3 og andre. Den komplette listen er tilgjengelig p\u00e5 nettstedet dedikert til Heartbleed<\/a><\/noindex>. Selv om oppdateringer mot denne s\u00e5rbarheten ble utgitt umiddelbart etter oppdagelsen, forblir problemet aktuelt fortsatt. S\u00e5 tidlig som i 2017 var nesten 200 000 nettsteder<\/a><\/noindex>, utsatt for Heartbleed.<\/p>\n

Hvordan beskytte seg.<\/b> Det er n\u00f8dvendig \u00e5 oppdatere OpenSSL<\/a><\/noindex> til versjon 1.0.1g eller h\u00f8yere. Man kan ogs\u00e5 manuelt deaktivere Heartbeat-foresp\u00f8rslene ved hjelp av alternativet DOPENSSL_NO_HEARTBEATS. Etter oppdateringen m\u00e5 informasjonssikkerhetsspesialister \u00e5 lese b\u00f8ker \"<\/a><\/noindex> utstede SSL-sertifikater p\u00e5 nytt. Bytte er n\u00f8dvendig i tilfelle data om krypteringsn\u00f8kler har kommet til hackere.<\/p>\n

Sertifikatforfalskning<\/h2>\n

\nMellom brukeren og serveren etableres en kontrollert node med et legitimit SSL-sertifikat som aktivt fanger trafikk. Denne noden gir seg ut for \u00e5 v\u00e6re en legitim server, fremlegger et gyldig sertifikat, og det \u00e5pner muligheten for et MITM-angrep.<\/p>\n

I henhold til unders\u00f8kelse<\/a><\/noindex> If you believe the team from Mozilla, Google, and several universities, about 11% of secure connections on the network are being 'listened to'. This is a result of suspicious root certificates being installed on users' computers.<\/p>\n

Hvordan beskytte seg.<\/b> Utilizing the services of reliable SSL providers<\/a><\/noindex>. You can check the 'quality' of certificates using the service Certificate Transparency<\/a><\/noindex> (CT). Cloud providers can also assist in detecting 'listening' \u2014 already today, some large companies offer specialized tools for monitoring TLS connections.<\/p>\n

Another method of protection will be the new standarden<\/a><\/noindex> ACME, which automates the issuance of SSL certificates. At the same time, it will add additional mechanisms for verifying the site's owner. More about it we wrote in one of our previous articles<\/a><\/noindex>.<\/p>\n

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

The Prospects of HTTPS<\/h2>\n

\nDespite a number of vulnerabilities, IT giants and cybersecurity experts are confident in the future of the protocol. The active implementation of HTTPS is advocated by<\/a><\/noindex> the creator of the WWW, Tim Berners-Lee. According to him, over time, TLS will become more secure, significantly enhancing connection safety. Berners-Lee even suggested that in the future, client certificates will emerge<\/a><\/noindex> for identity authentication. They will help improve server protection against attackers.<\/p>\n

The development of SSL\/TLS technology is also planned through machine learning \u2014 smart algorithms will be responsible for filtering malicious traffic. In HTTPS connections, administrators have no way of knowing the contents of encrypted messages \u2014 including detecting requests from malware. Already today, neural networks can filter potentially dangerous packets with 90% accuracy. (slide 23 of the presentation<\/a><\/noindex>).<\/p>\n

Konklusjoner<\/h2>\n

\nAttacks on HTTPS are largely related not to issues within the protocol itself, but rather to the support of outdated encryption mechanisms. The IT industry is gradually starting to move away from previous-generation protocols and is offering new tools for finding vulnerabilities. In the future, these tools will become increasingly intelligent.<\/p>\n

Additional links on the topic:<\/h5>\n

<\/p>\n