Hvordan vi fandt en sårbarhed i backupprodukt fra IBM - workaround offentliggjort og lidt om processen

Jeg skylder lige at følge op på mit tidligere blogindlæg, Bagdøre og datakompromittering via backupsystemer, hvor jeg med vilje slap "Angrebsscenarie F", nærmest midt i en sætning. Først nu kan jeg tale åbent om det.

Flemming Riis og jeg fandt simpelthen en fundamental sikkerhedsbrist i selve IBM Tivoli Storage Manager (TSM) klienten, mens vi researchede på IBM TSM's håndtering af autentifikation (node ID og node adgangskode) og usikre implementeringer af TSM, som blev behandlet i de øvrige scenarier.

Vi kunne næsten ikke tro vores egne øjne, da vi relativt hurtigt fandt en rimelig alvorlig - og voldsomt banal - sikkerhedsbrist.

Derefter indledte vi en Resposible Disclosure proces med IBM Product Security Incident Response Team (PSIRT), som jeg vil beskrive nærmere nedenfor, da den illustrerer hvor vigtigt det er, at stille krav og holde fast.

Selve sårbarheden

En angriber, der udnytter den fundne sårbarhed, kan i bund og grund udlæse Node ID og en obfuskeret værdi af Node adgangskoden - blot som almindelig bruger på et Windows system med TSM klienten installeret, f.eks. en Terminal/Citrix Server.

Nedenfor ses den konkrete rettighedstildeling i registreringsdatabasen, hvor almindelige brugere har læseadgang til følsom værdi.
IBM TSM registry read all users

Med den information, kan angriberen gendanne systemets filer - uanset NTFS rettigheder m.v. - på en anden maskine, som angriberen har adgang til og administrative rettigheder på. Det kan sådan set være vedkommendes egen private laptop, tilsluttet netværket og med TSM klienten installeret.

Ud over uautoriseret adgang til filer (dokumenter, regneark, konfigurationsfiler m.v.), kan en angriber f.eks. også opnå adgang til alt fra SAM database til følsomme registreringsdatabase-værdier, potentielt klartekst adgangskoder for servicekonti m.v.

Et insider angreb er således eksempelvis oplagt, herunder muligheden for Information Disclosure, Privilege Escalation og Credential Theft.

Responsible Disclosure processen

Jeg vil lige beskrive forløbet med IBM PSIRT. I mine øjne viser det hvor vigtigt det er, at stille relativt hårde krav til leverandører om deadlines m.v. I sidste ende selvfølgelig for kundernes (og dermed implicit leverandørens egen) skyld!

  • 03-03-2017 Rapporteret til IBM PSIRT via online formular, med første deadline d. 10-03-2017 (7 dage), hvor de forinden skal bekræfte modtagelse og test af sårbarheden. Anden og ultimative deadline er sat til 03-05-2017, altså 60 dage.
  • 07-03-2017 IBM PSIRT bekræfter modtagelse af vores henvendelse med et sagsnummer (Advisory ID).
  • 07-03-2017 Vi fortæller IBM PSIRT, at har intentioner om at samarbejde og release informationer om sårbarheden når der er workaround eller patch, dog senest 03-05-2017 (deadline). Samtidig indskærper vi, at IBM skal teste og bekræfte sårbarheden inden første deadline (3 dage tilbage) - ellers publicerer vi informationer om sårbarheden.
  • 10-03-2017 IBM PSIRT skriver tilbage, at vores submission er verificeret og vil adresseret i en fremtidig opdatering. Deres Product Team "håber" at levere "late 3rd Quarter 2017/ early 4th Quarter 2017".
  • 11-03-2017 Vi bekræfter overfor IBM PSIRT, at de har overholdt første deadline (10-03-2017). Vi holder fast i release deadline 03-05-2017, men indikerer samtidig, at vi er villige til at give mere tid, såfremt IBM PSIRT samarbejder og besvarer nogle uddybende spørgsmål om bl.a. kritikalitet m.v. Vi spørger også til muligheden for, at tilsvarende sårbarhed eventuelt måtte eksistere på ikke-Windows operativsystemer.
  • 12-03-2017 IBM PSIRT informerer os om, at de har videresendt vores spørgsmål til udviklerne.
  • 20-03-2017 Vi rykker IBM PSIRT for svar fra udviklerne.
  • 22-03-2017 IBM PSIRT sender uddybende svar på vores spørgsmål. Udviklerne skriver, at det er komplekst at rette fejlen og udbeder sig mere tid.
  • 05-04-2017 Vi gør IBM PSIRT klart, at vi ikke har fået tilstrækkelig commitment på en dato for frigivelse af patch og/eller workaround. Vi giver samtidig IBM PSIRT en ny deadline, så de får indtil 03-06-2017, altså 30 dage yderligere. Vi skriver også, at vi håber de vil beskytte deres kunder inden. Igen opfordrer vi til, at de frigiver en simpel workaround ift. rettighedstildeling i registreringsdatabasen.
  • 21-04-2017 Vi rykker IBM PSIRT for en bekræftelse på, at de har modtaget vores henvendelse af 05-04-2017 og evt. give os en statusmelding. Vi udbeder svar omkring spørgsmål (af 11-03-2017) til ikke-Windows operativsystemer.
  • 24-04-2017 IBM PSIRT svarer, at de har henvendt til til Product Team d. 21-04-2017 og afventer svar fra dem.
  • 27-04-2017 IBM PSIRT beklager forsinkelsen. Man dedikerer sig på at frigive en mitigation inden udgangen af maj måned i form af en Security Bulletin. En egentlig patch (fix) holdes til udmelding af d. 10-03-2017 (3rd/4th Quarter 2017). Nu fortæller IBM PSIRT, at den sårbarhed Flemming Riis og jeg har fundet selvstændigt, åbenbart allerede var rapporteret til IBM i september måned 2016, men at alle researchers vil blive anerkendt i Security Bulletin. Derfor står Kęstutis Gudinavičius fra SEC Consult også under Acknowledgement, men vi har aldrig kommunikeret sammen.
  • 23-05-2017 Vi spørger IBM PSIRT for en statusmelding og en dato for publicering af workaround og Security Bulletin. Vi rykker igen for svar omkring ikke-Windows operativsystemer.
  • 23-05-2017 IBM PSIRT skriver, at de publicerer en mitigation inden udgangen af maj. De bekræfter yderligere, at de vil tjekke og inkludere alle supporterede versioner og platforme af TSM.
  • 01-06-2017 Vi udbeder os information om hvor de har publiceret mitigation og Security Bulletin.
  • 01-06-2017 IBM PSIRT skriver, at de publicerede eftermiddagen før, og inkluderer dette link.

