| Starije izmjene na obje strane
Starija izmjena
Novija izmjena
|
Starija izmjena
|
racfor_wiki:napadi_na_https [2021/01/18 00:46]
fsodic [2.2 Sigurnosni zahtjevi HTTPS-a] |
racfor_wiki:napadi_na_https [2023/06/19 18:17] (trenutno)
|
| {{ :racfor_wiki:https2.png?direct&400 |}} | {{ :racfor_wiki:https2.png?direct&400 |}} |
| |
| Slika 2. Uspostava veze kod pristupanja stranici https://www.fer.unizg.hr. Vidljivo je nekoliko važnih paketa. Poruka //Client Hello// početak je uspostave TLS veze. Između ostalog, klijent poslužitelju nudi popis kriptografskih algoritama koje je spreman koristiti za komunikaciju (korak 2.I). Odgovor poslužitelja dolazi porukom //Server Hello// koja sadrži odabrani kriptografski algoritam s popisa (korak 2.I). Sljedeća važna poruka, //Certificate//, služi za autentifikaciju poslužitelja (korak 2.II). Porukama //Server Key Exchange// i //Client Key Exchange// dogovara se sjednički ključ (korak 2.III). Poslužitelj signalizira završteak rukovanja porukom //Server Hello Done//. Konačno, porukama //Encrypted Handshake Message// započinje enkriptirana komunikacija. Na slici je označen HTTP zahtjev koji se šalje nakon uspostave enkriptirane TLS veze. Unutar TLS paketa nalazi se isti HTTP zahtjev kao i na slici 1. Međutim, sadržaj je paketa enkriptirana te mu je integritet osiguran autentifikacijskim kodom poruke (HMAC). Nitko na mreži ne može čitati i mijenjati njegov sadržaj [8]. | Slika 2. Uspostava veze kod pristupanja stranici https://www.fer.unizg.hr. Vidljivo je nekoliko važnih paketa. Poruka //Client Hello// početak je uspostave TLS veze. Između ostalog, klijent poslužitelju nudi popis kriptografskih algoritama koje je spreman koristiti za komunikaciju (korak 2.I). Odgovor poslužitelja dolazi porukom //Server Hello// koja sadrži odabrani kriptografski algoritam s popisa (korak 2.I). Sljedeća važna poruka, //Certificate//, služi za autentifikaciju poslužitelja (korak 2.II). Porukama //Server Key Exchange// i //Client Key Exchange// dogovara se sjednički ključ (korak 2.III). Poslužitelj signalizira završteak rukovanja porukom //Server Hello Done//. Konačno, porukama //Encrypted Handshake Message// započinje enkriptirana komunikacija. Na slici je označen HTTP zahtjev koji se šalje nakon uspostave enkriptirane TLS veze. Unutar TLS paketa nalazi se isti HTTP zahtjev kao i na slici 1. Međutim, sadržaj je paketa enkriptiran, a njegov je integritet osiguran autentifikacijskim kodom poruke (HMAC). Nitko na mreži ne može čitati ili mijenjati njegov sadržaj [8]. |
| |
| Autentifikacija poslužitelja i sigurnost cijelog protokola počivaju na implicitnom povjerenju u autoritete za izdavanje certifikata. Naime, HTTPS je siguran samo uz garanciju da je treća strana, koja potpisuje autentičnost vlasnika certifikata, vjerodostojna i nekompromitirana. | Autentifikacija poslužitelja i sigurnost cijelog protokola počivaju na implicitnom povjerenju u autoritete za izdavanje certifikata (CA). Naime, HTTPS je siguran samo uz garanciju da je treća strana, koja potpisuje autentičnost vlasnika certifikata, vjerodostojna i nekompromitirana. |
| |
| |
| - Napadom ili utjecajem na autoritete koji izdaju i potpisuju certifikate | - Napadom ili utjecajem na autoritete koji izdaju i potpisuju certifikate |
| |
| Pristupi 1 i 2 u praksi su rijetko korisni. Kriptografski protokoli i algoritmi prolaze kroz rigorozan proces dizajna i analize sigurnosti. Protokol HTTPS uspješno se koristi već 20 godina i do sad nije zabilježen niti jedan napad koji iskorištava njegove teorijske nedostatke. Slična je situacija i s većinom kriptografskih algoritama koje on interno može koristiti. S vremenom se neki od tih algoritama uistinu jesu počeli smatrati nesigurnima te svakako postoje načini na koje se oni mogu napasti. Kako je fokus ovog rada sam protokol HTTPS, takvi se napadi neće detaljno razmatrati. | Pristupi 1 i 2 u praksi su rijetko korisni. Kriptografski protokoli i algoritmi prolaze kroz rigorozan proces dizajna i analize sigurnosti. Protokol HTTPS uspješno se koristi već 20 godina i do sad nije zabilježen niti jedan napad koji iskorištava njegove teorijske nedostatke. Slična je situacija i s većinom kriptografskih algoritama koje on interno može koristiti. Pojedini algoritmi s vremenom jesu zastarjeli i svakako ih je moguće uspješno napasti. Kako je fokus ovog rada sam protokol HTTPS, takvi se napadi neće detaljno razmatrati. |
| |
| Pristup 3 vrlo je čest problem u praksi. Nekoliko je napada koji ga koriste detaljnije opisano u sljedećem poglavlju. | Pristup 3 vrlo je čest problem u praksi. Nekoliko je napada koji ga koriste detaljnije opisano u sljedećem poglavlju. |
| //Heartbleed// svakom korisniku Interneta pruža mogućnost čitanja spremnika radne memorije na bilo kojem sustavu koji koristi ranjivu verziju paketa. Drugim riječima, ova ranjivost otvara mogućnost kompromitiranja privatnih ključeva poslužitelja na kojima počiva sigurnost svih protokola koji koriste TLS, pa tako i sigurnost HTTPS-a. Sve je to moguće bez ostavljanja ikakvih tragova. | //Heartbleed// svakom korisniku Interneta pruža mogućnost čitanja spremnika radne memorije na bilo kojem sustavu koji koristi ranjivu verziju paketa. Drugim riječima, ova ranjivost otvara mogućnost kompromitiranja privatnih ključeva poslužitelja na kojima počiva sigurnost svih protokola koji koriste TLS, pa tako i sigurnost HTTPS-a. Sve je to moguće bez ostavljanja ikakvih tragova. |
| |
| Iako je greška u paketu otklonjena vrlo brzo, //Heartbleed// i dalje predstavlja prijetnju svim poslužiteljima koji nisu instalirali navedeno ažuriranje. Ozbiljne implikacije dolaze i od činjenice da je ranjivost otkrivena tek dvije godine nakon svog nastanka [11]. | Iako je greška u paketu otklonjena vrlo brzo, //Heartbleed// i dalje predstavlja prijetnju svim poslužiteljima koji nisu instalirali navedeno ažuriranje. Ozbiljne implikacije dolaze i od činjenice da je ranjivost otkrivena tek dvije godine nakon nastanka [11]. |
| |
| S tehničke strane, ranjivost je nastala zbog nedostatka provjere duljine međuspremnika (eng. //buffer underflow//) pri odgovaranju na zahtjeve klijenta za provjeru stanja veze (eng. //SSL Heartbeat//). | S tehničke strane, ranjivost je nastala zbog nedostatka provjere duljine međuspremnika (eng. //buffer underflow//) pri odgovaranju na zahtjeve klijenta za provjeru stanja veze (eng. //SSL Heartbeat//). |
| |
| === 4.1.2 Napad BEAST === | === 4.1.2 Napad BEAST === |
| //BEAST// je kratica za //Browser Exploit Against SSL/TLS//. Riječ je //man-in-the-middle downgrade// napadu u kojem se napadač pozicionira između klijenata i poslužitelja te presretanjem poruka nastoji spustiti verziju TLS-a na 1.0 (ili bilo koju verziju SSL-a ((TLS 1.0 nadogradnja je na protokol SSL 3.0))). Navedena verzija pati od kriptografskog nedostatka koji napadaču pruža mogućnost prisluškivanja enkriptirane komunikacije. | //BEAST// je kratica za //Browser Exploit Against SSL/TLS//. Riječ je //man-in-the-middle downgrade// napadu u kojem se napadač pozicionira između klijenata i poslužitelja te presretanjem poruka nastoji spustiti verziju TLS-a na 1.0 (ili bilo koju verziju SSL-a ((TLS 1.0 nadogradnja je na protokol SSL 3.0))). Navedena verzija pati od kriptografskog nedostatka koji napadaču pruža mogućnost prisluškivanja enkriptirane komunikacije [2]. |
| |
| Od napada se najbolje obraniti konfiguriranjem poslužitelja da ne podržava TLS 1.0 ili bilo koju verziju SSL-a. Dok god su navedene verzije protokola podržane, poslužitelj je ranjiv. | Od napada se najbolje obraniti konfiguriranjem poslužitelja da ne podržava TLS 1.0 ili bilo koju verziju SSL-a. Dok god su navedene verzije protokola podržane, poslužitelj je ranjiv. |
| |
| === 4.2.1 SSL Strip === | === 4.2.1 SSL Strip === |
| //SSL Strip// vrsta je man-in-the-middle downgrade napada i izvodi se na sljedeći način [todo izvor]: | //SSL Strip// vrsta je //man-in-the-middle downgrade// napada i izvodi se na sljedeći način [16]: |
| - Napadač se pozicionira između klijenta i poslužitelja. Mogući načini uključuju lažne priključne točke za Wi-Fi, krivotvorene ARP poruke (engl. //ARP spoofing//), i kompromitiranje drugih računala na mreži. | - Napadač se pozicionira između klijenta i poslužitelja. Mogući načini uključuju lažne priključne točke za Wi-Fi, krivotvorene ARP poruke (engl. //ARP spoofing//), i kompromitiranje drugih računala na mreži. |
| - Klijent uspostavlja vezu s poslužiteljem (npr. www.fer.unizg.hr) najčešće uz preusmjeravanje s HTTP-a na HTTPS | - Klijent uspostavlja vezu s poslužiteljem (npr. www.fer.unizg.hr) najčešće uz preusmjeravanje s HTTP-a na HTTPS |
| - Odgovore koji pristižu s poslužitelja napadač vraća klijentu putem HTTP-a, odnosno, bez dodatne enkripcije | - Odgovore koji pristižu s poslužitelja napadač vraća klijentu putem HTTP-a, odnosno, bez dodatne enkripcije |
| - Napadač može nesmetano čitati i mijenjati poruke, čak i kad poslužitelj dopušta isključivo sigurne veze (jer je iz perspektive poslužitelja uspostavljena sigurna veza) | - Napadač može nesmetano čitati i mijenjati poruke, čak i kad poslužitelj dopušta isključivo sigurne veze (jer je iz perspektive poslužitelja uspostavljena sigurna veza) |
| SSL Strip napda sigurnost HTTPS tako da ga na dijelu komunikacijskog kanala uopće ne koristi. Uobičajeni tijek komunikacije prikazan je slikom 3. Slika 4 prikazuje uspješno provođenje napada. | SSL Strip napada sigurnost HTTPS tako da ga na dijelu komunikacijskog kanala uopće ne koristi. Uobičajeni tijek komunikacije prikazan je slikom 3. Slika 4 prikazuje uspješno provođenje napada. |
| |
| {{ :racfor_wiki:ssl-strip-1.png?direct&400 |}} | {{ :racfor_wiki:ssl-strip-1.png?direct&400 |}} |
| {{ :racfor_wiki:ssl-strip-2.png?direct&400 |}} | {{ :racfor_wiki:ssl-strip-2.png?direct&400 |}} |
| |
| Slika 4. Prikaz napada //SSL Strip//. Napadač se postavlja između klijenta i poslužitelja. U trenutku kada bi klijent bio preusmjeren na HTTPS, napadač uspostavlja HTTPS vezu s poslužiteljem, a s klijentom komunicira preko nezaštićene vezom. | Slika 4. Prikaz napada //SSL Strip//. Napadač se postavlja između klijenta i poslužitelja. U trenutku kada bi klijent bio preusmjeren na HTTPS, napadač uspostavlja HTTPS vezu s poslužiteljem, a s klijentom komunicira nezaštićenom vezom. |
| |
| Najsigurnija je obrana od //SSL Strip// napada gašenje podrške za HTTP na poslužitelju. Drugim riječima, odrekne li se poslužitelj mogućnosti preusmjeravanja klijenata pri njihovom inicijalnom dolasku na stranicu, prijetnja je u potpunosti otklonjena. Nažalost, spomenuto je rješenje nepraktično te bi poslužitelje koštalo mnogo dolazećeg prometa. | Zahvaljujući zaglavlju //Strict-Transport-Security// [9], //SSL Strip// danas je opasan u puno manjoj mjeri. Određeni web preglednici pri svakom pokušaju uspostavljanja HTTP veze nastoje prijeći na HTTPS (prije ikakve komunikacije s poslužiteljem). |
| | |
| Ipak, zahvaljujući zaglavlju //Strict-Transport-Security// [9], //SSL Strip// danas je opasan u puno manjoj mjeri. Određeni web preglednici pri svakom pokušaju uspostavljanja HTTP veze nastoje prijeći na HTTPS (prije ikakve komunikacije s poslužiteljem). | |
| |
| Konačno, Google pruža uslugu //HSTS preload//. Vlasnici web stranica imaju mogućnost dodati svoju domenu na popis i time osigurati da se na nju preglednici nikad ne pokušavaju spojiti nesigurnom vezom. Iako je riječ o Googleovoj usluzi, svi su proizvođači preglednika obećali podržati uslugu u budućnosti [9]. | Konačno, Google pruža uslugu //HSTS preload//. Vlasnici web stranica imaju mogućnost dodati svoju domenu na popis i time osigurati da se na nju preglednici nikad ne pokušavaju spojiti nesigurnom vezom. Iako je riječ o Googleovoj usluzi, svi su proizvođači preglednika obećali podržati uslugu u budućnosti [9]. |
| Uspije li napadač na bilo koji način doći do tajnih ključeva koje poslužitelji koriste pri autentifikaciji, sigurnosne garancije protokola prestaju vrijediti. | Uspije li napadač na bilo koji način doći do tajnih ključeva koje poslužitelji koriste pri autentifikaciji, sigurnosne garancije protokola prestaju vrijediti. |
| |
| Naime, dođe li u posjed tajnih ključeva (ili certifikata), napadač može nesmetano izvoditi man-in-the-middle napade, bilo u svrhu lažnog predstavljanja, prisluškivanja ili manipulacije poruka. Napad je iznimno teško otkriti. Iz perspektive klijenta, zbog povjerenja u tajnost ključa, poslužitelj se čini legitimnim. Iz perspektive poslužitelja, napadač izgleda kao samo još jedan klijent. | Naime, dođe li u posjed tajnih ključeva (ili certifikata), napadač može nesmetano izvoditi //man-in-the-middle// napade, bilo u svrhu lažnog predstavljanja, prisluškivanja ili manipulacije poruka. Napad je iznimno teško otkriti. Iz perspektive klijenta, zbog povjerenja u tajnost ključa, poslužitelj se čini legitimnim. Iz perspektive poslužitelja, napadač izgleda kao samo još jedan klijent. |
| |
| Napadač do tajnih certifikata može doći raznim metodama, često potpuno nepovezanim sa samom komunikacijom preko HTTPS-a. | Napadač do tajnih certifikata može doći raznim metodama, često potpuno nepovezanim sa samom komunikacijom preko HTTPS-a. |
| |
| === 4.2.2 Nedostatak povjerenja u autoritete za izdavanje certifikata === | === 4.2.2 Nedostatak povjerenja u autoritete za izdavanje certifikata === |
| Kao što je već spomenuto u ranijim poglavljima, sigurnost cijelog sustava počiva na implicitnom povjerenju u skupinu autoriteta koji stoje iza izdanih certifikata (CA). Uspije li netko napasti ili na drugi način utjecati na odluke tih tvrtki, implikacije na sigurnost protokola prilično su ozbiljne. Ukratko, kompromitiranje certifikata ovih autoriteta sličan je problem kompromitiranju certifikata jednog poslužitelja (opisan u poglavlju 4.2.2), ali uz značajno veći opseg jer su ugroženi identiteti svih poslužitelja kojima je kompromitirani autoritet izdao certifikat. | Kao što je već spomenuto u ranijim poglavljima, sigurnost cijelog sustava počiva na implicitnom povjerenju u skupinu autoriteta koji stoje iza izdanih certifikata (CA). Uspije li netko napasti ili na drugi način utjecati na odluke tih tvrtki, implikacije na sigurnost protokola prilično su ozbiljne. Kompromitiranje certifikata ovih autoriteta sličan je problem kompromitiranju certifikata jednog poslužitelja (opisan u poglavlju 4.2.2), ali uz značajno veći opseg jer ugroženima postaju i identiteti svih poslužitelja kojima je kompromitirani autoritet izdao certifikat. |
| |
| Upravo su zato autoriteti za izdavanje certifikata najprimamljivija meta kriminalcima, ali i svjetskim vladama te danas predstavljaju najslabiju točku sustava. Kako popularnost i reputacija određenog autoriteta raste, napada na njega postaje sve primamljiviji i sve opasniji. Kroz povijest je zabilježeno nekoliko ovakvih scenarija. Na sreću, svi su brzo otkriveni i utjecaj koji su imali nije bio značajan. Ipak, poslužili su za skretanje pažnje na najveću slabost sustava koja još uvijek nije adekvatno riješena. | Upravo su zato autoriteti za izdavanje certifikata najprimamljivija meta kriminalcima (ali i svjetskim vladama) te danas predstavljaju najslabiju točku sustava. Kako popularnost i reputacija određenog autoriteta raste, napad na njega postaje sve isplativijim i opasnijim. Kroz povijest je zabilježeno nekoliko ovakvih scenarija. Na sreću, svi su brzo otkriveni i utjecaj koji su imali nije bio značajan. Ipak, poslužili su za skretanje pažnje na trenutno najveću slabost sustava koja još uvijek nije adekvatno riješena. |
| |
| Autoritet za izdavanje certifikata VeriSign izdao je 2001. godine dva certifikata osobi koja je tvrdila da predstavlja Microsoft. Certifikati su nosili ime //Microsoft Corporation// i teoretski bi se mogli iskoristiti za distribuciju krivotvorenih ažuriranja operacijskog sustava Windows. Problem je brzo otkriven te su Microsoft i VeriSign poduzeli određene korake kako bi ograničili njegov opseg [12]. | Autoritet za izdavanje certifikata VeriSign izdao je 2001. godine dva certifikata osobi koja je tvrdila da predstavlja Microsoft. Certifikati su nosili ime //Microsoft Corporation// i teoretski bi se mogli iskoristiti za distribuciju krivotvorenih ažuriranja operacijskog sustava Windows. Problem je brzo otkriven te su Microsoft i VeriSign poduzeli određene korake kako bi ograničili njegov opseg [12]. |
| |
| 2011. godine izvršen je napad na Nizozemski CA DigiNotar koji je rezultirao izdavanjem brojnih lažnih certifikata. Ukupno ih pronađeno oko 500 [13]. Između ostalih, izdani su bili certifikati za tvrtke Yahoo!, Mozilla, WordPress, Google, i Tor. Kasnije je potvrđeno kako su se isti certifikati u Iranu koristili za provođenje //man-in-the-middle// napada na Googleove servise [14]. Proizvođači preglednika reagirali su stavljanjem svih DigiNotar certifikata na crnu listu [13]. Tvrtka DigiNotar bankrotirala je istog mjeseca [15], a počinitelji nikad nisu u potpunosti utvrđeni. Napad je poslužio kao demonstracija nedostataka sustava te osvijestio potrebu za hitnim reformama na kojima se još uvijek radi. | 2011. godine izvršen je napad na Nizozemski CA DigiNotar koji je rezultirao izdavanjem brojnih lažnih certifikata. Ukupno ih pronađeno oko 500 [13]. Između ostalih, izdani su bili certifikati za tvrtke Yahoo!, Mozilla, WordPress, Google, i Tor. Kasnije je potvrđeno kako su se isti certifikati u Iranu koristili za provođenje //man-in-the-middle// napada na Googleove servise [14]. Proizvođači preglednika reagirali su stavljanjem svih DigiNotar certifikata na crnu listu [13]. Tvrtka DigiNotar bankrotirala je istog mjeseca [15], a počinitelji nikad nisu sa sigurnošću utvrđeni. Napad je poslužio kao demonstracija nedostataka sustava te osvijestio potrebu za hitnim reformama na kojima se još uvijek radi. |
| ===== Zaključak ===== | ===== Zaključak ===== |
| U seminaru je dan kratak pregled sigurnosnih nadogradnji na HTTP koje omogućuje TLS, odnosno, HTTPS. Analizirane su moguće strategije napada na protokol te je pokazano da najuspješnije od njih protokol u potpunosti zaobilaze, bilo //downgrade// napadima ili kompromitiranjem čimbenika njegove sigurnosti. | U seminaru je dan kratak pregled sigurnosnih nadogradnji na HTTP koje omogućuje TLS, odnosno, HTTPS. Analizirane su moguće strategije napada na protokol te je pokazano da najuspješnije od njih protokol u potpunosti zaobilaze, bilo //downgrade// napadima ili kompromitiranjem čimbenika njegove sigurnosti. |
| |
| |
| [2] [[http://www.google.com/books?id=duWx8fxkkk0C&printsec=frontcover#v=onepage&q&f=false|Mayer, Richard E. The Cambridge handbook of multimedia learning. Cambridge University Press, 2005.]] | [2] [[https://www.netsparker.com/blog/web-security/how-the-beast-attack-works/|Zbigniew Banach. How the BEAST Attack Works. Netsparker, 2020.]] |
| |
| [3] [[https://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/|Craig Timberg. A flaw in the design. The Washington Post, 2015.]] | [3] [[https://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/|Craig Timberg. A flaw in the design. The Washington Post, 2015.]] |
| |
| [15][[https://web.archive.org/web/20110923180445/http://www.vasco.com/company/press_room/news_archive/2011/news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx|Press release. VASCO Announces Bankruptcy Filing by DigiNotar B.V. VASCO Data Security International, 2011]] | [15][[https://web.archive.org/web/20110923180445/http://www.vasco.com/company/press_room/news_archive/2011/news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx|Press release. VASCO Announces Bankruptcy Filing by DigiNotar B.V. VASCO Data Security International, 2011]] |
| | |
| | [16] [[https://www.venafi.com/blog/what-are-ssl-stripping-attacks|Anastasios Arampatzis. What Are SSL Stripping Attacks? Venafi, 2020.]] |
| |
