ShowNotes

2 maj, 2020

Show notes för #74 – Nigeriabrev från fängelset

Om du funderar på att visa chefen fingret på måndag och storma ut ur kontoret för att en Nigeriansk prins vill ge dig massiva mängder pengar, kanske du bör tänka om.

Avsnittet heter #73 – Nigeriabrev från fängelset
Det spelades in 2020-05-01 och lades ut 2020-05-03.
Deltagare: Mattias Jadesköld och Erik Zalitis.
Show notes skrivna av Erik Zalitis.

Vi har under den tid vi funnits karvat ut en egen liten nisch för oss själva. Där andra pratar om det absolut senaste som hänt, tittar vi ofta bakåt och funderar på hur vi hamnade där vi nu är nu inom IT-säkerhetsområdet.

Nigeriabrev är en gammal företeelse, som funnits långt före epost blev en grej.

Hope Olusegun Aroke verkar vara en tvättäkta ”kriminell hjärna” som inte låter någon form av hinder stoppa hans framfart. Så honom har vi garanterat inte hört det sista från.

Men har han skickat Nigeriabrev? Det vet vi faktiskt inte. Det står bara om bedrägerier, så det kan han mycket väl ha sysslat med. Därför tar detta avsnitt två spår: det berättar dels om honom och dels om Nigeriabrevet som fenomen.

Nigeriabrev

UC förklarar begreppet.
https://www.minuc.se/id-stold/vad-ar-nigeriabrev

För den som tror att det bara är de okunniga som åker dit på dem.
https://www.aftonbladet.se/nyheter/a/ngWlMm/han-atalas-for-miljardsvindel

Jag anser att girighet snarare än dumhet är förklaringen till att folk blir lurande. Men en mer djuplodande analys finns att läsa här.
https://www.bbc.com/worklife/article/20180727-why-so-many-people-fall-for-scams

Jo, jag sa ju att det är lukrativt nog att dra in mycket pengar så att bedragarna fortfarande vill hålla på med det… och det är det ju…
https://www.cnbc.com/2019/04/18/nigerian-prince-scams-still-rake-in-over-700000-dollars-a-year.html

Spamhaus och spam

Spamhaus ROKSO (Register of Known Spam Operation) visar att antalet ”spamoutfits” numera bara är runt 100 stycken, snarare än de runt 200 de var på den tiden jag var system admin. Kan man tänka sig att de minskat som en effekt av att spam som företeelse inte är lika lukrativt längre?
https://www.spamhaus.org/rokso/

Sanford ”Spamford” Wallace var i fängelse fram tills 2018 och han verkar inte ha hittat något sätt att spamma efteråt, så han har just nu ”indisponibel” för att fortsätta med sitt kall. Men vi lär inte ha hört det sista från honom…
https://en.wikipedia.org/wiki/Sanford_Wallace

Får också be om ursäkt för ett fel i programmet, det var inte Sanford Wallace, utan en annan spammare, Alan Ralsky som fick tonvis med reklamblad per post som en hämnd. Annars stämmer ju historien i sig…
https://www.theregister.com/2002/12/11/spammer_gets_junk_mailed/

Man ska ju kunna backa upp sina påståenden också, och här är en bra graf för att visa att spam-mängden minskar:
https://www.statista.com/statistics/420391/spam-email-traffic-share/

Redan 2015 var det ganska klart att spammens glansdagar var över och det har inte blivit ”bättre” sedan dess:
https://www.bbc.com/news/technology-33564016

(Eller, jo, det har blivit BÄTTRE. Beror på ens perspektiv på saken 🙂 )

För den som undrar vad som hänt, så kan man ju lätt se att spear-phishing och riktade attacker är det som växer i populäritet snarare än spammens breda ”hagelbrakar-spridnings”-metod för att nå ut.

Nigeria

Jag sa också att Nigeria har 150 miljoner invånare, vilket visade sig vara lite gamla uppgifter. 2016 års folkräkning fick det till runt 186 miljoner. Alltså ett mycket stort land sett ur ett befolkningsperspektiv.

Nigeria som land.
https://sv.wikipedia.org/wiki/Nigeria

25 april, 2020

