Hackers stelen broncode van Okta via GitHub-repository's

In een e-mail heeft Okta klanten geïnformeerd over een incident waarbij code is gestolen van de GitHub-repository's van de loginprovider. Volgens het bedrijf is er geen klantdata gestolen en hebben hackers geen toegang gehad tot de systemen van Okta.

Okta heeft de e-mail gestuurd naar IT-beheerders van zijn klanten. De e-mail is ingezien door BleepingComputer. Okta schrijft dat GitHub begin december 2022 contact heeft opgenomen met het bedrijf om het te informeren over mogelijke ongeautoriseerde toegang tot de repository's van Okta. Het bedrijf bevestigt dat er inderdaad code is gestolen.

Het gaat volgens de loginprovider om code van de Okta Workforce Identity Cloud. Het bedrijf benadrukt dat de hackers geen toegang hadden tot de code van Auth0, dat wordt gebruikt met de Customer Identity Cloud van het bedrijf. Verder zegt een woordvoerder van Okta tegen Engadget dat 'de gestolen code geen gevolgen heeft voor de veiligheid van de producten van het bedrijf, omdat de beveiliging niet afhankelijk is van of de broncode geheim is'.

Het is de tweede keer dit jaar dat Okta doelwit is van hackers. In januari drongen hackers van de Lapsus$-groep binnen bij het securitybedrijf. De schade was toen aanzienlijk groter doordat de hackers via Okta bij twee andere bedrijven konden binnendringen. Ook hadden de hackers toegang tot de Slack- en Jira-omgeving van Okta zelf.

Reacties (77)

Waarom zou je als IT security bedrijf je code op externe servers hosten? Meeste normale software bedrijven waar ik heb gewerkt zijn er lokaal gitlab of gerrit servers waar je extern alleen met een VPN bij kan.

Ja dat. Ik begrijp dat ook nooit. Je hele IP zet je toch niet 'zomaar' ergens op een online repository? Tussen quotes, want een github (lees Microsoft) heeft vast meer budget voor security dan het gemiddelde bedrijfje, maar de attack surface is ook weer vele malen groter.
Inderdaad een lokale repository achter een VPN zou me persoonlijk een beter gevoel geven.

...een lokale repository achter een VPN zou me persoonlijk een beter gevoel geven.

Wellicht jou een beter (onderbuik) gevoel, maar in januari had men al in het Okta netwerk ingebroken, nu pas in December zijn de accounts weer gehacked van Okta bij Github. Github is niet gehacked, maar men heeft kunnen inloggen met credentials/tokens van Okta bij Github...

En ook de Autho dochter van Okta is al eerder source code kwijtgeraak vanuit hun eigen omgevingt: https://www.bleepingcompu...pos-may-have-been-stolen/

Het is nochtans niet gewoon een onderbuikgevoel: een VPN met two-factor, een afgescheiden github server in een private omgeving die rechtstreeks niet via het internet te bereiken is, tegenover een github server die open en bloot op het internet bereikbaar is voor iedereen, weliswaar ook met credentials / tokens.

Hoe je het ook draait of keert, private/VPN is een extra laag beveiliging.

Ik begrijp dat iedereen van overal aan gegevens wil kunnen zonder extra stap zoals een VPN, maar zoals je zelf reeds aanhaalt: een dom foutje, een token die gelekt is, en je hebt het vlaggen.

Hoe je het ook draait of keert, private/VPN is een extra laag beveiliging.

Die private VPN omgeving is bereikbaar via het internet. Dat het alleen VPN verbindingen zou moeten accepteren is een heel ander verhaal. Zowel de 'private' omgeving van Okta als van Autho zijn binnengedrongen, onbekend is hoe deze omgeving exact is ingericht of hoe men exact is binnengedrongen. Maar wat wel duidelijk is, is dat Github zelf NIET is gehacked. Het issue is dus absoluut niet GitHub (in dit geval), het issue is Okta, ze hebben al laten zien dat hun omgeving hackbaar is, makkelijker hackbaar dan kennelijk hun Github account...

Een eigen 'private' omgeving met VPN, MFA, etc. heeft veel meer bewegende onderdelen, die allemaal zelf beheerd moeten worden. Dit geeft meer mogelijkheden tot fouten en meer onderdelen waarin exploits misbruikt kunnen worden.

