Een fysiotherapiepraktijk in Breda belde ons nadat ze hun website al twee keer hadden laten opschonen. Beide keren was de site na een paar dagen weer besmet: opnieuw spampagina’s, opnieuw een waarschuwing van Google. Het vorige bureau had de zichtbare rommel netjes verwijderd. Wat ze hadden gemist, was een bestand van elf regels in de map met plugins, met een naam die op een cachebestand leek. Dat bestand was de reden dat de aanvaller steeds gewoon terugkwam.

Zo’n bestand heet een backdoor, een achterdeur. Het is de meest onderschatte kant van een hack. Wie alleen de gevolgen opruimt en de achterdeur laat zitten, betaalt twee keer. In dit artikel leggen we uit wat een backdoor in WordPress precies is, waar ze zich verstoppen, hoe u ze herkent en wat er nodig is om ze echt kwijt te raken.

Wat een backdoor is en waarom aanvallers ze plaatsen

Een aanvaller die eenmaal binnen is, bijvoorbeeld via een lek in een verouderde plugin, weet dat dat lek op een dag wordt gedicht. Daarom is het eerste wat hij doet niet het plaatsen van spam, maar het regelen van een eigen ingang die niet van dat lek afhankelijk is. Dat is de backdoor: een klein stukje code dat op afroep opdrachten uitvoert, bestanden uploadt of een beheerdersaccount aanmaakt.

De achterdeur zelf doet niets zichtbaars. Hij wacht. Pas als de aanvaller een speciaal verzoek stuurt, komt hij in actie. Daardoor valt hij niet op in het gedrag van de site en vaak ook niet in een scan. De spam die u ziet, is de voorgevel; de backdoor is de sleutel onder de deurmat.

Vaak worden er meerdere backdoors geplaatst, op verschillende plekken, juist omdat de aanvaller weet dat er eentje gevonden kan worden. Wie er één vindt en stopt met zoeken, is daarom nog niet klaar.

Waar backdoors zich verstoppen

Uit de herstelklussen die wij doen, komen steeds dezelfde verstopplekken terug:

  • De uploads-map. Bestanden met een .php-extensie tussen de afbeeldingen, soms met een naam als image.php of een lange reeks cijfers. In een gezonde site hoort daar geen PHP te staan.
  • Bestaande plugins en thema’s. Een paar regels toegevoegd aan een legitiem bestand, vaak helemaal onderaan of verborgen achter een lange regel spaties zodat u moet scrollen om het te zien.
  • Nepplugins. Een map met een geloofwaardige naam zoals wp-cache-helper of core-security, met daarin één bestand. Soms staat de plugin niet eens in de pluginlijst omdat hij als “must-use”-plugin in de map mu-plugins is gezet, waar WordPress hem automatisch laadt.
  • Kernbestanden van WordPress. Bijvoorbeeld wp-config.php, index.php of een bestand in wp-includes. Deze vallen op bij een integriteitscontrole, maar alleen als die wordt uitgevoerd.
  • De database. Code in de instellingen van het thema of van een plugin, in een widget, of in een optieveld dat bij het laden van elke pagina wordt uitgevoerd. Bestandsscanners kijken hier vaak niet.
  • Een extra beheerdersaccount. Geen code, maar wel een achterdeur: een gebruiker met beheerdersrechten en een onopvallende naam, soms verborgen voor de gebruikerslijst.
  • Buiten WordPress. Een cronjob op de server die periodiek een bestand terugzet, of een aangepast .htaccess-bestand dat verzoeken doorstuurt.

Hoe een backdoor eruitziet

