Hackers vallen WordPress-plug-in aan door malware direct in code te verstoppen

Criminelen vallen WordPress-websites aan die van de WooCommerce-plug-in gebruikmaken. Daarmee hopen ze creditcardgegevens van online shoppers te stelen. De aanvallers injecteren malware in de WordPress-site.

De eerste signalen van de WooCommerce-aanvallen werden een paar dagen geleden opgemerkt door beveiligingsonderzoeker Ben Martin, die erover blogde nadat zijn beveiligingsbedrijf klachten van klanten kreeg. WooCommerce is een populaire gratis WordPress-plug-in waarmee webwinkels een eigen betaalmodule kunnen implementeren. Martin ontdekte dat criminelen op verschillende manieren WordPress-installaties binnen wisten te dringen en daar malware wisten toe te voegen aan standaard JavaScript-bestanden. "Het is natuurlijk niet de eerste keer dat WooCommerce en WordPress worden aangevallen", schrijft Martin. "Maar meestal bleef dat beperkt tot het aanpassen van de betaalinformatie in de plug-ininstellingen."

Volgens Martin zijn er in de huidige gevallen websites daadwerkelijk geïnfecteerd. Dat gebeurde doordat er code werd verstopt in JavaScript-bestanden waarmee de aanvallers het creditcardnummer en de cvv-beveiligingscode in plaintext opsloegen in cookies, schrijft de onderzoeker. De malware werd in de bestanden van de website zelf opgeslagen en niet vanaf bijvoorbeeld een externe server ingeladen, wat meestal het geval is. Hoeveel websites precies getroffen zijn door de malware, is niet bekend. WooCommerce draait op meer dan vijf miljoen sites.

De onderzoeker kon niet ontdekken hoe de aanvallers de websites in de eerste plaats wisten te infecteren. "Dat kan door een gecompromitteerd wp-admin-account komen, of door een sftp- of hostingwachtwoord te stelen of een ingang te vinden via kwetsbare software binnen de site." Martin geeft wel tips over hoe een aanval kan worden voorkomen. Dat kan door ervoor te zorgen dat de wp-admin-bestanden niet zomaar kunnen worden aangepast, namelijk door define('DISALLOW_FILE_EDIT', true ); aan wp-config.php toe te voegen.

Reacties (54)

[tom.cx]

Het is een bekend issue op Wordpress. Sites worden soms slecht ge-update en die zijn de sjaak. Vaak wordt het niet gedaan omdat een thema kapot kan gaan. Het is vaak te kostbaar om een thema bij te laten werken. Overigens. Als je statische content hebt raad ik altijd aan je Wordpress site te verstoppen achter bijv example.com/privegebied te zetten en in de hoofdmap een static site te plaatsen van de site. Dat kan je makkelijk doen met deze plugin: https://nl.wordpress.org/plugins/static-html-output-plugin/

[Reactie gewijzigd door tom.cx op 23 juli 2024 21:48]

[TheJoe]

Not compatible with WooCommerce.

[Jerie]

Het is geen bekend probleem met WordPress. Het is een bekend probleem met WordPress plugins. WordPress zelf is tegenwoordig relatief veilig, en ook makkelijk te updaten. Mensen updaten de plugins niet, of ze zijn door amateurs geschreven. Wat een recept is voor drama, icm PHP.

[levdbas]

Ik raad alle WordPress developers hier aan om https://roots.io/bedrock/ te gebruiken als basis voor je WordPress installaties. Dit zorgt ervoor dat zaken zoals define('DISALLOW_FILE_EDIT', true ); direct goed staan ingesteld om je installatie beter te beveiligen. Verder staan wachtwoorden buiten je root in een .env bestand.

[TheNephilim]

Zeker een mooie oplossing, maar wat doe je qua hosting? De meeste hosts bieden geen toegang tot een shell voor composer bijvoorbeeld.

[levdbas]

