jekob heidelberg bloghoved

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

Relateret indhold

Kommentarer (10)
Marc Andersen

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).

Noget siger mig, at selvom man burde gøre det, gør de færreste det nok. Både i forhold til en misforståelse af, at ens TCO stiger og sandsynligvis, fordi det er den eneste adgangsgivende mekanisme man har på det niveau. Så er der helt sikkert også nogen compliance krav, som på papiret opfyldes udelukkende med AD authentication.

Men jeg kan sagtens tage fejl.

I forlængelse af ovenstående: samtlige sikkerhedkontroller fra AV til SIEM, bør ikke bruge AD, da det er det første man ikke kan stole på ved kompromittering.
Generelt burde IT funktionernes adgangsgivende kontroller ikke blandes mere end nødvendigt sammen med dem fra den generelle befolkning. Faktisk burde de ikke engang sidde på det samme netværk. Hvordan skal man sobert fejlsøge en platform, der har problemer, når man sidder på selveste platformen, der er påvirket, f.eks. standard klienten på et netværk?
Business: "Brugerne kan af en eller anden grund ikke logge på"
IT: "Næh, det kan vi heller ikke..."

Kristoffer Balling

Enig, tarsnap er et godt valg.

Alternativer der ligesom tarsnap tilbyder kryptering, komprimering og de-duplikation er open-source Borg Backup (python) og closed-source HashBackup. Begge programmer er gratis at anvende (HashBackup planlægger betalingsversion).

Jeg anvender selv Borg op mod rsync.net med backup af mine vigtigste filer (dokumenter, egne billeder og video) hver time. Med de-duplikering tager en (uændret) backup af ~800 GB ca. 5-10 min ... dedup er uundværligt med VDSL upload-hastighed (~12 Mbps) da det kun er ændringer som uploades ;-)

HashBackup bruger jeg dagligt op mod BackBlaze B2 til musik og film fra medie-serveren.

Begge programmer kan slette gamle backups efter et brugerdefineret skema (fx behold ialt 48 time-backups, 14 daglige backups, 13 ugentlige, 6 månedlige og 1 årlig backup etc).

Jakob H. Heidelberg Blogger

Det kan sagtens lade sig gøre at lave et sikkert remote backup system, det har Colin Percieval bevist med tarsnap.

Jeg skriver det måske ikke klart nok, men det er i bund og grund ikke systemerne der er problemet, men de tilknyttede administrative procedurer. Dog med undtagelse af angrebsscenarie F, som jeg vil komme tilbage til.

Ift. tarsnap kunne man måske forestille dig, at en (ex)admin tog en key-fil med sig? Jeg kender ikke systemer, da jeg primært opererer i Windows verdenen. Måske er det ikke muligt?

Morten Christensen

Jeg har ikke meget forstand på det praktiske i den her disciplin, men er det gennemførligt, at skifte krypteringsnøglen på flere terrabyte backup, som ligger i den store cloud hos Amazon eller en af deres kolleger, når en af IT-administratorerne skifter job ?

Jakob H. Heidelberg Blogger
Poul-Henning Kamp Blogger

Ift. tarsnap kunne man måske forestille dig, at en (ex)admin tog en key-fil med sig? Jeg kender ikke systemer, da jeg primært opererer i Windows verdenen. Måske er det ikke muligt?

Hvis du ikke har styr på din egen sysadmin er du under alle omstændigheder totalt blottet. Se også: NSA, Snowden.

Det Colin har vist er at ikke alene kan cloud-backups laves således at data ikke er exponeret når de ligger i skyen, det kan også gøres utroligt billigt og pålideligt.

Problemet er at de fleste cloududbydere er meget mere fokuserede på at tjene penge og derfor hitter de på alle mulige "value-add" services, som kun kan virke hvis de har en gradvis større indsigt i hvad det er for data du har lavet backup af.

... og dermed ender du som kunde med at betale (meget!) mere for en lavere sikkerhed.

Jakob H. Heidelberg Blogger

Hvis du ikke har styr på din egen sysadmin er du under alle omstændigheder totalt blottet. Se også: NSA, Snowden.

Man kan f.eks. sikre sig, at sysadmins ikke har adgang til ens seneste cloud backups løbende, altså også efter de er stoppet i virksomheden ;-)

Det lyder fint med Colin til *nix. Andre løsninger kan selvfølgelig også kryptere m.v. Jeg forholder mig ikke til priser.

Poul-Henning Kamp Blogger

Det lyder fint med Colin til *nix.

Det er vigtigt at du forstår at det Colin har lavet er et kryptografisk princip for sikre backups. Det faktum at han har valgt at implementere det på UNIX (først?) er en ligegyldig detalje, for princippet virker på tværs af alle OS og platforme.

Og hvis du vælger at lukke øjnene for de "perverse incentives" Cloududbyderne lader sig friste af til at levere ringere sikkerhed for en højere pris, bliver det ret hurtigt ligegyldigt at høre på hvad du måtte have at sige...

Jakob H. Heidelberg Blogger
Log ind eller Opret konto for at kommentere