Wat ik een beetje mis, is heel WooCommerce lek, tot op de laatste versie van vandaag?
Dat dit bekende plugins zijn die ooit zijn gebruikt geloof ik, maar staat niks vermeld over kwetsbare versies etc.
Heb verschillende sites draaien, met verschillende plugins, sommige ook op deze lijst, paar tegen gekomen
op door de klant beheerde sites,
maar naar beter weten alles up-to-date ..

ben ik dan nog steeds zo lek als een mandje of was dat met versie xxx.xxx uit jaar xxx alleen het geval..

Ja dit artikel mist behoorlijk wat context.
Dit gaat namelijk om sites waarvan de beheerders geen updates draaien. De grotere en bekende plugins worden gepatcht en vormen geen bedreiging.
Het enkel noemen van namen zonder versienummers is net zo onzinnig als melden dat de Volkswagen Golf een gevaarlijke auto is omdat in de eerste versie geen ABS zat ofzo.

Scan dan hier voor een 'quick and dirty', ook voor ontbreken van plugin updates:
https://hackertarget.com/wordpress-security-scan/

En bedenk een gelikte site is nog geen veilige site.

#obserwator

Het probleem is dat er tussen het moment dat er een vulnerability is en er een update is die jij ook inderdaad geinstalleerd
hebt al een besmetting kan plaatsvinden en dan helpt updaten niet meer! Het is heel lastig om een site die eenmaal besmet
is nog schoon te krijgen, je moet in feite alles wegmikken (behalve hopelijk de database, maar dat is ook niet zeker!) en
opnieuw installeren.
Auto-updates aanzetten maakt recovery nog complexer, want dan kun je geen scan meer doen op files die de afgelopen
dagen veranderd zijn en dus de besmetting bevatten. Het update mechanisme is nogal dom: bij iedere update van een
plugin (of van wordpress zelf) worden ALLE files aangeraakt, zelfs als ze niet veranderd zijn in die update.

Het gaat dus in feite om het omgaan met de site, dus de juiste
website maintanance.

De makke is vaak dat de eigenaar van de website wel de beslissingen neemt, maar vaak zonder er voldoende verstand van te hebben.

Degenen, die de site vervolgens moeten onderhouden, kunnen dan niet doen wat ze moeten doen, nl. de veiligheid van de website onderhouden.

User enumeratie uitschakelen, directory listing uitschakelen, plug-ins en scripts goed onderhouden. Ook kunnen er dingen misgaan bij het beheer in een cloud.

Website security is ook iets dat je moet leren en komt niet iedereen aanwaaien.

Dus zoals met alles, valse zuinigheid maakt vaak dat men jaren schreit.

#obserwator

Dit gaat om WordPress in het algemeen. En ja je bent altijd lek. Het gaat erom of een lek gevonden is of niet. Versies bij deze plugins zouden een beter beeld geven gezien het veelal gaat om kwetsbaarheden in oudere versies van deze plugins.

Dit is wel een heel erg beperkte scan die ze uitvoeren. Beter is om zelf even in WordPress te kijken. Wanneer je twijfelt, tik de plugin naam en het woord Changelog in Google in en zoek daarin de versienummer op. De meeste ontwikkelaars hebben een Changelog en geven daarin ook aan wanneer die versie gereleased is.

Inderdaad. Als een site besmet is, helpt updaten doorgaans niet meer. De kans dat er uitvoerbare code in de database terecht is gekomen is erg gering. We zien dat nauwelijks omdat WordPress relatief weinig mogelijkheden biedt code vanuit de database uit te voeren. Het is overigens niet uit te sluiten.

Het opschonen is doorgaans een kwestie van alle code wegmikken en opnieuw op de server zetten en nog een aantal stappen zetten om herhaling te voorkomen. Het is even een rotklusje, maar wel veel effectiever en sneller dan alle malafide code opzoeken en verwijderen. Met name omdat die veelal direct opnieuw zal worden gegenereerd. We doen dit meerdere keren per week.

Dat WordPress alle bestanden aanraakt is niet erg. Wat ik al aangaf. In veel gevallen wordt code vrijwel meteen weer opnieuw gegenereerd en raak je daar zelf in een loop die veel tijd kost. In de praktijk scannen wij websites niet meer op code changes, al houden we daar wel een logboek van bij. We scannen veel meer op output van WordPress, waarvoor we AI hebben ontwikkeld. Die legt hacks doorgaans al binnen enkele minuten bloot.

Positief bedoeld, maar we zien wel een paar dingetjes in deze post waar we even op willen reageren, gezien we echt wel fans zijn van WordPress.

Het artikel dat als bron wordt aangehaald geeft aan dat er een Linux tool is die 30 methoden kan toepassen om toegang te krijgen tot WordPress op basis van lekken die soms al tot 7 jaar oud zijn, en in nieuwe versies van plugins veelal zijn gecorrigeerd.

Die plugins zelf zijn dus niet besmet met een backdoor. Ze bevatten een lek dat misbruikt kan worden om toegang te krijgen tot de betreffende websites. De term backdoor suggereert dat de ontwikkelaars bewust de deur open zetten om ongeoorloofd toegang te kunnen nemen/verlenen en is wat ons betreft niet de juiste term. Overigens wordt dit in de eerste paragraaf keurig genuanceerd.

Helaas is de kuur niet, zoals vaak wordt verondersteld, om code te updaten. Hoewel dat wel het gros van de hackers buiten de deur houdt, is plugin en themaselectie steeds vaker een probleem dat wij in het werkveld zien.

Er zijn grote organisaties die veelal afhankelijk zijn van de plugins en thema's die ze ontwikkelen. Die organisaties is er alles aan te doen om code snel en veilig te houden. Het zijn met name de hobbymatig ontwikkelde plugins die in veel gevallen al jaren geen updates meer hebben gekregen, die het gevaar vormen.

We krijgen weleens het verwijd dat een website is gehackt ondanks dat alle plugins keurig up to date werden gehouden... en dan zien we een plugin die 7 jaar geleden voor het laatst een update heeft gekregen. Of plugins en thema's waarvan het update mechanisme is verwijderd zodat er geen licentiekosten betaald hoeven te worden. Zogenaamde 'nulled' plugins en thema's. We zien dit soort foute keuzes niet alleen bij hobbyisten, maar ook bij websites van grote agencies. Het is een manier om de kosten te drukken en meer omzet uit een project te halen.

Cyber Security binnen WordPress krijgt vaak pas aandacht en budget na de eerste hack. Dit terwijl de website 24/7 haar best doet om iedereen aan te trekken.