ButterCMS is een populaire tool die wordt gebruikt om content voor blogs te beheren. Eerder deze week merkten we een mogelijk ernstig beveiligingsincident op dat het team ertoe aanzette om ButterCMS van onze site te verwijderen en een diepgaand onderzoek te starten naar wat er gebeurd was. Mogelijk werden 1.660 websites en meer dan 5.800 domeinen getroffen.
Ons doel is om de bevindingen van ons onderzoek te delen om te laten zien wat er kan gebeuren wanneer je dynamische derde partijen vertrouwt zonder continue verificatie.
Het ButterCMS-incident
We observeerden dat het incident begon op 9 september om 08:00 (PT), toen we een significante toename in fouten merkten omdat de DNS de hostnaam niet kon oplossen. Dit resulteerde in een storing van de blog op onze website.
Kort daarna merkten we dat de ButterCMS-site niet beschikbaar was omdat er geen DNS-records werden aangeboden.
Toen we dieper groeven, merkten we dat het ButterCMS-domein een WhoIs-update had op hetzelfde moment dat onze problemen begonnen. Een logische reden hiervoor zou een verlenging of een verandering in eigendom van het domein kunnen zijn geweest. Het laatste zou zeer zorgwekkend zijn.
Als het domein was "gekaapt" en in kwaadwillende handen was gevallen, had dit een ernstig beveiligingsrisico kunnen vormen, vergelijkbaar met het Polyfill-incident, waarbij een verandering van domeineigendom een grote browser supply chain-aanval veroorzaakte op bijna 500.000 websites. Dit resulteerde in kwaadaardige code die werd geïnjecteerd in de browsers van miljoenen bezoekers, wat leidde tot kwaadaardige omleidingen en mogelijk andere heimelijke aanvallen die niet werden opgemerkt doordat client-side beveiligingsmonitoring onderbenut werd.
Inmiddels hadden we de ButterCMS-integratie volledig uitgeschakeld om te voorkomen dat er gegevens werden aangeboden vanaf het mogelijk gecompromitteerde domein. Het uitschakelen van het CMS verwijdert het risico dat kwaadaardige code in onze site wordt geïnjecteerd.
We namen contact op via X (Twitter) om het ButterCMS-team op de hoogte te stellen:
We're experiencing DNS issues with
, it seems like your DNS was entirely wiped on several different networks.
Since I can not access the website I have no other way to contact your support team.— cody (@devlooskie)
Ze reageerden niet op ons bericht.
Om 08:30 observeerden we dat de DNS-records voor ButterCMS werden hersteld en, belangrijk, verwezen naar dezelfde IP's als vóór de downtime. Dit suggereerde dat het probleem waarschijnlijk te wijten was aan een verkeerde configuratie of downtime bij de DNS-provider die voor hun domein werd gebruikt. Tijdens de downtime zagen we geen records aanwezig. Niet voor de site, noch voor de API.
Zodra we bevestigden dat de service weer normaal was, hebben we onze wijzigingen teruggedraaid.
We namen uiteindelijk contact op met het ButterCMS-team via hun chatservice:
In het volledige bericht beweerde de supportmedewerker dat haar team niet op de hoogte was van het probleem, maar begon met onderzoeken. We kunnen de volledige berichtgeschiedenis niet delen, want nadat we om een casenummer vroegen, antwoordden ze dat ze er geen hadden. Intercom zou deze standaard moeten hebben.
We controleerden de ButterCMS-statuspagina, die tot op heden geen downtime toont. Dit deed ons aanvankelijk geloven dat het probleem ofwel aan onze kant lag, ofwel groter was dan het bleek te zijn.
De mislukte correspondentie met ButterCMS
Na dit alles namen we per e-mail contact met hen op. Dit was hun reactie:
Ze vermelden een recente overname van ButterCMS door Tiugo Technologies. Maar dit werd eind 2022 gerapporteerd, meer dan 1,5 jaar geleden. Hoewel dit nu de reden voor de domeinoverdracht verklaart, waren we niet op de hoogte gesteld of vooraf op de hoogte gebracht van de wijzigingen.
We volgden op en ontvingen het volgende bericht:
Een verificatieprobleem had het probleem kunnen zijn. We zullen meer weten in hun post-mortem verklaring die binnenkort zal worden geplaatst.
In een laatste opvolgende e-mail op 12 september was dit hun reactie:
We geloven dat communicatie over dit soort wijzigingen van vitaal belang is. Wanneer geplande wijzigingen misgaan, zelfs lichtjes, brengt dit klanten in aanzienlijk gevaar. Een snelle e-mail om gebruikers op de hoogte te stellen gaat een lange weg in dit soort scenario's.
Deze wijzigingen kunnen zelfs interfereren met AVG-vereisten, nu we weten dat het domeineigendom veranderde na een overname. De AVG vermeldt niet specifiek domeinoverdrachten, maar richt zich op de overdracht van controle over persoonsgegevens. Als de verandering in eigendom leidt tot een nieuwe verwerkingsverantwoordelijke die persoonsgegevens beheert, moeten de klanten (betrokkenen) hiervan op de hoogte worden gesteld. Dit valt onder de AVG-principes van transparantie en eerlijkheid (Artikelen 13, 14).
Klanten moeten op de hoogte worden gesteld van de identiteit van de nieuwe verwerkingsverantwoordelijke en eventuele wijzigingen in hoe hun gegevens zullen worden verwerkt. De kennisgeving moet binnen een redelijke termijn plaatsvinden.
We hebben gewacht met het plaatsen hiervan om te zien of er nog communicatie zou komen vóór het geplande webinar. Tot nu toe hebben we niets gezien.
UPDATE: Zelfs na het webinar, geen opname en geen blogpost of verklaring.
Later probeerden we te zoeken naar andere bedrijven die commentaar gaven op dit probleem, maar vonden er geen. Hoewel we hun exacte aantal klanten niet kunnen weten, werden mogelijk 1.660 websites en meer dan 5.800 aanvullende domeinen getroffen:
Het risico met dynamische derde partijen
Dit is ernstiger dan alleen veranderende records. Dit patroon is precies wat er gebeurt wanneer het domein van eigenaar verandert, of belangrijke WhoIs-details worden bijgewerkt.
Hoewel het probleem nu is opgelost, toonde deze situatie een potentiële beveiligingskwetsbaarheid.
De bredere les uit dit incident is het risico dat je loopt wanneer je vertrouwt op diensten van derde partijen die dynamisch content in websites injecteren. Een probleem dat we goed kennen en waartegen we beschermen aan de client-side.
Domeinen die in integraties worden gebruikt, kunnen worden gekocht door kwaadwillende actoren en worden uitgebuit voor aanvallen. De content die ze injecteren is dynamisch. Dit betekent dat de content kan veranderen op basis van verschillende factoren zoals tijd, regio en andere gebruikersspecifieke gegevens, waardoor het gemakkelijk is voor slechte actoren om detectie te omzeilen.
In dit geval wekte de verlenging van het ButterCMS-domein en het gebrek aan duidelijkheid rond de WhoIs-update een rode vlag op om ons eraan te herinneren om afhankelijkheden van derde partijen te monitoren.
Hoe een website is gebouwd, heeft aanzienlijke invloed op de kwetsbaarheid voor dit soort problemen. Idealiter zou elke invoer goed moeten worden gesaniteerd. Gebruikersinvoer moet worden opgeschoond om te voorkomen dat kwaadaardige code in de site wordt geïnjecteerd.
Veel ontwikkelaars implementeren geen goede sanitatie, vooral wanneer dit niet expliciet wordt behandeld in documentatie.
Als je zoekt naar "dangerouslySetInnerHTML", is er geen duidelijke begeleiding over hoe deze prop veilig te gebruiken. Zonder goede sanitatie kan elke geldige HTML worden geïnjecteerd, wat een ernstige XSS (Cross-Site Scripting) kwetsbaarheid creëert.
Wanneer HTML in de client wordt geïnjecteerd, kan de hele webpagina worden gecompromitteerd door script-injecties. Zonder waarborgen zou de geïnjecteerde HTML schadelijke scripts kunnen uitvoeren of gebruikers kunnen omleiden naar kwaadaardige sites, waardoor de functie effectief wordt omgezet in een open portaal voor beveiligingsrisico's.
Hoe dit aan de client-side wordt aangepakt
Natuurlijk is het risico van domeinverandering niet nieuw voor ons. Het is een veelvoorkomende aanvalsvector in de client-side beveiligingswereld. cside controleert al DNS-recordgeschiedenis, WhoIs-informatie en metadata.
Zolang de website actief blijft (en als gevolg daarvan ook onze proxy) en er wijzigingen of anomalieën optreden, detecteert onze engine dit. En, na het controleren van andere mogelijke kwaadaardige activiteiten, zal het domein, het script en dus een mogelijke aanval worden gewaarschuwd en/of geblokkeerd.
Je kunt je site snel en gratis beschermen door cside te gebruiken.