Show notes för #73 – När Hizbollah knäckte Israels radio

Ett exempel på hur en frekvenshoppande sändning kan se ut på ett ”vattenfallsdiagram” i ett program som matas av en SDR-mottagare.

Avsnittet heter #73 – När Hizbollah knäckte Israels radio
Det spelades in 2020-04-25 och lades ut 2020-04-26.
Deltagare: Mattias Jadesköld och Erik Zalitis.
Show notes skrivna av Erik Zalitis.

De flesta avsnitt vi gör är enkla att källforska till och därför behöver vi sällan spekulera i saker och ting utan kan berätta korrekta fakta om allt vi pratar om. Detta avsnitt är annorlunda och tvunget att bli spekulativt till sin natur, eftersom stridande parter är ovilliga att berätta hemligheter och kan antas sprida information som helt eller delvis inte är korrekt.

Vi berättar historien och pratar om teknikerna som används av de olika parterna utan att beskriva helt exakt hur de olika militärerna använder dem. En del av det är hemligt, annat kan vara svårt att hitta detaljer om och en del kan även vara föråldrat. Så diskussionen blir därför något schematisk men ger dig ändå allt du behöver veta.

Här är några fördjupningar i ämnena vi pratar om:

När kom SDR (Software Defined Radio)?

Tekniken kom till så tidigt som på 1970-talet, men började utvecklas som ersättare för traditionella radiosystem på 1990-talet. På 2000-talet mognade tekniken och blev allt mer vanlig. 2009 fanns den till exempel i många 3G-mobiler. Detta gör att, precis som Erik säger, är det definitivt en möjlighet att Hizbollah kan ha använt denna teknik mot Israel.

https://en.wikipedia.org/wiki/Software-defined_radio

Några noteringar om frekvenshoppning

Jo, alltså det är ju lämpligt att kryptera sändningen också… Hohum… Säger bara det.

Förutom de saker vi pratade om vad det gäller frekvenshoppning, kan man lägga till att tekniken också gör det mycket svårare att störa sändningarna eftersom frekvenserna byts hela tiden.

Däremot är ju SDR-tekniken något som ändrat ekvationen och frekvenshopp i sig självt är inte längre nog för att skydda sändningen.

Väl värt att notera är också att det kan vara svårt att följa frekvenshoppande sändningar även med en SDR-mottagare om varje sändning plockas upp så svagt att den ligger nära brusmattan i mottagningen.

Den otroligt duktiga uppfinnaren och skådespelerskan Hedy Lamar anses idag vara frekvenshoppningens moder.

Enigma

Vi kommer in på ett kär gammal diskussion, nämligen Tyskarnas Enigmakrypto och hur det knäcktes. Detta har inte så mycket med ämnet för dagen att göra, men är en intressant avstickare till gamla tiders radioavlyssning. Här kan ni höra avsnittet.

Länkar…

SDR-tävlingen vi pratar om:

https://www.rtl-sdr.com/tag/frequency-hopping/

Bruce Schneier som ställer sig tveksam till sanningshalten i rapporten:

https://www.schneier.com/blog/archives/2006/09/did_hezbollah_c.html

The Registers artikel som herr Schneier refererar till:

https://www.theregister.co.uk/2006/09/20/hezbollah_cracks_israeli_radio/

DVB-T mottagaren vi pratar om:

https://www.amsat.se/2012/11/20/guide-lyssna-med-rtl-sdr-under-100-kr/

19 april, 2020

Show notes för #72 – Nio fel

Avsnittet heter #72 – Nio vanliga fel vid penetrationstester.
Det spelades in 2020-04-18 och lades ut 2020-04-19.
Deltagare: Mattias Jadesköld och Erik Zalitis.
Show notes skrivna av Erik Zalitis.

Några tankar
Avsnittet är i någon form en fristående fortsättning på våra avsnitt om Etisk hackning och Cyber Kill chain. En del av ämnena togs upp redan där, men i detta avsnitt fördjupar vi diskussionen om svårigheterna man möte när man testar system.

