Honderdduizenden Wordpress-sites aangevallen via kwetsbaarheid WPGateway-plug-in

Door een zero-day in de Wordpress-plug-in WPGateway zijn meer dan 280.000 websites aangevallen. De kwetsbaarheid maakt het mogelijk voor aanvallers om een eigen admin-gebruiker toe te voegen aan het cms. Er is nog geen patch voor de kwetsbaarheid.

De kwetsbaarheid is ontdekt door het Wordfence-team, dat actief aanvallen op Wordpress monitort. Het team was in staat om meer dan 280.000 aanvallen te detecteren en tegenhouden via zijn eigen plug-in. Het team heeft sinds de ontdekking begin september 4,6 miljoen aanvallen gedetecteerd. Beheerders gebruiken WPGateway om bepaalde taken te vereenvoudigen, zoals het maken van back-ups en installeren van nieuwe plug-ins en thema's.

De zero-day staat bekend als CVE-2022-3180. De makers van WPGateway hebben nog geen patch uitgebracht. Daarom is alleen bekendgemaakt dat criminelen de kwetsbaarheid actief misbruiken en dat aanvallers in staat zijn om via deze zero-day volledige beheerdersrechten te krijgen over een Wordpress-website.

Websitebeheerders die de plug-in gebruiken, zouden er goed aan doen deze voorlopig te verwijderen, zo luidt het advies. De plug-in is dan weer te gebruiken als er een patch is. Beheerders kunnen controleren of ze zijn aangevallen door te kijken of er in de afgelopen maand een onbekende beheerder is toegevoegd aan de gebruikers van de website.

Reacties (53)

[Coolstart]

Wordpress blijft een kaas met gatenmodel zolang die plugins toegang hebben tot elke bit. En tegelijk heeft het ze groot gemaakt. Het is niet te tellen hoeveel plugins gehackt zijn geweest. Soms zelfs bewust.

Zeker plugins zoals deze die de installatie mee vergemakkelijken hebben root toegang nodig om te kunnen werken. Als daar dan breach is, is de schade groot.

Heb zelf veel WP sites ontwikkeld. (10jaar, non-stop) Je moest uw weg wat kennen want standaard ben je een vogel voor de kat. Brute force attacks, plugins die plots teveel ram op cpu verbruiken zonder dat je het doorhebt, virussen, malware.

Het risico werd enkel maar groter zodra de site groter werd, bekender was etc.

Je probeerde enkel deftige plugins te gebruiken en firewalls goed in te stellen op de server maar zelfs dat is een job op zich. Op een gegeven moment zijn we overgeschakeld op managed WP servers puur voor security & performance (Wp-engine).

Als je professioneel WP sites bouwt kan ik alleen maar aanraden om een top klasse Managed WP hosting te gebruiken en niet zelf iets te installeren op een server want vroeg of laat loopt het mis.

In dit geval zou de managed hosting de aanval opmerken en zelf alle betrokken plugins blokkeren.

[Reactie gewijzigd door Coolstart op 25 juli 2024 11:17]

[bones]

De hosting (ook wp-engine) is niet hetgeen wat voor deze hacks zorgt. Dit is hosting onafhankelijk. Heb hacks meegemaakt op alle grote hosting platformen.

Het probleem zijn de plugins die kwetsbaarheden bevatten, waardoor een hacker toegang krijgt tot de admin, en daar dan weer zelf een eigen plugin op kan installeren waarmee hij volledige toegang heeft.
Ook klanten admin (en dus toegang tot de plugins) geven is een slechte zaak. Veel websitebouwers doen dat omdat de klant dat kraag wil, maar dat is echt vragen om problemen.

Ikzelf heb 2FA en ip-restricties op de admin van alle websites die ik beheer, en klanten krijgen slechts beperkte rechten. Heb sinds ik deze methode gebruik 0 hacks meegemaakt (en beheer meer dan 100 sites).

[Coolstart]

Die goede managed servers gaan die plugins monitoren. Uw eigen server doet dat niet. Ip restricties en 2fa hadden we ook op managed dus zelf hosten is altijd extra gevaarlijk.

[Reactie gewijzigd door Coolstart op 25 juli 2024 11:17]

[Oon]

Wat is dit voor onzin