Voor kleinere projecten ben ik meestal gebonden aan kleinere hosts zonder shell toegang. Uitzonderingen zijn bijvoorbeeld Vimexx die o.a. composer en wp cli ondersteuning bieden. Maar ook zonder composer op je host kan je een hoop voor elkaar krijgen. Ik gebruik voor deze projecten ManageWP om eerste staging omgevingen te updaten om vervolgens de updates uit te rollen naar production.

[Xilonz]

De meeste hosts hebben tegenwoordig een shell.

Ik gebruik Deployer voor goedkopere websites, Trellis (van het zelfde team als bedrock) voor de sites die echt van de performance proviteren.

Op de discourse.roots.io word veel interessante informatie gedeeld over dat onderwerp.

[fantafriday]

Wel belangrijk op te merken is dat bij dit soort aanvallen de hele enabler externe afhankelijkheden als deze zijn.

[maradesign]

Laat ik er even een nettere reactie van maken. Azijn gehalte was wat hoog...exuses.

Voor developers is dit een mooie oplossingen. Mensen die een theme zelf kopen/installeren weten helaas niets van 'DISALLOW_FILE_EDIT' (zou standaard op true moeten staan wat mij betreft). En al helemaal niet van mooie oplossingen zoals bedrock.

Gelukkig doen veel hosters aan maatregelen zoals patch-man oid aan de kant van de hosting. Wat de gebruiker er zelf aan kan doen is alles up to date houden. Helaas moet je wel onderhoud plegen aan thema's op een gegeven moment, daar ontkom je niet aan. En als je het zelf niet hebt gemaakt, of een themeforest themer houd er mee op dan heb je een mooi probleem. Hoe meer plugins hoe meer er stuk / niet compatible kan worden. En soms moet je lang wachten tot sommige plugins compatible worden, met uitzondering van de populaire zoals woocommerce, yoast etc. En dat is zonde.

Het zijn vaak die draken van plugins zoals visual-composer met allemaal verwante plugins (sliders etc) waar je weinig goeds van hoort.

Als ik wordpress sites bouw dan doe ik dat met zo weinig mogelijk plugins.

[Reactie gewijzigd door maradesign op 23 juli 2024 21:48]

[wifikabelhuren]

"WooCommerce is een populaire gratis WordPress-plug-in waarmee webwinkels een eigen betaalmodule kunnen implementeren" volgensmij is het een webshop plugin

[Luchtbakker]

"WooCommerce is een populaire gratis WordPress-plug-in waarmee webwinkels een eigen betaalmodule kunnen implementeren" volgensmij is het een webshop plugin

Nee, het is een plugin dat je in Wordpress moet installeren. Hiermee maak je van je Wordpress site een webshop.

Wat ik mij trouwens afvraag is in hoeverre je creditcard gegevens kan stelen. Wordpress slaat namelijk vrijwel geen betalingsgegevens op. Betalingen lopen via een externe partij. (in mijn geval mollie). De betaalverwerker zegt alleen ja of nee, maar stuurt geen gegevens van de betaling door.

Ik kan mij niet voorstellen dat dit bij andere bedrijven anders werkt, maar correct me if i'm wrong.

[jasbroek]

Als je betaalgegevens buiten de webshop invult (zoals bij Mollie) zit je redelijk veilig. Je voert zoals je aangeeft geen creditcard gegevens in op de geïnfecteerde webshop, maar in de externe omgeving van Mollie.

Er zijn ook payment providers waar je al gegevens invult in de shop (kaartnummer en mogelijk cvv). Dat wordt dan meteen doorgestuurd naar de aanvallers.

Los van CC gegevens kunnen ze ook de waardes van andere velden 'afluisteren' zoals adres en wachtwoorden.

[jesse!]

Zoals ik uit het artikel opmaak, doen de hackers dit juist. Door javascript files aan te passen. Bijvoorbeeld een onclick event toe voegen aan de button die de creditcard gegevens verstuurd / verwerkt. En deze dan ook nog even in een cookie plaatst. Of verstuurt naar de hackers.