Daarnaast is 2FA of MFA niet een magisch wondermiddel, het is niet voor niets dat in februari MS alle AAD tenants forceert MFA number matching te gebruiken als standaard. En dat er hele boeken over zijn geschreven: https://www.wiley.com/en-...ntication-p-9781119650805

[Reactie gewijzigd door Cergorach op 22 december 2022 12:13]

Github staat volledig publiek. Nogmaals, je hoeft maar 1 token te lekken en men trekt alles leeg. Als die Github server achter een private VPN had gestaan, was die niet van buitenaf bereikbaar, en had men de token niet kunnen misbruiken. Men moet dan al door de VPN geraken (en als het goed is is dat het enige wat open staat) en dan moet men nog beginnen met de github server aan te vallen. Dat is mogelijk, maar het is makkelijker als er geen VPN voor staat. Als je je auto op straat zet (publiek) dan is er ook meer kans dat die gestolen wordt, tegenover dat je die in een gesloten garage zet.

En ja, MFA kan gehacked worden. Maar het is veel moeilijker.

Je eigen private omgeving geeft veel meer mogelijkheden tot fouten maken is ook een fabeltje wat vaak wordt aangehaald. Uiteraard heb je gespecialiseerd personeel nodig, maar de infrastructuur en patches beheren is eigenlijk het minste van het werk. Het echte werk kruipt in het beheren van security policies, het managen van de flow, gebruikersbeheer, etc. Dat beheer moet je evengoed in de cloud doen, en kan enorm ingewikkeld worden, zeker als je cloud services met elkaar wil laten praten. Laat dat dan ook nog iets zijn waar veel bedrijven van zeggen, ah, we hebben geen private infra meer, die dure systeembeheerder hebben we niet meer nodig, Pietje de boekhouder kent wat van PC, laat die de cloud omgeving maar beheren....

VPN is een extra (security) laag, maar voegt complexiteit toe en is ook niet feilloos. Het is een afweging tussen resources. Voor een kleine KMO zal GitHub ongetwijfeld een veel veiligere en dev-friendly omgeving zijn dan zelf een VPN op te zetten en een Git server onderhouden.

Pietje's zoon kent ook veel van computers en die zetten 15 jaar geleden de VPN hier op, zal wel tip-top werken! :-)

Overigens is zowel cloud als local infra werkt voor specialisten.

[Reactie gewijzigd door svennd op 22 december 2022 14:30]

Cergorach schreef:

het is niet voor niets dat in februari MS alle AAD tenants forceert MFA number matching te gebruiken als standaard.

Ik ben het grotendeels met je eens, ter aanvulling/info:

1) TOTP, ook met number matching, helpt niet tegen "evil proxy" phishing-aanvallen zoals afgelopen september op Github + CircleCi gebruikers.

2) Een viertal onderzoekers van de universiteit van Berkeley in Californië werken aan een publicatie getiteld "Security and Privacy Failures in Popular 2FA Apps" die al is geaccepteerd door de USENIX Security 2023 conferentie. De auteurs zijn Conor Gilsenan, Fuzail Shakir, Noura Alomar en Serge Egelman. Zij hebben 22 Android TOTP-apps aan de tand gevoeld, waaronder Google Authenticator, Microsoft Authenticator en Authy. In veel gevallen worden er géén back-ups gemaakt van de "shared secrets" (waardoor gebruikers niet meer kunnen inloggen na verlies van toegang tot hun smartphone), ofwel die belanden in een deel van de gevallen onversleuteld of zwak versleuteld op allerlei cloud-servers en deels zijn er andere privacy-issues.

Verwijzingen naar de laatste versie van die m.i. lezenswaardige publicatie, en mijn toevoeging dat TOTP niet helpt tegen "evil proxy" aanvallen, vind je in deze security.nl posting van mij.

[Reactie gewijzigd door ErikvanStraten op 22 december 2022 16:42]

Waarom niet? Het hosten van code is de core business van GitHub, je gebruikt de dienst dus exact waarvoor ie bedoelt is. Lijkt me prima. Diensten als GitHub, Atlassian (Confluence) e.d. worden heel veel gebruikt voor high-end closed source software.

Het risico op beveiligingsproblemen in professionele externe tools (bv GitHub) lijkt me niet perse hoger dan wanneer je vergelijkbare tools zelf gaat beheren. Als je een zelf een GitLab server hebt, moet je ook zorgen dat die up to date is, dat alle gebruikersrechten kloppen, dat users geen code mogen uitvoeren op andere delen van de server e.d. Dat is best complex, zeker als het verder niet je core business is.

