In februari 2018 werden meer dan 4.000 websites, waaronder prominente overheidsinstanties zoals het Information Commissioner's Office (ICO) van het Verenigd Koninkrijk, slachtoffer van de BrowseAloud aanval. Dit was niet zomaar een cybersecurity-inbreuk; het was een krachtige herinnering aan de verborgen gevaren van third-party scripts in onze steeds meer onderling verbonden digitale ecosystemen.
Wat Gebeurde Er Bij de BrowseAloud Aanval?
Een ogenschijnlijk onschuldige third-party dienst genaamd BrowseAloud, die websites helpt de toegankelijkheid te verbeteren door tekst om te zetten in spraak, werd gecompromitteerd. Kwaadwillende actoren injecteerden het CoinHive cryptocurrency mining script in de codebase van BrowseAloud. Dit script werd vervolgens onbewust uitgevoerd door de browsers van duizenden bezoekers op verschillende websites, waarbij hun apparaten werden gebruikt om cryptocurrency te minen zonder toestemming.
Cryptocurrency mining omvat het proces van het oplossen van complexe wiskundige problemen om transacties op de blockchain te valideren, een taak die traditioneel aanzienlijke computerbronnen vereist. Met de komst van scripts zoals CoinHive werd dit proces echter naar de browsers van nietsvermoedende gebruikers gebracht. Zo werkt het:
- JavaScript Uitvoering: CoinHive en vergelijkbare scripts zijn geschreven in JavaScript, dat kan worden uitgevoerd in elke standaard webbrowser. Dit maakt het ongelooflijk gemakkelijk om op grote schaal te implementeren. Waarschijnlijk het belangrijkste aspect van web supply chain aanvallen en wat cside beveiligt.
- Niet-Consensueel Gebruik van Bronnen: In tegenstelling tot typisch mining dat expliciete toestemming en toegewijde hardware vereist, gebruikt browser-gebaseerd mining de CPU-bronnen van elke bezoeker van een geïnfecteerde site. Het script draait zolang de webpagina open is, waardoor het minder opvalt maar potentieel schadelijk is voor gebruikersapparaten vanwege verhoogd stroomverbruik en slijtage.
- Winstgevendheid voor Aanvallers: Elk gekaapt apparaat draagt een kleine hoeveelheid mining-kracht bij. Wanneer dit echter wordt opgeschaald over duizenden apparaten, kan dit aanzienlijke cryptocurrency genereren voor aanvallers.
De Impact Van Deze Aanval
Deze aanval trof meer dan 4.000 websites, waaronder overheids- en onderwijssites, waardoor duizenden gebruikers zonder hun medeweten werden blootgesteld aan cryptojacking. Er werden geen persoonlijke gegevens gestolen, maar de implicaties waren niettemin aanzienlijk. Websites moesten offline worden gehaald, wat leidde tot serviceonderbrekingen en reputatieschade. De aanvallers maakten misbruik van een veelvoorkomende maar riskante praktijk: automatische acceptatie van third-party script updates. Dit incident benadrukte de noodzaak van rigoureuze monitoring en beheer van third-party componenten, wat veel organisaties over het hoofd hadden gezien.
Dit is waar cside tegen beschermt, zowel in het monitoren van de wijziging als de mogelijkheid om autonoom actie te ondernemen om te voorkomen dat de kwaadaardige code wordt geladen in de browser van de gebruiker.
Met andere woorden, dit zou zeer waarschijnlijk niet zijn gebeurd als cside destijds bestond en was geïmplementeerd. Je kunt gratis aan de slag met cside om jezelf te beveiligen tegen elk soort 3rd-party script aanval.
Wat Gebeurde Er Met BrowseAloud Daarna?
Na de cryptojacking aanval nam Texthelp, het moederbedrijf van BrowseAloud, onmiddellijk actie door de dienst tijdelijk offline te halen om het probleem te beperken en een grondige beveiligingsbeoordeling uit te voeren. Het incident leidde tot meer bewustzijn over de beveiliging van third-party diensten en de noodzaak van voortdurende waakzaamheid en regelmatige beveiligingsaudits.
BrowseAloud kwam weer online met verbeterde beveiligingsmaatregelen en een toewijding om dergelijke incidenten in de toekomst te voorkomen. De aanval leidde ook tot een bredere discussie onder webserviceproviders over het belang van het rigoureus beveiligen en monitoren van third-party scripts.
Het Lot van CoinHive
CoinHive daarentegen kende een ander traject. Aanvankelijk gelanceerd als een legitiem hulpmiddel om website-inhoud te monetiseren zonder advertenties door de CPU-kracht van bezoekers te gebruiken om cryptocurrency te minen, werd CoinHive al snel geassocieerd met ongeautoriseerde cryptojacking. De negatieve connotatie en het misbruik van het script in verschillende kwaadaardige aanvallen leidden tot aanzienlijke controle.
De levensvatbaarheid van de dienst werd verder uitgedaagd door de daling van de waarde van Monero en de toenemende moeilijkheid om het winstgevend te minen. Bijgevolg kondigde CoinHive in maart 2019 zijn sluiting aan, waarbij economische onhaalbaarheid werd genoemd als de primaire reden voor de sluiting.
Het domein CoinHive.com is nu eigendom van branche-expert Troy Hunt. Het is veilig en host zijn visie op beveiliging tegen vergelijkbare aanvallen en cryptojacking in het algemeen.
Vergelijkbaar met hoe wij nu het Baways.com domein bezitten en het hebben omgevormd tot een educatieve website.
Het gebruik van oude domeinen die eerder zo werden gebruikt, kan andere problemen veroorzaken, zoals Troy Hunt onlangs ondervond.
Leuke / domme / idiote e-mail van de dag:
runt een dienst om instanties van auteursrechtelijk beschermde afbeeldingen die zonder licentie worden gebruikt te volgen. In maart stuurden ze me meerdere e-mails waarin ze geld eisten voor auteursrechtinbreuk. Vandaag kreeg ik er nog een waarin om vele honderden euro's werd gevraagd:
— Troy Hunt (@troyhunt)
Nu terug naar zijn aanbevelingen over dit onderwerp, zijn aanpak omvat het gebruik van CSP om browsers te laten negeren van commando's van elk domein dat niet expliciet is toegestaan. In zijn geval implementeerde hij na het beveiligen van het CoinHive domein een CSP die ervoor zorgt dat zelfs als kwaadaardige scripts worden geïnjecteerd, ze niet zouden worden uitgevoerd omdat ze niet van een toegestane lijst van domeinen zouden komen.
Naar onze mening is deze aanpak goed, maar niet genoeg. Kortom, CSP's zouden niet de enige beveiligingsmaatregel tegen 3rd-party JavaScript aanvallen moeten zijn. Onze vergelijkingspagina geeft een geweldig overzicht van de functies die we bovenop CSP's hebben geïmplementeerd om de best mogelijke veiligheid te bieden met betrekking tot 3rd-party script inbreuken.
Wij geloven dat de sleutel ligt in het analyseren van het volledige script voordat het de browser van de gebruiker bereikt. Natuurlijk brengt dit een paar uitdagingen met zich mee, waarvoor we oplossingen hebben ontwikkeld. Je kunt meer lezen over deze visie en hoe we 3rd-party scripts beveiligen hier.
