Onderzoeker publiceert zerodays IBM-software nadat IBM weigerde patch te maken

Een beveiligingsonderzoeker heeft vier zerodays gepubliceerd die in securityproducten van IBM zitten. Dat deed hij nadat het bedrijf weigerde de lekken te patchen. Volgens IBM viel de melding van de onderzoeker buiten de scope van het responsible-disclosurebeleid.

De lekken zitten in de IBM Data Risk Manager. Dat is een tool voor bedrijven die verschillende functies heeft om de security te regelen. Beveiligingsonderzoeker Pedro Ribeiro vond vier lekken in de software. Drie daarvan klassificieert hij als 'kritiek', een andere als 'hoog risico'.

Het gaat om een authenicatieomzeiling, een command injection, een zwak standaardwachtwoord dat ergens werd gebruikt, en de mogelijkheid om willekeurige bestanden te downloaden. De aanvallen zijn alle vier niet alleen lokaal maar ook van een afstand uit te voeren, mits de IDRM op internet is aangesloten. Ribeiro zegt er wel bij dat dat vaak niet het geval is.

De onderzoeker heeft informatie over de lekken op GitHub gepubliceerd. Het lek zit in IDRM-versies tot zeker 2.0.3. Inmiddels is versie 2.0.6 van de software uit. Ribeiro zegt dat hij niet heeft kunnen testen of de lekken ook daarop werken. Aangezien hij de kwetsbaarheden pas meldde nádat 2.0.6 uitkwam en IBM in de release notes geen informatie had opgenomen over de specifieke bugs lijkt het er niet op alsof die al verholpen zijn.

De onderzoeker zegt contact te hebben opgenomen met IBM om hen over de lekken te melden. Hij deed dat via CERT/CC, de instantie die kwetsbaarheden in software categoriseert en coördineert. IBM weigerde de disclosure. Het bedrijf verwijst naar zijn voorwaarden op HackerOne. "Deze bugs zijn out of scope voor ons responsible-disclosureprogramma omdat dit product alleen bedoeld is voor extra ondersteuning voor betalende klanten", schrijft het bedrijf aan CERT/CC.

Het bedrijf zegt tegen ZDnet dat het de gang van zaken betreurt en dat het alsnog werkt aan een oplossing voor het probleem.

Door Tijs Hofmans

Nieuwscoördinator

23-04-2020 • 10:33

47

Reacties (47)

47
47
26
4
0
8
Wijzig sortering
"Deze bugs zijn out of scope voor ons responsible-disclosureprogramma omdat dit product alleen bedoeld is voor extra ondersteuning voor betalende klanten"
Dus een klant betaalt IBM voor extra ondersteuning op specifieke producten, en die producten zijn dan niet onderdeel van een responsible disclosure programma? Ik zou als klant mij achter mijn oren krabben over de extra (belabberde) ondersteuning.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 23:33]

Het wordt nog leuker:
of een IBM-klant van minimaal zes maanden oud
Je betaalt IBM voor een dienst, vindt er op de eerste dag al een kritieke beveiligingsfout in en dan zou je (als ik het artikel goed begrijp) als antwoord krijgen "kom over zes maanden nog maar een keer terug, dan gaan we überhaupt pas overwegen of we er iets mee willen doen... tot die tijd moet je lekker blijven betalen voor een dienst die je niet durft te gebruiken omdat je weet hoe lek die is"...!?

Ik zou nog kunnen begrijpen als meldingen van "zomaar iemand" wat trager opgepakt worden, terwijl meldingen van "trusted partners" meteen onderzocht worden. Maar meldingen van onbekenden helemaal negeren? Nee, die logica ontgaat me.
Nu lees ik de laatste tijd wel vaker artikelen waarbij mijn mening over IBM toch wat bijgesteld wordt.

Op Geenstijl stond ook een interessant stukje: Het Korsakov-contract met IBM
Het prijskaartje bedraagt 16.000 euro per terabyte per maand – ex BTW. IBM stuurt voor alleen al het polisgebeuren dus een maandelijkse rekening die hard richting de half miljoen euro gaat – en razendsnel oploopt. (...)

Ik vraag mensen met marktkennis of dit normale tarieven zijn. Niet dus. Sterker nog, de voorganger van IBM bij het UWV, Getronics, zou tarieven van 3.000 euro per terabyte per maand vragen – nog geen vijfde van IBM.