Op mijn eigen shared hosting VPS monitor ik wijzigingen, keur ik plug-in updates zelf goed, heb ik fail2ban ook voor WordPress ingesteld, heb ik 2FA afgedwongen en heb ik de mogelijkheid tot IP filters.

Ik heb veel websites gehad die gehackt werden, maar nog geen enkele WordPress. Is gewoon een kwestie van geen vage lage kwaliteit plugins gebruiken. Hosting heeft er geen reet mee te maken, en juist die wordpress-specifieke hosts zijn niet interessant voor grotere websites, want daar loop je snel tegen performance problemen aan die je niet binnen WP opgelost gaat krijgen.

Een beetje kennis en dingen fatsoenlijk opzetten brengt je veel verder dan zomaar in de marketingtaal van dat soort diensten trappen

[bones]

Precies hosting is niet het probleem. Bij wp-engine kun je ook gehackt worden.

[RobertPeterson]

IP restricties en 2FA kun je niet op een eigen server zetten? Je kunt op een normale Plesk of Cpanel server alles zelf monitoren.. Malwarescans en alles.

Dat heeft echt niks met je hosting te maken, maar met de serverbeheerder. Kun je geen server beheren besteed het dan uit, kun je dit wel dan heb je met Plesk, Cpanel etc genoeg opties om een veilige server te maken die de websites voor je monitort en bijv direct in quarantaine gooit wanneer er iets echt mis is.

Installeer daarnaast Cloudlinux zodat elke website in een eigen container draait en je hebt weinig tot geen risico.

[bones]

Heb ook met de monitoring van wp-engine al hacks meegemaakt daar. Het heeft niks met de hosting provider te maken maar met het beheer en configuratie van de website.

[ggroen1]

Goede suggesties. Ik ga er naar kijken. Wat zou je adviseren voor het afdwingen van 2FA en IP-restricties? Dan kom je ook weer bij plug-ins uit lijkt me?

[bones]

Voor de restrictie geen plugin, gewoon via ftp de .htaccess aanpassen voor ip restrictie.
Zie bijvoorbeeld deze link: https://www.wpbeginner.co...iting-access-in-htaccess/

Voor 2fa gebruik ik wel een plugin, deze: https://wordpress.org/plugins/wp-2fa/

[Klauwhamer]

Ik begrijp niet zo goed dat je met zoveel ervaring alsnog zoveel issues hebt gezien en uiteindelijk kiest om risico te mitigeren door managed hosting te kiezen. Uiteindelijk heb je een WP-core met plugins, je weet dus wat de WP-stack behelst. De infra-stack naar "buiten" is ook bekend, inclusief mogelijke vulnerabilities en de genomen hardeningmaatregelen. Uiteraard kun je eens pech hebben, maar zóveel pech dat je managed hosting adviseert?

[Coolstart]

Ik zie geen reden om nog zelf te hosten buiten dat het goedkoper is.
Performance & security zijn gewoon goed geregeld. Beter dan je ooit zelf kan organiseren.

De meeste narigheid gebeurde natuurlijk in the early days. Dat is al een hele tijd geleden. Nadien toen ik besefte hoe kwetsbaar Wordpress en zijn plugins waren ben ik net zoals iedereen extra lagen veiligheid beginnen opzetten. IP restricties, VPN, Plugins handmatig uitschakelen etc.

Je kan nog steeds beweren dat zelf hosten beter is omdat jij toevallig gespaard bent gebleven van maar ik raad het niet aan omdat eigen hosting te voorzien. Zeker als je met meerdere devs zit te werken.

Er is zoveel geregeld en vooral beter geregeld. Ik sprak van performance & Security. Beide dus.
Een paar uit men hoofd:

- Scalability (incl pieken van hoge CPU load opvangen)
- Instant page loads (Net zoals static)
- Dev, staging & production sites
- Klanten management & billing
-Continu monitoren van plugins.

[Klauwhamer]

Maar ik stel helemaal niet dat zelf hosten beter is, ik vind het alleen opmerkelijk dat je met zoveel ervaring alsnog kiest om de stack onder te brengen bij managed hosting om security risks te mitigeren. Specifiek dat vind ik vreemd.

Als je professioneel bent zou ik een rack huren bij een datacenter en zorgen voor voldoende resources zodat je scalability en load balancing kunt faciliteren, evenals een OTAP als dat nodig is. Tsja. Ik weet niet, maar het lijkt alsof je frontend / commercieël georiënteerd bent. Misschien ben ik te veel backend geörienteerd.