Denna gång försöker vi också fundera på vad som bör ingå i en bra rapport:

  • Ska ha en sammanfattning (Executive summary) med övergripande risk.
  • Lista alla mål som man kommit överens om.
  • Lista alla sätt det gick att ta sig in.
  • Ranka sårbarheter enligt något system som är enkelt att överblicka.
  • Föreslå förbättringar och lösningar.
  • Rapporten anpassas i omfång och detaljnivå efter uppdragets storlek och karaktär.

Allmänt om pentester, SDLC och när man gör tester

Software Development Life Cycle heter det ju faktiskt…

Pentester sker normalt i samband utrullningen av ett nytt system eller i samband med utrullningen av en ny version av ett system.

Testerna simulerar attacker och dokumenterar allting som upptäckts “på vägen”.

Pentester utföres alltid av en oberoende granskare.

Vår lista på de nio vanligaste felen som görs vid pentester:

1 – Att inte förstå avgränsningarna I uppdraget
2 – Att inte prioritera riskerna
3 – Att använda fel verktyg
4 – Att göra en dålig rapport
5 – Att bara ”kryssa för boxar” istället för att ge kreativiteten en chans.
6 – Att skada produktionssytem
7 – Att använda gammal teknik och ha gammal kunskap
8 – Att inte göra återkommande tester
9 – Att kunden inte genomför förbättringarna som föreslås.

15 april, 2020

När man är under attack

The firewall, the firewall, the firewall is on fire.. We don’t need no water…

Jag tror vi lämnar Coronan för en stund och funderar lite på det där med att bli attackerad. Det var lite roande i början av året, när jag trodde vi råkat ut, men det är mycket sällan man kan le åt sånt här.

Veckans avsnitt handlar om hur AddTech blev drabbade av en ransomwareattack och hur de klarade av att återställa sina system medan attackerarna försökte ta sig tillbaka in. Och just den sista detaljen fick mig att haja till när Jesper berättade om den. Inte nog med att de krypterade all data, när de kastades ut, genomförde de ”social engineering”-attack där de försökte få tillbaka sin skadlig kod på systemen igen. De som ringde upp pratade bra Svenska, men denna gång var personalen beredda…

Under det snart ett och ett halvt år som vi funnits har vi hunnit intervjua en stor mängd personer inom IT-säkerhetsområdet, men veckans intervju är en av de ytterligt få tillfällen där någon har kunnat ge oss insiderinformation om hur en riktig attack gick till och vad IT-chefen tänkte medan han jobbade med att få tillbaka allting.

Vad finns det för lärdomar att dra? Kanske är det hur enkelt ransomware kan sprida sig lateralt. Från EN ENDA smittad dator, till att en stor del av systemen går ner på kort tid. Eller en värre sak….

Jesper säger att AddTech inte verkar ha fått någon data läckt, och det är kanske den bästa delen av historien. Tänk om det hade hänt. En sådan situation sätter ett utsatt företag i en situation där utpressningen kan komma tillbaka gång på gång tills informationen inte längre är värdefull. Hackarna kanske skulle kunna kontaktat företaget en gång i halvåret och krävt pengar på nytt. Det är riktigt svårt att göra något åt, om det skulle hända.

Den positiva nyheten är att i den värld, som rör sig allt snabbare, är information en färskvara. När den är några år gammal, har den i stort sett inget värde.

Så vad är lösningen? Hur kan man garanterat stoppa sådana här attacker? Det kan man inte, men det finns möjlighet att minska riskerna. Det är dags att ta fram löken igen. Alltså den där modellen att bygga säkerheten i många lager. Börjar med segmentering, nedlåsning, MFA, skadlig kodskydd, offline backup, övervakning och allt det där… Men Jesper berättar också om värdet av att träna sina anställda att vara uppmärksamma och skeptiska, vilket är ett underskattat skydd som dock kräver att man håller kurser regelbundet, då glömskan slå till efter några månader.

Även om jag anser mig vara duktig på IT-säkerhet, lärde jag mig mycket från denna intervju.

Mvh

Erik Zalitis

20 mars, 2020

När det gått snett i verkligheten inom Open Source

I IT-säkerhetspoddens tredje, och sista, är Linus Karlsson (Security Specialist) från Debricked med oss och pratar om när det gått snett I verkligheten. 

