EIT060 Datasäkerhet - Projekt 2. Jacob Ferm, dt08jf0 Johan Paulsson, dt08jp8 Erik Söderqvist, dt08es8 Magnus Johansson, dt08mj9 26 februari 2011

Transkript

1 EIT060 Datasäkerhet - Projekt 2 Jacob Ferm, dt08jf0 Johan Paulsson, dt08jp8 Erik Söderqvist, dt08es8 Magnus Johansson, dt08mj9 26 februari 2011

2 Innehåll 1 Introduktion 1 2 SSL Anslutningsprocessen Säkerhet Certifikat CA - Certifikatauktoritet Autentisering Beskrivning av Outstandning Journal Delivery System (OJDS) 3 5 Säkerhetsanalys av OJDS Spoofing attack Avlyssningsattack Man-in-the-middle attack Förfalskade certifikat Denial of Service-attack Utomjordingar strålar upp servern till deras rymdskepp Replay-attack Den mänskliga faktorn Sammanfattning 7

3 1 Introduktion Denna projektrapport behandlar ämnet SSL och autentisering med certifikat.vi beskriver kortfattat grunderna i SSL samt hur en typisk anslutning fungerar. Autentisering med hjälp av certifikat behandlas även kortfattat under den första delen av rapporten. Den andra delen av rapporten inleds med en beskrivning av system som vi har implementerat. Därefter följer en säkerhetsevaluering av detta system där vi går igenom olika typer av attacker som system kan utsättas för. 2 SSL SSL, Secure Socket Layer, är ett protokoll som skapats för att möjligöra krypterat utbyte av information mellan två enheter. SSL uppfanns eftersom det saknades funktioner för säkert utbyte av information i nätverksmodellen. Protokollet arbetar mellan TCP-lagret och applikations-lagret i nätverksmodellen men det är valfritt för processer om de vill använda den extra säkerheten. Här tillhandahåller protokollet funktioner för kryptering. SSL kan också användas för att autentisera parter med varandra, förutsatt att de har en gemensam betrodd tredje part. Dess placering i nätverksmodellen ovanför TCP-lagret innebär att protokollet inte behöver hantera garanterad leverans av data eftersom detta redan görs i TCP-lagret. SSL-lagret består av två lager, SSL Record Layer och SSL Handshake Layer. Record-lagret tar hand om fragmentering och kryptering av data från överliggande lager. Den kryptering som används bestämms i Handshake-lagret. SSL används bland annat i HTTPS-protokollet som möjliggör säker kommunikation över World Wide Web samt i SMTP som används för e- post. 2.1 Anslutningsprocessen Klienten börjar med att skicka ett Client Hello-meddelande till servern för att starta handskakningen. Meddelandet innehåller först ett 28 byte stort pseudoslumptal som används senare för att beräkna Master Secret: Meddelandet innehåller även vilka olika kryptering och kompression som klienten har implementerat. Servern svarar med sitt eget Server Hello-meddelande som även det innehåller ett 28 byte stort pseudoslumptal. Servern skickar även med vilken krypterings- och kompressions-algoritm som ska användas. Servern kan även skicka sitt certifikat samt begära certifikat från klienten. En annan valfri del i meddelandet är Server Key Exchange som användes i vissa implementationer. Slutligen avslutas meddelandet med Serer Hello Done. Klienten svarar sedan med ett meddelande som innehåller Client Key Exchange, Change Cipher Spec och Finished. Meddelandet kan även innehålla information om certifikat och servern har krävt det. Innehållet i Client Key Exchange beror på vilken sorts krypteringsalgoritm som ska användas. Change Cipher Spec låter servern veta att följande meddelanden kommer krypteras enligt den algoritm som tidigare valts. Meddelandet avslutas med Finished. Servern svarar ett eget Change Cipher Spec och avslutar med Finished. Handskakningen är sedan avklarad och säker kommunikation kan nu ske. 1