[mpol]

"zou ik een rack huren bij een datacenter"

Maar dat is toch zelf hosten? Ik neem aan dat zelf hosten niet gaat over je raspberry pi thuis achter je modem.

Ik ben het met je eens dat ik de stap van zelf hosten naar managed hosting een erg grote vind. Shared hosting bij een goede provider zou al veel problemen kunnen voorkomen.

[Klauwhamer]

Ja, dat is "zelf hosten", maar waarom vraag je dat?

[mpol]

"Maar ik stel helemaal niet dat zelf hosten beter is"

Waarna je vervolgens wel adviseert om een rack te huren. Je spreekt jezelf tegen in beide berichten

[RobertPeterson]

Volgens mij lopen zij vast haha.

Er is zoveel geregeld en vooral beter geregeld. Ik sprak van performance & Security. Beide dus.
Een paar uit men hoofd:

- Scalability (incl pieken van hoge CPU load opvangen)
- Instant page loads (Net zoals static)
- Dev, staging & production sites
- Klanten management & billing
-Continu monitoren van plugins.

Ik denk dat Coolstart vooral denkt: goh wat is het allemaal lekker geregeld bij managed hosting, deze dingen zijn allemaal geregeld en ik hoef me nergens zorgen om te maken.

Terwijl klauwhamer denkt, huh dat zijn geen voordelen aan managed hosting, dat is gewoon een normale server.

[Reactie gewijzigd door RobertPeterson op 25 juli 2024 11:17]

[Klauwhamer]

Euh, wat ik schreef was gericht op Coolstart z'n opmerking "Je kan nog steeds beweren dat zelf hosten beter is omdat jij toevallig gespaard bent gebleven van maar ik raad het niet aan omdat eigen hosting te voorzien." -- Ik heb nooit beweerd dat zelf hosten "beter" is (en het stoort mij dat dit zijn of haar lezing is).

Ik heb gezegd wat ik zou doen, als ik professioneel Wordpress-sites zou bouwen en hosten. Dat is niet per se advies aan anderen.

[P_Tingen]

Je hebt professionaliteit op verschillende vlakken en ik kan me prima voorstellen dat je als WP-bouwer geen verstand hebt / geen verstand wil hebben van het installeren en hosten van WP. Dan kun je dat dus beter uitbesteden aan iemand die dat wel kan en wil.

[Oon]

Performance & security zijn gewoon goed geregeld. Beter dan je ooit zelf kan organiseren.

Er is zoveel geregeld en vooral beter geregeld. Ik sprak van performance & Security. Beide dus.
Een paar uit men hoofd:

- Scalability (incl pieken van hoge CPU load opvangen)
- Instant page loads (Net zoals static)
- Dev, staging & production sites
- Klanten management & billing
-Continu monitoren van plugins.

Dat jij weinig of geen kennis hebt van servers betekent niet dat het een feit is dat ergens anders hosten beter is.

Alles dat jij noemt kan voor 5 euro per maand op een willekeurige cloud host zoals DigitalOcean of Linode, of als je het breder wil trekken AWS of Azure. Je moet alleen de kennis hebben als je het zelf wil doen.

Ik vind het vreemd dat je doet alsof je expert bent in WordPress en alsof ergens anders hosten absoluut de beste optie is, terwijl het toch wel duidelijk is dat je maar weinig kennis hebt. Misschien eerst leren hoe je zelf voor performance en security zorgt voordat je een dienst gaat aanraden die onnodig duur is en geen voordelen biedt behalve dat je zelf niks meer hoeft te doen.

[mcompagner]

Een gedachtegang die ik altijd gebruik is door plug-ins te gebruiken die op veel sites gebruikt wordt, hierdoor is de kans kleiner dat er iets malafide mee gebeurd. Verder ook goede managed servers gebruiken en actief monitoren op lekken via bijvoorbeeld ManageWP.

[RobertPeterson]

De kans is kleiner wanneer een plug-in op veel websites wordt gebruikt? Dat reageer je in een artikel waar net 280.000 websites zijn aangevallen. Toch een vrij populaire plug-in niet?

[mpol]

Toch blijft het erg lastig om te beoordelen welke plugin redelijk veilig is en welke niet.