Riskerna att inte uppdatera Open Source och beroende applikationer

Ett vanligt fenomen är dåliga rutiner på att uppdatera sin mjukvara  (eller dependencies som det benämns i avsnittet). Linus tar fallet med Equifax som exempel. 

Equifax är ett stort kreditupplysningsföretag I USA som drabbades av en läckage där 145 miljoner människors information läckte. Ungefär hälften av USAs befolkning. Information som namn, adresser och körskortsuppgifter läckte. 

Grundorsaken berodde på att Equifax nyttjade ett bibliotek, som är väldigt vanlig, som heter Apache struts. Biblioteket används för att skapa webtjänster baserat på Java. 

Trots att Equifax upptäckte sårbarhet i Apache struts tog det ungefär ett halvår innan de presenterade detta. Anledningen vara att biblioteket inte uppdaterats och konsekvenserna blev att Equifax fick sitt varumärke svärtat samt att de fick betala tillbaka oerhört mycket pengar. De fick bland annat erbjuda gratistjänster till sina kunder. 

Om man litar på A, som litar på B, betyder det automatiskt så att man litar på B? 

Linus tar ett annat exempel som är mycket mer sofistikerat och som bygger på just att man litar på sin mjukvara och på så viss även litar på mjukvarans beroende program. 

Den här gången drabbar det registryt NPM, eller rättare sagt Event Stream som är ett populärt paket bland java-script. Paketet gör en väldigt specifik grej, och i just detta fall, strömmar av event. Paketet är oerhört populärt och nyttjas i massor av mjukvara. 

Event Streams skapare blir kontaktad av en okänd person som har ett antal förslag på förbättring och skickade dessa. Allt kändes som att personen agerade i all välmening. Förbättringarna godkändes, men ytterligare en dependencies smögs med. Det syntes men eftersom personen verkade schysst lade man ingen större notis om det, eftersom det inte innhöll något skadligt. 

Men en månad senare uppdaterades just den här dependencies med ny kod. Den här gången skadlig!  

Attacken var väldigt sofistikerad, och riktad, eftersom den skadliga koden aktiverades bara när mjukvaran hanterade Bitcoins. Dessutom om balansen på Bitcoin-plånboken hade hög likviditet. På så vis upptäcktes det inte lika lätt. 

Konsekvenserna är okända men skadliga koden skeppas tillsammans med mjukvara för Bitcoin. 

Hur kan man skydda sig mot detta? 

I första exemplet gäller det givetvis att se till att ha en tydlig patchrutin. Mjukvaran ska vara uppdaterad. Man måste också ha koll på vilka beroenden som finns i mjukvaran och att även dessa är uppdaterade. 

Det andra exemplet är knepigare eftersom det nästan är ett Social Engineering-attack där skaparen av mjukvaran luras att uppdatera sin kod. Ett tydligt svar finns inte riktigt utan det diskuteras fortfarande huruvida det är grundaren som var oansvarig medan en annan stor grupp tycker att man inte kan ha sådana förväntningar på en person som skapat mjukvaran på sin fritid. Dessutom en person som inte har tid att uppdatera mjukvaran längre. 

Vem man ska lita på kanske inte är det viktiga utan mer mekanismen hur man tar in ny mjukvara, och upprätthåller den, i sin kod. 

13 februari, 2020

Machine learning inom Open source

I IT-säkerhetspoddens andra specialavsnitt är Emil Wåreus (Head of Data Science på debricked) tillbaka. Den här gången pratar vi om hans favoritämne – machine learning. 

Att nyttja Maskininlärning har på sista tiden blivit betydligt billigare och det finns ramverk att arbeta med som kan tillämpas till sin mjukvara. 

Säkerhetsföretaget debricked hanterar extremt mycket data i sitt analysverktyg för att identifiera sårbarheter i open source. Därför används maskininlärning för att processa all information. 

Maskininlärning inte samma sak som AI 

