Starbucks zet per ongeluk api-sleutels van interne systemen op GitHub

Ontwikkelaars van de Starbucks-applicaties hebben per ongeluk api-sleutels op GitHub gezet. Aanvallers konden daarmee in potentie toegang krijgen tot interne systemen van het bedrijf. Er zijn geen aanwijzingen dat dat daadwerkelijk is gebeurd.

Het lek werd gevonden in een publieke GitHub-repository. Een beveiligingsonderzoeker vond de api-sleutels. Hij bracht Starbucks daarvan op de hoogte via het responsible disclosure-programma op HackerOne. De api-sleutels werden gebruikt voor toegang tot JumpCloud. Dat is een Active Directory-platform dat Starbucks intern gebruikt voor onder andere gebruikersrollen en toegangscontrole via single sign-on. Met de sleutels was het dus mogelijk nieuwe rollen toe te kennen aan gebruikers, en in te loggen in het systeem. Ook was het mogelijk Starbucks' Amazon Web Services-account over te nemen.

Starbucks gaf het lek een hoge prioriteit en dichtte dat binnen drie weken. De onderzoeker kreeg 4000 dollar als beloning, het maximale bedrag dat het bedrijf uitkeert voor bug bounties. Naast het aanwijzen van het lek liet hij ook een proof-of-concept zien waarin hij aantoonde hoe het lek kon worden uitgebuit.

Reacties (75)

[Quilt]

Binnen de drie weken?
Ik vermoed dat het toch wel sneller is gegaan.
Even een key revoken of refreshen is minder dan 5 minuten.

Misschien heeft het nog drie weken op GitHub gestaan?

[Keypunchie]

Het revoken is 5 minuten, maar de distributie van de nieuwe keys in alle applicaties/systemen die er gebruik van maken, zal wel iets langer zijn geweest. Ook omdat er de kans bestond dat sommigen dat via die Github deden (lekker makkelijk, toch ;-) )

Bij een organisatie met de omvang van Starbucks zal zelfs een 'emergency security change' van deze aard door een CAB heen moeten.

Vooral belangrijk om je te vergewissen dat het oplossen van het lek niet erger is dan het probleem dat het creeert. Wel neem ik aan dat een workaround (bvb. intrekken mogelijhkheid om nieuwe gebruikers te maken, of rechten van anderen aan te passen voor het account) zo snel mogelijk in plaats is gebracht.

Mijn volledig natte-vinger schatting:
Een dag of twee om te snappen wat het lek en de impact was en dit bij de juiste mensen kenbaar te maken dat het ook echt een probleem was.
Een 'paniek'dag om mitigaties/workarounds aan te brengen
Twee dagen om een permanente oplossing te verzinnen en door te spreken
Dan een week tot twee weken voor de voorbereiding en implementatie van de 'fix' en nieuwe keys.

[edit]
Als ik de link volg, zie ik ook iets dat bovenstaande ondersteund:
17 oktober: melding
21 oktober: melder valt op dat de key revoked is/repository onzichtbaar. Vraagt om update, maar krijgt te horen dat het nog 'in progress is'
28 oktober: Starbucks meldt "we zijn nog aan het valideren"
4 november: Starbucks meld: "we zijn blij met onze oplossing en we geven je een bug-bounty"

Kortom, binnen 4 dagen is er al iets aan gedaan, maar pas 2 weken later wordt het sein veilig gegeven.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 13:39]

[n00bs]

Ehm, kans op datalekken... ik neem aan dat de 1e dag, juist naast een analyse en doorspitten van logs, ook meteen de keys invalid worden gemaakt, eventueel systemen vanaf buiten tijdelijk niet toegankelijk maken.

[Yggdrasil]

De keys die gepubliceerd zijn kun je niet meer vertrouwen. Deze drie weken omvat waarschijnlijk naast het wijzigen van alle keys (dat je overigens niet altijd "in minder dan 5 minuten" doet, afhankelijk van de key) ook het auditen van mogelijk misbruik en hopelijk ook het onderzoeken van de reden van het lek en het bijwerken van interne procedures om herhaling te voorkomen.

[Marientjuh]

Er moet een oplossing ontwikkelt worden om die keys niet meer in je source code te hebben. Dan moet doorgetest worden of de single sign on oplossing nog naar behoren werkt. Daar kan in een groter team wat tijd over heen gaan.

