Månad: april 2019

24 april, 2019

När man säger för mycket

Det är en allt mer ovanlig syn: felmeddelandet som säger allt.

Kommer ni ihåg när man kunde gå till en hemsida och se följande meddelande?

”Microsoft OLE DB Provider for ODBC Drivers error ’80040e14’

[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ’46’.

/webapp.php, line 12″

Detta förekommer fortfarande, men just detta meddelande är idag nästan ett museiföremål. Meddelandet ovan kommer från en sårbar webbapplikation som råkat ut för någon som testat att lägga till en apostrof i ett indatafält. Detta är en indikator att man kan göra en SQL-injektion. Meddelandet avslöjar även vilken databasmotor man använder.

Att säga att det inte sker längre är dessvärre att tro för väl om säkerheten på Internet. Det finns stora mängder exempel på system som berättar vilken version de är eller läcker ut annan känslig information. Det finns många ställen där man kan demonstrera detta. En av de mest användbara är ”Google Hacking Database” som innehåller en lista på sökord som kan användas för att hitta sårbara applikationer eller intressanta saker att titta djupare på. Den bygger på att applikationer ofta läcker ut konfigurationer, lösenord eller loggar på nätet, som Googles sökmotor snappar upp när den indexerar sidorna. Ett exempel ur den digra listan: prova följande länk för att hitta applikationer på Github som hårdkodar sina lösenord i konfigurationsfiler. Många av dessa är troligen av rätt begränsad användning. Men det finns anledning att fundera på om det är så lämpligt att skriva en applikation på detta sätt. Kan man använda denna information för att hacka? Svaret är att det beror på ens fantasi.

Sen finns ShodanHQ som låter dig söka efter enheter som är nåbara från Internet. Detta verktyg har vi pratat om på podden, så det enda jag kan säga här är att det avslöjar mycket. Det ska noteras att sökningen är helt laglig. Den gör absolut ingen skada. Däremot ska du inte göra något för att ta över systemen. Vi avråder starkt från att faktiskt försöka hacka system utan tillstånd. Vi tar inget ansvar för vad som händer om du försöker dig på något sådant. Håll dig på den lagliga sidan!

Vad finns det att lära av detta? Det jag ser är att det är viktigt att inte ge ut någon information annat än den mest absolut nödvändiga. All information kan komma att användas av någon som har oärliga avsikter.

18 april, 2019

Att förstå säkerheten

I början av 2000-talet fanns siten ”Interface Hall of Shame”. Denna site visar exempel på värdelösa grafiska användargränsnitt. Min favorit är hur de relaterar till någon som på ett forum undrade hur en dropdown meny kunde fås att fungera när man hade tusentals möjliga val i den. Svaret är: varför vill du ens bygga något så dumt?

Säkerheten är inget undantag från att dålig design. Eller, vad som nästan är ännu värre, exempel på egenpåfunna lösningar. Som jag skrivit i tidigare blogginlägg: inom säkerhetsområdet är det i stort sätt alltid en dålig idé att komma på sin egen krypteringsalgoritm och tro att den kommer förbli säker om man bara låter bli att berätta hur den fungerar.

Men det finns många tillfällen där personer och företag har byggt lösningar utan att förstå säkerheten bakom.

I Windows 95 sparades lösenorden man loggade in med i ett format som Microsoft själva hade hittat på. Hur det fungerade höll man givetvis för sig själva. Och det tog inte lång tid för några duktiga hackare att knäcka det. Lärdomen av det, som jag skrev ovan, är att inte hålla det hemligt och att inte försöka bygga algoritmerna själv.

Säkerhetsexperten Steve Gibson kom på en metod för att skydda datorer från överbelastningsattacker. Innan hans lösning blev ens byggd, tittade några andra säkerhetsexperter igenom vad han gjorde reklam för och sågade lösningen. Den var inte säker. Steve hade inte pratat med någon annan medan han satt på kammaren och byggde vad han trodde var en perfekt lösning. Dessutom hade han troligen inte koll på att en liknande lösning redan fanns och hade används under ett antal år. Lärdom: prata med andra om din lösning och kolla om du måste bygga den överhuvudtaget.

De som uppfann den trådlösa krypteringsmetoden WEP gjorde en katastrofalt dålig lösning som visade sig var extremt enkel att knäcka. Om man skyddar sitt trådlösa nätverk med WEP, är det i princip som att skicka data i klartext. Anledningen till problemet var att man inte förstått hur man krypterar säkert och gjort några nybörjarfel i designen. Lärdomen är att se till att man förstå området man ger sig in på innan man bygger sin lösning. Bara för att du själv inte kan hacka din egen lösning, betyder det inte att andra inte kan.

Och jag har själv gjort en tavla. Jag byggde ett autentiseringssytem i php som jag var mycket noggrann med att säkra. Alla inmatningar kontrollerades och sanerades. Databasanropen skedde med ett nedlåst konto. När jag provade att göra en SQL-injektion, lyckades jag hacka min egen lösning på första försöket Jag hade helt enkelt glömt att kontrollera datat från inmatningsfältet för lösenordet, vilket är det andra fältet som skickar data till applikationen. Lärdomen är att inte anta du gjort allting rätt för att du tycker att du kan området. En förmildrande omständighet var att jag faktiskt kollade säkerheten innan jag släppte applikationen lös på nätet.

Säkerhetsområdet kan vara svårt att förstå och jag tror att det korrekta sättet att hantera det är att vara öppen och låta andra titta på vad du gör. Se till att källkoden till det du bygger släpps fritt på nätet om du kan. Använd alltid testade och vedertagna principer när du arbetar med säkerhet. Försök inte göra allt själv och förlita dig inte helt och hållet på någon enstaka person som har rykte om sig att vara en guru.

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.

Facebook Spotify Soundcloud Apple Rss

Senaste avsnitten

Scroll to top