Emil har tidigare byggt robotar (eller autonoma agenter), till exempel drönare som följde efter människor, och där noterade han att begreppet maskininlärning missförstås. Ofta blandas det ihop med AI fast det är helt separata saker. Så för att förtydliga: 

  • AI kan beskrivas, ur ett autonom-agent-perspektiv, som human, det vill säga en agent som kan förstå sin omgivning och ta beslut helt utan styrning. 
     
  • Maskininlärning däremot, ur samma perspektiv, kan delvis uppfatta omgivningen men är bättre på varseblivning. Den fungerar väl i en stängd miljön men om man tar drönararbetet som exempel är omgivningen fysisk. Maskininlärning som teknik kan då inte “förstå” omgivningen men däremot analysera bilder. Problem kan uppstå där till exempel maskininlärning kan tro att en ko kan vara i en hästhage (där ett AI, som förstår omgivningen, förmodligen skulle anta det är en häst eftersom den förstår att det är en hästhage). Det är således viktigt att träna sin maskininlärning. 

Processad information måste bli rätt 

Vi tar oss an den amerikanska databasen NVD igen, där Emil upptäckte att sårbarheterna som presenterades var missvisande. 

Sårbarheter presenteras som att 60% av produkter som visas endast har en sårbarhet och 90% med under sex sårbarheter. Det blir alltså svårt att se allvarligheten i de olika mjukvarorna och vilka projekt som innebär störst risk att nyttja. 

Debricked tar hjälp av sin egen maskininlärningsalgoritm för att samla NVD tillsammans med issues på Github (repository med mjukvaror) för att få kvalité på informationen. Den tittar till exempel på språkbruket i skapade issuen och vad för ord som den innehåller för att bilda sig en uppfattning. På så vis kan algoritmen avgöra vad som är en säkerhetsbrist och vad som till exempel är en bugg. 

Den guidar utvecklare i rätt riktning och att göra rätt. 

Algoritmen läser miljoner rader av text (från flera olika repositories) och förstår och kategoriserar problemet. 

Träna sin algoritm 

Maskininlärning måste hela tiden tränas på sådant den känner till och på sådant den inte känner till. Tekniken kallas Semi-supervised learning och där använder debricked Googles TensorFlow. 

Vi återanvänder häst-exemplet. Emil tränar sitt dataset med ett antal bilder på hästar och sådant som är markerat som “inte häst”. Sedan massor av bilder på sådant som är helt okänt. Algoritmen processar bilderna och förstår, och blir ännu mer träffsäker, på vad som är en “häst i en bild”. 

Det finns färdigtränade algoritmer för till exempel bildanalys och text men inte mycket för att upptäcka säkerhetsbrister. Där är debricked ledande och slår andra som gör liknande. 

 
Vad är en säkerhetsbrist? 

Debrickeds algoritm kan läsa nästan vilken text som helst och avgöra om det är ett säkerhetsproblem som beskrivs eller inte. Företaget arbetar vidare med att kategorisera vikten av hur allvarlig bristen är. 

Emil poängterar vikten att förstå sitt område som dataanalytiker. Man måste kunna till exempel säkerhet för att kunna utveckla maskininlärning som hanterar säkerhet. Man måste hela tiden jobba och undersöka hur träffsäker sin maskininlärning är. Det går inte att ha en algoritm som förutspår sju av tio fel och genererar för mycket falska larm (false positive). Det är viktigt att den data som levereras till kund är minst över 90% korrekt, så kunden kan fokusera på rätt saker. 

Avslutande tips 

Emil avrunda med tips inom maskininlärning 

  • Det är viktigt att ha låg false positive men att arbeta med att öka informationen att ta in utan att sänka kvalitén med hög träffsäkerhet 
  • Arbeta med erkända ramverk (t.ex. TensorFlow) 
  • Arbeta med matematiken för att optimera effektivt och för att förstå sin data 
  • Förstå din domän först (område) som maskininlärningen ska hantera 
  • Maskininlärning är ett medel för att nå ditt mål 
31 januari, 2020

Statistik inom Open source

Affärsmodell med Open source 

Allt fler företag väljer att skapa mjukvara baserat på öppen källkod (Open source). I IT-säkerhetspoddens avsnitt pratar vi med Emil Wåreus Head of Data Sience på debricked om risker kopplat till öppen mjukvara och statistik (eller fun facts).

