Kort samengevat: niet-gerapporteerde CMS DNS-wipe met WHOIS-registrar-overdracht als rood signaal
- 'Klein DNS-probleem' of overname: Externe leveranciers zijn dol op de zin "klein DNS-probleempje", maar een volledige DNS-wipe die precies samenvalt met een WHOIS-registrar-update ziet er vanuit de client-side identiek uit aan een Polyfill-achtige domeinovername, en slechts één van die twee scenario's eindigt met een klantmelding.
- Wij haalden het weg en volgden het: cside haalde ButterCMS op 9 september om 08:00 PT uit onze eigen blog, op het moment dat de DNS niet meer resolvde samen met een WHOIS-update, en onze engine volgt al DNS-recordgeschiedenis, WHOIS-metadata en gedragsdrift voor elk extern domein bij ongeveer 1.660 potentieel getroffen sites en 5.800 aanvullende domeinen.
- Geen post-mortem, geen vertrouwen: Als je CMS-leverancier na een outage die door zou kunnen gaan voor domeinkaping geen statuspagina-update, geen dossiernummer en geen post-mortem kan leveren, is de vraag niet of je de oplossing vertrouwt, maar of continue verificatie van elke dynamische derde partij een basisvereiste is of slechts een leuk extraatje.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
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 zagen dat het incident begon op 9 september om 08:00 (PT), toen we een significante toename in fouten opmerkten 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. Dat 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 bij 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 zouden worden aangeboden vanaf het mogelijk gecompromitteerde domein. Het uitschakelen van het CMS haalt het risico weg 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 zagen we dat de DNS-records voor ButterCMS werden hersteld en, belangrijk, verwezen naar dezelfde IP's als vóór de downtime. Dit suggereert 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 functioneerde, hebben we onze wijzigingen teruggedraaid.
Uiteindelijk namen we 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 dossiernummer vroegen, antwoordden ze dat ze er geen hadden. Intercom zou deze standaard moeten hebben.
We controleerden de ButterCMS-statuspagina, die tot op vandaag geen downtime toont. Dit deed ons aanvankelijk geloven dat het probleem ofwel aan onze kant lag, ofwel groter was dan het uiteindelijk 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 noemen een recente overname van ButterCMS door Tiugo Technologies. Maar dit werd al 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 geïnformeerd over de wijzigingen.
We volgden dit op en ontvingen het volgende bericht:
Een verificatieprobleem kon de oorzaak zijn geweest. We zullen meer weten via hun post-mortemverklaring die binnenkort zal worden gepubliceerd.
In een laatste vervolg-e-mail op 12 september was dit hun reactie:
Wij geloven dat communicatie over dit soort wijzigingen essentieel is. Wanneer geplande wijzigingen misgaan, zelfs een klein beetje, brengt dat klanten in aanzienlijk gevaar. Een snelle e-mail om gebruikers op de hoogte te stellen helpt in dit soort scenario's al enorm.
Deze wijzigingen kunnen zelfs interfereren met AVG-vereisten, nu blijkt dat het domeineigendom veranderde na een overname. De AVG noemt domeinoverdrachten niet specifiek, maar richt zich op de overdracht van controle over persoonsgegevens. Als de eigendomswijziging ertoe leidt dat een nieuwe verwerkingsverantwoordelijke persoonsgegevens gaat beheren, moeten de klanten (betrokkenen) hierover worden geïnformeerd. Dit valt onder de AVG-principes van transparantie en eerlijkheid (Artikelen 13, 14).
Klanten moeten worden geïnformeerd over de identiteit van de nieuwe verwerkingsverantwoordelijke en over eventuele wijzigingen in de manier waarop hun gegevens worden verwerkt. Deze kennisgeving moet binnen een redelijke termijn plaatsvinden.
We hebben gewacht met het plaatsen van dit artikel om te zien of er alsnog communicatie zou komen vóór het geplande webinar. Tot dusver hebben we niets gezien.
UPDATE: Zelfs na het webinar geen opname, geen blogpost en geen verklaring.
Later probeerden we op zoek te gaan naar andere bedrijven die commentaar gaven op dit probleem, maar vonden er geen. Hoewel we hun exacte aantal klanten niet kennen, 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 inmiddels is opgelost, toonde deze situatie een potentiële beveiligingskwetsbaarheid aan.
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 opgekocht door kwaadwillende actoren en worden misbruikt voor aanvallen. De content die zij injecteren is dynamisch. Dat betekent dat de content kan veranderen op basis van diverse factoren zoals tijd, regio en andere gebruikersspecifieke gegevens, waardoor het voor kwaadwillenden gemakkelijk is om detectie te omzeilen.
In dit geval wekte de verlenging van het ButterCMS-domein, samen met het gebrek aan duidelijkheid rond de WhoIs-update, een rode vlag op die ons eraan herinnerde om afhankelijkheden van derde partijen te monitoren.
Hoe een website is gebouwd, heeft een aanzienlijke invloed op de kwetsbaarheid voor dit soort problemen. Idealiter zou alle 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 in de documentatie wordt behandeld.
Als je zoekt naar "dangerouslySetInnerHTML," is er geen duidelijke uitleg over hoe je deze prop veilig kunt gebruiken. Zonder goede sanitatie kan elke geldige HTML worden geïnjecteerd, wat een ernstige XSS-kwetsbaarheid (Cross-Site Scripting) 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 naar kwaadaardige sites kunnen omleiden, waardoor de functie feitelijk verandert in een open portaal voor beveiligingsrisico's.
Hoe dit aan de client-side wordt aangepakt
Het risico van een domeinwisseling is voor ons uiteraard niet nieuw. Het is een veelvoorkomende aanvalsvector in de wereld van client-side beveiliging. cside controleert al DNS-recordgeschiedenis, WhoIs-informatie en metadata.
Zolang de website online blijft (en daarmee ook cside) en er wijzigingen of afwijkingen 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 gemeld en/of geblokkeerd.
Je kunt je site snel en gratis beschermen door cside te gebruiken.