In de plugin directory op wordpress.org worden reviews gedaan voor nieuwe plugins, maar de updates worden minder streng gemonitord. Aantal installaties, reviews, eerdere beveiligingsproblemen en hoe die opgelost zijn, het telt allemaal wel mee. Zelf de code bekijken kan ook, maar voor een grote plugin is dat niet te doen.

Bij premium plugins is er helemaal geen standaard review. Toch zijn er veel mensen die aannemen dat betaalde plugins beter zijn. In dit geval is dat niet zo, de gradatie van het lek is nogal heftig met een "unautheticated admin" escalatie.

[RobertPeterson]

100%! mijn vuistregel is altijd: Werk met zo weinig mogelijk plug-ins, en monitor de plug-ins die lang niet worden geupdate.

Ik vond alleen zijn gedachtegang wel mooi, gebruik alleen plug-ins die populair zijn, zo is de kans kleiner dat het een malafide plug-in. Dat onder een artikel van een plug-in die dus 4,6 miljoen websites blootsteld. Vond ik ironisch!

[Brahiewahiewa]

De kans is kleiner wanneer een plug-in op veel websites wordt gebruikt? Dat reageer je in een artikel waar net 280.000 websites zijn aangevallen. Toch een vrij populaire plug-in niet?

Het zijn er ondertussen zelfs 4,6 miljoen

[laptopleon]

Er zijn naar schatting zo’n 64 miljoen Wordpress sites, dus je moet dit wel in het juiste perspectief blijven bekijken. 13/14e heeft deze plug-in niet.

@RobertPeterson

De kans is kleiner wanneer een plug-in op veel websites wordt gebruikt?

Dat het niet waterdicht is en dat er ook grote aantallen slachtoffers kunnen vallen doet er niets aan af dat de stelling in het algemeen best waar kan zijn.

[Reactie gewijzigd door laptopleon op 25 juli 2024 11:17]

[Brahiewahiewa]

Er zijn naar schatting zo’n 64 miljoen Wordpress sites, dus je moet dit wel in het juiste perspectief blijven bekijken. 13/14e heeft deze plug-in niet...

13/14e is nog niet aangevallen. Je weet niet waarom dat is. Er zondermeer van uitgaan dat het is omdat ze die betreffende plug-in niet draaien is een gevaarlijke veronderstelling

[laptopleon]

Ik kan trouwens nergens die 4,6 miljoen terugvinden en uit het commentaar hieronder en persberichten blijkt dit cijfer een misverstand te zijn.

Hoe dan ook heb je er niet zo veel aan, als websitebeheerder, of er nou veel of weinig anderen hetzelfde probleem hebben.

Waarom ik denk dat je beter een populaire plugin kunt kiezen is simpelweg kapitalisme: Een plugin up to date houden, kost tijd en moeite. Veel plugins leveren nauwelijks wat op, waardoor de maker er het minimale aan doet, net genoeg om het beschikbaar te houden, laat staan dat hij actief gaat zoeken naar beveiligingsgaten of nog beter: Daar onderzoek naar laat doen door een professionele club.

Bij een plugin waar flink geld aan verdiend wordt, zijn de belangen om dat zo te houden ook flink groot. Vaker zijn het ook grotere bedrijven, die meer kennis in huis hebben en een reputatie die ze niet kwijt willen.

[RobertPeterson]

De stelling kan best waar zijn, maar het aantal gebruikers is niet inherent aan zero days of andere vurnabilities.

Enkele voorbeelden hiervan zijn de breaches in de volgende plug-ins:

Google Site Kit https://www.wordfence.com...er-search-console-access/

Duplicator https://www.wordfence.com...cts-over-1-million-sites/

GDPR Cookie content https://blog.nintechnet.c...ugin-fixed-vulnerability/

De pagebuilder van Site Origin https://www.wordfence.com...cts-over-1-million-sites/

Ik snap de logica wel, maar de grote jongens zijn de afgelopen jaren heel vaak gewezen op kwetsbaarheden. De logica de andere kant op kan ook waar zijn. Hoe groter de plug-in hoe meer "hackers" zoeken naar kwetsbaarheden in hun plug-in. Heb jij een plug-in die door 10 wordpress sites wordt gebruikt, waarom zouden ze dan de moeite doen om een vulnerabilitie te zoeken.

[laptopleon]

Klopt, niemand gaat moeite doen om een plug-in die nauwelijks gebruikers heeft, uit te pluizen op een veiligheidslek.

