Securitytrainer wijst naar een dunne openstaande deur naast drie zwaar beveiligde deuren

Ergens op 25 juli logt een medewerker van OpenAI in op het eigen hulpforum. Hij beantwoordt een vraag van een gebruiker, sluit het tabblad en gaat door met zijn dag. Hij heeft niets gedownload, niets geklikt en niets fout gedaan. Toch is zijn ChatGPT-account op dat moment van iemand anders, en die iemand kan bij zijn GitHub. In de loop van die middag opent er via zijn Codex een pull request in de interne monorepo van OpenAI.

Dat staat niet in een gerucht. Het staat in de eigen writeup van het team dat het deed, Hacktron, met een tijdlijn op de minuut. Tussen vijf en zes uur ’s ochtends UTC hadden ze code-uitvoering en beheerdersrechten op community.openai.com. Tussen acht en tien uur lag hun melding bij het bug bounty-programma van OpenAI op Bugcrowd. Tussen half twee en half vier ’s middags namen ze een medewerkersaccount over, lieten ze Codex die pull request openen en stopten ze met testen. Om 22:49:45 diezelfde avond liet OpenAI weten dat het gat dicht was.

Het lek zat niet in het forum, en dat is het punt

Bij dit soort nieuws is de reflex om naar het zwakke systeem te wijzen. Een forum, daar zal het wel aan liggen. De onderzoekers schrijven zelf dat die conclusie te makkelijk is: “It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access.” Het forum was één manier om het aan te tonen, niet de oorzaak.

Vertaal dat naar jouw organisatie en het is oncomfortabel. Elke dienst waar je mensen met de bedrijfsknop inloggen, hoort bij je identiteitsgrens. De statuspagina, het klantenforum, dat ene ideeënportaal van marketing, de oude helpdesk die nog twee keer per jaar wordt gebruikt. Op de risicolijst staan ze onderaan, want er staat geen klantdata in. Op de inlogpagina staan ze op precies dezelfde hoogte als je e-mail.

Een account met koppelingen is geen chatapp meer

Waar het echt misgaat, is wat er tegenwoordig aan zo’n account hangt. In hun draadje op X noemt het team het rijtje dat via ChatGPT en Codex gekoppeld kan zijn: Outlook, Gmail, Google Drive, Slack, GitHub. Eén overgenomen sessie is dan geen gesprekgeschiedenis, maar een sleutelbos. Hoe die koppelingen werken staat in het Help Center van OpenAI: je verbindt een app, je autoriseert hem bij de dienst zelf, en daarna leest ChatGPT standaard automatisch mee. John Rood vatte het onder de thread zo samen: “An AI account is now an identity broker with tools attached. Secure it like the control plane, not a chat app.”

Dat vinden wij de kern van dit verhaal, en het is precies het stuk dat in de meeste bedrijven nog nergens is geregeld. Een AI-abonnement wordt gekocht als gereedschap, zoals een notitie-app. Vervolgens klikt iemand “verbind met Drive” om een document te laten samenvatten, en dan is die knop een permanente toegangsweg die niemand meer nakijkt. De aanvaller hoefde in dit geval geen wachtwoord, geen code uit een app en geen medewerking van de gebruiker. Dat is wat het onderscheidt van de social engineering waar we het hier meestal over hebben: hier viel de mens niet om, het koppelvlak viel om.

6.500 dollar is vijf keer hun gemiddelde uitbetaling

Op X gaat de discussie vandaag over geld. OpenAI betaalde 6.500 dollar, en dat vindt de securitywereld te laag voor toegang tot een interne monorepo. Onderzoeker Ian Carroll schrijft: “It seems like the bounty table of the AI labs is a bit too low.” Dat laatste is beter geformuleerd dan het boze deel van de tijdlijn, want wij zochten de tabel op en daar wordt het verhaal anders.

Op de programmapagina van OpenAI op Bugcrowd staan twee cijfers die de verontwaardiging in een ander licht zetten: 623 uitbetaalde meldingen, en een gemiddelde uitbetaling van 1.170,70 dollar over de laatste drie maanden. Deze melding kreeg dus meer dan vijf keer het gemiddelde. En in de tijdlijn van de onderzoekers staat een opmerking van OpenAI zelf: “testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding, not the actions against Discourse.”

