Texter

14 april, 2019

Från Sälen med GDPR-information

”GDPR känns lite mossigt att prata om nu och väldigt uttjatat” sa Emma till mig en dag ”men kanske vore intressant om vi istället pratade om vad som hänt nu?”

Och så blev det. I veckans avsnitt tog vi tre en liten paus från Zetups konferensaktiviteter och tog ett snack om GDPR. 

Emma nämner även supergruppen ”29-gruppen” och här är en fin länk (42 sidor PDF) som är en slags sammanställning.

Vi pratar också Opt-in och Opt-out. Här kommer en liten förenkling:

Opt-in – att man aktivt måste kryssa i sitt godkännande, t.ex. på en website

Opt-out – att det redan är förkryssat (vilket då innebär att man t.ex. klickar vidare utan gör ett aktivt val).

Klassisk Opt-in – här måste besökaren kryssa i ”I accept the…” för att komma vidare
10 april, 2019

När säkerheten blir för svår

Numera är det ärligt talat rätt lätt att motivera säkerhet i princip alla lägen. Det är ingen som längre tycker det är för jobbigt att man måste logga in på alla ställen man går. Det är alltid bättre än att bli av med sina uppgifter eller att någon hackar ens konto.

Men det finns fortfarande en smärtgräns när säkerheten blir ett hinder i vägen för arbetet. En klassisk mekanism för att demonstrera säkerhet i ett projekt eller när man konstruerar något är ”USE”-modellen. Den går ut på att se tre faktorer : ”Användarvänlighet (Usability), Säkerhet (Security) och Kostnad (Economy)”.

Användarvänlighet är när en produkt är enkel och kan användas utan problem eller utan att kräva några förberedelser. Säkerhet är en process där produkten görs så säker som det går. Och kostnad är att produkten är så billig som möjlig. Det som är intressant är att man bara kan välja två av dessa faktorer. Den tredje får man offra. En produkt som är billig och
användarvänlig är inte säker. En produkt som är
användarvänlig och säker är inte billig och en produkt som är billig och säker är inte användarvänlig.

Ett klassiskt exempel på när säkerheten offras är när president Kennedy krävde att man skulle sätta en kod på varje kärnvapenbestyckad missil. Denna kod måste anges för att låsa upp missilen. Detta blev byggt, men man valde koden 00000000 (åtta nollor) som kod för alla missiler. Detta dokumenterades också i pappren. Så på pappret var det ett säkert skydd, medan det i verkligheten inte dög någonting till i det avseendet.

Enligt boken ”Jävla skitsystem” skriven av Jonas Söderström, lade IT-avdelningen in ett lösenordsskydd på en vårdcentrals terminaler. Detta stängde skärmen efter ett antal minuters inaktivitet. Terminalerna i receptionen måste ju vara igång, så personalen lade datormusen i en vagga som används för att kontinuerligt skaka om blodprovet så att de inte ska koagulera. Effekten blev att vaggan höll muspekaren igång så att skyddet aldrig startade.

Listan på hur folk går runt säkerhet kan göras hur lång som helst, men anledningen verkar alltid vara den samma: det är för jobbigt hantera saker som har hög säkerhet. Och det är också utmaningen för oss i branschen: att bygga säkerhet så att den säkra vägen också är den naturliga. Ett exempel: biometrisk inloggning är hyggligt säker och gör inte lösningen mycket krångligare än att bara använda namn och lösenord. Så visst finns det säkerhet som fungerar utan att vara iväg.

7 april, 2019

Hur förberedd är du?

I veckans avsnitt pratar vi med Anna-Maria Stawreberg eftersom hon skrivit boken Prepping.

Avsnittet är inspelat på Zetups kontor i Kista och jag tog emot henne på eftermiddagen och Erik hade riggat upp ett av konferensrummen med mikrofoner och ljudutrustning.

Anna-Maria är knivskarp. Det märker jag direkt när hon kliver in på vårt kontor och hur hon ser sig omkring, noterar våra bilder på väggarna och ställer frågor. Jag hinner knappt avsluta mitt svar förrän hon förstått vad jag menar.

