Gehackt! Wat nu?

Het gebeurde recent in mijn netwerk; de WordPress administratie was ’s nachts gehackt. De gevolgen onoverzichtelijk. Maar één ding weten ondernemers maar al te goed: een datalek moet je melden. Maar was er klantdata buitgemaakt? WordPress is immers niet hetzelfde als directe databasetoegang.

Voor- en achterkant

Dit is het eerste onderscheid wat ik hielp te maken. WordPress (of ieder ander CMS) maakt de voorkant van je website en is toegankelijk voor buitenstaanders. En dat is maar goed ook, anders krijg je nooit een bezoeker. Nadeel: je CMS heeft ook een administratiegedeelte. Bij WordPress is deze standaard te vinden onder /wp-admin.

De achterkant zijn componenten als een database of mailserver waar je voorkant op leunt en “mee praat”, maar vanzichzelf geen “interface” naar de buitenwereld hebben. Word jouw WordPress gehackt, dan betekent dit dus niet automatisch dat een hacker ook toegang tot je database kreeg.

WordPress plugins

De vraag of klantdata toegankelijk is geweest, hangt af van de plugins die je in WordPress gïnstalleerd hebt.

Stap 1 – Waar?

Eerst moet je achterhalen waar je allemaal klantdata via uitvraagt en dus opslaat in je CMS. Alleen via de standaard gebruikersaccount functionaliteit? Of ook via bijvoorbeeld een form builder en e-commerce plugin? Dergelijke plugins voegen allemaal hun eigen tabellen aan je database toe, die buiten het bereik van WordPress vallen. Noteer de URL die je ziet tijdens het bladeren door de plugin pagina’s voor later gebruik (bijvoorbeeld: ../wp-admin/admin.php?page=itsec&module_type=recommended).

Stap 2 – Wanneer?

Je moet nu bepalen wanneer de hack ongeveer plaatsvond. Dit helpt je in stap 3 met gerichter zoeken. Dus als de laatste medewerker om 20.34 ’s avonds voor het laatst zich in de CMS administratie actief was of de website ‘normaal’ bezocht, dan is dat je startpunt. Het eindpunt is wanneer je de hack opmerkte én je de gevoeligheid oploste (bijvoorbeeld door plugins bij te werken).

Stap 3

We weten nu waar we naar zoeken en wanneer. De volgende stap is om in je ‘server logs’ stap 1 en 2 samen te brengen. Server logs onbekend? Een korte uitleg:

Een stukje software zorgt ervoor dat jouw website toegankelijk is voor de buitenwereld. Apache, Nginx, IIS zijn veelvoorkomende pakketten en noemen we web servers. Net als Office Word draait binnen Windows, draait WordPress binnen Apache. En die laatste houdt super nauwkeurig bij welke content (HTML, CSS, plaatjes, javascript) is uitgegeven op welk tijdstip aan welk IP-adres. Je vindt deze informatie in de ‘access logs’.

Ik laat hier even buiten beschouwing hoe je bij deze logbestanden komt. De aanbieder van je server kan je hierbij helpen.

Als je jouw logbestand open hebt in bijvoorbeeld Excel, kan je op zoek naar bezoeken aan specifieke URLs. Je zal een hele reeks aan rijen krijgen die er allemaal uit zien als hieronder.

127.0.0.1 – – [09/Nov/2018:13:55:36 +0100] “GET /wp-admin/admin.php?page=plugin_naam_uit_stap_1 HTTP/1.0″ 200 2326

Dit toont je het IP adres van de bezoeker (127.0.0.1), de datum en de opgevraagde pagina. Zie je hier verzoeken aan pagina’s die onderdeel maken van plugins die klantdata tonen? En gebeurde dit buiten tijden dat het aannemelijk is het een werknemer was (IP-adres kan hierbij helpen dit in te schatten)? Dan moet je er vanuitgaan dat klantdata is gelekt.

Afhankelijk van de plugin kan je hier minder of meer concreet zijn. Voor je melding aan de autoriteiten zal dit niet uitmaken.

Stap 4

Nu je hebt aangetoond dat klantdata in het zicht van de hacker is geweest (en wellicht gedownload), moet je jouw melding doen bij het meldloket datalekken. Hiervoor is het goed om nog inzichtelijk te maken welke data welke plugin precies toont op de betreffende pagina’s. Een wachtwoord van een gebruiker zal dit bijvoorbeeld veelal niet zijn. Hetzelfde geldt voor creditcard- of bankgegevens.

Red flags

Kans dat je dit leest voordat er iets fout gaat is klein. Want why bother? Website bediengemak wint het in 9 van 10 gevallen van security en privacy.

Mocht je toch nieuwsgierig zijn wat enkele red flags zijn die jou kunnen helpen bij het inschatten van je ‘security readiness‘. Hieronder een lijstje:

• Alle werknemers hebben administrator-rechten
• Je hebt een plugin als Database Browser of ARI Adminer in WordPress geïnstalleerd
• PHPMyAdmin is jullie formele database management tool
• De server draait op PHP 5.6 (of ouder…)
• Je WordPress administratie bevindt zich op de standaard /wp-admin locatie
• Er is geen two-way authentication ingesteld voor de inlog op je administratie
• Als je als gebruiker je wachtwoord opvraagt, krijg je deze in platte tekst in de e-mail opgestuurd
• Het server ‘root’ wachtwoord hangt op een prikbord in kantoor