[Croga]

Zoals Luchtbakker al zegt kan dit helemaal niet. De creditcard gegevens worden nooit via Wordpress verwerkt, ook de knop die die gegevens verzend zit helemaal niet in de wordpress site, die zit in de site van de payment provider.

[memoryeffect]

Maar wat houdt een hacker dan tegen om via javascript te zorgen dat deze knop niet de pagina van de payment provider opent, maar wat creditcard velden tevoorschijn tovert?

Als je de javascript bestanden kunt aanpassen kun je de hele website op zo'n manier aanpassen dat het jou uitkomt.

[Croga]

Uiteraard. Maar aangezien je dan als website eigenaar nooit geld zult zien ga je dit heel snel ontdekken. Het doel van een hack is juist níet ontdekt te worden zodat je zo lang mogelijk de gegevens kunt blijven oogsten.

[FriXion]

Ze zijn dan nog wel zo slim om de bezoeker daarna alsnog door te sturen naar de betaalprovider natuurlijk.

[KeRsTmAnNeKe]

Denk dat het vooral bij Amerikaanse partijen anders werkt, daar is het veelal je creditcardgegevens in de webshop zelf invullen ipv via een losse PDP na betaling.

[darkpluisje]

Inderdaad, betaalmodules zijn weer een aparte stap binnen woocommerce via bijvoorbeeld Mollie of Stripe.

[bbob]

Verschil is dat men het hier heeft over een creditkaart module, waarbij je dan via de eigen site de betaling afhandelt. In de USa heb je sneller rechtstreeks een account bij een creditcard firma.
In NL heeft de shop dan gewoon een module waarbij de klant naar een payment provider gaat. Andere website en data blijft ook bij die payment provider. De payment provider geeft jou ook geen creditcardgegevens terug.

De hack is dus maar van toepassing op een klein aantal gebruikers.

[sumac]

Verschil is dat men het hier heeft over een creditkaart module, waarbij je dan via de eigen site de betaling afhandelt. In de USa heb je sneller rechtstreeks een account bij een creditcard firma.

....

De hack is dus maar van toepassing op een klein aantal gebruikers.

De hack is dus juist van toepassing op een groot aantal gebruikers. In de VS zitten immers veel meer woocommerce webshops dan in NL. Hier zal het inderdaad wel meevallen.

[bones]

Ja het maakt van je wordpress site een webshop door e-commerce functionaliteiten toe te voegen.

[Bensimpel]

Dat kan door ervoor te zorgen dat de wp-admin-bestanden niet zomaar kunnen worden aangepast, namelijk door define('DISALLOW_FILE_EDIT', true ); aan wp-config.php toe te voegen.

Dit is wel een goede tip, waarom wordt dit niet standaard in Wordpress toegepast? Kan dit nodig zijn om plugins te laten werken? Als ik dit aanpas in mijn wp-config.php bestand, blijven plugins gewoon werken?

Voor deze hack lijkt het wel alsof men SFTP en/of admin accounts hebben weten te bemachtigen. Dus als men in je SFTP kan komen kunnen ze niet alsnog de wp-config.php aanpassen??

[iApp]

Als de hackers kunnen inloggen via FTP, dan kunnen ze alles. Namelijk:
> Toegang krijgen tot de database en daar een eigen admin account aanmaken
> Malware toevoegen, of zoals in dit geval bestaande JS bestanden aanpassen
> Spamberichten versturen
> Je website platgooien

Bij mijn firewall sta ik een lijst met externe ip adressen toe die mogen inloggen via sFTP. Die lijst download de server ieder uur uit een private Github repository. Zo voorkom ik dat mensen ongewenst kunnen inloggen op poort 21/22, terwijl ik de flexibiliteit houd om zelf wijzigingen in het beleid door te voeren door de lijst in Github aan te passen.