[Reactie gewijzigd door Sando op 22 juli 2024 23:33]

AWS rekent $120 per TB per maand |:(
Poeh. Ik snap dat de overheid wat meer verwacht van haar cloud storage, maar da's wel een factor 140 oid.
Beetje een appel en peer vergelijking die deze man doet. Uit ervaring weet ik dat storage heel duur kan zijn. Zeker als je allemaal requirements stelt die je eigenlijk niet hebt :p

Nu vind ik IBM wel altijd nogal duur maar ja, dat weet je:p
Je wordt gedownmod maar je maakt wel een valide punt: We weten niet welke vereisten er zijn aan deze storage.

Ik heb zelf ook veel gesprekken gevoerd over opslag en klanten denken vooraf niet goed na over wat ze echt nodig moeten hebben. Iedereen begint met de eis: Alles driedubbel redundant over drie fysieke locaties en synchroon (RTO / RPO moet nul zijn). Dan bereken je de (gigantische) prijs en komt een normale klant zeer snel terug op zijn vereisten.

IBM weet dit natuurlijk ook en de overheid weet alleen dat hij kwart voor vier naar huis heen moet. Waarschijnlijk is dit slechts 1 van de valkuilen van IBM.
Voor de context (uit die link), dat is in 2007. Duidelijk andere tijden qua prijzen van HDD's.

Toen zat het rond de dollar per GB aan HDD capaciteit, dus 1000 dollar voor een TB. Kijkend naar de huidige consumer prijzen voor cloud opslag dan zit dat ongeveer 2-3 keer de aanschafprijs van een TB per jaar. Dus dan zou 2000 dollar per jaar wel de ondergrens zijn destijds.

Heb je nog niet meegerekend het gebrek aan veel aanbieders destijds en het verschil tussen consumer en Enterprise voorwaarden.

[Reactie gewijzigd door Raafz0r op 22 juli 2024 23:33]

[...]
Dus een klant betaalt IBM extra voor extra ondersteuning op specifieke producten, en die producten zijn dan niet onderdeel van een responsible disclosure programma? Ik zou als klant mij achter mijn oren krabben over de extra (belabberde) ondersteuning.
Ik vind het ook een vreemde gang van zaken en denk dat het eigenlijk gewoon realisme is van IBM. Ik heb wel eens een klant de oren moeten wassen omdat die gevoelige data niet wilde beveiligen want dat vond de klant maar onhandig. Zelf sta ik op dit gebied vrij stevig in mijn schoenen en heb de klant dus overtuigd om het anders te doen. Iemand die in een minder sterke positie zit kan of durft dat mogelijk niet als dat betekent dat de klant wegloopt en z'n baas boos wordt.
Daarbij zal custom code die voor één klant wordt geschreven wel minder aandacht krijgen dan het hoofdproduct. Dat zou natuurlijk geen excuus mogen zijn, maar laten we wel wezen, zo gaat dat. Extra lastig wordt het wanneer die code onveilig is omdat de klant daar om vroeg. Ik snap dat het commercieel niet aantrekkelijk is om daar verantwoordelijkheid voor te nemen.

Ik denk dat er overigens best een boom op te zetten is dat het wel degelijk hun verantwoordelijkheid is. Van een architect verwacht je ook dat die z'n klanten tegen houdt als ze een gebouw vragen dat waarschijnlijk zal instorten. Ik weet niet of er een wettelijke verplichting is, maar willens en wetens een ander laten verongelukken is niet de bedoeling.
Dit lijkt mij typisch een geval waarbij de melding verzand raakt in de bureaucratische molen van een groot bedrijf. De onderzoeker is geen partij die de software zou moeten gebruiken dus gaan we dit als IBM niet serieus nemen. Wellicht met de gedachte dat hackers niet snel op zoek gaan naar lekken in zulke specifieke software.
Misschien zit/zat er iemand bij Marketing die dacht "Misschien kunnen we een support contract aan hackers verkopen". want zonder contract mogen ze toch niet hacken omdat dat tegen de EULA in gaat :+
Ik snap dat nooit. Als je op dag 1 zegt "valt erbuiten" waarom dan na openbaar making alsnog eraan werken? En kom nu niet aan met "want nu weet iedereen ervan". Je vindt het een belangrijk risico of niet. Niet eerst niet en dan wel.
AuteurTijsZonderH Nieuwscoördinator @Hukkel8023 april 2020 11:03
Helemaal opvallend omdat het geen geldkwestie kan zijn - IBM betaalt niet voor rd-meldingen, er worden alleen kudo's uitgedeeld.
Niet om het een of ander maar bij zulke berichten vraag ik mij toch altijd af wat nu precies het geval is: wordt een van de oudste, grootste en meest succesvolle IT bedrijven ter wereld blijkbaar gerund door een stelletje halvegaren die geen idee hebben van veiligheid en totaal niet geïnteresseerd zijn in service aan de klanten of er speelt er wel iets meer mee op de achtergrond waar we niets van weten... En zoals Tijs al opmerkt: een financiele kwestie zal het in ieder geval niet zijn.
Bedrijven worden niet bestuurd door techneuten, maar door economen.
Dat IBM een techbedrijf is zegt alleen iets over de vloerwerkers. Het bestuur let alleen op winstgroei. En als zij inschatten dat iets niet fixen (en dus minder kost) niet tot klant- of imagoverlies leidt dan wordt het niet gedaan.
Tja, IBM moet blijkbaar wennen aan het concept internet. Dat er ook niet-betalende gebruikers zijn die hun producten gebruiken, of in elk geval kunnen benaderen.
Lol. Nu moet ik IBM wel wat meer credits geven dan dat. Ik weet het, makkelijk afgeven op een forum. Maar IBM heeft zich redelijk bewezen en ik weet uit ervaring dat er niet de eerste de beste rondlopen.
Dit idd. Ja het valt buiten onze richtlijnen dus doen we er niets mee.
Of de 'Alleen als je onder contract/gelieerd bent bij ons' of een klant van minimaal 6 maanden.

Ik weet niet of ik in het laatste geval uberhaupt voor 6 maanden klant zou blijven als een dergelijk veiligheidsrisico maar niet serieus wordt genomen als ik deze in de periode daarvoor zou hebben gemeld...

Het zal wel weer eens een kosten/baten kwestie zijn. Imagoschade is niet aan de orde als het nog allemaal onder de pet blijft. Nu is 'the cat out of the bag' en dan is het imago ineens een stuk belangrijker.

'Bedrijf met de pet' is dat over een week allemaal al weer vergeten en zal zich er totaal niet druk over maken. Als ze er uberhaupt van op de hoogte zijn / worden gesteld.
Het is meervoudig. Credits voor de onderzoeker en IBM alsnog dwingen er iets mee te doen. Iedereen kan nu alle ins en outs lezen over dit lek en kwaadwillenden kunnen het dus ook gebruiken nu.
Volgensmij ligt het anders, en gaat het om het 'programma' waar men deze disclosures kan melden (met waarschijnlijk een geldelijke beloning), en omdat deze onderzoeken niet voldoet aan wie daar meldingen kunnen maken, valt dat dus er buiten, niet de bug zelf, maar het melden/verwerken van de bug.
Wat ik van belang vind hier:

'De aanvallen zijn alle vier niet alleen lokaal maar ook van een afstand uit te voeren, mits de IDRM op internet is aangesloten. Ribeiro zegt er wel bij dat dat vaak niet het geval is.'

Ik ga er standaard van uit dat software security flaws heeft, alles zit hier achter een VPN en firewall, met daarbij ook nog een firewall op host-niveau. Toegang tot iedere service, zelfs https, gaat alleen op een need to have basis. Ik verbaas me dat er blijkbaar systemen (IRDM) zijn die vanaf het internet bereikbaar zijn...

edit; toevoeging (IRDM)

[Reactie gewijzigd door paradoXical op 22 juli 2024 23:33]

De gedachte dat alles wat van internet komt gevaarlijk is, maar alles wat intern zit veilig is, is ook echt niet meer van deze tijd.
Dat eerste is meer waar dan ooit :D Intern is leuk, maar 9 vd 10x ook gekoppeld via-via en daarmee ook vatbaar.
Ik verbaas me dat er blijkbaar systemen zijn die vanaf het internet bereikbaar zijn...
Daar verbaas ik mij dan weer over.
Tja de grote vraag is of je dan ook uitgaand verkeer whitelist, of dat je dat alleen blacklist.
Want de meeste bedrijven doen alleen inkomend verkeer whitelisten.

Waardoor je alsnog zo lek als een mandje bent met dit soort gevallen, aangezien de software gewoon intern staat en naar buiten kan communiceren en antwoorden terug kan ontvangen.

En tja, dat jij je verbaast dat T.net vanaf het internet te bereiken is, tja dat is jouw verbazing, ik begrijp het wel...
Uitgaand verkeer bedoel je. Ingaand verkeer vertrouwen is nooit goed.
Ik reageer hier op het feit dat IDRM systemen vanaf het internet bereikbaar zijn. Jij weet zelf ook wel dat ik daar geen publiek webservertje mee bedoel...
Out of Scope ?

Misschien klopt je scope dan niet voor bepaalde gevallen.
Zeker als het om een "security product" gaat.

Bijzonder.
Ze zullen vast naar impact en severity gekeken hebben en daarbij tot deze conclusie zijn gekomen. Dat jouw mening (en die van vele anderen) anders is, no offence, maar daar doet IBM niks mee.
En waarom doen ze er dan na media-aandacht wél wat mee? Als het werkelijk geen grote impact had, dan hadden ze ballen moeten hebben en moeten zeggen "media-aandacht of niet, we blijven bij onze conclusie".
Omdat de publicatie ze er nu toe dwingt, wat het doel was van de onderzoeker.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:33]

