Bagdøre og datakompromittering via backupsystemer
Sammen med min gode ven og kollega, Flemming Riis, har jeg på det seneste undersøgt opsætningen af nogle udbredte backupsystemer, herunder hvordan de potentielt kan misbruges af angribere.
Tanken er ikke at »male fanden på væggen«, men at gøre opmærksom på en reel problemstilling, som i følge vores erfaring er noget overset.
Flemming skrev i går en teknisk opsummering på hans blog (engelsk): Protecting your secrets, one more step to remember.
Nedenfor ses primært på Tivoli Storage Manager (TSM) fra IBM, men det er væsentligt at pointere, at andre backupsystemer kan udgøre en tilsvarende sikkerhedsrisiko, hvis de vel at mærke ikke administreres korrekt.
I det følgende opererer jeg med to forskellige overordnede arkitekturer:
Cloud setup: remote/shared/hosted setup (fjernbackup).
On-premises setup: klassisk setup med "lokale" og interne backupservere.
Disse arkitekturvalg ses i lyset af følgende angribere og tilhørende angrebsscenarier:
Tidligere administratorer: f.eks. en person, som har haft kendskab til opsætningen af et miljø. Enten cloud eller on-premises setup.
Server administratorer: f.eks. en person, som er lokal administrator på en enkelt host, men dermed kan gætte hvordan man gendanner andre servere, inkl. Domain Controllers. Enten cloud eller on-premises setup.
Ondsindede hackere: f.eks. uvedkommende som én gang har kompromitteret et miljø og ønsker en bagdør (persistence) - eller kører på samme shared backupplatform som din virksomhed.
Vi undlader her at se på cloud tjenesteudbyderes (eller deres angriberes) mulighed for at stjæle eller manipulere med ukrypterede backupdata, eller sletning af backupdata generelt.
Backup- og restorestrategi
En udbredt backupstrategi forsøger at isolere backupsystemer fra det almindelige netværk, både på netværksniveau og i forhold til autentifikationssystem. Det vil sige, at man gør sig uafhængig af almindelige centrale autentifikationssystemer, såsom Active Directory (AD).
I tilfælde af omfattende eller fuld kompromittering, enten af ondsindede hackere eller malware (ofte ransomware), kan systemer og data således fortsat gendannes fra et uafhængigt og "rent" miljø - også selvom angriberne skulle have opnået Domain Admin rettigheder eller tilsvarende.
Det princip er umiddelbart sundt og lægger sådan set i god tråd med et cloud setup, der dels er isoleret rent netværksmæssigt og dels har et selvstændigt autentifikationssystem (på godt og ondt).
Opsætning og administration
Hvis vi ser specifikt på konfigurationen af TSM, så skal backup-klienten (servere med backup agent installeret), ud over basal konfiguration, opbevare følgende i registreringsdatabasen:
Node ID
Node kode (password)
Node krypteringsnøgle (symmetrisk)
Alle disse informationer er desværre, i rigtig mange IT-miljøer, statiske i hele serverens levetid.
Yderligere opbevares de i enten klartekst eller lettere obfuskeret, da serveren skal kunne autentificere sig og kryptere data løbende.
Den primære bekymring her er den anvendte kode, som anvendes i forbindelse med både sikkerhedskopiering og efterfølgende gendannelse.
Det er væsentligt, at det til enhver tid kun er de rigtige personer eller systemer, som har kendskab til anvendte koder.
På den lyse side
En positiv ting er, at man ofte ikke har mulighed for at slette sikkerhedskopier automatisk eller vha. kommandoer. Det er en god sikkerhedsmekanisme, da en ransomware f.eks. ellers kunne slette alle sikkerhedskopier programmelt i forbindelse med et angreb. Hermed ville sandsynligheden for, at offeret betaler for dekryptering af data, være væsentlig højere.
I tilfælde hvor backupsystemet kun opbevarer f.eks. de 10 seneste backup-versioner, kan man dog forestille sig, at en ransomware efter kryptering initierer 10 backupkørsler, som dermed overskriver gamle (og brugbare) versioner. Det er dog (indrømmet) et meget tænkt eksempel, men det er værd at overveje.
Kryptering af data
Det er ikke alle virksomheder, der vælger at kryptere deres backupdata - hvad enten den valgte løsning er on-premises eller i cloud.
Dette er ofte grundet øgede omkostninger for storage plads, da deduplikering ikke er særlig effektiv for krypterede data. Man betaler typisk for storage, så det bliver oftest væsentlig dyrere hvis man vælger at kryptere.
Hvis der ikke er økonomi til at kryptere data fra alle hosts, kan man vælge kun at kryptere de mest kritiske data, som minimum Domain Controllers.
Når man vurderer mulige konsekvenser af nedenstående angrebsscenarier, skal man også tage i betragtning hvorvidt der er anvendt kryptering eller ej, samt hvordan krypteringsnøgler er opbevaret.
Cloud setup
I det følgende gives eksempler på angrebsscenarier relateret til cloud setup.
For enkelthedens skyld tages der udgangspunkt i et cloud setup, som er bredt eksponeret mod hele verden (typisk en enkelt TCP port), hvilket ikke er ualmindeligt (se sidste afsnit i dette blogindlæg).
Angrebsscenarie A: tidligere medarbejder stjæler fortrolige data via cloud setup
Det er meget almindeligt, at man husker at lukke for medarbejderes brugerkonti, når de forlader virksomheden af den ene eller anden grund.
De rigtig grundige skifter også adgangskoder på andre brugerkonti, som fælleskonti (fyha!) og servicekonti, såfremt den afgåede medarbejder havde adgang til disse.
De færreste husker dog at skifte koder for backupløsningen, hvilket selvfølgelig er ekstra alvorligt, såfremt man anvender en cloud løsning.
En tidligere medarbejder kan således løbende gendanne aktuelle data og opsætninger for implicerede systemer i hele deres levetid, potentielt flere år, eksempelvis via proxy-tjenester eller Tor netværk.
For TSM er det blot et spørgsmål om at installere backup agenten/klienten på en maskine (behøver ikke være domain joined), og sætte den op korrekt, f.eks. ved import af registreringsdatabaseindstillinger og konfigurationsfiler (se Flemming Riis' blogindlæg).
Angrebsscenarie B: administrator hos kunde #1 stjæler data fra kunde #2
I visse tilfælde har vi under penetrationstests opdaget, at tjenesteudbydere af cloud backup anvender standardkoder (enten statiske eller let gættelige mønstre), som det forventes at kunderne skifter i forbindelse med installationen, men at dette ikke sker i praksis.
Disse koder er sommetider ens eller indeholder mønstre hvor f.eks. NodeID'et indgår. Således kan man i visse tilfælde gætte hvad andre systemer benytter af koder, hvis blot man kender én.
Hvis en administrator hos kunde #1 således kan gætte - eller brute force - anvendte Node ID'er hos kunde #2 (ofte fortløbende numre inden for en tildelt nummerserie), kan vedkommende potentielt stjæle data m.v.
On-premises setup
I det følgende gives eksemper på angrebsscenarier relateret til on-premises setup.
Angrebsscenarie C: tidligere medarbejder med fysisk netværksadgang har bagdør
I forhold til cloud setups, der oftest er bygget til at være tilgængelige fra hele verden, er on-premises setups noget mere sikre eksponeringsmæssigt. Her skal en angriber i hvert fald også ulejlige sig med at sikre netværksadgang.
Virksomheder som ikke har god fysisk sikring på alle netværksopkoblede lokationer, og som ikke har fornuftig firewall-segmentering mellem subnet, vil have svært ved at holde en motiveret angriber ude.
I sådanne tilfælde er det ikke svært at komme ind fra gaden med en PC, tilslutte den netværket, og (med kendskab til TSM konfiguration) begynde at gendanne data, herunder f.eks. stjæle seneste Domain Controller backup.
Se sidste afsnit omkring anbefalinger om netværksisolering.
Angrebsscenarie D: malware på bruger PC har bagdør
Et enkelt lille stykke malware, f.eks. en simpel Remote Access Trojan (RAT) i brugerkontekst, kørende på en PC tilsluttet virksomhedens netværk kan være nok til, at en angriber kan holde en bagdør åben og når som helst tiltvinge sig fulde rettigheder i miljøet igen.
En sådan RAT fjerner behovet for den fysiske adgang til netværksswitche eller trådløse netværk, som i angrebsscenarie C, og giver ellers samme omfattende muligheder. En RAT leveres ofte nemt via Phishing eller lignende.
Hvis man således tror, at man har smidt angriberne ud og ryddet helt op efter et angreb, herunder måske skiftet alle adgangskoder i AD, men man ikke har skiftet backup-kodeord, så er man muligvis hurtigt i problemer igen.
Angrebsscenarie E: administrator på server P stjæler data fra server Q
Kendskab til hvordan f.eks. TSM er sat op på blot en enkelt server, kan lede til fuld kompromittering af miljøet. Dette i tilfælde af der anvendes ens Node koder eller f.eks. mønstre (set i praksis med Node ID med simpel padding).
I så fald er det eneste administrator på server P skal gøre, at gætte f.eks. Node ID for en eller flere andre servere i miljøet.
Under en nylig penetrationstest var det én mekanisme til at få Domain Admin adgang i kundens miljø. Vi gendannede simpelthen bare NTDS.dit og SYSTEM filerne fra en Domain Controller - til en anden server vi havde overtaget.
Angrebsscenarie F: almindelig bruger på server R får øget adgang lokalt
Såfremt en bruger - administrator eller ej - har mulighed for at udlæse konfigurationsdata fra registreringsdatabase og filsystem (f.eks. TSM opsætning), kan disse informationer misbruges, f.eks. til Local Privilege Escalation (LPE) eller uautoriseret adgang til følsomme data (lokalt).
For nogle backupsystemer har vi konstateret, at almindelige brugere, f.eks. i et terminalservermiljø, kan udlæse de nødvendige konfigurationsdata.
Jeg vil vende tilbage til dette i et kommende blogindlæg, da vi fortsat researcher på området.
Beskyttelse og minimering af risiko
Hermed nogle generelle råd i relation til ovenstående problematikker:
Benyt ikke den standard Node kode, som ofte udleveres af tjenesteudbyderen til initiel installation.
Skift Node koder til stærke, unikke og tilfældige koder. Dette udføres enten løbende eller som minimum i tilfælde af, at en person med kendskab til koderne forlader virksomheden.
Nogle udbydere af fjernbackup tilsluttes via VPN tunneller eller MPLS forbindelser, og er altså ikke bare åbne for alle i verden. Her reduceres angrebsfladen til tjenesteudbyderens øvrige kunder (såfremt man ikke har dedikeret setup).
Nogle udbydere af fjernbackup tilbyder IP-filtre, så der kun kan re-etableres data fra givne IP-adresser. Det kan dog være tilfældet, at andre kunder hos udbyderen også er whitelistede i det IP-filter, men risikoen vil blive minimeret.
Interne backupsystemer, bør netværksmæssigt isoleres således, at kun relevante systemer kan kommunikere med dem for sikkerhedskopiering og gendannelse af data. Der er således ofte ikke behov for adgang fra f.eks. klient-subnets.
Sørg for logning og eventuelt alarmering ved gendannelse af (kritiske) data og/eller systemer. Få eventuelt blot en periodisk rapport fra system- eller tjenesteudbyder over, hvad der er gendannet inden for en given periode.
Undersøg om der er mulighed for krav om 2-faktor authentificering ved gendannelse af data.
Kryptér backupdata, hvor det giver mening i forhold til data- og systemklassifikation.
Tak for denne gang
/Jakob
