Code injection in php files in Wordpress op IIS 8.5

[Verwijderd]

Een aantal websites die ik heb draaien zijn afgelopen woensdag iets veranderd qua code.
De index.php file van Wordpress was bijvoorbeeld veranderd van 1 kb naar 80 kb.
In de index.php stond extra code die een soort van scrambled was.
Ook bevatten een aantal wordpress sub directories extra bestanden ala b.php en e.asp.
Ook zijn er .htaccess bestanden aangemaakt die ook rare code in zich hadden.
Deze zijn aangemaakt op 26 oktober.
De websites zelf lijken er niet van te leiden, echter de zoekresultaten van betreffende websites bevatten ineens rare tekens.

Ik kwam op het spoor van deze "code injection" vanwege een melding van Google Webmaster Tools dat er ineens een extra owner van de website in Google Webmaster Tools was. Deze heb ik verwijderd.

De websites draaien php 7 op IIS 8.5 en Mysql 5.7. Ik heb gekeken naaar de logging en heb het idee dat ze via post commando`s de injection hebben gedaan. De rechten op de website zijn gezet met iusr rechten en deze stonden op read write op alle content. Nu is dat read write verhaal nodig om de websites ( naar mijn mening) te kunnen updaten voor zowel wordpress , plugins en thema`s. Als ik dit zet naar alleen read en execute, dan weigert wordpress de updates.

Inmiddels heb ik de rechten anders gezet, ( iis apppool/website naam) echter blijf ik met het fenomeen zitten dat ik toch read write rechten nodig heb om de boel te updaten.
Het wijzigen van de rechten van iusr naar iis apppool\website naam zorgt er in ieder geval voor dat elke website nu een aparte user heeft en er niet cross ( 1 website besmet de andere?) kan worden geinject onder de defaultapp. ( volgens mij)

Nu is inmiddels alle gerestored naar de juiste en goede versie, echter het blijft mij een raadsel hoe dit kan gebeuren.

Hebben jullie hier wellicht ervaring mee, of ideeen hoe je wordpress kan wapenen tegen dit soort "injections"

Voor zover mij bekend is er geen toegang verschaft via rdp/ftp of andere accounts.
Sommige wordpress sites waren up to date, andere niet. Ook 1 joomla site was besmet met dit fenomeen.

.

[larshack]

Klinkt als een brakke/lekke/gehackte plugin van zowel Joomla! als Wordpress.
Wat je hier tegen kan doen is in ieder geval de juiste lees- en schrijfrechten op je bestanden en mappen en zorgen dat je de plugins blijft updaten. Meer kun je er niet echt aan doen ben ik bang.

[.Maarten]

Je zegt het zelf al. Software niet up to date.
Vooral plugins geven vaak problemen omdat deze lang niet altijd bijgewerkt worden.

[Verwijderd]

@Larshack en .Maarten
Het zou kunnen dat die een nog niet gepatchte plugin is, maar desalniettemin had ik ook een volledig up to date site die dit fenomeen had.

Punt met de lees en schrijfrechten begrijp ik wel, maar het zou mooi zijn als het update mechanisme het dan ook nog zou doen.

[HollowGamer]

larshack schreef op maandag 31 oktober 2016 @ 12:56:
Klinkt als een brakke/lekke/gehackte plugin van zowel Joomla! als Wordpress.
Wat je hier tegen kan doen is in ieder geval de juiste lees- en schrijfrechten op je bestanden en mappen en zorgen dat je de plugins blijft updaten. Meer kun je er niet echt aan doen ben ik bang.

Klinkt als een brakke setup eerder.

@TS:
Nooit zomaar write permissies geven aan bestanden/mappen!
WP kan prima updaten als alles goed is geconfigureerd, dat lijkt me hier niet het geval.

Verder hoop ik dat je de wachtwoorden en de beveiliging hebt opgeschroefd, zoals met 2FA.

[iTeV]

Joomla! geupdated naar laatste versie?

Er is laatst een nieuwe patch uitkgekomen voor Joomla! i.v.m beveiligingslekken:
https://www.security.nl/p...nstige+beveiligingslekken