Als er na publicatie opeens wel impact was, dan kan het natuurlijk niet zijn dat ervoor geen impact was he...

Als de impact groot genoeg is om het nu wel te fixen was het hiervoor ook risicovol, want als iemand met een zwart hoedje op achter deze zero-days komt gaat hij niet eerst langs IBM, maar via TOR de zwarte markt op. Bij IBM hebben ze een security groep die dit zal moeten weten, maar waarschijnlijk is het niet eens bij hun terecht gekomen... #BigBusinessBigManagement
De impact voor IBM is niet anders, maar doordat de info die nodig is om het lek actief te kunnen misbruiken op straat ligt, moet IBM het nu wel dichten. De impact van het probleem zelf veranderd niet, maar het gemak waarop het te misbruiken is wel.

De deur stond op barsten, de beveiligingsonderzoeker heeft nu de deur stuk gemaakt, waardoor nu iedereen die wil naar binnen kan.

EDIT:
Geldt ook voor @tweaknico

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:33]

Ik mag hopen dat het publiek zijn van de info mee wordt genomen in de impact analyse van een probleem, anders hebben al die bug-programma's natuurlijk geen zin.
Wat als iemand van de bug weet (hoe weet IBM dat dan, als ze op de zwarte markt komen kan het jaren duren voor het aan het licht komt) buiten de onderzoeker om? De impact is en blijft hiermee altijd hetzelfde, ander hou je, zoals @tweaknico zegt, "security by obscurity" wat de meest zwakke leidraad is voor een bedrijf als IBM.