Daarom bewijst het omgekeerd net zo goed niks dat er genoeg voorbeelden te vinden zijn van lekken in populaire plug-ins, want ja, dat zijn bij wijze van spreken sowieso de enige die interessant zijn om te hacken.

Maar goed, hier komen we toch niet uit want er zijn sowieso geen concrete cijfers over bijvoorbeeld geleden schade te vinden, gerelateerd aan grote of juist minder populaire plug-ins.

Ik hou zelf al heel wat jaren een stuk of 15 wordpress sites overeind, met diverse plug-ins, bij diverse hostingbedrijven. In al die jaren is er nauwelijks iets vermeldenswaardigs misgegaan. Één keer heb ik een soort slapende malware gevonden waarvan nooit duidelijk is geworden wat het doel was, zonder schade, nadat een klant zelf had zitten hobby-en. Ooit is een hostingbedrijf zelf gehackt via een andere site. Nou ja, gehackt in zoverre dat de server een paar uur offline ging, tot de backup teruggezet was.

In de praktijk zijn van al die miljoenen sites er maar betrekkelijk weinig interessant om te hacken, want de meeste bevatten geen interessante gegevens. Meeste zijn in feite niet veel meer dan een digitale folder van een bedrijfje of sportvereniging of zo.

[RobertPeterson]

Ben benieuwd waar het eindigt!

[mpol]

Aantal aanvallen en aantal websites die zijn aangevallen is natuurlijk niet hetzelfde als het aantal actieve installaties van de plugin. Bij premium plugins wordt dat gewoonlijk niet gepubliceerd, al zouden de mensen van WordFence wel een schatting kunnen maken en publiceren.

"The Wordfence firewall has successfully blocked over 4.6 million attacks targeting this vulnerability against more than 280,000 sites in the past 30 days."

[RobertPeterson]

Hier boven werd op mij gereageerd, ik dacht dus dat 4,6 miljoen websites gecompromitteerd waren.

Premium plug-ins hoeven en kunnen niks publiceren aangezien het om een aanval op de website gaat, plugins zijn natuurlijk niks anders dan self hosted software. Hierover hebben ook premium plug-ins lang niet altijd data over hoe dit gebruikt word en of dit aangevallen wordt. Het verschil tussen een premium en een freemium plug-in is de licensie code. niet de manier waarop het werkt.

Wordfence detecteert aanvallen op een wordpress bestanden, of het nu om gratis of betaalde plug-ins gaat.

Wel was op deze 280,000 websites dus ook wordfence geinstalleerd.

[superior_1986]

Niks is veilig, zelfs besturingssystemen zijn niet 100% beschermt. Probleem van plugins is dat mensen zonder budget/tijd gratis of 'makkelijke' oplossingen zoeken die openbaar zijn. Hierdoor is code leesbaar en kan je de gaten/lekken makkelijker vinden en bovendien zelf ook testen of het daadwerkelijk werkt.

Zie ook met front/back-end libraries genoeg fout gaan, de impact van de WordPress-plugin is gewoon enorm intressant als je ruim 280.000 sites met 1 fout kan overnemen.

Pas geleden nog gezien dat er veel websites hun .env in de root laten staan (config bestand) deze kan je via Google zoekmachine met weinig tot geen moeite vinden. Complete gmail accounts en database toegang is hierin niet uitgesloten die staan daar ook in.

Dus is het dan specifiek WordPress die voor de gatenmodel zorgt, in mijn mening niet.

[MazDaMan1970]

De kracht van WP zit hem in de gebruikersvriendelijkheid en daarom is het ook het meest populaire CMS. En als iets populair is... Tja, dan krijg je het 'Windows-effect'.
Ik persoonlijk ben meer fan van Joomla, wat naar mijn mening iets beter in elkaar zit, maar hiervan is de leercurve een stuk hoger.

[Alfa1970]

Een firewall instellen doet niets om dit soort problemen op te lossen.
Je laat poort 80/443 open staan om de site bereikbaar te maken.
Dus hebben aanvallers alle toegang die ze nodig hebben.

Het probleem met websites die gebakken zijn met tools zoals deze is dat men die tools laat slingeren op de website. Wat men feitelijk zou moeten doen is een scheiding maken tussen de ontwikkel omgeving waar de website op wordt ontwikkeld, en de productie omgeving waar de website wordt gehost.

