[wordpress, mySQL, PHP] Admin rol lijkt verstoord te zijn

[Anoniem: 2842]

Ik ben al weken op zoek naar een oplossing, maar zelfs in het Wordpress forum lijkt niemand mij te kunnen helpen. Ik hoop dat iemand hier de uitdaging aan kan. Uiteraard heb ik me hier ook al sufgezocht.

Voorgeschiedenis Ik heb een admin account in mijn Wordpress installatie. Ik ben een keer gehacked waarna mijn host een backup heeft teruggeplaatst. Daarna heb ik de naam van mijn admin account veranderd omdat ik vermoed dat men gewoon mijn wachtwoord heeft gekraakt. Met andere woorden, de admin account kreeg een andere naam.

Probleem Recentelijk viel mij op dat de update naar 3.5 beschikbaar was. Als admin kreeg ik de melding dat ik de site admin moet raadplegen. Vreemd, want voorheen kon ik dat als admin zelf en dat zou ook zo moeten. Toen bedacht ik me dat ik ook al tijden geen plugins heb kunnen updaten. De opties om plugins te activeren en deactiveren zijn er wel, maar verwijderen, updaten en installeren niet meer. Daarnaast mag ik bij een aantal plugins niet meer bij de settings onder de melding "Je hebt onvoldoende rechten voor toegang van deze pagina."

Database check Ieder Wordpress blog heeft een admin. In de database staat de key wp_capabilities voor mijn admin dan ook als a:1:{s:13:"administrator";s:1:"1";}. Ik heb deze installatie van Wordpress 3.5 met een andere vergeleken en kon in de database geen veranderingen vinden behalve de naam van de admin account. Bij de probleemsite heb ik die gewijzigd omdat ik in het verleden al eens ben gehacked. Uiteraard heb ik geprobeerd om de accountnaam terug te zetten naar admin, maar dat gaf geen oplossing.

Workarounds Ik heb inmiddels wel mijn update naar Wordpress 3.5 uitgerold. Dit heb ik handmatig gedaan volgens de readme van Wordpress zelf. Dat ging niet al te lastig. Ik hoopte dat dit probleem meteen opgelost zou zijn, maar helaas is dit niet het geval gebleken.

[TheNephilim]

Dus, je wil zeggen dat je admin account geen beheer rechten meer heeft?

Hoe heb je de naam van je account veranderd?

[Anoniem: 2842]

Ik heb de login veranderd in de database. Dit doe ik voor al mijn installaties omdat het lekker vlot werkt. Ik heb wel nog steeds admin rechten om gebruikers aan te maken, rollen toe te wijzen en om een aantal plugins in te stellen en thema's aan te passen. Dat maakt het voor mij zo vreemd.

[TheNephilim]

Is het niet gewoon omdat de beheerder 'admin' moet heten en niet anders? Ik zie niet zo in waarom je 'admin' een andere naam zou willen geven. Gewoon een sterk wachtwoord (http://www.random.org/passwords/) van minimaal 16 tekens lang. Voor de klant een nieuwe account aanmaken natuurlijk.

Over een oplossing, nou probeer er weer eens 'admin' van te maken, misschien helpt dat.

[uashy]

Handigste is waarschijnlijk om volgende te doen:
1. naam van administrator weer terug wijzigen in database
2. testen of je alle rechten weer hebt
3. nieuwe gebruiker aanmaken en die de rol Administrator geven
4. testen of de nieuwe gebruiker de juiste rechten heeft
5. als stap = ja, dan de oude admin gebruiker verwijderen en daarbij aangeven dat alle berichten naar de nieuw aangemaakte administrator moeten worden overgezet.

Zelf rechtstreeks wijzigingen aanbrengen in de database kan, maar is erg gevaarlijk als je niet alle relaties tussen de tabellen direct overziet.

Ik ga er overigens van uit dat in de wp_usermeta tabel de waarde voor wp_user_level op 10 staat.

[ Voor 7% gewijzigd door uashy op 04-01-2013 17:29 ]

[Beatboxx]

Kan je niet de backup nog een keer terugrollen? Of de backup deels terugrollen, namelijk alleen de tables die te maken hebben met de users?

[Anoniem: 2842]

Het terugnoemen van de gebruikersnaam had ik uiteraard al meteen gedaan, maar dat werkte niet. Bij andere accounts verander ik de admin naam ook op deze manier, maar heeft het niet deze vreemde gevolgen.

Ik ben verder blijven spitten en heb de oorzaak gevonden. Er blijken twee variabelen in de config.php gewijzigd te zijn.

Wanneer je Wordpress installeert, staat dit in je config.php:

define( 'DISALLOW_FILE_EDIT', false );
define( 'DISALLOW_FILE_MODS', false );

Bij mij was dit om één of andere reden veranderd naar

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

Deze verandering verklaart het vreemde gedrag van de admin account. nalezen leert mij dat dit een tactiek is die je normaal gebruikt om hackers het leven lastiger te maken. Bij true zal Wordpress zelf haar bestanden namelijk niet aanpassen. Heeft een hacker toegang tot een account met adminrechten, kan hij vanuit Wordpress dus niet veel schade aanrichten. Ik denk dat in mijn geval, de hacker zijn of haar werk heeft gedaan en op deze manier probeerde te voorkomen dat ik de boel zelf gemakkelijk ongedaan kon maken.

Waarom dit met de rollback niet is opgelost is mij alleen een raadsel en is iets dat ik met mijn host uit moet gaan zoeken. Voor nu ben ik in ieder geval van een groot probleem verlost.

[uashy]

Mooi dat het is opgelost. Als het terugzetten van de backup het probleem niet heeft opgelost, dan is de hacker waarschijnlijk al langere tijd binnen geweest zonder dat je dat gemerkt hebt.

Vraag is nu of je nog je backup kunt vertrouwen. De wp-config.php was in de backup was immers ook aangepast. Misschien zijn er nog wel meer bestanden aangepast. Ik ga er van uit dat de wp-config.php tenminste in de backup zat. Of als de backup op dezelfde server staat als de Wordpress installatie, kan het zijn dat hij zelf de backup heeft aangepast (vergezocht misschien, maar niet ondenkbaar).

Denk dat het raadzaam is om een schone installatie van Wordpress te doen (alleen de files, niet de databases). Je zult dan wel je thema eventueel opnieuw moeten maken. Je weet dan in ieder geval zeker dat er geen geheime achterdeurtjes meer zitten in de Wordpress bestanden.

Omdat je niet zeker weet hoe je de vorige keer gehacked bent, zou je zelfs zo ver kunnen gaan dat je de hele server niet meer vertrouwd...

(ik klink mischien wat overdreven, maar heb beroepsmatig het een en ander meegemaakt op dit vlak)

[ Voor 33% gewijzigd door uashy op 05-01-2013 15:11 ]