Laat ik het herformuleren in een vraag: waarom zou de impact van een bug veranderen als de info publiek zou worden, ook al ben je bewust dat deze info misschien allang op straat ligt (immer zero-day, zijn niet nieuw...)

edit: n moet r zijn :)

[Reactie gewijzigd door svsoke op 22 juli 2024 23:33]

De impact van het probleem veranderd niet, het probleem an sich veranderd immers niet. Ook een zero day hoeft immers niet direct op straat te komen. Een zero day houdt in dat de bug van begin af aan al in het systeem zit, zover ik altijd begrepen heb.

De context van het probleem is echter wel veranderd, doordat de beveiligingsonderzoeker (oftewel een hacker, maar is maar net welke naam je er aan hangt) het probleem publiekelijk uit de doeken doet, waardoor het risico op kwaadwillend misbruik groter geworden is. En daardoor heeft IBM besloten het alsnog op te pakken. Als IBM het alsnog zou laten voor wat het is, zou het inderdaad security through obscurity zijn en dat is (hoe dan ook) uit den boze.

Volgens mij zitten we dus wel redeijk op 1 lijn, maar leggen het anders uit.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:33]

Ik had al zo'n vermoeden, security land zit zo vol met "bekijk het vanuit dit perspectief" gevallen waar perspectieven net een beetje verschillen, praat nogal snel over hetzelfde zonder dat je t weet.
Ik denk dat de veronderstelling, er is maar een (1) persoon die het gemeld heeft dus het is nog niet erg bekend ==> "risico is laag" een verkeerde inschatting is.