[Reactie gewijzigd door iApp op 23 juli 2024 21:48]

[borft]

Waarom mensen in 2020 uberhaupt nog FTP gebruiken is mij een volkomen raadsel. Het is een achterhaald, ouderwets en inherent onveilig protocol (want geen encryptie, tenzij je het nog obscuurdere ftps gebruikt). Er zijn veel betere oplossingen voor, zoals bijvoorbeeld sftp, of rsync over ssh.

Je webserver toestaan om files in de web applicatie aan te passen is natuurlijk ook van de zotte, dat getuigt gewoon van rotte architectuur. Beter zijn bestanden van je web applicatie alleen door een andere uiser te schrijven. Als je per se configuratie aan wilt kunnen passen, schrijf die dan ergens in bv een database, en op zo'n manier dat het niet uitvooerbaar is, of direct benaderbaar vanaf het web.

[Foamy]

Alles blijft gewoon werken. Je kunt enkel via het dashboard geen bestanden meer rechtstreeks wijzigen. En aangezien veel mensen dat toch nog doen staat dit standaard ingeschakeld. Veel gebruikers weten gewoon niet hoe je thema en plugin-wijzigingen via FTP doorvoert.

[Bensimpel]

Ah helder, ja ik pas vaak style dingen aan via de dashboard, maar admin account en SFTP wachtwoord pas ik gewoon iedere maand aan, (random, niet opvolgend). Dat is gewoon een standaard checklist die ik iedere maand doorvoer.

Kan ik ook via de SFTP maar dat is wat omslachtiger.

[bones]

Ja de tip is zinloos als ze ftp toegang hebben. Het zorgt er alleen voor dat je binnen Wordpress geen bestanden kunt aanpassen.

[Reactie gewijzigd door bones op 23 juli 2024 21:48]

[huiz]

Je kunt het ook in je child theme functions.php plaatsen.

Het beste is sowieso om je FTP login niet hetzelfde te maken als je DB toegang. Dan kunnen ze alleen via je admin-account naar binnen.

Als je een nieuwe WordPress installatie doet en checkt wie er allemaal inlogt, dan zie je soms al binnen een paar uur talloze pogingen vanuit Oekraine en die kant op. Standaard kun je onbeperkt blijven inloggen op WordPress.
Ik installeer altijd een plugin die het fout inloggen beperkt en meestal hernoem ik wp-login.php naar iets anders tot ik zelf weer eens wil inloggen. Even via FTP herstellen, inloggen en daarna de naam weer wijzigen. Zolang in je browser het login-cookie geldig is, hoef je zelf ook niet gebruik te maken van wp-login.php.

Het nadeel is wel dat je geen nieuwe gebruikers kunt aanmaken (bijvoorbeeld via reactiemogelijkheid of via WooCommerce).

[Anoniem: 58485]

Dan kunnen ze alleen via je admin-account naar binnen.

En vervolgens "upload" ik een dummy thema wat een payload/backdoor heeft en voila, ik ben binnen, want ik kan immers je wp-config.php uitlezen.

[bones]

Zover ik weet klopt die tip van Martin niet. Met zijn code kun je alleen vanuit wordpress admin zelf geen bestanden aanpassen. Maar als iemand ftp of hosting account toegang heeft dan kan dat alsnog.

Verder is het raar dat er niet meer info is, er worden dagelijks wordpress sites aangevallen, met en zonder woocommerce. Het artikel doet nu vermoeden alsof er een lek is in woocommerce maar dat is helemaal niet zeker.

[Reactie gewijzigd door bones op 23 juli 2024 21:48]

[Foamy]

Dat is ook niet de letterlijke tip die in de bron wordt gegeven:

One thing I would recommend to everyone concerned about the security of their WordPress website is to disable direct file editing for wp-admin by adding the following line to your wp-config.php file:

Het is dus een algemene beveiligingstip, en niet zozeer een tip tegen deze specifieke hack.