Prepping dårå? Är det bara knäppgökar som har hela källaren full med konserver eller amerikanska redneck med hemmet fullt av vapen och konspirationsteorier?
Kanske. Några ja…. men tänk så här istället. Ifall mobilnätet går ner eller svenska elnätet hackas. Har ni några rutiner hemma? VAR ska ni ses? Vem ser till att hämta barn från skolan? Var och hur ska ni ta del av nyheter och information? Kan du till exempel telefonnummer till din familj utantill?


4 april, 2019

Säkerhetsäggen finns fortfarande

Det är riktigt gammalt nu och jag minns att det pratades om det redan när jag började min karriär inom säkerhetsområdet. Jag talar om de berömda ägget. Alltså den där säkerhetslösningen som fungerade som ett enda hårt skal. Tog man sig igenom det, kom man åt det goda innanför utan hinder. Istället förordade man löken. Denna fantastiska ätbara tingest som hade lager på lager som måste tas bort innan man kunde komma någon vart. Precis så skulle säkerheten vara. Lösning på lösning där varje lager skyddade det nästa. Halleluja! Jag var på en föreläsning där man släppte ett riktigt ägg på en utvikt sopsäck och sedan släppte man en lök på samma sätt. Inga poäng om du lyckas gissa vilket som gick sönder och vilket som höll! Pedagogiskt och något effektsökande. Men idag är det väl inte så längre?

Kanske inte. I alla fall inte huvudsakligen. Men ändå på något sätt ska jag säga. En kompis till mig ringde för några dagar sedan och var överlycklig över att han hackat en Chromecast. Denna tingest, menade han på, var lätt att ta kontroll över. Huvudsakligen för att de har tjänster som är öppna och bjuder på lite motstånd till den som vill ta över dem. Själv roade jag mig med att hacka mitt eget Netgear NAS en kväll jag hade tråkigt. Så dessa enheter finns ju alltid. Och vad skyddar sådana tingestar?. Dörren till huset. I övrigt kan man ta sin dator och koppla in den på nätet och prata direkt med dem. Många ägg finns bland skrivare, scanners och TV-apparater som man kopplat in bland kontor-PCs på arbetsplatser. Ingen löksäkerhet så långt ögat kan nå. Men webbapplikationerna har brandväggar, reverse proxys och nås enbart via ett VPN med multifaktorautentisering. En riktig lök!

Sen hur ser det ut inne i applikationerna? Bland många organisationer jag varit ute på ser man samma mönster: numera får man inte ut så mycket data ur en katalogtjänst som Active Directory utan att autentisera sig. Men om du autentiserar dig med ett helt vanliga användarkonto är det mesta tillgängligt. De flesta attributen är läsbara du kan tömma hela personalkatalogen med några enkla LDAP-frågor från en dator med Kali-Linux på. Den webb-baserade personalkatalogen är skyddad av Kerberos och släpper bara ut utvald information, så där har du katalogtjänstens ägg mot personalkatalogens lök. En låst ytterdörr och en öppen bakdörr som ger dig både äggvita och ägg-gula. Ok, jag ska sluta prata ägg nu. Påsken är i instundande, så det kanske är rätt tid för det, men jag tror att jag lyckats få fram min poäng med denna diskussion.

28 mars, 2019

Misstag med sessionshanteringen i webbapplikationer

Låt oss vara lite tekniska för en stund. Autentisering, auktorisering och sessionshantering är en svår konst. Man vill att användaren ska loggas in på ett säkert sätt och att man inte ska kunna ta sig in i sessionen. Här är några vanliga misstag som görs av programmerare.

Session fixation

När man bygger en webbapplikation är det ganska vanligt att man använder sessions-id. Dessa är till för att man ska kunna hålla en användare inloggad. Det är en mycket känslig del av det hela rent säkerhetsmässigt. Den korrekta metoden är att logga in en användare och sedan sätta ett sessions-id därefter. Detta ska leva tills användaren loggar ur eller tills en viss tid uppnåtts. När jag utför pentester, stöter jag ofta på webbapplikationer som sätter sessions-id INNAN användaren loggar in och sedan använder samma sessions-id EFTER att du loggat in. I ett sådant scenario går det ofta att ta över användarens hela session med ett mail och lite social engineering.


Man skriver ett mail med en länk till applikationen som man ska hacka. Detta mail anger ett sessions-id som man själv hittat på. Användaren klickar på länken och loggar in som vanligt. Nu vet du denna användares sessions-id efter du själv bestämt det. Då kan du på din egen webbläsare ange samma sessions-id och gå in som användaren utan att behöva logga in.