[HitDyl]

Daar heb je secret managers voor icm ENV vars. Die ze waarschijnlijk ook gebruiken. Dit moet haast wel per ongeluk gepushed zijn nadat een developer het lokaal voor test doeleinden heeft aangepast. Er zijn normaliter wel protocollen om dit alsnog te voorkomen. Streng beleid omtrent het gebruik van productie api keys op development machines en een streng code review beleid met meerdere reviewers.

[StefanJanssen]

En dat is een van de redenen dat ik zelf die dingen nooit wil hebben. Mocht het nodig zijn dan maak ik een kopie van m'n lokale repo folder en verwijder de remote. Dan kun je doen wat je wilt en daarna je changes overzetten.

[supersnathan94]

En precies dit is dan ook de reden dat dingen als docker/kubernetes secrets zo handig zijn. Kan je nooit in je repo krijgen.

[BCC]

Dat maakt natuurlijk niets uit. Ik heb genoeg docker Images gezien met hardcoded api keys er in. Bijvoorbeeld in de dockerfile 🤔

[supersnathan94]

Dat maakt wel degelijk uit. Want als je die had gebruikt had je geen api keys in de dockerfile hoeven zetten. Docker en kubernetes injecteren secrets als environment variabelen in de container. Als je daar dus in kan kun je ze dus uitlezen. Echter is dat op zo’n moment al niet je eerste concern want je hele infra is dan kennelijk al zo lek als een mandje.

[eborn]

Dat iets kan wil niet zeggen dat het ook gebeurt. Uiteideljk voorkom je dit soort zaken enkel door code reviews.

[Verwijderd]

Die is er ook, kappen met wachtwoorden en keys hardcoden in je scripts/code. Er zijn overigens tools zoals Gittyleaks en Git Secrets die automatische scans of op basis van patterns kunnen doen, zodat je commit/merge wordt afgekapt.

[CH4OS]

Even snel enkel vervangen van de key(s) zou ervoor hebben gezorgd dat de nieuwe key(s) óók in de github van Starbucks zou(den) verschijnen, dus vervangen alleen is niet echt een oplossing.

[supersnathan94]

In principe staat die key voor altijd op Github. De hele history blijft bewaard tenzij het een branch is geweest die nu dus verwijderd is zonder merge. Dan zou je die commits nog kunnen prunen.

[GLaDTheresCake]

Netjes disclosed, netjes opgepakt, netjes betaald. Een keer een goed security verhaal horen met een happy ending is mooi, hoop dat meer bedrijven in de toekomst zo blijven reageren, dit is wel de juiste insteek.

[Aristos]

Maar is 4.000 euro niet een beetje weinig? Ik zit helemaal niet in de beveiliging, maar het overnemen van een hoop interne systemen is je toch wel meer dan 4k waard?

[JorzoR]

Maar is 4.000 euro niet een beetje weinig? Ik zit helemaal niet in de beveiliging, maar het overnemen van een hoop interne systemen is je toch wel meer dan 4k waard?

Dat ligt er maar net aan hoe dat bedrag bepaald wordt.

Als je puur naar de complexiteit van het vinden van dit probleem kijkt was het helemaal niet zo ingewikkeld. Want het was "slechts" een API key die in te zien was. Vrijwel iedere developer snapt dit en daar hoef je geen security expert voor te zijn.

Er zijn zelfs tools die Github repo's scannen voor API keys, secrets of wachtwoorden. Dus ik kan mij voorstellen dat het vrijwel geen tijd heeft gekost om er achter te komen.

4.000 vind ik persoonlijk wel netjes, is toch een mooi maand salaris voor vrijwel geen werk.

[Reactie gewijzigd door JorzoR op 22 juli 2024 13:39]

[RJG-223]

4.000 vind ik persoonlijk wel netjes, is toch een mooi maand salaris voor vrijwel geen werk

Dat lijkt me een beetje kort door de bocht. Natuurlijk: het zien van die keys en het bedenken van de consequenties is in twee seconden gebeurd. Reken dan nog een uurtje, misschien twee, voor het lezen van de voorwaarden, het maken van een rapport, en het opsturen naar het juiste adres. Maar dat betekent niet dat je voor die een of twee uur werk $ 4000,- krijgt. Zo'n onderzoeker is misschien wel fulltime bezig met security-onderzoek, en af en toe vindt ie iets. De beloning daarvoor moet dan óók compenseren voor alle andere dagen dat ie wel werkt, maar niets vindt.

