1. No category

Attacker och
skyddsmöjligheter
Situationen i dagens
internetdominerade datormiljö
Grundfrågor att ställa sig idag
• Vad vinner vi på att ansluta en tänkt ny
tjänst till nätet, eller behålla en tjänst där?
• Hur ändrar detta skaderisker för tjänst
jämfört med att inte ha den via internet?
• Hur ser balansen mellan vinst och risk ut för
helt nya tjänster? För våra existerande
tjänster?
Exempel idag
• Basstationer i mobilnät underhålls via nätet, inte
via människor som låser upp larmad, fysisk dörr
till basstationens dator. Hur vet vi nu att ingen
obehörig installerar avlyssningsprogram, kopplar
bort nätkryptering o s v via kända nätattacker?
• Värme i sommarstugor styrs via enkel PINskyddad SMS-tjänst. Hur vet vi nu att ingen gissar
PIN och på pin kiv sätter värmen under
fryspunkten?
Då vi identifierat (nya) risker
• Exakt hur kan våra identifierade möjliga
skador via nätuppkopplingen uppkomma?
• Finns kända skydd mot just dessa hot?
• Är skydden tillräckligt effektiva?
• Stör skydden effektiviteten för den tjänst vi
vill tillhandahålla? I så fall, till vilken grad?
Problem, som fått stor uppmärksamhet
i olika sorters media
•
•
•
•
•
•
•
•
•
Allmänna direkta ”inbrottsförsök” från nätet
E-postburna virus/maskar/trojaner
Spam
Phishing
Skimming
”Identity theft”
Bot-nets och Denial of Service
Massavlyssning
Diverse tricks med webbsidor, adresser och länkar
Problem specifika för vissa
organisationer och personer
• Åsiktsmotiverad DoS
• Åsiktsmotiverade sabotage av hemsidor
• Anställdas överutnyttjande av rättigheter, ”insiderproblemet”
• Politiskt motiverad övervakning
Ovanliga problem (tror vi)
• Nätavlyssning (som får effekter för den
avlyssnade)
• Medvetet förfalskade signaturer eller certifikat
• Industrispionage från konkurrent via dator
• Medvetet sabotage från konkurrenter
Men motexempel från närtid…
• Stuxnet: Riktat sabotage
• NSA och FRA: Total avlyssning, inklusive med
aktiv hjälp av tjänsters tillhandahållare
Motiv bakom attacker
• Visa sig duktig, ”skrytfaktorn”
• Direkt ekonomisk vinning
• Komma åt åsiktsmotståndare och dem
man ser som angripare eller kriminella,
inklusive politiska motiv
• Gynna egna staten/företaget
• Nyfikenhet
Medias standardråd
• Ha brandvägg och virusfilter, och uppdatera
dem.
• Var misstänksam mot bilagor o s v.
• Ladda inte ner saker från skumma sajter.
• Besök bara välkända, pålitliga sajter.
• Ha automatuppdateringar påslaget.
• Välj bra lösenord
Fungerar råden? Räcker de?
• Uppdaterad brandvägg och virusfilter är självklart. Men de
tar inte helt nya hot och hjälper inte mot säkerhetsluckor
• Bilagor är nödvändiga för de flesta. Manipulerade sådana
kan ha transporterats via betrodd kontakt.
• Vilka sajter är skumma? Inga nya kontakter???
• Automatuppdatering stjäl ofta resurser just då datorägaren
själv behöver dem, vilket gör att många slår av
uppdateringarna. Datorn är alltid sårbar då den slås på,
eller då uppdateringen inte skickats ut av leverantören än.
• Lösenordteknikens svaghet har vi presenterat tidigare
Hur långt räcker det vi hittills
gått igenom i kursen?
• Vi har lärt oss principer för användarautentisering,
hur de bör implementeras och deras svagheter
• Vi har snuddat vid vissa problem med
nyckelhantering och certifikat
• Vi har nämnt grundproblem med virusskydd och
andra filter och med IDS
• Så vad mer behöver kommenteras?
• Låt oss först titta på listorna över välkända hot
Kommunicerar jag med någon pålitlig?
• Webb-läsaren kan varna för rapporterade
skumma adresser, men det är lätt att flytta
skumt innehåll till ny adress
• Certifikat ska säkerställa att jag i alla fall
nått avsedd adress, ”skum” eller inte, men
fungerar det alltid?
Problem med certifikat
• Om Eve fått certifikat i Bobs namn blir Alice lurad. Eve
dekrypterar allt avsett endast för Bob, och kan skicka data
som Alice tror kommer från Bob. Falskt Microsoftcertifikat har varit i omlopp…
• Äldre certifikat använde den numera knäckta SHA-1 för
signaturen, vilket möjliggör skapande av falskt certifikat
• Det är så vanligt att ärliga sajters certifikat har gått ut, så
användaren struntar ofta i varningar om ogiltiga certifikat
• Certifikat bygger på att klienten kan kontrollera
certifikatets äkthet med en nyckel för signerande CA, men
hur får man en pålitlig CA-nyckel?
CA och certifikatsäkerhet
• Om SSL/TLS får ett certifikat, kontrolleras att certifikatet
gäller för anropad adressat och är signerat av godkänd CA.
• SSL/TLS innehåller vid leverans vissa generella CAnycklar för verifiering av certifikat
• Grundcertifikat signerade med någon av dessa nycklar ger
möjligheter att kontrollera certifikat från utgivare på nästa
nivå o s v i CA-träd
• Om Bobs certifikat inte är utfärdat av CA i ett träd som
Alice känner till, måste Alice själv hämta rätt
verifieringsnyckel på ett säkert sätt för att våga lita på att
hon kommunicerar med just Bob
14
Skydd mot virus/maskar/trojaner
• Ständigt uppdaterad särskild skyddsprogramvara
• Begränsa skademöjligheter om du drabbas:
– Snäva behörigheter, särskilt för känsliga operationer,
logga inte in som administratör i onödan
– Minimering av automat-tjänster för e-post m m
– Sandlådor i webbläsare
• Ha back-up på ej ändringsbart medium, alltså inte
i moln, där attackkoden kan ändra, och inte på fast
monterat medium lokalt
Spam
• Spam är bara delvis ett säkerhetsproblem
– Spam kan begränsa tillgänglighet genom överbelastning
– Spam kan begränsa tillgänglighet genom att användaren
slänger verklig post som förväxlats med spam
• Åtgärder är adressfiltrering (black-list, white-list,
grey-list) och innehållsfiltrering. Samt regler
utöver black-list, som möjliggör blockering av
uppenbara spam-källor.
• Sortering av misstänkt spam till särskild mapp
Phishing
(lura användaren att sända t ex lösenord till fel adressat)
• Phishing bygger på att attackeraren kan sända det
kontrollanten förväntar sig vid ID-autentisering.
• Motmedel måste bli att attackeraren inte vet vad
mottagaren förväntar sig
– ”Challenge - response” med kryptografisk styrka
• Eller övergång till metod där attackeraren inte kan ta emot
och därefter kopiera giltig signal
– Förbindelse som är tidsberoende krypterad med godkänd
mottagares nyckel
– Autentisering av ”kontrollanten” innan sändning
– Man-in-the-middle hindras inte av inledande autentisering!!! Enda
skyddet där är innehållskryptering med ägarkontrollerad nyckel.
Skimming
(normalt = falsk avläsning av autentiseringskort)
• Falska kortläsare kommer alltid att kunna tillverkas
• RFID är bara mer lättlästa ”kort”!!! Deklarerat maximalt
”läsavstånd” gäller korrekthet för godkänd utrustnings
funktion, inte att avläsning är omöjlig på längre avstånd
oberoende av utrustning
• Försvar är aktiva kort, som verkligen använder stark
challenge-response. Kortets hemliga innehåll är ej
åtkomligt för läsare.
• (Fysiskt svårförfalskade kort är en annan möjlighet, som
prövats historiskt)
”Identity theft”
• Amerikanskt uttryck för att man gör saker i annans namn (och lyckas
med det). Allt vanligare som ”identitetsstöld” även i Sverige.
• Grundproblem: Ingen (egentlig) autentisering av identitet krävs.
Lösenord krävs som mest, ibland bara kontonummer eller annan mer
åtkomlig information som ”verifiering” av användarens ID.
• Åtgärdsförslag innebär ofta endast att minska , inte utesluta,
spridningen av data, som många måste känna till. Alltså ingen vettig
grundåtgärd, då ändå många känner till det som påstås ”bevisa” ID.
• Enda möjliga åtgärder: Applikationen/servern ska betrakta identiteten
som preliminär och utan juridisk bindning tills verklig autentisering
genomförts, aldrig godkänna det som flera känner till som bevis för
ID, aldrig lagra och sända lösenord i klartext. Vid extra känsliga
operationer ska starkare autentisering krävas. Användare ska se till att
ha starka lösenord, som är olika för olika tillämpningar.
Användarmisstag
(t ex att sända hemligt innehåll till fel mottagare)
• Begränsa alltid behörighet till ”need to
know”/”need to handle”
• Logga vad som händer, följ upp orsaker och
förbättra systemet där misstag kan göras mindre
sannolika
• Automatkryptera allt på bärbara media
• Åtgärda bristande användarvänlighet
• Utbilda personalen (får aldrig ersätta något av
ovanstående!!!)
Botnets och Denial of Service
• Två sidor: Att inte bli del av botnet och att hantera
attack från botnet
• Uppdatering av säkerhetshål är kritiskt för att inte
bli del av botnet
• Resurser och uppsättning av protokoll anpassade
för att klara mer än normal belastning behövs
• Beredskap för reducerad service (t ex förenklade
och/eller färre tillgängliga webbsidor) under attack
• Bra ISP, som kan hjälpa till
”Insiders”
• Återigen inga onödigt vida behörigheter
• Loggning
• Spårning, inklusive individuell och säker
användarautentisering
• Utbildning (fungerar både klargörande och
avskräckande, om den utförs rätt)
Nätavlyssning
• Bra kryptering är mycket lätt att åstadkomma idag. Enda
ursäkten för att inte kryptera inom en organisation är att
man verkligen inte ser något hot, även om data når andra
än adressaten.
• För allmän surfning blir problemet att tjänster ofta inte
stöder bra kryptering, trots att sammanställning av
kommunikation kan vara känslig även för ”oskyldiga”
data. Och tjänsten kan samarbeta med avlyssnaren.
• Högre säkerhet kräver mer komplex nyckelhantering än
grundversioner
Industrispionage via dator
• Händer det??? Tja det finns kända fall, men oftare
handlar det om att nästla sig in i företaget, utnyttja
”social engineering” o dyl.
• Det är idiotiskt att inte inse möjligheten och
bevaka säkerhetshål, ha restriktiv inre brandvägg i
DMZ-konfiguration och ha snäva behörigheter
internt
Medvetet, riktat sabotage
• Idag mest känt som DoS, ändring av dåligt
skyddade webb-sidor och framkallande av
tillfällig systemkrasch
• Idag använt politiskt (Estland, Georgien, Taiwan
kontra Kina o s v) och ”militant”, som mot vissa
industrier och näringar
• Fysiskt sabotage rekommenderades av 70-talets
terrorister
• Det verkliga hotet vore smygändringar...
Hemsidessabotage
• Ändring ska kräva hög behörighet (med bra
autentisering för innehavaren)
• Säkerhetshål ska automatbevakas
• Rätt version ska finnas lätt tillgänglig för
återladdning, men oåtkomlig från webbservern för ändring
Och så alla webb-tricks!
• Nedgradering av skyddsnivån i protokollet
vid handskakning
• Attack-URL som liknar måltavlans
• DNS-spoofing – att dirigera om anrop till
attackerarens sidor via DNS-avkodning
• Dold vidaredirigering i länkar
• Dolda knappar till länkar/åtgärder
• Och att smyga in exekverbar kod
Vad är exekverbar kod och vad är
”bara” data?
Kod via hål i ”extrafunktioner”
• Läsare (browsers) och verktyg för e-post har ofta många
och diversifierade funktioner utöver grundfunktionen att
förmedla innehåll
• Typiska extrafunktioner är att följa länkar i dokument och
webb-sidor, att öppna bilagor, editering och annat
• Man kan inte presentera en bilagas typ m m utan att öppna
åtminstone headern, och säkerhetshål där har gett
möjlighet att få kod exekverad
• Det är dålig säkerhetsarkitektur att göra alltför mycket
automatiskt, utan att fråga användaren
• Onödiga tjänster ska slås av
Klassisk introduktion av kod:
Buffer overflow/overrun
• Internlagring i datorer blandar direkta
maskininstruktioner, avkodbara instruktioner,
pekare till programkod och rena data allt efter
tillgängligt minnesutrymme
• Om användaren (=attackeraren) lyckas skicka in
datasträngar, som är längre än reserverat utrymme
för indata, kan datasträngens innehåll överlappa
utrymme där processorn hämtar instruktioner eller
pekare på instruktioner
Mobil kod
• Mobil kod är ett samlingsnamn för all möjlig sorts
programkod som är öppet till för att tas emot och
automatiskt exekveras över nätet
• Hit hör hemsides-applets, makron till ordbehandling och
mycket annat
• För webbläsare använder man i regel ”sandlåda”, d v s
behörighetsbegränsning kopplad till varifrån koden kom,
till exempel får koden bara läsa lagrade data som skapats
av kod-avsändaren (gäller även cookies)
• Signerad mobil kod har garanterad avsändare, men ingen
som helst garanti för vad den gör med sin behörighet
Scripts
• ”Scripts” är egentligen bara benämning på en
samlad serie instruktioner.
• Scripts kan vara program på en server, där de utför
uppgifter nödvändiga för att fylla webb-sidor med
rätt uppgifter utifrån klientens anropsdata
• Det kan också vara motsvarande funktioner, som
körs i anroparens dator
• Det kan vara en serie instruktioner från anropare
Att få ”elaka” scripts exekverade
• Cross site scripting, XSS, innebär att angriparen smyger in
eget script i svar från ”pålitlig” webb-sajt, t ex genom
säkerhetsluckor, genom att delar av svaret hämtas från
opålitlig sajt utan att anroparen ser det o s v
• Exempel:
– Man kan lyckas ändra vidarelänk i den efterfrågade sidan eller
ändra hämtningsadress för delar av innehållet
– Man kan smyga in kod i det som borde vara text i fält som fylls i
av användarna (kommentarsfält o s v)
• Säkerhetshotet är framför allt att sådana insmugna script
körs med den ”pålitligas” behörighet
Cookies
• Cookies är korta teckensträngar, som en tjänst lägger i en
klients webb-läsare för att spara egen information från
samma session eller en tidigare
• Cookies är praktiska, eftersom tjänsten inte behöver spara
kundspecifik information med egna resurser, och kan se
information från tidigare sessioner med oidentifierad
användare med variabel IP-adress
• Cookies har standardformat, och kan därför avslöja mycket
om klientens webb-aktiviteter
• Cookies ska bara kunna läsas av den som skapat dem.
Har kursen nämnt allt relevant?
• Det dyker kontinuerligt upp nya tjänster och
kommunikationsstrukturer med nya svagheter, liksom att
nya svagheter hittas i det gamla
• Vi har inte alls berört grundläggande säkerhetskärnor i OS,
hårdvaruåtgärder o s v
• Vi behandlar ”dolda kanaler”, att lista ut datainnehåll på
annat sätt än att direkt läsa data, bara som ett enda exempel
i labben
• Kursboken (och OH till TSIT02) innehåller mycket mer!
• Utnyttja chansen att fråga på sista föreläsningen!