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.
> 
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
- Security Bulletin: IBM Spectrum Protect (formerly Tivoli Storage Manager) Windows Client password exposure (CVE-2016-8939)
- Controlling access to Windows registry entries for IBM Spectrum Protect backup-archive and data protection clients
- CVE-2016-8939 på cve.mitre.org
- How we found a vulnerability in IBM's backup product - the workaround and a bit about the Responsible Disclosure process