cookies utan secure-flaggan

Ofta realiseras sessions-ids med cookies. Om man inte sätter flaggan ”secure” på dessa, kan man övertala applikationen att skicka dem över en klartextförbindelse. Genom att använda ett verktyg som sslstrip, kan en attackerare på det lokala nätverket få tag i giltiga sessionscookies.

sessions-id i get-metoden

Om man tillåter sessions-ids i address, som tillexempel www.sårbarsite.se/app?SESSION=235234532556768, kan en användare av misstag råka ge bort sin session via mail. Man bör också undvika att ta in variabeln via både get och post.

Sessionen tar aldrig slut

En session måste ha en klocka som räknar ner och avslutar sessionen när användaren varit inaktiv en viss tid. En del webbapplikationer byter även sessions-id när sessionen varit igång en viss tid. Men många webbapplikationer låter sessionerna lever i all evighet, eller har extrema värden som gör att en session kan vara inaktiv i veckor och fortfarande vara aktiv.
cookie utan httponly-flaggan

Mindre allvarligt, men ändå. En sessionscookie bör vara satt httponly, för att hindra att man på klientsidan kan manipulera den med javaskript-kod.

Ingen webcookie

En webcookie är ett värde som läggs till jämte session-id. Den måste finnas i anropen för att användaren ska kunna göra ändringar i webbapplikationen. En session är nämligen giltig i alla flikar i en webbläsare (Om man inte köra i inprivate mode). Detta gör att elak kod som körs i en annan flik kan göra ändringar i den webbapplikation du använder. Ofta saknas denna webbcookie, vilket gör webbapplikationen sårbar för en cross site request forgery-attack. Med en webcookie kan du bara göra ändringar i webbapplikation från den fliken du loggade in i webbapplikationen med. Detta kan skydda dig om du är inne och ändrar inställningarna i en routers webbinterface medan du surfar i en annan flik (Inte att rekommendera, dock!)

Ingen HSTS (HTTP Strict Transport Security)

HSTS är en HTTP Header som säger åt en webbläsare att ALLTID använda HTTPS mot en sida. Denna enkla mekanism gör verktyg som sslstrip verkningslösa. Tillsammans med secure-flaggan på sessionscookie, ökar de säkerheten enormt.
Ingen HTTPS

Detta borde inte vara ett problem idag, men det är det. Siter som hanterar inloggningar men inte har HTTPS finns fortfarande. Detta är ganska självklart ett problem. Men det finns fortfarande de som lever i det förgågna.
Så för att sammanfatta: det finns ett antal metoder man kan använda för att se till att användaren kan lita på att deras interaktioner mot din webbsida är säker. Använd dessa!

21 mars, 2019

Problemet med gamla prylar

Har du en router hemma som är 10 år gammal? Eller en trådlös accesspunkt från 2015 som du kör ditt nätverk genom? Detta kan visa sig vara ett problem. Första gången jag stötte på problemet var 2006 när jag läste om att en person hade klagat på en populär tillverkare av nätverksutrustning avsedd för hemmabruk. Han hade nämligen klagat på att han tidigare rapporterat ett allvarlig säkerhetshål i en av deras produkter och att de hade inte svarat eller gjort något åt detta problem trots att det gått flera månader sedan han hörde av sig. Detta verkar tyvärr vara ganska vanligt, men vad som är värre är när det överhuvudtaget inte kommer någon säkerhetsfix.

Din billiga hemrouter kan vara så gammal att tillverkaren helt enkelt inte skapar rättningar för den längre. De rekommenderar istället att man köper en ny modell och kör den istället. En del tillverkare av enheter man kopplar till nätet lägger in gamla versioner av Linux-kärnan som aldrig uppdaterats trots att det finns nya versioner.

Om man kollar efter uppdateringar eller nya versioner av firmware får man bara veta att ”du har den senaste versionen”, vilket gör det lätt att tro att allting är i sin ordning. Vi har diskuterat liknande problem med uppdateringar i tidigare inlägg på denna blogg. Men detta är ett separat problem och blir allt värre när mängden övergivna produkter blir kvar, uppkopplade på nätet.