De ontwikkel omgeving zou onmogelijk bereikt moeten kunnen worden vanaf het productie net. (aka het internet).
Door die scheiding kun je een groot deel van de problemen, zeker degene waar het nu over gaat, voorkomen. Bijkomend probleem is echter dat voor de functionaliteit van de website een deel van de code noodzakelijkerwijze wel beschikbaar moet zijn.

Dus je kan wel zeggen dat WP een gatenkaas is, maar, de manier waarop het gebruikt wordt is voor een groot deel mede verantwoordelijk voor het wijdverbreide misbruik.

Elk stukje code is in potentie een kwetsbaarheid.
Ik ben de laatste tijd aan op youtube aan het kijken naar afleveringen over hacks en de kwetsbaarheden die men daar laat zien zijn mind boggling.
Het gaat om zaken die functioneel helemaal functioneren zoals het hoort te zijn, maar toch door een kleine vergissing de deur open zetten voor een hack.

Het is erg lastig om zulke problemen te vinden.
Ja het zijn bugs, maar het zijn geen bugs die de beoogde functionaliteit in de weg staan, dus bestaande QA tests, unit tests en dergelijke gaan dit soort bugs niet vinden.
Er moet een heel ander soort tests worden ontwikkeld wil je dit soort problemen op gaan sporen, om te kunnen isoleren waar het probleem exact zit en dan ook nog een methode vinden om het probleem op te lossen zonder de beoogde functionaliteit aan te tasten. (Pen tests zijn een deel van die nieuwe methodes, maar niet afdoende imo.)

[Zoop]

Zoals @Oon ook zegt, wat is dit een lading onzin zeg. Alsof je plugins niet kan monitoren op een VPS? Daar heb je echt geen WP Engine voor nodig hoor.

Wordpress is dan ook echt niet bijzonder, of een uitzondering op iets, de security maatregelen die je moet nemen om je WP site hacker-vrij te houden gelden evengoed voor ieder ander project. Ja sure, WP is een prime target voor hackers en met name dmv de plugins, maar dat gevaar schuilt echt evengoed in iedere andere vorm van website. Als je denkt dat het daarvoor niet even hard nodig is als voor WP dan geloof je in Security through obscurity "ik zit wel goed, want niemand gaat dit toch hacken". Verkeerde gedachtegang imo.

Dus stel je moet een ander CMS systeem gebruiken zoals Drupal, die hebben ook plugins, die kunnen ook vies spul bevatten, again, sure, bij Wordpress zal het sneller gebeuren, maar je hebt echt absoluut geen fancy hosting nodig om je hiervoor in te dekken.

[MrHarry]

beetje offtopic maar puik dat tweakers ook security dingen post die van grote impact is.

[Luchtbakker]

beetje offtopic maar puik dat tweakers ook security dingen post die van grote impact is.

Het is eerder triest dat dit opvalt. Het zou gewoon dagelijkse kost moeten zijn. Maar leaks over nieuwe designs van producten levert een hoge click byte op en dat vind TMG minder leuk.

Ontopic: mijn website heeft helaas ook met de aanval te maken gehad.

[vanaalten]

Tweakers.net is veel breder dan security-topics. Nieuwsberichten gaan over games, auto's, tech-algemeen en ga zo maar door.

Als je security-topics als dagelijks kost wil, kan je denk ik beter een site pakken die alleen over security gaat. Zo iets als https://www.security.nl/ bijvoorbeeld (al weet ik niet of er betere alternatieven zijn, ik zit niet zo in de security-hoek).

[HKLM_]

Aangezien je over TMG praat heb je geen idee waarover je praat

[Skit3000]

Wat is er specifiek gedaan met jouw site? "Alleen" een extra adminaccount is nog geen probleem zolang die niet gebruikt is om andere dingen aan te passen.

[Luchtbakker]

Wat is er specifiek gedaan met jouw site? "Alleen" een extra adminaccount is nog geen probleem zolang die niet gebruikt is om andere dingen aan te passen.

Er is in mijn geval een rare plugin geïnstalleerd met een dsfihasfhfs naam, en heeft vervolgens alle content verwijderd. Op zich niet bijzonder want ik hield back-ups bij, maar wel vervelend voor de mensen die het niet doen.

[Reactie gewijzigd door Luchtbakker op 25 juli 2024 11:17]