Daar valt iets voor te zeggen en het legt tegelijk de vinger op de wond. Wie een programma zo inricht, betaalt naar het onderdeel dat hij zelf bezit, terwijl de aanvaller de keten koopt. Op de programmapagina staat trouwens ook dat OpenAI de prioriteit en beloning naar eigen inzicht kan aanpassen op basis van waarschijnlijkheid of impact. De ruimte om anders te beslissen was er dus.

Het getal dat ons meer zegt, is veertien uur. Zo lang duurde het tussen de melding en de fix aan de kant van OpenAI, op een zaterdag. Dat is sneller dan de meeste Nederlandse organisaties hun eigen meldingen intern doorgeven, en dat verdient krediet in plaats van hoongelach.

Wat wel blijft steken, is die uitzondering. De plek die deze hele keten mogelijk maakte, stond in het eigen beloningsbeleid als niet-van-ons, omdat een externe partij hem host. Formeel klopt dat. Praktisch hing de identiteit van medewerkers er wel aan. Dat is precies de blinde vlek die je zelf hebt zodra je je firewall test alleen op je kernsystemen richt en het gehoste randspul overslaat omdat het van een leverancier is.

“Koppel dan niets” is geen advies dat iemand opvolgt

Eerlijk over onze eigen kant: het makkelijke advies vanuit security is om AI-koppelingen te verbieden. Dat werkt niet, en wie het toch oplegt, krijgt schaduwgebruik met privéaccounts terug. Bovendien deden de onderzoekers hier het nette werk: ze lieten Codex een onschuldige pull request openen om de toegang te bewijzen zonder gevoelige code te lezen, ze stopten na twee uur, en ze meldden het meteen. Dat is geen vrijbrief, maar het maakt hun conclusie wel geloofwaardiger dan de kop “OpenAI gehackt” suggereert.

De bruikbare les is dus niet “geen koppelingen”, maar: behandel het koppelvlak als een toegangsrecht met een eigenaar en een einddatum. Hetzelfde onderscheid dat we maakten bij de gelekte Mistral-code: niet elk incident bij een leverancier is jouw incident, maar wel elke sleutel die jij hebt uitgedeeld.

Welke randdienst hangt er aan jouw inlogknop?

Doe dit deze week, het kost een halfuur. Open het overzicht van gekoppelde applicaties bij je identiteitsprovider, in Microsoft Entra of Google Workspace, en zet er drie kolommen naast: wie is de eigenaar, wanneer is het voor het laatst gebruikt, en wat kan iemand met een sessie hier bereiken. Alles wat op de eerste twee vragen geen antwoord heeft, gaat uit. Doe daarna hetzelfde binnen de AI-tool zelf, bij de koppelingen van je zakelijke ChatGPT- of Copilot-omgeving, en haal weg wat je niet elke week gebruikt.

Dat is de kant van de human firewall die niet over klikgedrag gaat. Je mensen kunnen bij een aanval als deze niets fout doen, maar iemand in je organisatie heeft wel besloten welke diensten aan de bedrijfsidentiteit mogen hangen. Wie die knopen niet bijhoudt, is even kwetsbaar als de medewerker die zonder nadenken op een link in een phishingmail klikt, en het lijkt alleen minder erg omdat er geen mail bij te pas komt.

Het moment om op te letten komt bij de volgende inbraak op een leverancier met een AI-koppeling. De vraag is dan niet of ze binnen zijn gekomen, maar of jouw identiteitsprovider die dienst überhaupt op de lijst had staan. Staat hij er niet op, dan heb je geen incident gemist, dan heb je nooit geweten dat hij bestond. Meer over de menselijke kant staat in de briefing.

Rik Hoogland, security-awareness-specialist en vaste auteur van Humanfirewall.nl

Rik Hoogland
Rik begeleidde jarenlang phishing-simulaties en awareness-programma's bij Nederlandse organisaties. Op Humanfirewall.nl legt hij uit hoe oplichters mensen bespelen en hoe je daar als team tegen bestand raakt. Stel Rik je vraag.

Zelf een situatie die niet vertrouwd voelt?

Beschrijf wat er gebeurde of waar je over twijfelt, dan denkt Rik mee over de juiste reactie.