När jag gjorde värnplikten, känns som hundra år sedan nu, så fanns det en allmänt vedertagen ”sanning”. Fienden skulle landsätta sina trupper i Sverige på midsommarafton, när minst halva befolkningen var satt ”ur stridbart skick”.
Det här var bland det första som for genom mitt huvud sent på kvällen den andra juli, när jag svarade i telefonen och fick beskedet att Kaseya var under attack. Efter ett och ett halvt år i mer eller mindre karantän skulle USA öppna upp och fira sin självständighetsdag. Minst halva befolkningen var inte i skick att analysera loggar.
Så vad var det som hände egentligen? Det har gjorts dussintals artiklar i ämnet så jag ska inte gå in på detaljer utan snarare prata lärdomar och subjektiva iaktagelser. En utmärkt artikel har vår partner SentinelOne gjort här: https://www.sentinelone.com/blog/revils-grand-coup-abusing-kaseya-managed-services-software-for-massive-profits/
Kaseya VSA är ett verktyg som används inhouse eller av Service Providers till att hantera klientdatorer och servrar. För att sådan mjukvara ska vara effektiv så krävs höga behörigheter i operativsystemet som hanteras. Det krävs även metoder att snabbt och enkelt skjuta ut script för att hantera olika typer av händelser. Detta sammantaget gör att Kaseya VSA måste anses vara ett mycket kraftfullt och – i fel händer, farligt system. Så sent som förra året skedde en annan, betydligt mindre sofistikerad attack då en Kaseyaserver togs över genom att man knäckte ett lösenord. Säkerhetsåtgärder hade därför vidtagits för att motverka den typen av attacker med hjälp av tvåfaktors-autentisering. Kaseya har aktivt arbetat med ett säkerhetsföretag från Holland för att genomlysa sin kod samt göra pentester de senaste åren.
Den här gången hade man inte upptäckt en svaghet i koden vilken föranledde en så kallad ”zero day” som det ryska ”Ransomware as a service”-syndikatet REvil utnyttjade och kunde gå förbi autentiseringen. Rykten har spridits om att Kaseya känt till sårbarheten i flera år, något som de bestämt förnekar.
Det som hände när väl REvil hade passerat autentiseringen var att man använde Kaseyas modul ”Agent procedures” för att skjuta ut kod till alla datorer, ”agenter” som var online. Då källan var betrodd för klienterna så var det ytterst få antivirus som reagerade på detta. För att tekniker inte skulle kunna komma in och stoppa skeendet så blockerades övriga inloggningar. Man döpte även proceduren till ”Kaseya VSA Agent Hotfix”. Det skadliga programmet gjorde en rad saker men viktigast för användaren var att det i slutändan krypterade alla filer man kom åt på c: på datorn, och publicerade en ruta som berättade att användaren hade sju dagar på sig att betala 44999 dollar i kryptovalutan ”Monero” för att få tillbaka innehållet. Efter sju dagar skulle summan dubbleras.
REvil gjorde en väldigt sofistikerad attack, använde bland annat stulna certifikat för att signera koden. Dock så gjorde man även ett par grova misstag:
- Samma nyckel användes överallt, Kaseya har nu fått tag på nyckeln och alla filer kan låsas upp. Detta är faktiskt anmärkningsvärt men lyckosamt för de som blivit drabbade.
- Endast C: krypterades. På framförallt servrar är det ovanligt att spara data på c:
- Endast tre servrar(så kallade CC) användes för att styra attacken, dessa kunde snabbt svartlistas och blockeras.
Tidigare har vi på Cuebid gjort en utmärkt intervju med Nils på SentinelOne om ”Supply Chain Attacks”, den finns att se här: https://www.youtube.com/watch?v=TTSoGDrrK5A. När den som attackerar använder sig av befintliga leverantörers kod för att penetrera slutanvändares infrastruktur. Ett mycket effektivt sätt att ta sig in då leverantören redan är betrodd och eventuella varningar i Antivirus ses som felaktiga och ofta ignoreras eller görs undantag på.
Cyberattacken mot Kaseya är dock inte en klassisk Supply Chain attack, ingen kod hos Kaseya modifierades. Det talas om att den egentligen inte passar in under någon kategori av attack och att det ska komma en helt ny kategori. Visst användes Kaseya som verktyg för att komma åt att kryptera filer men egentligen inte på annat sätt än vad Windows inbyggda verktyg användes.
Vad kan man dra för lärdomar?
Egentligen kommer inga revolutionerande nya sätt att tänka säkerhet ut av det här, det är saker som vi redan visste men det tål att upprepas. Det här var ett kreativt sätt att komma åt användare men det här var undantaget. Det är fortfarande så att det vanligaste sättet att infektera klienter och komma åt data är via e-post och genom nedladdade filer. System för att centralt hantera klienter på ena eller andra sättet kommer även i fortsättningen att behövas och den dåliga nyheten är att alla dessa har råkat ut för attacker.
Det är alltid dumt att lägga alla ägg i samma korg, använd backup och se till så att backupen är skild från övrig infrastruktur på alla sätt som är möjliga.
Använd antivirus på samtliga system och ta alltid larm och varningar på allvar. Saknar organisationen resurser att övervaka och hantera larm så behöver funktionen outsourcas.
Patcha, sätt en baseline på företaget på hur många patchar som får saknas innan en enhet anses vara incompliant.
/Stefan Elensky