U hoeft geen programmeur te zijn om verdachte code te herkennen. Backdoors hebben een paar kenmerken:

  • Ze bevatten functies die code uitvoeren die van buiten komt: eval, base64_decode, gzinflate, system, exec, of combinaties daarvan.
  • De code is onleesbaar gemaakt: een lange sliert willekeurige tekens die pas bij het uitvoeren wordt ontcijferd.
  • Ze lezen iets uit een verzoek (een parameter in de URL, een cookie, een formulierveld) en doen daar direct iets mee.
  • Het bestand heeft een datum die afwijkt van de rest van de map, of juist een datum die kunstmatig gelijk is gemaakt aan de andere bestanden.

Let wel: sommige legitieme plugins gebruiken ook base64 of eval, bijvoorbeeld voor licentiecontroles. Een verdachte functie is een aanleiding om te kijken, geen bewijs. Als u niet zeker weet wat u ziet, verwijder het dan niet zomaar; een verkeerde verwijdering kan de site platleggen.

Waarom opschonen alleen niet genoeg is

Het patroon uit de inleiding, opruimen en drie dagen later opnieuw besmet, heeft meestal een van deze oorzaken:

  1. Er is een backdoor blijven zitten, vaak op een van de minder voor de hand liggende plekken hierboven.
  2. Het oorspronkelijke lek is niet gedicht: de verouderde plugin staat er nog, of het zwakke wachtwoord is niet veranderd.
  3. De beveiligingssleutels (salts) zijn niet vernieuwd, waardoor gestolen sessiecookies nog geldig zijn.
  4. Er is een back-up teruggezet die de besmetting al bevatte.
  5. Een buursite op dezelfde hostingaccount is besmet en herinfecteert de opgeschoonde site.

Goed herstel bestaat daarom altijd uit drie delen: de besmetting weghalen, de ingang sluiten en alle sleutels vervangen. Het tweede en derde deel worden het vaakst overgeslagen. Hoe u de salts vernieuwt, leest u in het stappenplan voor het resetten van beveiligingssleutels.

Zo pakt u het grondig aan

Een aanpak die in de praktijk werkt, of u het nu zelf doet of laat doen:

  1. Maak eerst een kopie van de besmette site, inclusief database. Niet om terug te zetten, maar om te kunnen onderzoeken en om niets kwijt te raken.
  2. Vervang WordPress zelf door een verse download van dezelfde versie. Daarmee zijn alle kernbestanden in één keer schoon.
  3. Vervang elke plugin en elk thema door een verse versie uit de officiële bron. Wat niet meer wordt gebruikt, verwijdert u definitief.
  4. Doorzoek wat overblijft: de uploads-map, mu-plugins, maatwerkcode en de database, op de kenmerken hierboven.
  5. Controleer gebruikers, cronjobs en .htaccess en verwijder alles wat u niet kent.
  6. Vervang alle wachtwoorden en sleutels: WordPress-accounts, database, FTP/SFTP, hostingpaneel, salts.
  7. Dicht het oorspronkelijke lek en zet monitoring aan zodat u een nieuwe wijziging binnen een dag ziet.

Hoe wij die stappen in de praktijk uitvoeren, staat uitgebreider in onze werkwijze bij het verwijderen van malware.

Conclusie: wantrouw een snelle schoonmaak

Bij de praktijk uit Breda vonden we uiteindelijk drie backdoors: het bestand in de pluginmap, een regel in de database en een verborgen beheerdersaccount. Na een volledige herinstallatie, nieuwe sleutels en het verwijderen van de verouderde plugin die de ingang was geweest, is de site sindsdien rustig gebleven. De les: als een herstel binnen een uur klaar is en er is niet naar de ingang gekeken, is het geen herstel maar uitstel.

Wordt uw site voor de tweede keer besmet, vraag dan aan wie het opruimt welke backdoors er zijn gevonden en welk lek is gedicht. Een goed antwoord is concreet. Wilt u dat een partij met ervaring het overneemt, dan valt dit onder hackherstel en beveiliging zoals WebMaintor die aanbiedt, met een herbeoordeling bij Google als de site gemarkeerd is. Maar begin met de vraag. Die alleen al maakt duidelijk of u met de juiste partij praat.