Het risico niet hoger? Wat te denken van slimme programmeurs die code met wachtwoorden en al op Github zetten?

Aangezien dat in een private repository op Github zal gebeuren is er geen verschil met de situatie waarin dat gebeurt in een repo die je zelf host.

Ligt eraan hoe je het zelf host. Ik ken niet alle ins- en outs van configuraties van Github repositories, maar private repositories in de cloudomgeving van Github zijn denk ik wel gewoon bereikbaar vanaf alle addressen. Als je een eigen github oplossing draait op je interne netwerk en niet beschikbaar stelt naar het internet heb je in ieder geval een lagere attack surface. Dan kan je je developers via een stepping stone toegang geven tot je repository.

Maar ook hier geldt, gebruiksgemak of security..

GitHub private repositories kunnen werken op basis van IP-Whitelist. Ik moet via VPN verbinden met de repositories. Dat gaat zo ver dat we bijv. ook niet zomaar GitHub's eigen action runners kunnen gebruiken, want die IP ranges hebben we niet gewhitelist.

In het geval van GitHub Enterprise kun je ook gebruik maken van de login via Azure AD. Hieraan kun je vervolgens Conditional Access instellen waarmee je een hoop mogelijkheden hebt om toegang te beperken.

Als je wachtwoorden en ingevulde env bestanden commit val je wat mij betreft niet onder de categorie "slimme programmeur".

Waarom zou dat niet kunnen in een private repository dan?

Is dat een serieuze vraag bij dit artikel? Er was ongeauthoriseerd toegang tot de repositories van Okta, staan dan ook al je wachtwoorden dan nog eens in een env bestand heb je een groter probleem.
Security bestaat uit meerdere lagen, niet 1

Het hoeft natuurlijk niet in een publieke repository te staan. Of je je wachtwoorden in code nou in een on-prem repository of in een private repository in een SaaS dienst zet, het is beide even dom.

Als je programmeurs hebt die dat doen, heb je toch echt grotere problemen dan het wel/niet gebruiken van github IMO

Daar heb je je pipeline voor die dat meteen flaged tijdens de commit ,

Alleen al het feit dat er mensen zijn die dat doen in je organisatie geeft aan dat je een human probleem hebt en geen storage probleem.

Die zelfde persoon zal waarschijnlijk dus ook source code naar zijn prive mail sturen om het thuis te bewerken.

Bovendien heeft GitHub zelf al de mogelijkheid om hierop te gaan scannen. Dus het is aan jou als bedrijf om a) die optie aan te zetten b) te blokkeren dat die code uberhaupt op de repo komt c) je mensen degelijk op te leiden dat zulke zaken niet gebeuren.

De nadruk wordt hier gelegd bij GitHub, maar GitHub heeft hierin nul-en-generlei een fout gemaakt. Integendeel, ze hebben gemerkt dat er verdacht gedrag gaande was en dat geflagd. Moet ik nog maar zien gebeuren bij bedrijven die het allemaal zelf wel even zullen regelen.

Inderdaad, er horen geen wachtwoorden of iets dergelijks thuis in broncode! Dit is gewoonweg slecht programmeren, je werk met env variabelen of iets dergelijks en dummy accounts en wachtwoorden om iets lokaal te testen.

Het zal je verbazen maar de source van Windows staat ook op Azure :
https://dev.azure.com/mic...ase/winrt/error/error.cpp

Niet dat je erbij kan maar Microsoft heeft z'n dingen wel redelijk op orde denk ik.
Maar ik snap je punt wel, Github en Azure is wel een grote eend in die vijver die het internet heet.

Het zal je verbazen maar de source van Windows staat ook op Azure :
https://dev.azure.com/mic...ase/winrt/error/error.cpp

Verbazing, Microsoft host eigen broncode!

Een VPN oplossing met fixed IP is gewoon in te stellen met GitHub, moet je uiteraard wel de enterprise editie gebruiken.

https://docs.github.com/e...ses-for-your-organization

Inderdaad een lokale repository achter een VPN zou me persoonlijk een beter gevoel geven.

Maar of het ook veiliger is, die vraag wordt niet beantwoord door jouw gevoel.