Statistiken är viktig att förstå för att välja rätt öppen källkod och hur komplext det kan vara för att undvika säkerhetsrisker. 

   Öppen källkod kan jämförs som en rörelse där skapare nyttjar öppen källkod och publicerar sina anpassningar på internet för hela Open source-scenen. Engagemanget är stort och förslag med funktionell och säkerhetsmässiga förbättringar diskuteras inom rörelsen.  

   Det kan tyckas märkligt att företagare lämnar ut sin affärsidé och delar med sig till vem som helst och för att förstå hur det hänger ihop tar vi oss till 80-talet. Trenden var då att man såg sin mjukvara just som själva affärsidén. Resultatet blev en statisk mjukvara (eller proprietär kod) med ett hackigt community. . 

   Open source startade samtidigt på konsumentsidan där engagemanget blev stort bland användare. När det nu är utbrett på företagssidan är en vanlig affärsmodell open core där kärnan är öppen medan tilläggstjänster såsom support och konsultarbeten blir affärsmodellen. På så vis behålls engagemanget i Open source och samtidigt kan företagare vara lönsamma genom att hjälpa sina kunder med vad de faktiskt efterfrågar. 

Flera hundra beroenden 

Det många inte vet är att en öppen källkod ofta inte är just en mjukvara. Tvärtom. Vanligare är snarare att mjukvaror använder flera hundra direktimporterade mjukvaror som den är beroende av. Beroenden med sina egna öppna källkod och sårbarheter. Emil Wåreus tar ramverket React som exempel som är en plattform baserad på Java och skapat av Facebook. Verktyget är väldigt populärt just nu för att skapa webapplikationer och bygger på just öppen källkod. Men få känner till att React har ungefär 3.500 beroenden. Hur ska man ha koll på vilka man använder och vilka säkerhetsrisker det finns att nyttja ett sådant ramverk? 

   Här finns fördelen med den öppna källkodsscenen där man kan ta del av andras upptäckter och idéer till skillnad mot stängd mjukvara där tillverkaren ansvarar för att upptäcka sårbarheter och täppa till dessa. 

   För att reda ut svårigheterna finns debrickeds mjukvara som analyserar mjukvaran inom tre områden – sårbarheter, licensieringen och hälsokontroll (health check), där det sistnämnda undersöker just communityt för att analysera hur högt engagemanget såsom bidragande medlemmar. Det hela poängbedöms av debricked vilket hjälper upphovsmakarna att välja rätt öppen källkod. 

Flera datakällor för att upptäcka sårbarheter 

Debricked är integrerat med Amerikanska NISTs “National Vulnerability Database” (NVD) som är en öppen databas där man kan hitta kända sårbarheter i öppen källkod. Här rapporterar communities (till exempel Github) till NVD för analys. NVD undersöker vilken typ av sårbarhet som avses och om det är kopplat till säkerhet eller inte. Ungefär femtio nya sårbarheter registreras – per dag! 

Statistik från NVD visar vilka projekt som innehåller mest sårbarheter. Bild nedan visar de högst rankade just nu.  

   Men NVD räcker inte för att upptäcka sårbarheter så därför är databasen bara en av datakällor som debricked nyttjar. En stor del upptäcks inte eftersom NVD har koll på 50.000 projekt som har ungefär 120.000-130.000 sårbarheter. Debricked däremot hittar över 200.000 sårbarheter relaterat till säkerhet eftersom de samlar in från flera datakällor. 

   Den andra stora källan är, numera Microsoft-ägda GitHub, som debricked nyttjar som datakälla. Här undersåker debricked så kallade issues på Github. 

   Om man skapar en enkel websida baserad på öppen källkod med populära verktyg och installerar enligt standard kan man räkna med ungefär 10.000-15.000 beroende mjukvaror med hundratals sårbarheter. Nästa steg blir att analysera sårbarheten som oftast (ungefär 30%) kan täppas till genom att uppdatera. Men resten är klurigare. Man ska ställa sig frågan – använder jag den här mjukvaran? Eller kan jag bygga runt det på något vis?  

Fyra råd 