Er zijn heel veel beroepsgroepen die af en toe een grote betaling krijgen voor een kortdurende prestatie, terwijl ze die prestatie alleen kunnen leveren door heel veel tijd te werken/investeren, zonder daarvoor betaald te worden.

[JorzoR]

Maar dat betekent niet dat je voor die een of twee uur werk $ 4000,- krijgt. Zo'n onderzoeker is misschien wel fulltime bezig met security-onderzoek, en af en toe vindt ie iets.

Ik snap dat het waardevol is dat iemand iets in korte tijd kan doen, vaak kan dat alleen omdat diegene dus voorafgaand al jaren werk heeft gestoken om dat dus te kunnen doen. Dus je kan niet alleen puur naar uren vs. beloning kijken. Maar neemt niet weg dat 4.000 dollar voor zoiets relatief makkelijks, een mooi bedrag is.

Er zijn heel veel beroepsgroepen die af en toe een grote betaling krijgen voor een kortdurende prestatie, terwijl ze die prestatie alleen kunnen leveren door heel veel tijd te werken/investeren, zonder daarvoor betaald te worden.

Exact mijn punt inderdaad

De beloning daarvoor moet dan óók compenseren voor alle andere dagen dat ie wel werkt, maar niets vindt.

Dit argument slaat nergens op. Waarom zou een Starbucks zijn (mogelijke) gefaalde pogingen moeten compenseren? 1, je weet niet of dat werkelijk zo is. 2, dat is het risico van het vak. Je werkt voor jezelf in deze context, dus je bent ondernemer, dus je loopt bepaalde risico's. Dat is er 1 van, dat je meer werk doet dan geld wat je ervoor terug krijgt. Daar tegenover staat ook het tegenovergestelde, dus het balanceert elkaar wel uit. Als dat niet zo is, dan doe je wat verkeerd.