Wij hebben inmiddels álles in de cloud zitten, juist vanwege het feit dat wij het zelf nooit zo veilig kunnen maken als dat Azure en AWS dat kunnen. Nadeel is dan wel weer dat we dankzij deze providers wel weer aantrekkelijker zijn geworden voor aanvallen, omdat deze twee vrijwel de complete markt domineren.

Bij mij op het werk is het juist het security team dat wil dat we van een git repo in onze eigen cloud omgeving gaan naar een centrale repo bij een SaaS provider.
De git in onze eigen cloud is hard afgesloten van de buitenwereld, heeft backups, heeft access logs welke worden gerepliceerd naar de security cloud en access keys zijn niet langer geldig dan een uur. En security heeft toegang om te scannen. Maar blijkbaar is dat niet genoeg, het wordt vast beter als we naar SaaS gaan

Veel bedrijven waar ik gewerkt heb gebruikten een bepaalde mate van "security by obscurity"..

Is het realistisch dat een "normaal" bedrijf de security standaarden van een bedrijf als MS kan evenaren? Er zijn zoveel aanvals-vectoren dat je echt wel van goede huize moet komen. Niet onmogelijk, wel moeilijk en kostbaar.

[Reactie gewijzigd door bille op 22 december 2022 09:32]

Juist! Want hoe kon dit gehackt worden? Niet door een kwetsbaarheid in GitHub lijkt me, want dan had de titel van het bericht anders geluid.

Zonder details weten we niet veel denk ik. Voor hetzelfde geld hebben ze iemand omgekocht of onder druk gezet om inlog credentials te delen....

5 dollar wrench ... https://xkcd.com/538/

Ha ha ha, precies

Gezien het domein waarin Okta opereert, zou ik dit als kerncompetentie bestempelen en van ze verwachten dat ze een securirty standaard van Microsoft evenaren of zelfs overtreffen.

Niet helemaal natuurlijk. Als je het hebt over de login ben ik het met je eens, dat is namelijk wat ze doen. Alleen het veilig houden van data gaat een stuk verder dan alleen de login natuurlijk, en dat stuk heeft OKTA niet zo veel mee te maken. Ze zijn een login provider, maar dat betekent niet dat ze heel veel weten van anti-malware, of het encrypten van bestanden op een publieke cloud bijv.

Er zit een factor 125 tussen de omzet van Okta en Microsoft. Dus dit is geen realistische verwachting.

Waarom zou je als bedrijf iets doen dat niet je core business is? Gewoon een dienst afnemen bij een bedrijf die wel gespecialiseerd is. Dat is volkomen normaal. Of moeten alle bedrijven ook weer zelf schoonmakers in dienst nemen, en koks voor de kantine, en zelf alle telefoons beheren, geen cloud meer gebruiken, zelf mailservers beheren, alleen maar strom van eigen generator/zonnepanelen gebruiken?

Je neemt als bedrijf gewoon diensten van andere bedrijven af, omdat je wilt besparen op tijd, moeite en geld. En Github levert heus wel een veilige dienst, maar je moet het natuurlijk wel goed inzetten.

dok33 schreef:

Waarom zou je als bedrijf iets doen dat niet je core business is?

Aan de andere kant kun je je afvragen of als een bedrijf, wiens core business "cloud-inloggen" is, dit jaar al meerdere breaches (zie onderin) had i.r.t. "cloud-inloggen", dit hele concept wel zo'n goed idee is - vanuit beveiligingsoogpunt.

Staat dat dan nog voldoende in verhouding tot "besparen op tijd, moeite en geld"?

Ook als de sources "niet supergeheim zijn" levert dit wel reputatieschade op voor Okta en het concept "cloud-inloggen".

Ook als de sources "niet supergeheim zijn" levert dit wel reputatieschade op voor Okta en het concept "cloud-inloggen".

Dat is wel een heel ander soort issue dan wat we bespraken, maar zal voor hun nu vast deel zijn van het heroverwegen hoe ze met hun code omgaan.

Maar alles zelf doen is niet perse beter of veiliger. Vaak zelfs niet.

Maar alles zelf doen is niet perse beter of veiliger.

Dat hangt van allerlei omstandigheden af.

Vaak zelfs niet.

Als je, in plaats van één, 10 ontwikkelaars met toegang tot een privaat github-account hebt, loop je 10x zoveel risico dat 1 van hen een fout maakt of in een phishing-aanval trapt.