Emil Wåreus ger fyras råd för öppna källkodsprojekt.  

  • Använd debricked tidigt i processen innan du importerar mjukvara för att förstå hur säker den är och undersök poängbedömningen.  
  • Sätt policys för att blockera osäker mjukvara. På så vis hjälper man utvecklare att göra rätt och förhindra att fel kod importeras 
  • Räkna på mjukvaran som är tänkt att användas. Räkna hur mycket tid och pengar det krävs för att säkra mjukvaran 
  • Använd inte gammal mjukvara 

Man får också väga “springa framåt” mot “håll tätt bakåt” i projektet. 

28 september, 2019

SQL-Injektioner

I avsnitt nummer 45 tar vi oss an begreppet SQL Injection.

Jag och Erik verkar gilla den här sårbarheten, eftersom förutom avsnittet, finns ju Eriks bloggartikel i ämnet här.

I avsnittet pratar vi om ”OWASP Top Ten Project” och den är ju intressant att kika på. – länk.

Och så nämner vi lite fakta – 65% av alla webbattacker nyttjar SQLi som vektor. Källan finns här (https://www.cbronline.com/news/sql-injection-attacks) – en väldigt spännande vinkel i artikeln är att spelkonton är hackares nya favorit.

23 juni, 2019

Avsnitt om identitetsintrång

I avsnitt 31 om id-kapning pratar vi om Identitetsintrång och begreppet beskrivs på många olika vis från olika källor.

Polisens sida om identitetsintrång har en hyfsat bra punktlista på åtgärder för att skydda sin identitet men behöver kompletteras med några andra saker:

  • Lita på din dator om du ska göra internetköp
  • Lita på sidan du handlar ifrån
  • Aktivera adresslås (väldigt viktigt) för att undvika att obehöriga byter din bokföringsadress
  • Se till att ditt betalningskort är ”säker kortbetalning aktiverat”

Den sista punkten är olika beroende på vilken bank man använder så undersök vad som gäller för just din bank. Smart är ju givetvis att onlineköp behöver godkännas med Mobilt BankID

12 juni, 2019

Dessa vilda dagar

Pratade tillsammans med Mattias med Marcus Murray från TrueSec och han sa att ”Ondskan har mognat”. Det slog an en klang och jag har funderat på det en hel del. Sanningen är att det känns som innan nästan inte hinner reagera mellan att man får veta att en viss typ av attacker blir vanligare och man ser att det händer i ens närhet.

Förut kunde attacker hanteras utan allt för mycket svett. Ett totalt övertagande av en miljö hände ju även då, men det vanligaste var att man hanterade enstaka datorer med skadlig kod eller läckta uppgifter. Idag är det mer och mer vanligt att man helt plötsligt har hundratals servrar och klienter som är krypterade eller på annat sätt övertagna. Ett litet ”nålstick” dödar hela organisationen.

Attacker blir allt mer riktade och det har vi ju talat om många gånger tidigare. Vad blir det av detta i framtiden, kan man undra? Hur många system måste tas över innan någon form av smärtgräns är nådd. Baltimore hålls gisslan, men när hör vi att även New York, Seattle och Washington råkar ut? Är det framtiden? Att i princip alla är drabbade och det blir standard att återställa allt från början eller punga ut med miljoner dollar till hackare för att få tillbaka viktigt data. Det kommer till sist bli som en form av hackar-skatt. Kanske blir det ett system med beskyddarpengar för att man inte ska bli drabbad. Och om man nu spenderar pengar på security operations centers som hela tiden övervakar allting, blir det ju ändå en ökad kostnad för att kunna försätta driva sin verksamhet. Detta i sig är också en form av ”hackarskatt” för alla. En kostnad som man anting betalar till attackerare eller till de som ska skydda mot dem.

Är Zero Trust Networks ett hopp för framtiden eller tar sig allt mer organiserade hackers förbi även detta? Det är inte utan ett visst mått av frustration som jag ser hur det blir allt mörkare på säkerhetsfronten.

Men kanske måste man även se ljuset. Vi blir allt mer säkerhetsmedvetna och fler och fler utbildar sig i säkerhet, vare sig de vill jobba inom området eller bara förstå hur saker fungerar.

Facebook Spotify Soundcloud Apple Rss

Senaste avsnitten

Scroll to top