4 2.2 Säkerhet SSL skapades för att TCP saknade vissa säkerhetsfunktioner så som krypterad autentisering, integritet- och konfidentialitetsskydd. Genom att kryptera överföringen av information ger SSL ett skydd mot avlyssning av förbindelsen. SSL skyddar mot Replay-attacker tack vare dess användning av pseudoslumptal vid handskakningen. Eftersom Finish-meddelandet innehåller ett hash-värde av den tidigare handskakningen autentiserar både servern och klienten sig för att undvika Man-in-the-middle-attacker. Genom att kräva att starka krypteringsalgoritmer måste vara implementerade för att kunna använda SSL skyddar man sig mot att klienten försöker använda äldre och möjligtvis knäckta krypteringsalgoritmer. 3 Certifikat Digitala certifikat är elektroniska dokument som används för att bekräfta en användares identitet på internet. I ett certifikat binds en pubilk nyckel ihop med en användares uppgifter som till exempel namn och adress. 3.1 CA - Certifikatauktoritet Digitala certifikat skapas av en certifikatauktoritet (CA). Denna CA måste sedan vara betrodd av båda parter i till exempel en banktransaktion mellan bank och användare. Varje CA sparar information så som den publika nyckeln och personuppgifter för att dessa sedan skall kunna användas i transaktioner. Alla parter som har cerifikat utgivna av samma CA litar på varandra. De största utgivarna av digitala certifikat är VeriSign Inc och GoDaddy. De har 47.5% respektive 23.4% av marknaden. Dagens webbläsare har integrerat ett antal betrodda CA som alltid går att lita på. Om en webbsida skulle använda ett certifikat som inte är signerat av någon av webbläsarens betrodda CA får användaren direkt en varning om att denne besöker en sida vars identitet inte kan verifieras. VeriSign har introducerat fem olika klasser av certifikat. Klass 1. för privatpersoner. Menat att från början användas för e-post. Klass 2. för organisationer som vill styrka sin identitet. Klass 3. för servrar och mjukvarusignering där självständig verifiering och kontroll av identitet behövs. Klass 4. för transaktioner mellan företag online. Klass 5. för privat organisationer eller statlig säkerhet. Figur 1 är en skärmdump från Nordeas webbsida. Det gröna fältet som visas innan webbadressen visar att hemsidan använder ett certifikat som är utgivet av ett CA som är betrott av webbläsaren. Om man klickar på det gröna fältet kommer det upp mer information om certifikatet vilket också syns på bilden. Informationensfönstret innehåller bland annat vad för typ av kryptering som används, mer detaljerad information om vem certifikatet är utgivet till och vilken klass certifikatet tillhör. 2

5 Figur 1: Skärmdump från Nordea. 3.2 Autentisering Autentisering kan ske på följande sätt då en användare ansluter till en webbplats som påstår sig ha ett utfärdat certifikat. Webbläsaren börjar med att ta emot den publika nycklen som webplatsen i fråga tillhandahåller. Webbläsaren skickar då en förfrågan till certifikatauktoriteten om denna nyckeln verkligen tillhör denna webbplats. Dock skulle en förfalskad webbplats också kunnat använda den riktiga nyckeln då denna är publik. Däremot vet inte den förfalskade sidan den privata nycklen som krävs för att dekryptera informationen som skickas. 4 Beskrivning av Outstandning Journal Delivery System (OJDS) OJDS är ett journalsystem som är implementerat i java och består av två program, en klient och en server. Fokus av systemet är att bevara konfidentialiteten av journalerna. Skriv- och läsrättigheter av journalerna måste därför kontrolleras för att ingen obehörig ska få access till dem. Autentisering sker med hjälp av certifikat som är signerade av en certifikatauktoritet som både klienten och servern litar på. Då en användare måste ha användare måste ha tillgång till en keystore och nycklen till denna keystore sker en tvåfaktorsautentisering. Anslutningen mellan klienten och servern sker med hjälp av SSL-protokollet vilket krypterar informationen som skickar mellan dem för att säkerställa att ingen obehörig tar del av journalerna. SSL används även för att autentisera parterna för varandra. För att få en enkel översikt över vilka förändringar som skett i systemet sparas alla förändringar samt åtkomstförsök i en logfil. 3