Als die ontwikkelaars via VPN's met de "omvuurmuurde" zaak verbinden, evt. met externe servers met een zelf opgesteld toegangsbeleid, zijn de risico's welliswaar ook groter bij meer ontwikkelaars, maar het effectieve totale risico kan dan veel kleiner zijn dan bij gebruik van externe partijen zoals github (evt. in combinatie met CircleCi).

M.a.w. bij cloud-toepassingen, waar individuele medewerkers via publiek internet op moeten inloggen, explodeert het aanvalsoppervlak met het aantal gebruikers.

[Reactie gewijzigd door ErikvanStraten op 22 december 2022 13:07]

Maar daar doe je net alsof die 10 ontwikkelaars in staat zijn om het beheer van die server, van dat VPN, alle operationele zaken er omheen, zoals updates en gebruikersbeheer, instellen van MFA, en het netwerk en de firewalls, gewoon de normaalste zaak van de wereld vinden en er wel even bij doen. Naast het werk dat ze zouden moeten doen om geld te verdienen met je bedrijf.

Los van of men daar de kennis voor heeft, willen ze dat wel, als ze als ontwikkelaar aan het werk zijn?

Of ga je al uit van een bedrijf dat er nog een aparte ondersteunende IT afdeling op na kan houden?

Maar daar doe je net alsof die 10 ontwikkelaars in staat zijn om het beheer van die server, van dat VPN, alle operationele zaken er omheen, zoals updates en gebruikersbeheer, instellen van MFA, en het netwerk en de firewalls, gewoon de normaalste zaak van de wereld vinden en er wel even bij doen. Naast het werk dat ze zouden moeten doen om geld te verdienen met je bedrijf.

Serieus? Volgens Wikipedia had Okta in januari ruim 5000 medewerkers.

Los van of men daar de kennis voor heeft, willen ze dat wel, als ze als ontwikkelaar aan het werk zijn?

Want als je cloud-based bent heb je geen beheerders, helpdesk-medewerkers en security-specialisten meer nodig?

Of ga je al uit van een bedrijf dat er nog een aparte ondersteunende IT afdeling op na kan houden?

Heb je wel eens naar de admin-pagina's van MS 365 en AAD gekeken? Denk je dat elke amateur zoiets fatsoenlijk kan beheren?

De beheerpagina's van commerciële github-accounts ken ik niet, maar ook dat managen leer je vast niet in een paar minuten. Zoveel klanten, zoveel wensen - en dus zoveel keuzes en complexiteit

[Reactie gewijzigd door ErikvanStraten op 22 december 2022 15:59]

Uiteraard kan een lokale server een verbetering zijn, maar als de beveiliging daarop niet goed is vanwege het gebruik van simpele wachtwoorden en/of geen 2FA, is er nog een steeds een zwakke schakel En dus een mogelijk risico.

Waarom zou je je als security bedrijf blootstellen als een nog groter doelwit door je eigen servers op te zetten? Alsof Okta het budget heeft om een beveiliging van het niveau van GitHub en Microsoft op te zetten.

Het gaat hier heel waarschijnlijk om credentials die in iemands handen zijn gekomen die ze niet had mogen hebben. Waar het dan gehost is hat niks uitgemaakt...

Maar dan ga je er van uit dat je als bedrijf beter in staat bent om dergelijke servers te beheren, dan een bedrijf wat er zijn core business van gemaakt heeft. En dat betwijfel ik in veel gevallen.

Volgens mij is hier namelijk ook niet ter sprake dat de servers van het externe bedrijf gehackt zijn.

Waarom zou je als IT security bedrijf je code op externe servers hosten? Meeste normale software bedrijven waar ik heb gewerkt zijn er lokaal gitlab of gerrit servers waar je extern alleen met een VPN bij kan.

Even een aanname maar waarschijnlijk is dit gestolen dmv gelekte credentials. En qua credentials en toegang is Github prima in te richten. Van MFA tot accestokens kan je het prima regelen.

Je kan inderdaad ook github intern gebruiken (met een eigen server). Want ze hebben ook een self-hosted versie.

Maar als je collaboreert met externe partijen dan is de cloud github veel handiger.

[Reactie gewijzigd door GekkePrutser op 22 december 2022 09:55]

Alsof er nog nooit een on-prem of gerrit server achter vpn gecompromised geweest is ... of codebases via de laptop van een developer gelekt zijn. Dat laatste gebeurd staat minder frequent, maar het is hoe je met de access omgaat die belangrijk is.

