2D1395, Datasäkerhet Autentisering och Code-Based Access Control Datum: 2006-09-12 Skribent: Carl Lundin Föreläsare: Gunnar Kreitz Den här föreläsningen behandlade autentisering och Code-Based Access Control. Autentisering görs idag oftast med användarlösenord. Föreläsningen behandlade hur man distribuerar lösenord bra, hur man ska och inte ska välja lösenord samt format på lösenordsfilen. Alternativa autentiseringsmetoder togs också upp, t.ex: fingeravtryck. Exempel på hur svenska banker autentiserar sina kunder på internet presenterades. Som ett komplement till ID-Based Access Control, IBAC, som kursen behandlat hittills, kan man använda Code-Based Access Controll, CBAC. I CBAC ger man olika kod olika rättigheter. Java Sandboxing som är en implementation av CBAC togs upp, med bland annat en introduktion till hur man sätter Permissions. 1 Autentisering 1.1 Allmänt om autentisering Autentisering går ut på att verifiera en påstådd identitet. Det är inte detsamma som att identifiera någon. Autentisering görs oftast med hjälp av lösenord. Det finns dock flera problem med autentisering med hjälp av lösenord: 1. Det är svårt att distribuera lösenorden. Svårigheten kan lösas med: - Kryptografi. Ex: Systemadministratören krypterar lösenordet med användarens publika nyckel och skickar till användaren. - Känna igen användaren. Ex: Systemadministratören ringer användaren, han/hon känner igen användarens röst och ger användaren dennes lösenord. Men rösten kan förfalskas och telefonen avlyssnas. - Legitimering. Ex: Staten utfärdar ID-kort som kan verifiera att användaren är den han/hon utger sig för att vara. När användaren visar ID-kortet kan systemadministratören ge användaren lösenordet. - Alternativ kanal. Ex: När en användare av en internettjänst ber om ett användarkonto bör användarnamn och lösenord skickas i olika alternativa kanaler som med e-post eller sms. De alternativa kanalerna gör det svårare för en tänkbar avlyssnare att snappa upp användarnamn och lösenord. 2. Det är svårt att välja ett bra lösenord. Exempel: - Ett lösenord är dåligt om det går att gissa. Ex: användarnamn = lösenord, se Folkpartiskandalen i källor. 1
2 2D1395 Datasäkerhet HT 2006 - Ett förinställt (eng. default) lösenord är bekvämt, men dåligt ur säkerhetssynpunkt. Ex: Ofta är det möjligt att googla fram en routers förinställda lösenord. - Ett lösenord som består av ord är dåligt. Ex: På internet finns stora ordlistor med ord på flera språk och med vanliga personnamn. 3. Slumpmässiga lösenord är svåra att knäcka, men tyvärr också svåra att komma ihåg. Trick för att få fram ett bra slumpmässigt lösenord: - Tänk på en fras och välj första bokstaven i varje ord. - Lägg sedan in siffror och blanda versaler med gemener. Som systemadministratör vill man förhindra att elaka personer tar reda på användarnamn och deras lösenord. Hur gör man då det? - Man prövar att själv att cracka lösenordsfilen. Lyckas man få fram ett användarnamnlösenords par tvingar man användaren att byta till ett bättre lösenord. - Man kan generera slumpmässiga lösenord åt användarna. Används lösenorden ofta kommer förmodligen användarna att komma ihåg sina lösenord. Används lösenorden sällan finns det en stor risk att användarna t.ex. har Post-It lappar på skärmen/under tangetbordet med användarnamn och lösenord. - Man kan också tvinga användare att byta lösenord ofta. Det finns dock en risk för att folk går runt detta genom att t.ex. ta sina vanliga användarnamn och lägga till 1. Nästa gång ändras lösenordet till användarnamn2. - En annan bra sak är att be användarna att inte ge bort lösenord till främligar. Enligt en undersökning gjord i Storbritannien ger mer än 70% mer än gärna bort sitt användarlösenord för en bit chocklad (news.bbc.co.uk, -06). Man vill alltså skydda lösenordsfilen från att läsas. Även om någon elak person på något sätt lyckats få tag i filen, ska det vara svårt att använda sig av den. Önskad effekt kan fås med: - Enkelriktad funktion (t.ex. kryptografisk hashfunkion). Istället för att spara lösenordet i klartext i lösenordsfilen, sparar vi SHA1(lösenordet) i lösenordsfilen. Den här lösningen kan dock knäckas av elaka personer genom att de för varje ord i ordlistan prövar SHA1(ord) istället. Översättnigen till hashsummor görs innan attacken. Får man en match mellan två hashsummor har man funnit ett lösenord. - Saltning. För att kunna klara att elaka personer testar hashsummor kan man salta lösenorden med en slumpsträng. Exempel: Lösenordsfilen utan saltning: gkreitz, SHA1(lösenord) alba, SHA1(password) Lösenordsfilen med saltning: gkreitz, 34gff3d, SHA1(lösenord34gff3d) alba, ffg4dhn, SHA1(passwordffg4dhn) För att den elaka personen ska kunna hitta lösenord måste han/hon nu istället för att testa SHA1(ord), även testa SHA1(ord0001), SHA(ord0002) och så vidare. Saltning är enkelt, ökar säkerheten dramatiskt och används därför också i praktiken.
Autentisering och Code-Based Access Control 3 - N-faktor autentisering. Istället för att kräva en sak för att autentisera en användare kräver man med den här metoden flera (N st) autentiseringar. Man kan t.ex kräva någonting som användaren.... vet. Ex: Lösenord eller personligt identifikationsnummer, PIN... är. Autentisering genom test av användarens fysiska egenskaper kallas biometri. Exempel är fingeravtryck, iris-scan och röst-test. Det här sättet att autentisera sig ger dock upphov till problem. Till exempel kan det vara känsligt att lagra användares fingeravtryck i en databas. Det har även visat sig att testen är möjliga att förfalska, t.ex. gelatinfingrar med någon användares fingeravtryck... har. Ex: Dosa eller ID-kort... gör. Det här sättet att autentisera sig är ganska outforskat. Exempel är skrivrytm på tangentbord... bara kan göra från en speciell plats. Här autentiserar sig användaren genom att vara på en speciell plats, t.ex. vid en säkerhetskontroll eller en särskild terminal. Kontrollen skulle även kunna göras med GPS. 1.2 Exempel på svenska bankers autentiseringsmetoder Nordea: PIN + kort med engångskoder Nordea använder ett system som fungerar så att man med en engångskod samt PIN kan logga in. SEB: PIN + Dosa SEB använder en dosa som man får av banken. I inloggningsrutan från man 8 siffror som man matar in i dosan, den returnerar 6 siffror som tillsammans med personnummret gör att man kan logga in. Det här är en typisk Challenge/Response som är tidsbegränsad. Skandia: PIN + TLS-certifikat Skandia använder alltså TLS-certifikat. TLS är ett standardprotokoll för kryptering och autentisering över internet. Certifikatet är personligt och med PIN-koden kan man logga in. Man in the Middle-attacker mot bankerna Spoofing är när en elak person/program utger sig för att vara till exempel banken och försöker få användaren att logga in. Personen/programmet kommer då över användar-lösenords-paret och kan använda detta i sina attacker. Det är dåligt om bara ena parten autentierar sig. Challange/Response försvårar spoofing.
4 2D1395 Datasäkerhet HT 2006 Nordea-attack Figur 1: Figuren visar ett försök till spoofing vid Nordeas inloggning. I slutet av augusti 2006 gjorde någon elak person en så kallad phishing-attack mot Nordea. Phishing går ut på att lura folk att ge ifrån sig sitt användarnamn och lösenord; se källor för länk. SEB-attack Figur 2: Figuren visar hur en Man in the Middle-attack kan se ut mot SEB:s inloggning. Skandia-attack Det går inte att göra en Man in the Middle-attack mot Skandia, på grund av deras certifikat.
Autentisering och Code-Based Access Control 5 2 Code-Based Access Control 2.1 Allmänt om Code-Based Access Control Hittills har vi i kursen bara talat om ID-Based Access Control, IBAC, vilket kan fungera bra på ett universitetssystem där personen som gjort något elakt kan ställas till svars för vad denne gjort. Men tyvärr fungerar den här metoden inte alltid lika bra. Till exempel bryr vi oss inte om just vilken kinesisk cracker som programmerat spyware-programmet som är installerat på min dator, eftersom det blir svårt att få denne ställd till svars och dessutom har inte varje programmerare i världen ett specifikt programmerar-id. Istället för IBAC finns alltså Code-Based Access Control. Här får olika kod olika rättigheter. Men hur ger vi rättigheter till kod? Och hur identifierar vi koden varifrån kom den och har någon signerat den? Figur 3: Figuren visar hur en attack för att komma åt lösenordsfilen kan gå till. Den elaka personen skickar en begäran att få certifikatet för lösenordsfilen. Målet är att banken ska skicka hela lösenordsfilen i ett felmeddelande. Som tur är görs det inte här, det vore annars en stor säkerhetsrisk! Det är ett faktum att kod från olika ställen kan anropa varandra. För att skydda sig från att elak kod utnyttar snäll kod, tillåter man bara det som alla inblandade får göra. Den här kontrollen av inblandade kan implementeras på olika sätt: - Vid varje funktionsanrop, uppdatera rättigheter för koden. Den här lösningen ger dock dålig prestanda. - Gå igenom stacken när rättigheter krävs. Exempel på nästa sida:
6 2D1395 Datasäkerhet HT 2006 Figur 4: Figuren visar vad man brukar kalla en stackwalk, den fungerar alltså så att man kontrollerar funktioners rättigheter på stacken för att utröna om den anropande koden ska få uföra en begärd handling. Men klassen System i det här exemplet kan i vissa fall låta koden få rättigheter att göra något om System säger jag litar på den här koden, då avbryter vi stackkontrollen och låter koden köra. Vem ger då koden rättigheter? - Användaren. Kan blir problem eftersom användare har en tendens att godkänna allt för att få saker att funngera. Elak kod kan på detta sätt få för mycket rättigheter. - Systemadministratören. Administratören måste bland annat kunna sätta default rättigheter så att den vanliga användaren inte ska behöva bry sig om det. 2.2 Java Sandboxing Säkerhet är viktigt för java. Java applets används överallt på internet; där kör man kod som vem som helst kan ha skrivit (kanske en elak person?!) på sin egen dator. Hur säkerställer vi att koden som körs inte tar befälet över datorn och till exempel börjar skicka iväg data på hårddisken till en server i Litauen? Java använder sig av något som kallas sandboxing. Det fungerar så att man exekverar koden i en begränsad sandlåda. Den första kontrollen av appletkoden görs av Byte Code verifieraren. Verifieraren kontrollerar innan koden körs att: - class-filen är i rätt format - ingen operandstack får overflow - metoder blir anropade med argument med rätt typ och även returnerar rätt typ - ingen illegal datakonvertering mellan typer sker - alla referenser till andra klasser är korrekta - inga privata klassvariabler används utanför klassen
Autentisering och Code-Based Access Control 7 Den andra stationen för koden är Class Loadern. Dess uppdrag är att ladda in klasser som behövs för att köra koden. Den definierar också själva kodens klass och sätter rättigheter enligt policyfilen. Den sköter även namespace-problematiken. Den sista och viktigaste uppgiften har Security Managern. Det är den som är Code-Based Access Control:s Reference Monitor, det vill säga det är den som kontrollerar att en process som ber om en resurs har tillåtelse att göra det. För att göra den här kontrollen måste programmet anropa checkpermission-metoden i Security Managern med det begärda Permission:et. Den skickar då vidare förfrågan till Access Controllern som gör en stackwalk för att se om koden ska få tillåtelse. Security Managern är avslagen by default, men kan, om man vill testa klassen Klass, användas med kommandot java -Djava.security.manager Klass. Säkerhetspolicys mappar kod till permissions. Permissions representerar systemets resurser och tillåtna operationer på dem. Permissions ges till kod och de behövs för att få tillåtelse att använda system resurser. I Java kan man bara sätta positiva permissions. Exempel på permissions: Koden får läsa från /etc/passwd: java.io.filepermission "/etc/passwd", "read"; AllPermission är ett wildcard för att uttrycka att koden får göra allt: java.lang.allpermission; Man kan sätta permissions utifrån CodeSource, dvs. var koden kommer ifrån (URL), om den är signerad och vem eller vad det kommer ifrån (principal). Exempel: grant codebase "http://www.kth.se", signedby "gkreitz"{ permission java.io.filepermission "/tmp", "write"; } Här får kod från KTH-URL:en och som är signerad av gkreitz tillåtelse att skriva till /tmp-katalogen. Figur 5: Figuren visar hur ett anrop från kod får sina rättigheter kontrollerade. Om Security Manager är avslagen returnerar den alltid (svarar OK ), annars skickar den vidare förfrågan till Access Controllern. Access Controllern antingen returnerar tillbaka (svarar OK ) eller kastar ett Exception.
8 2D1395 Datasäkerhet HT 2006 Figur 6: Figuren visar hur en policy används vid javakod-raden import name.gkreitz.elak. Först invokerar Javas virtuella maskin loadclass-metoden för Class Loadern. Class Loadern laddar in koden name.gkreitz.elak. Class Loadern anropar sedan policyklassen med getpermission. Den i sin tur returnerar rättigheter till klassens Protection Domain. 3 Källor Folkpartiskandalen: http://www.aftonbladet.se/vss/val2006/story/0,2789,881558,00.html Nordea phishing/fraud: http://www.realtid.se/articlepages/200608/30/ 20060830173643_Realtid242/20060830173643_Realtid242.dbp.asp Folk ger lösenord mot chockladbit: http://news.bbc.co.uk/2/hi/technology/3639679.stm