[RVervuurt]

Dit hebben ze altijd gedaan. Hier wat voorbeelden betreffende alleen Wordpress:
nieuws: WordPress rolt geforceerd update uit tegen kwetsbaarheid in UpdraftPl...
nieuws: WordPress installeert geforceerd beveiligingsupdate voor Jetpack-plug-in
nieuws: WordPress informeert gebruikers week na uitbrengen patch over ernstig...

[Mangu429]

beetje offtopic maar puik dat tweakers ook security dingen post die van grote impact is.

Je doet net alsof dit de eerste keer is.
Dit soort berichten komt hier met grote regelmaat langs.

[P_Tingen]

Voor de zwemvereniging beheer ik de (WP) website en die probeer ik zo goed als ik kan dicht te timmeren, maar ik ben developer, geen beveiliger.

Een van de maatregelen is een geautomatiseerde backup naar google drive. Daar gebruik ik nu de plugin UpDraftPlus voor, maar zijn er betere alternatieven?

[Oon]

Een goeie developer heeft ook de nodige kennis van security. Een security consultant zal altijd net iets verder kunnen gaan, maar je zou toch op z'n minst moeten weten wat je waar dicht kan timmeren en waar de grootste risico's zitten.

Een mooi startpunt is bijvoorbeeld een whitelist voor de PHP bestanden die direct mogen worden aangeroepen, in principe is dat alleen index.php en de login en hoofdpagina in wp-admin (maar die kan dan weer achter een IP filter waardoor verder afschermen minder belangrijk is).

Heel veel van de hacks zitten in direct aanroepbare bestanden, niet valideren van input van gebruikers, en in assets waar een leuk docs.php bestandje inzit dat zo lek als een mandje is. Als je even scant op PHP bestanden en kijkt wat er wel aangeroepen moet worden dan kun je heel snel die selectie doen.

En daarnaast dingen als het RPC endpoint uitzetten, want die heb je absoluut niet nodig op 99% van de WP websites

[syl765]

Er zijn helaas heel wat wordpress ontwikkelaars die het allemaal niet zo nauw nemen. Regelmatig gebeurde het dat een klant aangaf dat een bepaalde plugin niet werkte na een update of andere zaken, hoevaak wij dan terwijl we nog aan het zoeken waren al een bericht kregen, we hebben het al opgelost door plugin y te installeren. Niets testen, gewoon een andere proberen en als het weer werkt, dan is alles weer koek en ei.

Maar goed het blijft een spannend platform!

[Saven]

Tja, elke koekenbakker kan een website bouwen met Wordpress en een lading aan gare plugins. You get what you pay for. Wij hebben in het verleden wel eens wat in WP gebouwd, maar dan alles in house.

Sloeg natuurlijk nergens op, want op die manier zijn er ontelbaar veel betere oplossingen. Ik zou developers aanraden om eens te kijken naar producten als Contentful.

[Reactie gewijzigd door Saven op 25 juli 2024 11:17]

[Verwijderd]

Men moet eens kijken naar Modsecurity + OWasp ruleset. Dat is een WAF (Web application firewall) op serverniveau en niet wordpress niveau wat CPU cycles vreet.

Ergo al zou je website "onveilig" zijn of een zero day exploit bevatten, men komt met de POSTS die ze maken om die exploit te krijgen gewoon niet door.

Ik heb een oeroude Magento 1.5 shop volgens mij gedraaid voor een klant nog dat zo lek was als kaas, de hele dag in de logs triggermeldingen kwamen over potentieele aanvallen etc.

Nooit gehacked. Enige nadeel is wanneer je shared hosting hebt de kans op zoiets heel erg klein is. Bij een eigen server kan je dat mooi customizen.

Sws backups op wordpress niveua is niet wenselijk. Dat moet je op hosting niveau doen. Zo blijft de backup "gescheiden" van de wordpress installatie.

[Cartman!]

Blijven hangen in t PHP 3 tijdperk? Je opmerking slaat nergens op want onveilige software kun je in elke taal maken.

[berchtold]

Maar in php blijft het raar genoeg makkelijker om onveilig te schrijven dan in andere talen.

[Cartman!]

Graag onderbouwing met feiten ipv onderbuik gevoel.

De grootste problemen mbt security afgelopen jaren waren toch echt niet afkomstig vanuit PHP (Log4j, Heartbleed bijv).