Ik heb wat on-prem gitlab's gezien die ver achter liepen qua security patching bvb omdat ze af en toe als er ruimte was een upgrade werd uitgevoerd.

Aangezien dit gebeurd zal zijn met gestolen credentials lijkt het me niet dat het zelf hosten veel geholpen zou hebben.

Ik heb meer vertrouwen in de security van bitbucket, github etc ... dan van een of andere kmo die lokaal een git servertje hebben draaien.

Wij hebben alles nu Azure staan, en voor ons is deze software zeer belangrijk. We hadden het op eigen gitlab, maar dat voldeed niet meer ivm de hoeveelheid repositories en de verschillende regels and artifactories.

Voor ons is deze software zeer belangrijk, we hebben hele teams die zich met security en risico bezig zijn om dat allemaal in recht banen te leiden

[Reactie gewijzigd door rvt1 op 22 december 2022 21:39]

Wij hebben een SVN server draaien. Is dat het zelfde soort?

Omdat het twee verschillende dingen zijn. Jij suggereert dat security by obscurity veiliger is?
Linux is ook gewoon open source, is daarmee linux zo lek als een mandje?
Zoals ik het lees maakt het voor veiligheid niet uit dat de code is gelekt.

Verder zegt een woordvoerder van Okta tegen Engadget dat 'de gestolen code geen gevolgen heeft voor de veiligheid van de producten van het bedrijf, omdat de beveiliging niet afhankelijk is van of de broncode geheim is'.

Ik ben geen security expert dus verbeter mij gerust als ik er naast zit. Maar hiermee kunnen ze toch wel gerichtere aanvallen uitvoeren? Het lijkt mij namelijk dat als je de code hebt van een product dat je ook wel kan achterhalen wat de zwakke plekken zijn.

Ja en nee. Bij open source software die goed onderhouden wordt is de kans op veiligheidsproblemen die lang blijven bestaan juist kleiner omdat er zoveel mensen meekijken. Hier gaat het echter over closed source software die gestolen is en dus misschien niet openbaar gemaakt wordt maar enkel circuleert bij mensen met slechtere bedoelingen. Dat lijkt me geen goede zaak voor de veiligheid.

Ja en nee. Bij open source software die goed onderhouden wordt is de kans op veiligheidsproblemen die lang blijven bestaan juist kleiner omdat er zoveel mensen meekijken.

Dat is de theorie. De realiteit is dat vrijwel niemand gratis tijd spendeert aan reviews van andermans software. Zolang onafhankelijke reviews niet worden gedaan blijft het keuren van eigen vlees door dezelfde developers die het product ook hebben gemaakt.

Niet gratis, maar er zijn genoeg bedrijven die open source software doorlichten, omdat het dat bedrijf waarde heeft om security issues te vinden. Google is bijvoorbeeld een bedrijf dat serieus resources besteed om opensource software door te lichten

Commerciële saas providers met closed source software laten ook betalende audits uitvoeren door firma's waarbij de code bases onder NDA's liggen, er gebeurt ook penetration testing.

Het is niet omdat het niet in de public space gebeurt dat het er niet is.

Dat zeg ik ook niet, ik reageer op @downtime die aangeeft dat het voor opensource in de praktijk niet zou gebeuren

Google beperkt zich natuurlijk niet tot open source en vind met enige regelmaat security issues in closed source software. Het is derhalve onjuist om te stellen dat open source veiliger is omdat het doorgelicht wordt door derden.

Dat beweer ik ook helemaal niet. Ik zeg enkel dat open source OOK wordt doorgelicht door betalende partijen, meer niet.

De thread gaat daar wel over, dus excuus voor mijn verwarring.

Dat is de theorie. De realiteit is dat vrijwel niemand gratis tijd spendeert aan reviews van andermans software

Daar ben ik het niet mee eens.
Als ik kijk naar grote open source projecten als Magento en Wordpress, of repository bij packagist dan zijn er wel degelijk veel mensen die fouten verbeteren.

Je gebruikt code, je ziet een probleem, je wil dit probleem niet hebben, dus je fixt het en vraagt een MR aan.

