13 jan 2016
Dat hackers hun code versleutelen met Base64 weten de meeste ondertussen wel. Dan krijg je een reeks aan cijfers en letters waar geen enkele logica in lijkt te zitten.
Maar hackers hebben ook enkele favoriete plekken om hun hackers code neer te zetten.
Een hack in de header.php
De header.php in je thema is het eerste wat geladen wordt. Het wordt op iedere pagina geladen en bevat de <head> waar javascript in geladen kan worden zonder dat het al te veel opvalt.
Hoe herken je een hack in de header.php?
Dan moet je eigenlijk weten welke js files er ingeladen moeten worden, welke je thema oproept en welke via plugins ingeladen worden.
De overige eruit knippen is te risicovol dus zul je ze even door moeten lezen.
En als het base64 code is, ja dan is de kans 99.9% dat het er niet hoort! Even een backup maken en die eruit knippen is dan de eerste stap.
Een hack in de uploads mappen
Met de nadruk op uploads “mappen” aangezien deze mappen vrij beschrijfbaar zijn en ze dan ook direct lekker strooien met de files. Jaartallen zoals 2011, 2012, 2013, 2014 worden alsnog volgezet.
Hoe vind je die hack files in de uploads mappen?
Tja redelijk simpel, er horen GEEN php bestanden in de uploads mappen te zitten, NERGENS. En dus kun je met een zoekopdracht op de server naar php direct alle files eruit halen.
Een hack in de core van WordPress
Als je bemerkt dat je wp-admin, de wp-includes mappen en overige core files hack files bevatten kun je die eruit knippen maar gemakkelijker is het totaal opnieuw uploaden van WordPress.
De “root” ook wel bekend als de “www” en “httpdocs”, zijn met zekerheid mappen die gevonden kunnen worden, aangezien het de basismap van al je bestanden is. Hier zetten hackers graag wat bestanden in.
1 voordeel, je kunt een schone WordPress installatie vergelijken met die bestanden en zo snel uitvinden welke bestanden niet thuishoren in je site.
Upload gewoon de nieuwste WordPress zonder de wp-config & de wp-content map te overschrijven (Altijd eerst een backup maken!!)
Een lek in de plugins
Dit noem ik bewust een “lek”, aangezien de plugin die lek is vaak bestanden wegschrijft naar de mappen die ik hierboven heb beschreven.
Plugins gaan met regelmaat lek en zijn eigenlijk de strop voor WordPress.
WordPress is een solide betrouwbaar systeem maar de mensen achter de plugins.. zitten ze op een zolderkamertje? Zijn het professionele programmeurs? Of stiekem hackers die eerst een schone release lanceren om er daarna een lek in te bouwen bij de update..
Hoe dan ook, als je voor een plugin hebt gekozen, zorg dan dat die uit de bibliotheek van WordPress komt of officieel gekocht is.
Gebruik geen illegaal gedownloade plugins die eigenlijk aangekocht moesten worden. De uploaders van die plugins stoppen er vaak backdoors in!
Voorkom een grote zoektocht!
Als een hack(er) zijn weg heeft gevonden in je WordPress website zijn wij als ervaren WordPress experts zelfs 1-2 uur aan het zoeken, spitten, lezen om de hacks en backdoors eruit te halen.
Maar als je preventief de Ithemes Security PRO gebruikt weet je wanneer & waar bestanden zijn aangepast of zijn ge-upload.
Je ziet de naam van het bestand, de datum en tijd!
En Ithemes Security PRO stuurt je een e-mail wanneer bestanden worden aangepast!
1 Er zijn een aantal mappen van een WordPress installatie die beschrijfbaar zijn. Dan moet blijkbaar omdat je dan bestanden kunt uploaden, het thema en plugins kunt updaten. Toch vind ik dat raar, die mappen hoeven toch alleen beschrijfbaar te zijn voor de beheerder? Waarom zijn die mappen beschrijfbaar voor anderen?
2 Met FTP is het heel makkelijk om de rechten van bestanden en mappen te wijzigen. Kun je dan niet voor de veiligheid na een update en alle mappen op alleen lezen zetten? Of werkt de site dan niet meer?
1) Plugins maken ook gebruik van diverse mappen. Alhoewel dat in de regel de uploads mappen zijn maken sommige plugins gebruik van de wp-content map of zelfs de public_html (Root van de server).
Van CMOD 777 naar 755 is inderdaad zoal een aanrader mocht het nog publiekelijk beschrijfbaar zijn.
2) Alleen lezen (444) is goed voor de Htaccess en sommige andere bestanden maar de meeste moeten uitvoerbaar zijn.
Dan kom je op CMOD 555. Dat is lezen en uitvoeren. Daarmee werkt een WordPress website alsnog, de automatische en handmatige updates zijn dan niet meer mogelijk totdat je de mappen en bestanden weer schrijfbaar maakt maar de site werkt meestal nog wel.
Bij websites waar lekke plugins gebruikt werden die niet te vervangen zijn hebben wij de website in samenspraak met de website-eigenaar “bevroren” door alles op 555 te zetten (Uploads mappen meestal niet maar soms is zelfs dat nodig).
De meeste sites werken goed, tenzij ze logs en/of andere bestanden wegschrijven zoals pdf facturen e.d.
Ik zou graag eens iets bij een hacker willen terugdoen. Hoe hun lopen te f*cken met mijn website en dat ik dan bij hun inbreek en de tafel en bank enzo saboteer en de deur zodat iedereen zo naar binnen kan. Maar die losers verschuilen zich achter heg internet en zullen wel thuiswonend zijn en op een zolderkamertje bij pappa en mamma zitten te programmeren. Of scripts tr knippen en te plakken