Uit de bron wordt ook niet meer informatie beschikbaar. Daar staat echter wel aangegeven dat dit niet perse een lek in WC hoeft te zijn, maar dat hackers zeer waarschijnlijk via een alternatieve route bestanden op de site gewijzigd hebben.

[stftweaker]

Belangrijkste is. Welke versies van woocommerce zijn getroffen? En wanneer komt de patch?

[R4gnax]

Belangrijkste is. Welke versies van woocommerce zijn getroffen? En wanneer komt de patch?

Het is geen lek in WooCommerce.
De noviteit hier is dat aanvallers na in een Wordpress installatie binnen te zijn gedrongen, hun malware payload direct in de WooCommerce JS files geplaatst hebben ipv een nieuw los JS bestand toe te voegen.

Dat maakt het moeilijker om op het oog te realiseren dat je site geinfecteerd is.
Dat is alles.

Gevalletje komkommertijd.

[thepelikan]

Het bericht is beetje geschreven alsof het lek in WooCommerce zelf zit. De onderzoeker heeft hier geen aanwijzingen voor gevonden. Als je het originele bericht leest dan zie je dat dit soort aanvallen zich richten op het stelen van creditcard gegevens. Ook websites die gebruik maken van de betaal modules van Stripe worden aangevallen.

[R4gnax]

Ook websites die gebruik maken van de betaal modules van Stripe worden aangevallen.

Stripe's widget voor credit card betalingen draait binnen een iframe op een ander domein en die communiceert op geen enkele wijze de CC gegevens terug naar het domein van de website zelf.

Sites die gebruik maken van Stripe zullen heus ook wel aangevallen worden, maar zijn zeer zeker niet zo makkelijk te exploiteren als het geval is wanneer een stukje malicious javascript met een simpele onchange event listener naar de inhoud van je CC-nummer en CVC veld kan luisteren.

[Glodenox]

Tja, als men de bestanden op een server kan aanpassen via FTP of kan inloggen als admin is het sowieso game over qua beveiliging. Dat is van toepassing op eender welke server en het gebruikte framework maakt dan niet uit. Anderzijds kan het uiteraard geen kwaad om de exacte oorzaak te vinden hiervan als dit redelijk vaak lijkt voor te vallen. Men moest toch maar eens een kwetsbaarheid gevonden hebben.

[iApp]

Beetje apart bericht. Er wordt in verteld dat Woocommerce webwinkels worden geinfecteerd, maar niet welke. Ik kan mij voorstellen dat het brocanterie winkeltje op de hoek het niet zo nauw neemt met de beveiliging, terwijl grotere webwinkels met een VPS en een consultant in dienst alles wel op orde lijkt te hebben.

Kortom: hebben we het nu over bestaande lekken (dus slordig met inloggegevens omgaan), of is de Woocommerce plug-in zo lek als een winkelmandje? Ik lees het er niet in terug.

[Kenhas]

De onderzoeker kon niet ontdekken hoe de aanvallers de websites in de eerste plaats wisten te infecteren

Dat maakt het natuurlijk ook wel een stuk moeilijker om te zeggen wie/wat er geïnfecteerd is.

[MediQ]

Dat kan door ervoor te zorgen dat de wp-admin-bestanden niet zomaar kunnen worden aangepast, namelijk door define('DISALLOW_FILE_EDIT', true ); aan wp-config.php toe te voegen.

Dat is niet wat die functie doet. Het staat ook niet helemaal duidelijk in het bron-artikel. DISALLOW_FILE_EDIT zorgt ervoor dat het niet meer mogelijk is vanuit de wp-admin-omgeving om plugin en theme bestanden aan te passen. Dat geeft dus enige bescherming als kwaadwillenden in je wp-admin kunnen komen, bijv. door een admin account te hacken. Zie ook
https://wordpress.org/support/article/editing-wp-config-php/#disable-the-plugin-and-theme-editor