Det vigtigste af ovenstående er for mig at se, at den tidligere researcher åbenbart ikke har sat pres på IBM for at fixe problemet. Derfor har sårbarheden fået lov at leve videre i bedste velgående - indtil vi også faldt over samme. Det finder jeg yderst problematisk.

I den periode, har IBMs kunder været sårbare overfor denne relativt basale angrebsmetodik. Det er virkelig ikke "rocket science" og det er så lidt der skal til for at løse problemet.

Jeg har undervejs gjort mig flere tanker om manglende standarder for Responsible Disclosure timelines, bug bounty programmer osv., men det må blive en anden gang. Input modtaget gerne!

Anbefalinger

Jeg vil anbefale alle, der kører med IBM TSM produktet, at:

1) implementere workaround på alle relevante systemer (primært servere med TSM backup klient på).

2) begrænse adgangen til TSM serverne, så kun relevante systemer (dvs. dem der tages backup af og evt. skal restores data på) kan kommunikere (standard TCP 1500).

Relevante henvisninger

Relateret indhold

Jakob H. Heidelbergs billede
CEO og Security Advisor hos Improsec ApS med mange års erfaring indenfor IT-sikkerhed og bl.a. en fortid som Cyber Security Architect hos Microsoft (World Wide Global Practice), Senior Security Consultant hos Microsoft (MCS Denmark), MVP indenfor Enterprise Security og Principal Security Advisor hos FortConsult (NCC Group). Han arbejder med, og blogger om, cybersikkerhed på relativt teknisk plan, med primært fokus på Microsoft-platformen og hvordan man beskytter denne bedst muligt mod aktuelle angrebsmetoder.

Kommentarer (9)

Claus Juul

Denne "feature" er der flere der har kendt til i meget lang tid.

Jeg selv har kendt den siden 2004 (ca.) hvor jeg var Backup Tekniker.
Jeg skal ærligt indrømme at jeg ikke havde tænkt på den som en sårbarhed, men jo det er det selvfølgelig.

Jeg havde dog ikke undersøgt rettighederne i registeringsdatabasen mv.

Når jeg tænker over det kan det være at den viden jeg fik i 2004, måske stammede fra IBM!

Claus Juul

Jeg vil vove at påstå at det ikke er nødvendigt for at kunne restore til andre noder, da du bare skal kende passwordet.

Når jeg tænker over det, mener jeg at der også er en måde at udlæse passwordet i klartekst eller er det at man kan skifte password uden at kende det gamle, husker det ikke helt.

Jeg mener at det samme trick gør sig gældende for krypteringsnøglen. Den står vist også i registeringsdatabasen i hash'et form, men kopieres den til en anden maskine, har du ikke behov for at kende nøglen, men igen jeg graver hukommelse frem, der er mere end 10 år gammel, så måske husker jeg galt.

Troels Arvin

Mange tak fordi du kaster lys på et it-sikkerhedsaspekt, som jeg mener overses mere end godt er: Direkte eller indirekte adgang til backup-data.

Svarede IBM nogensinde på, om ikke-Windows systemer er omfattet af et lignende problem?

Jakob H. Heidelberg Blogger

Svarede IBM nogensinde på, om ikke-Windows systemer er omfattet af et lignende problem?

Tak for det. IBM har svaret, at de vil tjekke og inkludere alle supporterede versioner og platforme af TSM. Dermed håber jeg, at de f.eks. på Linux/Unix sørger for, at der ikke ligger klartekst konfigurationsfiler (inkl. Node adgangskode) med Read rettighed til almindelige brugere osv., men reelt kan jeg ikke være sikker på, at de har tjekket op på det og jeg har desværre ikke lige umiddelbart mulighed for at teste det i nærmeste fremtid.

Troels Arvin

Placeringen af node-password afhænger på unix af indstillingen for "passworddir": https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.0/client/r_opt...

Placeringen er på Linux-servere /etc/adsm, hvori man finder filen TSM.PWD. Et hurtigt kig på nogle Linux-servere får mig til at konkludere, at TSM.PWD har fornuftige (root-only) indstillinger, med mindre nogen aktivt har ændret noget. Så det er jo godt.

Jakob H. Heidelberg Blogger

Placeringen af node-password afhænger på unix af indstillingen for "passworddir": https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.0/client/r_opt...

Placeringen er på Linux-servere /etc/adsm, hvori man finder filen TSM.PWD. Et hurtigt kig på nogle Linux-servere får mig til at konkludere, at TSM.PWD har fornuftige (root-only) indstillinger, med mindre nogen aktivt har ændret noget. Så det er jo godt.

Tak!

Log ind eller opret en konto for at skrive kommentarer