Een bug vinden en fixen in een CMS is niet vergelijkbaar met een review. Een code review van een security product is lastig omdat je zwakheden moet vinden in code die het functioneel gezien gewoon doet.
Dat een encryptie in een jaar met een cluster computers gekraakt kan worden terwijl het een miljoen jaar hoort te zijn ga je niet merken tenzij je heel veel specialistische kennis in huis hebt. Dat is echt heel wat anders dan “deze functie in mijn CMS doet het niet, dus ik maak wel even een fix zodat ie wel werkt”.

Het is niet hetzelfde, omdat het opvolgend is.
Je fixt een bug, je laat het reviewen.

En een bug fixen is vaak makkelijker dan een functie toevoegen. En in open source projecten worden zelden 'even een fix' gemaakt want dan komt het niet door de code review heen.
En dan zie je vaak ook nog dat iemand een nette oplossing maakt omdat die het een goed idee vind.

WordPress is tegenwoordig aardig veilig. Het is al het gedoe eromheen (plugins) waar geregeld rotzooi tussen zit.

Gratis security scan Uiteraard heb je gelijk dat het aanvallen zo makkelijk wordt, maar als je code goed is zou dat geen probleem mogen zijn.

Ja en nee. Je kunt wel gerichter naar zwakke plekken zoeken, maar dat hoeft niet te betekenen dat ze er ook zijn en dat je ze ook kunt misbruiken. Vergelijk het met andere open source tooling, die is ook niet inherent onveilig omdat de code openbaar is.

Is er ook bekend hoe de unauthorized access op github plaats heeft kunnen vinden? Of gaat het hier meer om een organisatorische fout waar iemand die niet meer toegang zou moeten hebben tot de code erbij kon (of juist iemand die de code kopieerde voordat die vertrok)?
Lijkt me dat die vraag nu voor veel bedrijven op gaat die de code in private github repositories hebben staan.

Maar was is er nou precies gestolen, ik ben tegenwoordig meer bezig geweest met Keycloak. Maar dacht dat Okta al opensource was?

Betreft dit een mono repo met alle code? Of een repo met een paar services, of front-end code. Kan van alles zijn toch?

Overigens hoeft dit niks te betekenen over de "veiligheid" van de code. Zolang de juiste protocollen gebruikt worden.

[Reactie gewijzigd door Nark0tiX op 22 december 2022 10:55]

En dat weer net voor kerst.. Lekkere timing wel..

**start fluisteren** Log4J **stop fluisteren**

Dit is helemaal niet vergelijkbaar met het Log4J issue, dat was daadwerkelijk een kwetsbaarheid in een library die in heel veel Java applicaties zit, dit gaat alleen maar over het uitlekken van code, wat op zichzelf nog geen kwetsbaarheid is, van een specifieke applicatie die niet overal in zit, waardoor de impact al vele malen kleiner is.

Ik had eigenlijk het idee dat @Semafoor89 wat inside informatie heeft hier en dat de gebruikte vulnerability iets met Log4j te maken heeft.

Maar dat was maar mijn aanname.

Nee, geen inside informatie.
En als het met Log4J te maken heeft, is dat een heel kwalijke zaak.

Ik snap dat het niet net als Log4J een kwetsbaarheid is die in heel veel libaries zit. Ik hint daarmee alleen wel op de timing. Daarnaast is het lekken van code inderdaad geen major issue, behalve dat bij het uitlekken van code, er gerichter kan worden gezocht naar potentiele zwakke plekken.

.... van een specifieke applicatie die niet overal in zit, ....

Stiekem wordt OKTA op meer plekken geimplementeerd dan dat je aan de buitenkant kan zien. (Weet ik uit eigen ervaring.)

[Reactie gewijzigd door Semafoor89 op 22 december 2022 10:20]

Klopt, het is de meeste gebruikte third-party IDP. Ik denk dat Microsoft ADFS er nog bovenuit komt maar dat zit dan ook standaard in Office 365.

Wij hebben op het werk gelukkig een andere third-party IDP Nouja 'gelukkig'... Die wij hebben is helaas erg slecht. Okta is veel beter, alleen in dit geval is het niet zo fijn om op Okta te zitten omdat er wellicht aanvallen komen door fouten in de code.

[Reactie gewijzigd door GekkePrutser op 22 december 2022 10:26]

Slechte PR: "Onze broncode is gestolen"
Goede PR: "We hebben onze broncode ongepland geopensourced"

De engelstalige meervoud is ‘repositories’. ‘s is in het engels een afkorting van ‘his’.