De kern moet zijn hoe makkelijk is het te misbruiken en hoe groot kan de buit worden.
Bij een beveiligins pakket kan de buit bij falen formidabel groot worden. (ongeacht hoeveel mensen het ontdekken).
0 = nog niet ontdekt,
1 = het is ontdekt.
2 = het is vaker ontdekt.
(van 0-> 1 is een oneindige groei, van 1-> 2 is slechts 100% groei, 2-> 3 is slechts 50% groei etc.).

Er van uitgaan dat slechts 1 van de 7*10^9. mensen het gat ontdekt heeft is naief. Het is/zijn er Minimaal 1... er zijn er ook een aantal die het niet publiceren (meest gunstige geval), of op de zwarte mark publiceren (ouch), of aan toko's als Hacking-team of zo verkopen.

(herformulering)

[Reactie gewijzigd door tweaknico op 22 juli 2024 23:33]

Ik denk dat de veronderstelling, er is maar een (1) persoon die het gemeld heeft dus het is nog niet erg bekend ==> "risico is laag" een verkeerde inschatting is.
Dat is ook verkeerd. Als de enige onderbouwing is 'dat slechts 1 iemand het gemeld heeft' een sterke onderbouwing is bij de impact analyse gaat er wel meer niet goed, eigenlijk. Ik ga er daarom ook wel vanuit dat dit alleen niet het enige is in de analyse die IBM uitgevoerd heeft, maar dat blijft enkel gissen; ik werk niet bij IBM en weet ook de specifics niet.
De kern moet zijn hoe makkelijk is het te misbruiken en hoe groot kan de buit worden.
Bij een beveiligins pakket kan de buit bij falen formidabel groot worden. (ongeacht hoeveel mensen het ontdekken).
0 = nog niet ontdekt,
1 = het is ontdekt.
2 = het is vaker ontdekt.
(van 0-> 1 is een oneindige groei, van 1-> 2 is slechts 100% groei, 2-> 3 is slechts 50% groei etc.)
Ik snap zelf heel goed wat je zegt, maar IBM heeft er nu eenmaal een ander beleid op. Doordat zij het anders behandelen, komt er ook een ander oordeel uit, dat is het enige dat ik heb willen aangeven, of dat goed of slecht is weet ik niet, ik ken de specifics er niet van. Maar velen hier lijken wel hun mening klaar te hebben en te weten hoe het wel zou moeten. Daar is op zich niets mis mee, maar daar doet IBM niets mee, zij hebben ook nog eens hun policies e.d. Waar ze nu dus ook van moeten afwijken doordat de beveiligingsonderzoeker het lek gepubliceerd heeft en iedereen die een beetje kan programmeren en/.of scripten het nu kan misbruiken. Dat maakt het potentiële gevaar opeens een heel stuk groter, waardoor IBM nu simpelweg het moet oplossen.
Daarmee concludeer je dat een bedrijf als IBM "Security by Obscurity" als leidraad moet nemen?......
Ik hoop voor IBM dat dat NIET hun leidraad is.
Het bedrijf zegt tegen ZDnet dat het de gang van zaken betreurt en dat het alsnog werkt aan een oplossing voor het probleem.

Klaarblijkelijk komt IBM onder de druk van publiciteit dus tot een andere conclusie, en gaan ze er wel wat mee doen.

no offence.
Zero Days in een product dat Data Risk Manager heet. Dat is wel een Risk.
Niet echt slim van IBM: Iemand meldt dat er security-verbeterpunten aan de IBM software zijn. Hoe ze dat meldt maakt dan helemaal niet uit, dat moet je oppakken en omarmen (maar niet dood knuffelen). Als je dat gaat negeren omdat het niet via de juiste kanalen binnen komt dan moet je de definitie van 'de juiste kanalen' aanpassen. Nu gaan anderen er mee aan de haal, elk op hun eigen manier.
Ben benieuwd hoe ze dat zien met bug die dan in redhat gevonden gaan worden...
IBM preserves Red Hat’s independence and neutrality
Voor de nieuwschierigen: IBM Closes Landmark Acquisition of Red Hat for $34 Billion

[Reactie gewijzigd door Sando op 22 juli 2024 23:33]

Hah, dit gaat iemand zijn baan kosten.
Iemand niet nog niet snapt dan IBM niet meer de 'big blue gorilla' is,
die alles naar zn hand kan zetten.
Hackers zijn toch ook altijd klanten |:(

Domme actie van IBM

Op dit item kan niet meer gereageerd worden.