Een grote SaaS-speler in e-commerce, BigCommerce, is getroffen door een supply chain aanval. Daarbij zijn volgens meldingen klantgegevens gestolen via gecompromitteerde inlog- en app-gegevens van een derde partij: de Ribon-apps. Dit is precies het type incident waarbij niet de hoofdinfrastructuur als eerste doelwit hoeft te zijn, maar een schakel in het app-ecosysteem.
In dit artikel leggen we stap voor stap uit wat er bekend is over de BigCommerce datadiefstal, welke gegevens zijn geraakt en welke herstelmaatregelen BigCommerce volgens de beschikbare informatie heeft genomen.
Wat is er gebeurd bij de BigCommerce datadiefstal?
BigCommerce stelt dat het incident begon doordat een applicatiesleutel (een toegangssleutel) van Ribon is gecompromitteerd. Ribon is een storefront- en optimalisatie-app die door Fastr wordt beheerd onder de naam “Be A Part Of”. De app kan door merchants zelfstandig worden geïnstalleerd op hun BigCommerce-winkels.
De sleutel werd volgens de technische beschrijving gebruikt in de periode 13 september tot en met 17 september. Met die toegang konden aanvallers de klantdata binnen de BigCommerce-omgeving benaderen.
Welke klantgegevens zijn gestolen?
Volgens een technische uiteenzetting van Master of Malt ging het om een set persoonlijke gegevens die klanten aan hun webwinkel gekoppeld hadden. Concreet worden genoemd:
- namen
- e-mailadressen
- telefoonnummers
- adressen
Master of Malt beschrijft daarnaast de manier van exfiltratie: de gestolen data zou “page by page” zijn gedownload, totdat de sleutel werd ingetrokken.
Waarom was de aanval mogelijk via een derde app?
BigCommerce draait op een SaaS-model en biedt daarnaast ondersteuning voor een groot aantal derde partijen. In dit geval zijn er aanwijzingen dat de aanval niet direct op BigCommerce zelf was gericht, maar op de toegang van de Ribon-app die op honderden winkels stond.
Het kernpunt is dat wanneer een derde partij een toegangssleutel of API-credentials heeft, aanvallers die sleutel kunnen misbruiken om gegevens te bereiken die binnen de scope van die app vallen. Daarmee verschuift het risico van “platformbreuk” naar vertrouwensrelaties in het app-ecosysteem.
Dat principe zie je vaker terug in supply chain incidenten. Als je wilt vergelijken met andere voorbeelden binnen dit thema, is het ook interessant om te lezen hoe in andere gevallen credentials of productintegraties misbruikt worden. Een relevant artikel hierover is bijvoorbeeld malafide npm-pakket via B-tree prototype, waar ook de keten van softwarelevering centraal staat.
Wanneer werd de sleutel ingetrokken en hoe snel volgde communicatie?
De misbruikperiode liep tot 17 september, waarna de toegangssleutel werd ingetrokken. Op diezelfde datum werd Ribon-kant bekend met het probleem: er wordt genoemd dat de ontwikkelaars de misuse pas bewust werden op 16 september of dat de awareness rond dat moment ontstond, waarna intrekking volgde op 17 september.
Vervolgens startte BigCommerce met het informeren van merchants op 18 september. Op dat moment waren de toegang tot de sleutel al uitgeschakeld en waren de gerichte Ribon-applicaties bij de getroffen winkels bovendien gedeïnstalleerd, volgens de beschikbare beschrijving.
Wat zegt BigCommerce zelf: geen inbraak in het platform?
BigCommerce benadrukt dat het om een compromis van third-party credentials ging. In de communicatie wordt gesteld dat de betrokken API-credentials van Ribon en “Ribon 1.5” gecompromitteerd waren door een onderliggende systeemcompromissie binnen Fastr.
Daarnaast wordt genoemd dat die credentials zijn gebruikt om kwaadwillende scripts te injecteren in een beperkt aantal storefronts. Cruciaal is het onderscheid dat BigCommerce aangeeft: dit zou volgens hen geen inbreuk op Commerce-systemen of het BigCommerce platform zijn geweest.
In de praktijk komt dit neer op twee sporen: (1) het intrekken van de sleutel en (2) het wegnemen van de app-instanties op getroffen winkels om de aanvaller buiten werking te stellen.
Welke herstelacties zijn genomen?
Op basis van de beschikbare informatie nam BigCommerce meerdere maatregelen om verdere schade te beperken:
- De uninstall van de getroffen Ribon-apps uit de impacted stores.
- Het uitschakelen of intrekken van de gecompromitteerde toegangssleutel.
- Het direct informeren van de getroffen merchants.
- Het aanleveren van loggegevens die developers kunnen gebruiken voor hun eigen onderzoek.
Door de app te verwijderen wordt de vertrouwensrelatie tussen merchant en third-party weer opgeruimd. Dat is vaak een van de snelste manieren om een supply chain aanval te “dichten”, zeker wanneer een app toegangsscope heeft tot data.
Is duidelijk hoe Ribon is gecompromitteerd?
Volgens de beschikbare berichtgeving is het onduidelijk hoe Ribon precies is geraakt en of er mogelijk ook andere partijen zijn getroffen. Zowel Be A Part Of als Fastr hebben het incident niet publiekelijk bevestigd in de aangehaalde broncontext.
Security nieuws rond supply chain incidenten laat vaak een deel van de keten onverklaard totdat partijen hun interne onderzoeken afronden. Daarom is het verstandig om dit soort gevallen te zien als een signaal: niet alleen “patch management” telt, maar ook het monitoren van third-party privileges en integratiegedrag.
Wat betekent dit voor merchants en securityteams?
Als merchant kun je op dit soort incidenten reageren door je installaties en rechten te herijken. Een paar praktische aandachtspunten:
- Beperk de tooling: laat alleen apps draaien die je echt nodig hebt en houd de lijst actueel.
- Volg installatiestatus en scope: weet welke apps toegang hebben tot klantdata en waar die toegang toe dient.
- Monitor voor afwijkingen: let op ongebruikelijke datatoegang of plotselinge veranderingen in storefrontgedrag.
- Herbouw vertrouwen: als er signalen zijn van misbruik, verwijder dan snel de getroffen integratie en start een eigen incidentanalyse.
Voor securityteams is dit ook een extra reden om te investeren in zicht op de softwareleveranciersketen: wie heeft welke credentials, hoe zijn die gekoppeld en welke datastromen zijn er aan die koppelingen verbonden?
Vergelijkbare supply chain signalen
Dit incident past in een bredere trend waarin data en functionaliteit via integraties en leveranciers worden aangeraakt. Het is daarom nuttig om vergelijkbare cases bij te houden. Zo is er bijvoorbeeld ook aandacht geweest voor gevallen waarin broncode of toegang via een keten wordt aangetast, zoals besproken in het securitylandschap rond andere supply chain gebeurtenissen.
Wil je die bredere context verkennen, dan kan je ook kijken naar datalek CrowdSec, waar de impact van gecompromitteerde software-artefacten en broncode op beveiliging en vertrouwen duidelijk wordt.
Conclusie
De BigCommerce datadiefstal laat zien hoe datadiefstal kan ontstaan via een gecompromitteerde derde partij. In dit geval is de kern dat aanvallers toegang kregen doordat een Ribon-toegangssleutel is misbruikt, waardoor klantgegevens zijn gedownload. BigCommerce reageerde door de sleutel uit te schakelen, de apps te verwijderen uit getroffen winkels en merchants te informeren.
Voor de markt is dit een duidelijke waarschuwing: ook wanneer je platform “veilig” is, kunnen supply chain risico’s via integraties en app-credentials alsnog grote gevolgen hebben. Door installaties te beheren, rechten te beperken en gedrag te monitoren, kun je de impact van dit soort incidenten aanzienlijk verkleinen.
Bron: https://www.securityweek.com/bigcommerce-data-stolen-via-ribon-apps-hack/