6 5 Säkerhetsanalys av OJDS Vi analyserar här journalsystemet OJDS som vi har implementerat. Vi listar upp olika typer av attacker och förklarar hur dem går till när ett system blir utsatt för dem. Om systemet kan försvara sig mot den specifika attacken förklarar vi hur och om systemet inte har något skydd mot just den attacken så ger vi förslag på hur det hade kunnat gå att förhindra det intrånget. Genom hela analysen är det hackern Mallory som utför alla attacker. 5.1 Spoofing attack En spoofing attack innebär att en intet ont anande användare luras till att använda en falsk klient som ser ut precis som den riktiga. Denna klient kan därmed spara ner till exempel användarnamn och matchande lösenord som användaren skriver in. I vårt system finns inget direkt skydd mot denna typ av attacker. Om nu en användare skulle utsättas för en falsk klient skulle detta program kunna kopiera den keystore och lösenord som användes. Denna information skulle sedan kunna vidarebefordras till den som utför attacken. Ett sätt att försvara sig mot detta är att göra användarna medvetna om att det finns risk för spoofing attacker annars är det vädlgit svårt att försvara sig mot. Andra metoder för att skydda sig mot denna typ av attack är att visa antalet misslyckade inloggningar, ha en trusted path som används i Windows XP(crtl + alt + del) eller ha någon form av ömsesidig autentisering. 5.2 Avlyssningsattack Under en avlyssningsattack befinners sig den som attackerar mellan klienten och servern och avlyssnar trafiken som skickas mellan dem. Om meddelandena inte är krypterade kan Mallory läsa allting i klartext vilket inte är acceptabelt om informationen är hemlig. Detta kan lösas genom att kryptera informationen så att Mallory inte lika lätt kan se vad som skickas mellan dem. Detta skyddar dock inte mot trafikanalys då Mallory istället avläser när meddelanden skickas och hur stora de är för att försöka avläsa någon hemlig information. I vårt system skyddas användarna från denna typen av attack genom att kryptera information som skickas mellan servern och klienten med hjälp av SSLprotokollet. Även fast Mallory lyssnar på handskakningen så kommer det inte hjälpa eftersom både klienten och servern krypterar med sina privata nycklar som vi antar att Mallory inte har tillgång till. 5.3 Man-in-the-middle attack Denna typ av attack som även kallas bucket-brigade attack är en form av avlyssningsattack. Den fungerar som så att en hacker till exempel kommer in mellan två kommunicerande parter. Hackern kan därifrån kontrollera och manipulera all information som skickas mellan parterna utan att dem har någon som helst aning om detta. Ett exempel på hur detta kan gå till är att vi har två parter som vill kommunicera, Alice och Bob också har vi en hacker, Mallory. Till att börja med frågar Alice om Bobs publika nyckel. Om Mallory snappar upp denna nyckeln så kan 4

7 en man-in-the-middle attack inledas. Mallory skickar ett falskt meddelande till Alice med sin publika nyckel som Alice då tror kommer från Bob. Alice använder nu Mallorys nyckel för att kryptera ett meddelande som hon sedan skickar till Bob. Återigen fångar Mallory detta meddelande och kan dekryptera det och läsa, skriva om eller vad hon nu vill göra med det och sedan vidarebefordra till Bob osv. Nedan följer en enkel bild på hur detta kan se ut. Figur 2: Illustration av man-in-the-middle attack. I handshake-fasen i vårt system väljs vilken typ av kryptering som används. Detta är helt beroende på vad det finns för tillgängliga krypteringsmöjligtheter på den dator vilken klientprogrammet körs på. Vi antar att servern alltid ska ha tillgång till krypteringsalgoritmer som fungerar mot avlyssningsattacker. Dock är det inte helt säkert att klienten har det men på skoldatorerna väljs alltid Diffie-Hellman som standard i handshake-fasen. Det kan därför vara viktigt att upplysa eventuella användare om att de behöver se till så att klienterna har tillgång till bra krypertingsmöjligheter för att försvara sig mot avlyssningsattacker. 5.4 Förfalskade certifikat Certifikatförfalskning innebär att hackare knäcker ett giltigt certifikats privata nycklar och på så sätt kan skapa sig ett eget CA. Detta CA kan sedan användas för att utfärda certifikat till vem som helst utan någon som helst säkerhetskontroll. CA skapade med MD5 och SHA-1 kryptering var standard fram till 2008 då en grupp säkerhetsforskare lyckades knäcka detta med hjälp av ett antal Playstation 3. Efter detta slutade flera av de stora certifikats distributörerna bland andra Verisign att utfärda certifikat skapade med MD5. Redan utgivna certifikat återkallades dock inte vilket har resulterat i till exempel Nordea från exemplet tidigare i texten fortfarande använder denna knäckta algoritm. Vårt system använder MD5 och SHA-1 vilket innebär att det teoretiskt sett kan utsättas för certifikatsförfalskning för att få tillgång till hemlig information. Det saknas i dagsläget bra alternativ för att skydda sig mot denna typ av attack. Dock har nyligen SHA-2 börjat användas inom USA:s statliga myndigheter. Det pågår även en tävling för nästa generations SHA kryptering som är inne i slutfasen. Vinnaren ska presenteras någon gång under