Det finns idag ingen riktigt bra lösning på problemet, utom att möjligen välja produkter som har lite längre livslängd och byta ut dem när de inte längre underhålls. Detta kan innebära att du får köpa lite dyrare saker, men i längden blir både ditt hemmanätverk och Internet säkrare.

17 mars, 2019

Varför är lösenordet dött?

I veckans avsnitt pratar vi att NIST förkastat sina gamla rekommendationer med komplicerade lösenord som som regelbundet behöver bytas till någonting helt annat.
Det är längden på lösenordet som är avgörandet och inte hur många gånger man byter a mot @.

Lösenord i all ära men är det inte lite omodernt att logga in överallt för lösenord kommer ju alltid kunna hackas.

Vad ska man ha istället då?

Vidare tar vi upp ersättare såsom biologiska inloggningar och multifaktorautentisering.

13 mars, 2019

Varför sårbarhetsskanningar inte räcker

Jag har märkt en intressant sak: många företag och organisationer blandar ihop säkerhetsskanningar med pentest. Ett pentest är när man på ett kontrollerat sätt försöker bryta sig in i ett system, medan en sårbarhetsskanning bara försöker hitta möjliga sårbarheter. Detta är mycket märkligt, men jag har sett det många gånger. Felet verkar även finnas bland de som jobbar inom området. För ett antal månader sedan hjälpte jag till att intervjua en arbetssökande till en tjänst som pentestare. Han berättade att han sökte tjänsten eftersom han var intresserad av säkerhet. Jag frågade vad han hade gjort för typer av säkerhetarbeten. Han sa att han kört programmet Nessus ett par gånger och lämnat över resultaten till någon annan att tolka. Nessus är ett program som hittar vanliga miskonfigurationer och säkerhetshål i tjänster. Ganska uppenbart kanske, men han fick inte jobbet.

Jag läste på ett forum för pentestare där en del personer beklagade av säkerhetsföretag säljer sårbarhetsskanningar som pentester. De betalar ett företag för att skanna av deras tjänster och komma med en automatgenererad rapport över ”allvarliga säkerhetshål”. Detta är knappt ett halvt pentest om ens det.

Betänk att pentest är en förkortning av penetrationstest, vilket innebär som ovan skrivet är att en inhyrd konsult eller flera försöker ta sig in i systemet. Lyckas de, lämnar de över en rapport som förklarar hur de tog sig in. Om ett försök att faktiskt hacka systemet inte görs, är det inte ett pentest. När jag gör pentester brukar jag faktiskt lämna in även hittade sårbarheter och miskonfigurationer, för att jag hittade dem på vägen när jag analyserade systemet för sårbarheter. Det tycker jag ingår i ett bra test även om det inte är huvudsyftet med det.

Så varför är inte en sårbarhetsskanning tillräcklig? Jo, för att den inte hittar problem med systemlogiken. Den kan se att en programvara har sårbarheter som potentiellt skulle kunna användas för att ta sig in. Men den kan inte hitta felaktigheter i hur t.ex. en webbapplikation hanterar inloggningen, som möjliggör att man tar över sessionen.

Sen är sårbarhetsskanningar dåliga på att hitta alla fel. Jag gjorde en gång ett pentest mot en webbapp och min programvara, Burp suite hittade ingenting. När jag klistrade in lite javaskriptkod direkt i ett inmatningsfält, hittade jag en möjlighet att köra javaskriptkod hos andra användare och läcka ut information den vägen. På så sätt kunde jag få ut data från andra användares ärenden (det var ett ärendehanteringssystem). Ett automatiserat program hade aldrig kunnat förstå vidden av problemet.

En annan attack jag gjorde mot en kund var att ladda upp ett dokument som i själva verket var ett litet program. Men detta kunde jag på under fem minuter ta över servern som körde webbapplikationen och även hela nätverket. Alla dessa attacker är värda oändligt mycket mer än att bara lämna in en rapport där det står att HTTP-protokollet stöder version 3.0 av SSL vilket inte är bra.

Om du anlitar någon att göra ett pentest på din miljö, se då till att du verkligen får vad du betalar för. Som jag skrev förut finns det många som säljer dåliga tjänster därute.

10 mars, 2019

Mötet med Åsa