(ben trouwens zelf zzp'er in deze branche)

[Reactie gewijzigd door JorzoR op 22 juli 2024 13:39]

[RJG-223]

Dit argument slaat nergens op. Waarom zou een Starbucks zijn (mogelijke) gefaalde pogingen moeten compenseren? 1, je weet niet of dat werkelijk zo is. 2, dat is het risico van het vak. Je werkt voor jezelf in deze context, dus je bent ondernemer, dus je loopt bepaalde risico's. Dat is er 1 van, dat je meer werk doet dan geld wat je ervoor terug krijgt. Daar tegenover staat ook het tegenovergestelde, dus het balanceert elkaar wel uit. Als dat niet zo is, dan doe je wat verkeerd.

Dat argument is wel degelijk relevant. De beloning moet ook in verhouding staan tot de moeite die het kost om de beloning op te strijken. Als iemand die er z'n werk van maakt in een jaar bijv. 12 bugs kan vinden, dan zullen die gemiddeld elk minstens een maandloon op moeten leveren. Anders kan, en zal, die persoon ander werk zoeken waarmee die wél een belegde boterham kan verdienen. Starbucks hoeft dus niet letterlijk de gefaalde pogingen te compenseren, maar als ze naar verhouding te weinig betalen voor de moeite die het kost om iets te vinden, dan gaat niemand moeite voor ze doen. En onder al die 'moeite' vallen ook alle gefaalde pogingen.

Nu neem ik aan dat iemand per jaar méér dan 12 security bugs kan vinden, maar waarschijnlijk leveren de meesten per stuk ook veel minder op dan 4000,-

[JorzoR]

De beloning moet ook in verhouding staan tot de moeite die het kost om de beloning op te strijken.

Starbucks hoeft dus niet letterlijk de gefaalde pogingen te compenseren, maar als ze naar verhouding te weinig betalen voor de moeite die het kost om iets te vinden, dan gaat niemand moeite voor ze doen. En onder al die 'moeite' vallen ook alle gefaalde pogingen.

Het moet inderdaad wel rendabel zijn. Maar 4.000 dollar voor iets wat je mákkelijk binnen 1-2 uur kan aankaarten bij ze, is behoorlijk rendabel.

Verder is het allemaal vrijwillig en zelfstandig. Starbucks is niet de werkgever van jou in dit geval, dus ze hoeven er helemaal niet voor te zorgen dat jij er genoeg boterhammen mee verdient. Dat is aan jou, en dat is ook het leuke van ondernemen.

Dat iemand dan 12 van dat soort issues nodig heeft om z'n boterham te verdienen op jaarbasis, is toch echt zijn probleem, niet dat van Starbucks. Als de opbrengsten van hun bug bounty programma te weinig zijn, komt daar natuurlijk ook een bepaald kwaliteit mensen op af. Hoe meer je betaald, hoe meer "experts" er naar gaan kijken. Je ziet hier dus ook gewoon een stukje marktwerking.

Tevens heeft Starbucks de "power van de crowd". Er is dus vrijwel altijd iemand die een bug/security issue wilt aankaarten in de ruil voor geld.

[Reactie gewijzigd door JorzoR op 22 juli 2024 13:39]

[supersnathan94]

Maar om even heel cru te zijn. Hoe is dat starbucks zijn probleem?

Dit is natuurlijk niet handig van ze en $4k is dan leuk leergeld. Voor een externe partij (ZZP-er) is dat ongeveer een week aan uren.

[JorzoR]

Maar om even heel cru te zijn. Hoe is dat starbucks zijn probleem?

Ik snap je niet helemaal. Waar reageer je precies op?

[supersnathan94]

Eigenlijk meer een reactie op dit:

De beloning daarvoor moet dan óók compenseren voor alle andere dagen dat ie wel werkt, maar niets vindt.

En een aanvulling op jouw laatste alinea.

[TheVivaldi]

Het is inderdaad maar net hoe je het bekijkt. Voor mij persoonlijk zou 4 ruggen een hoop zijn. Ik zit wel in een andere branche dan IT-*security*, maar toch: ik moet 3-4 maanden werken voordat ik dat verdiend heb.

[SmileyFace]

Starbucks is, in zeker zin, niet afhankelijk van zijn computersystemen. Hun belangrijkste vorm van omzet is koffie verkopen op locatie. Daar hebben ze hun systemen verder niet heel erg bij nodig. Ik denk dat als zoiets bij een Google of Facebook zou gebeuren, waar hun bestaan afhankelijk is van hun systemen, dat de bounty ook wel een heel stuk hoger had gelegen.

[Providentia]

Ik kwam onlangs bij een McDonalds die mij geen kop koffie konden geven omdat hun interne systeem eruit lag. Ik kan je verzekeren dat dit zeer grote consequenties zou kunnen hebben gehad. Denk aan inventory management, personeel inroosteren, algemene administratie, financiële administratie etc. Als zo'n systeem er landelijk (wereldwijd?) uit zou komen te liggen dan denk ik dat dit zomaar een erg duur geintje had kunnen worden.

[SmileyFace]

Je mist het punt wat ik maak. Het enige wat ik zeg is dat ze in principe gewoon nog geld kunnen verdienen zonder dat ze de systemen nodig hebben. Dat ze mensen niet kunnen inroosteren of extra voorraad bestellen etc. is niet belangrijk op dat moment. Dat ze geld blijven verdienen wel. Én daarom is het bedrag lager dan wat we zien van de grote internetbedrijven. Dit is vooral mijn punt niet dat ze die systemen niet nodig hebben dat is totaal niet wat ik heb gezegd.

[Reactie gewijzigd door SmileyFace op 22 juli 2024 13:39]

[supersnathan94]

Dat is eerder luiheid van het personeel dan daadwerkelijk beleid en technisch er toe in staat zijn.

Het is niet zo dat de wereld stopt als het internet niet werkt. Hoe denk je dat men dit vroeger deed?

Het koffiezetapparaat werkt ook gewoon nog hoor. Het kost alleen wat meer moeite. En dat vonden ze het waarschijnlijk niet waard voor een kop koffie.

[K-aroq]

Al die problemen die je noemt worden pas een probleem als een systeem echt lang niet beschikbaar is.

Inventory management: een simpel backup proces bestaat uit het doorbellen van wat je nodig hebt aan het distributiecentrum. Ja, je zult minder optimaal voorraadbeheer doen, maar je hoeft de boel niet te sluiten. De winst zal wat minder worden, maar dat is altijd beter dan "nee" verkopen.

Personeel inroosteren: bellen met je personeel en een offline excel of tekstbestandje bijhouden. Dan kan je later invoeren in het administratiesysteem

Algemene en financieele administratie: offline bijhouden en reconciliatie doen als het allemaall weer werk.

Het is allemaal niet perfect, maar het leven is ook niet perfect. Maar alles is beter dan dat je klant naar Burger King gaat.

[Providentia]

Ik ben het volledig met je eens. Het is zeker te doen. De vraag is alleen of het personeel capabel genoeg is om het ook uit te voeren. Ik durf het te betwijfelen.

Alleen al het zelfstandig moeten berekenen (al dan niet met een rekenmachine) van de prijs van een bestelling is al een hele opgave voor sommige mensen.

Ik denk dat het voorbeeld wat ik eerder noemde een goede aanwijzing is. Op dat moment was er schijbaar geen capabel personeel, althans, de beslissing die genomen werd was dat het beter was om de toko te sluiten in plaats van het handmatig te doen.

[PcDealer]

En de pos-systemen dan? Misschien worden die ook verbonden met de AD. Ik weet niet of ze cash betalingen accepteren.

[SmileyFace]

In principe kan je op pin automaten gewoon een bedrag invoeren zonder dat je deze aanslaat op hun pos systeem. Ik neem aan dat ze een aparte payment provider hebben zodat hun pin systemen wel gewoon werken als pos-systeem wegvalt. Cash is idd ook een optie en vaak wordt deze dan ook geaccepteerd.

Maar het punt wat ik dus probeer te maken is is dat als ze een beetje hebben nagedacht over hun systemen dan zouden ze gewoon nog geld kunnen verdienen ook als hun kassa systeem wegvalt. Dit is anders bij internetbedrijven die afhankelijk zijn van deze systemen om geld te verdienen.

[supersnathan94]

Cash betalingen moet je accepteren. Bedrijven die zeggen van niet zijn onwettig bezig.

[K-aroq]

Onzin:

https://www.rijksoverheid.nl/onderwerpen/geldzaken/vraag-en-antwoord/kan-ik-met-een-wettig-betaalmiddel-overal-betalen

[gimbal]

Maar toch staat de politie niet bij ze voor de deur of krijgen ze bekeuringen opgelegd, het wordt gedoogd. Met name in de horeca zie ik steeds vaker "card only". Het gaat zelfs zo ver dat men pinautomaten gaat aanpassen om een fooi te kunnen geven waardoor het niet meer mogelijk is om contactloos te betalen...

"Onwettig bezig zijn" vind ik tegenwoordig redelijk flexibel interpreteerbaar; er is de wet en er is waar men mee weg kan komen om te kunnen overleven in een snel veranderende en digitaliserende samenleving. Ik snap card only prima. Geen geld aanwezig in het pand, geen overvallen/diefstal/gestuntel van personeel wat niet eens meer kan hoofdrekenen. Alles traceerbaar, alles extern, geen verantwoordelijkheden, alles automatisch.

En doffe ellende als er een langdurende storing is.

[TheVivaldi]

Plus het is helemaal niet onwettig volgens de overheid zelf: nieuws: Starbucks zet per ongeluk api-sleutels van interne systemen op GitHub

[MicGlou]

Je kan als bedrijf helemaal niets als je systemen plat liggen; geen betalingen, geen bestellingen en ga zo maar door. Zelfs de groenteboer op de hoek kan vrijwel niets meer als zijn systeem platligt... ieder bedrijf, hoe klein ook, zal vrijwel volledig stil liggen op het moment dat de systemen niet werken... er zullen uiteraard uitzonderingen zijn van bedrijfjes die zaken nog heel ouderwets doen of eventueel een bepaalde tijd kunnen overbruggen, maar als je meedoet in de huidige economie moet het gewoon werken anders kan je niets.

[SmileyFace]

Als we kijken naar bijvoorbeeld subway waarbij ze ook nog wel eens een storing hebben van hun systemen. Zij kunnen dat gewoon een bedrag invoeren op hun pin-systeem zonder dat ze ook maar iets op hun pos-systeem aanslaan. Zo doen ze gewoon nog verkopen en kunnen ze gewoon nog geld verdienen zonder dat ook maar een van hun eigen systemen het nog doet.

[MicGlou]

En als dat pin-systeem dan niet werkt? Ook dat is onderdeel van hun systemen voor bedrijfsvoering... En dan nog heb je het zoals ik al heb genoemd over een tijdelijke workaround, als dat dagen duurt dan komen de problemen vanzelf.

[Keypunchie]

Je pinsysteem is hopelijk niet afhankelijk van je web services, dan heb je iets wel heel fout gedaan.

De pin is van een extern bedrijf, je bankrekening doet het ook nog gewoon.

Wat je wel kwijtraakt is zaken als geautomatiseerd voorraadbeheer en je zult de administratie handmatig moeten doen.

Maar als het een beetje netjes geregeld is, dan kan het internet eruit liggen en buffert een kassasysteem gewoon zaken een tijdje lokaal.

Worden geen streepjescodes bijgewerkt en dat soort zaken, maar kan je wel een dag gewoon je omzet blijven draaien.

[SmileyFace]

Ik zie dat iedereen mijn reactie gewoon niet goed leest dus dit zijn de laatste woorden die ik eraan vuil maak.

Mijn punt is dat het een bedrijf is wat goederen verkoopt, niet internet diensten. Degene die zegt "4000 is laag" vergelijkt dit denk ik met de tienduizenden/honderdduizenden die een intenetbedrijf voor dit soort dingen geeft. Dit is een oneerlijke vergelijking in mijn mening want ze hebben de systemen niet persé nodig om geld te verdienen. Ook als dit dagen duurt kunnen ze gewoon contant gaan accepteren en een nood payment provider gaan accepteren. Voor voorraad zetten ze gewoon een noodpagina op waarbij elk filiaal op kan geven wat ze allemaal nodig hebben.

Voor alles is een workaround een bedrijf wat producten verkoopt. Voor een intenetbedrijf wat diensten verkoopt of serverruimte niet echt. Ze kunnen letterlijk niet meer door met hun bedrijfsvoering en moeten eerst de problemen oplossen. Daarom zijn de bountys bij dit soort bedrijven hoger dan de 4000 die Starbucks hiervoor geeft

[Dennisdn]

Ik theorie kunnen ze prima koffie zetten en even met contant geld werken. Maar om dat áchteraf van álle locaties allemaal weer recht te moeten zetten + alle tel- en steel-risico’s is het een hele simpele rekensom om de deur dicht te doen, hoe vervelend ook voor de klant.

[zx9r_mario]

Al die hipsters zullen waarschijnlijk met Apple Pay betalen

[mike123]

Ze zijn er niet afhankelijk van maar voordat de machine voor de allereerste keer word aangezet moet deze volgens de Starbucks regels al aan het internet hangen.
Ze willen alles monitoren wat er met het apparaat gebeurd.
Dit heb ik gehoord van monteurs die deze machines plaatsen en onderhouden.
Machines geven online ook hun eigen storingen automatisch door.

[Melkunie]

Ben ik het in principe wel mee eens, maar uit het artikel maak ik op dat Starbucks een actief bugbountyprogramma waarin alle voorwaarden en beloningen in beschreven staan. Dan is er niet echt een reden om hier ineens van af te gaan wijken.

[CH4OS]

Ik vond het juist raar dat Starbucks hun limiet betaalde hiervoor, maar goed, we kennen de exacte details niet, dus inschatten of dit (te) veel of (te) weinig is, is lastig.

[segil]

is drie weken niet heel erg lang om die informatie weg te halen van Github? Of zou toegang tot deze repo noodzakelijk zijn en het blokkeren leiden tot serieuze problemen?

[m3gA]

Waarschijnlijk zul je ook een audit moeten doen of de keys misbruikt zijn etc.

[Blokker_1999]

Je kan geen informatie weghalen uit je git repo en zelfs als het kan, dan is dat niet de juiste oplossing. Je wil niet met het risico blijven zitten dat mensen die keys gezien en opgeslagen hebben. Je moet de keys wijzigen. Dat kan relatief snel, maar je moet intern ook een hoop procedures doorlopen en dat kan enkele weken duren voordat je alles kan markeren als gedaan.

[Luminai]

Het zijn sleutels van interne systemen. Zou goed kunnen dat deze systemen niet extern benaderbaar zijn wat het risico aanzienlijk verlaagt.

[RVervuurt]

Er konden nieuwe rollen gegeven worden aan gebruikers en er was zelfs toegang mogelijk tot de AWS die ze gebruiken, dus wat je zegt gaat niet helemaal op.

[CH4OS]

Met code dat nodig is voor aansturing erbij online... Er moet dus _iets_ geweest zijn dat wel degelijk van buitenaf nodig was, anders stond het niet in de repository.

[UPPERKEES]

git-secrets kan hierbij helpen om dit te voorkomen. Behalve dan voor AD stuff, daar zie ik geen support voor.

[Reactie gewijzigd door UPPERKEES op 22 juli 2024 13:39]

[latka]

Is de echte oplossing niet om gewoon geen omgevingsvariabelen in versiebeheer te hebben en developers geen toegang tot productie te geven? Je ziet dit soort fouten een paar keer per jaar voorbij komen en ze zijn triviaal te voorkomen door sourcecode en configuratie strikt te scheiden.

[UPPERKEES]

Absoluut, maar dit kan ook geen kwaad als extra safe guard.

[latka]

Niet in de cloud zetten is ook een extra safeguard. Het probleem voorkomen is altijd beter.

[hackerhater]

Heel veel omgevingen hebben support voor .env-bestanden en die zijn dan ook ten zeerste aan te raden om te gebruiken.
En dan je .env bestand in de gitignore zetten. Dan moet je het bestand echt forceren voor ie opgenomen wordt in de repository.

[latka]

En nog beter: de developer alleen accounts voor development systemen geven. De .env voor productie door beheer laten beheren en niet in github zetten (maar een intern versioning systeem, kan wel git zijn, maar unencrpypted prod. ww. in de cloud zetten is nooit slim).

[Auredium]

Een menselijke fout die wat goed wordt opgevangen en opgelost zoals het hoort. Ik had eventueel nog graag de naam van de onderzoeker in kwestie in het artikel gezien, nu moeten wij deze via andere bronnen achterhalen. (niet echt een issue, meer een opmerking).
Het bedrag van 4000 euro is natuurlijk maar een schijntje maar je mag er vanuit gaan dat de onderzoeker in kwestie zich bewust was van deze maximale bounty. Door de juiste procedure te volgen heeft de onderzoeker wel aangetoond betrouwbaar te werk te gaan in mijn ogen.

De naam van de onderzoeker is overigens Vinoth Kumar voor de mensen die niet willen of kunnen doorklikken naar de originele disclosure.

[Reactie gewijzigd door Auredium op 22 juli 2024 13:39]

[Keypunchie]

Schijntje ten opzichte van de mogelijke schade, maar aan de andere kant is het wel een stevig maandsalaris. Ik vind het niet kinderachtig, in ieder geval.

[RJG-223]

Schijntje ten opzichte van de mogelijke schade, maar aan de andere kant is het wel een stevig maandsalaris. Ik vind het niet kinderachtig, in ieder geval.

Kun jij mij vertellen hoeveel maanden deze onderzoeker heeft moeten werken (dwz: zoeken naar security bugs in allerlei software) zonder iets te vinden, en dus zonder betaald te worden ?

$4000,- is een leuk bedrag, en goed betaald als je toevallig op de kwetsbaarheid stuit (alhoewel je waarschijnlijk veel meer kunt krijgen als je hem op de zwarte markt verkoopt :-). Als je er echter je werk van maakt, dan is $4000,- misschien wel aan de weinige kant...

Natuurlijk weet ik ook niet of deze onderzoeker er toevallig tegen aan liep, of dat ie er zijn werk van gemaakt heeft.

[supersnathan94]

Het vinden van dit soort keys is een fluitje van een cent. Daar zijn zelfs webservices voor die dit op de seconde scannen. Het daadwerkelijke werk komt daarna.

[Reactie gewijzigd door supersnathan94 op 22 juli 2024 13:39]

[Keypunchie]

Tsja, als je een koffer met 10.000 euro vindt en die zelf houdt, dan heb je ook meer dan een vindersloon. Het is wel heling.

Als je je beroep ervan maakt om koffers te vinden, dan kan het voorkomen dat je een maand lang geen koffer vindt... Om maar het punt te maken, dat je beroep ergens van maken niet betekent dat het dan de verantwoordelijhkheid is van anderen om het rendabel te maken, dat moet je helemaal zelf doen.

[RJG-223]

Als je je beroep ervan maakt om koffers te vinden, dan kan het voorkomen dat je een maand lang geen koffer vindt... Om maar het punt te maken, dat je beroep ergens van maken niet betekent dat het dan de verantwoordelijhkheid is van anderen om het rendabel te maken, dat moet je helemaal zelf doen.

Ja, maar als je er je beroep van maakt, en je vindt gemiddeld 12 koffers met geld per jaar, dan zul je gemiddeld één maandloon per koffer moeten krijgen. Anders ga je ander werk zoeken, en dan worden die verloren koffers met geld wellicht niet gevonden, of door iemand die ze niet terugbrengt. Het is dus niet de verantwoordelijkheid van anderen om het voor jou rendabel te maken, maar het is wél in hun belang om het rendabel genoeg te maken dat iemand het de moeite waard vindt om ze te gaan zoeken...

[TweakOverflow]

Starbucks gaf het lek een hoge prioriteit en dichtte dat binnen drie weken.

Een security incident waarbij het mogelijk is om aan te melden op interne systemen van Starbucks heeft gewoon een doorlooptijd van 3 weken. Ik ben niet heel bekend met GitHub, maar ik neem toch aan dat die API keys er binnen een dag vanaf gehaald is en de betreffende API keys in de resterende tijd zijn vervangen?

Persoonlijk vind ik 3 weken veel te lang voor een dusdanig incident, mag hopen dat ze er iets van geleerd hebben zodat ze het de volgende keer sneller sneller kunnen herstellen.

[Keypunchie]

3 weken tot volledige oplossing.

Dat is niet hetzelfde als 3 weken kwetsbaar.

Stel je voor ik ontdek dat op een webdienst van mij er een ernstige kwetsbaarheid zit bij uploadfunctionaliteit
Dan zal ik ws. binnen een uur (of twee) van dat ik op de hoogte ben gebracht een manier vinden om te voorkomen dat het ge-exploiteerd wordt (bvb. ik zet geheel of gedeeltelijk de uploadfunctionaliteit uit).

Maar pas daarna ga ik aan de 'echte' oplossing werken en dat kan nog wel even duren, want die fix moet ook ontwikkeld, getest en geaccepteerd/gevalideerd worden, voordat ik de boel weer open gooi. Sterker nog, misschien wacht ik na livegang zelfs nog even op terugkoppeling met de oorspronkelijke melder, voordat ik aan disclosure begin.

Kortom, wat er in die 3 weken is gebeurd, weten we niet. Alleen dat *na* die 3 weken de terugkoppeling is gekomen. (zie ook mijn eigen natte-vinger tijdlijn voor hoe zo iets kan lopen).

[edit] Als je de link volgt, dan zie je dat er binnen 4 dagen al iets van aktie is ondernomen.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 13:39]