8 5.5 Denial of Service-attack En DoS-attack är då Mallory utnyttjar svagheter i servern eller försöker överbelasta den för att förhindra legitima användare från att få åtkomst till servern. En DoS-attack attack som utnyttjar svagheter i servern försöker få programmet att krascha genom att till exempel skicka oväntade meddelanden som servern inte kan hantera. Överbelastning sker ofta genom en så kallad DDoS-attack där stora nätverk av datorer försöker ansluta till servern. Figur 3: Illustration av en DDoS-attack. Vårt system är extremt sårbart mot denna typen av attacker. Servernprogrammet krascha väldigt lätt om rätt kommandon inte anges eller om det blir något fel i autentiseringen. Servern klarar heller inte av att hantera filer som inte följer den mall vi skapat vilekt betyder att även en legitim användare skulle kunna råka krascha servern. Servern klarar av att hantera flera anslutningar åt gången men det finns inget direkt skydd mot medvetna belastningsattacker. Svagheterna i servern hade gått att åtgärda om mer tid hade lagts till impementationen men eftersom det inte var huvudprioriteten med projektet anser vi att det räcker att vi är medvetna om det. 5.6 Utomjordingar strålar upp servern till deras rymdskepp Om utomjordingar kommer och strålar upp servern så har vi ingen kryptering på databasen som skulle kunna stoppa dem från att läsa journalerna. Detta anser vi vara en väldigt orealistisk händelse så vi har valt att inte implementera något skydd för detta. Foliehattar på servern är ett sätt att skydda sig mot detta om vi hade lagt mer tid på implementeringen, det är trots allt svårt att göra foliehattar. 6

9 5.7 Replay-attack Vid en Replay-attack skickas ett gammalt meddelande som Mallory har fångat upp för att försöka avläsa någon information i svaret och på så vis hitta någon väg att få åtkomst till servern. Detta skulle kunna användas för att få OJDSservern att skicka ut journaler en gång till om Mallory har fångat in ett getkommando. OJDS skyddar sig mot Replay-attacker genom att använda olika nycklar vid varje anslutning, dessa skickas under handskakningen i SSL-protokollet och skapas med hjälp av slumptal vilket gör att de inte är förutsägbara. 5.8 Den mänskliga faktorn En viss utbildning hade krävts för att användarna ska kunna använda OJDS utan att krascha servern. En speciell mall på journalen måste användas för att servern ska godta den och spara ner den, i annat fall finns det en risk att servern kraschar. Det finns inga begränsningar på skrivrättigheterna på journaler, så alla som har skrivrättigheter har möjlighet att ändra all information och även ta bort innehållet i en journal. Vi har gjort så för att vi litar på att doktorer och sjukskötare som blivit autentiserade inte skulle göra så. I en vidare implementering hade man kunnat göra skrivrättigheterna mer avancerade så att det fanns begränsningar på vad användarna hade fått ändra i journalerna. Om en användare råkar ta bort sin keystore eller glömmer bort sitt lösenord finns det inget lätt sätt för en administratör att återställa det. Användaren måste då få en ny keystore med ett nytt certifikat signerat av certifikatsauktoriteten. Eftersom en användare måste ha sin keystore på datorn den loggar in ifrån måste användaren ta med sig sin keystore på till exempel ett USB-minne. Om användaren sedan glömmer ta bort sin keystore på en dator eller tappar bort sitt USB-minne kan obehöriga råka få tillgång den och behöver då endast lista ut lösenordet. Om en doktor skapar en ny journal men sedan glömmer bort namnet på filen som skapades kommer man inte kunna hitta den igen utan att en administartör söker igenom servern. I vidare implementering skulle en mer avancerad databas med funktioner för att lista filer implementerats. 6 Sammanfattning Sammanfattningsvis kan vi säga att vårt system inte är en programmerares (som inriktat sig på datasäkerhet) dröm direkt. Där finns flera brister i implementeringen och det kan finnas sätt att göra intrågn i systemet genom till exempel Spoofing-attacker. Tack vare att SSL-protokollet används finns ett ganska bra skydd mot Avlyssningsattacker och Man-in-the-middle-attacker då protokollet sätter upp en krypterad anslutning på ett säkert sätt. Användningen av ceritifikat gör det svårare för Man-in-the-middle-attacker att lyckas. En annan attack som SSL ger ett skydd mot är Replay-attacker. Implementationen har inget direkt skydd mot falska ceritifikat utan förlitar sig på att certifikatauktoritetens privata nyckel inte går att knäcka. 7

10 OJDS-systemet har väldigt dålig säkerhet mot DoS-attacker då det räcker med ett felaktigt kommando för att krascha servern. Systemet har heller inget skydd mot överbelastningsattacker men det anser vi bör hanteras av operativsystemet på servern. En stor risk med vårt system är den mänskliga faktorn då felaktiga kommandon och borttappade keystores kan få allvarliga konsekvenser. En vidare implementation av systemet skulle kunna lösa flera av dessa risker. Slutligen kan vi säga att Outstandning Journal Delivery System ger ganska bra skydd för konfidentialitet men systemet har väldigt bristfällig tillförlitlighet då det befinner sig i ett tidigt alfastadie. 8