Jag var lite nervös inför veckans avsnitt eftersom vi valt att ta en ny infallsvinkel i avsnittet. Nämligen en mer personlig intervju. Tanken var att vi skulle få reda mer på personen bakom själva tekniken.

Vi har ju bjudit in många till våra avsnitt tidigare men då har vi pratat om tekniken. Nu ville jag att vi skulle prata mer om personen. Bakgrunden, kopplingen till säkerhetsbranschen och eftersom det var Åsa Schwarz vi pratade med, hennes författarskap.

I mina anteckningar, ja manus om du vill, inför intervjun skrev jag ”Det verkar som att samtidigt som du grundar bolag blir du också författare. Vad var det som fick kreativiteten att flöda? (här vägrar jag fråga ”hur har du tid som mamma till två barn, författare och säkerhetsspecialist) ”

Klassiker! Jag valde att stryka mitt lilla skämt innan jag skickade henne frågorna men faktum var att hon själv nämnde det under intervjun vilket jag tyckte var roligt.

Vi pratar en hel del om hennes böcker, naturligtvis om ”de sju nycklarna” men även hennes andra vilket ni kan finna här på (Bokus-länk).

6 mars, 2019

En titt på branschens ordsallad

Det är många olika ord i omlopp inom IT-säkerhetsområdet och därför tänkte jag beskriva några av dem:

– Vulnerability / Sårbarhet
En sårbarhet är ett fel i ett program som kan utnyttjas för att ta över programmet, hindra det från att fungera eller ändra i dessa funktion.

– Exploit / Som substantiv: kod som utnyttjar sårbarhet, som verb: att utnyttja en sårbarhet
Kod som utnyttjar en sårbarhet för att attackera ett program eller en maskin. Virus, masker och annan farlig kod använder exploits för att ta kontroll över system. Jag har inte hittat något riktigt bra Svenskt ord för exploit.

– Payload
Koden som ska köras på ett system som just tagits över. Automatiserade programvaror som MetaSploit framework består normalt av exploitkod för att ta sig in i systemet och en payload som utför önskade attacker. En vanlig payload är ett reverse-shell, som är en kommandoprompt med fulla rättigheter som upprättas mellan ditt system och det du just tagit över. Exploitkoden är som en missil med payloaden som sin stridsspets.

– Malware / Farliga program
Program som egentligen inte är virus, utan men har oönskad effekt. Malware kan ofta spela in tangentbordstryckningar(keyloggers), skicka iväg kontokortsuppgifter från din maskin eller visa oönskad reklam.

– Threat / hot
Ett hot är något som kan skada, skapa oönskade förändringar eller förstöra. Exempel på hot: inbrott, stulna datorer eller stöld av hemlig information.

– Threatagent / hotagent Någon som genomför ett hot. Om hotet är inbrott, är en inbrottstjuv en hotagent.

– Risk Ett vanligt sätt att se en risk är att se den som något som uppstår när sårbarhet och en hotagent existerar samtidigt. En dåligt låst dörr är en sårbarhet medan en inbrottstjuv är en hotagent. Tillsammans uppstår en risk!

– CIA-triaden
Confidentiality, Integrity, Availability. Detta är en enkel men effektiv metod för att analysera IT-säkerhetsrelaterade hot. Confidentiality (konfidentialitet) handlar om att hantera hot om informationsläckage. Det kan handla om allt från att hindra attackerarna från att läsa hemliga dokument till att undvika läckage av kontokortsuppgifter. Integrity (Integritet) handlar om hot mot informationens pålitlighet. Det handlar ofta om att skydda dokument eller information från obehörig förändring. Ett exempel finns i filmen Wargames där huvudpersonen attackerar sin skolas datorsystem för att ändra och förbättra sina betyg. Tillgänglighet (Availability) handlar om hot mot systemets nåbarhet. Om man tänker stänga ner databaser eller skicka miljontals anrop till ett system för att lasta ner det, faller attacken inom denna kategori.

Detta är inte en komplett lista på något sätt. Definitionerna kan säkert också debatteras, men denna lista är menad för att klargöra de olika begreppen som ofta används i t.ex. säkerhetsbulletiner. Området kan fördjupas nästan hur mycket som helst. Och ja, det blir lätt mycket svengelska, det erkänner jag.

Facebook Spotify Soundcloud Apple Rss

Senaste avsnitten

Scroll to top