[mocean]

Keys weghalen is vast zo gebeurd, maar ze vervangen, zonder downtime is (afhankelijk van het gebruik) nog best complex. Je moet dus een alternatief opzetten om de keys te distribueren, de keys revoken, nieuwe keys uitgeven., als je daar mee door een OTAP straat moet dan is 3 weken best oke.

[RVervuurt]

Maar waarom heeft Starbucks geen private repos?

[Blokker_1999]

Omdat ze open source willen werken. Waarom zou een bedrijf zijn code geheim moeten houden?

[RVervuurt]

Waarom zou een Starbucks app opensource moeten zijn? Het is niet zo dat je dan lekker de repo kan forken en je eigen Starbucks app op je telefoon kan zetten met wat aanpassingen, gezien je de verbinding met de database e.d. mist (waar je dus die API-keys weer voor nodig hebt).

[CH4OS]

Het is een keuze, Starbucks koos om opensource te zijn, zodat iedereen kan zien wat de code doet en wat niet. Ook kunnen anderen je dan wijzen op leaks en fouten in de code en daar eventueel verbeteringen voor doen.

Afhankelijk hoe eea opgezet is, kun je de app dan wel degelijk forken en de servers van Starbucks gebruiken.

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:39]

[StefanJanssen]

Om bijvoorbeeld beveiligingsproblemen op te sporen.

[DutchKevv]

Ik heb ook eens per ongelijk keys mee gecommit op een public GitHub repo en kreeg al vrij snel een mailtje van een bot die het ontdekte, die vroeg om een vrijwillige bijdrage voor het 'gratis melden', terecht want het klopte.

Is het niet handig als GitHub daar zelf ook een bot voor gebruikt? Al dan niet als een @action ?