Hacked Wordpress website

[xehexehex]

Ola!

Heb een gehackte wordpress website van een kennis. Obviously krijgt men nu op elke webpagina een multipart/form venster waarin data kan worden geupload in de root folder binnen WP.

Heb uploads al disabled, maar nu is de root folder dus de 'shit'. Heb de website al helemaal verplaatst naar een nieuwe host, via een secured droplet, maar obviously zit het in de theme.

Theme is echter custom en niet zomaar opnieuw te maken, hoe kan ik het beste scannen op deze injectie? Heb alle logische plekken al bekeken; PHP-bestanden, CSS files etc.

Source:

<form method="POST" action="" enctype="multipart/form-data"><input type="file" name="image"><input type="Submit" name="Submit" value="Submit"></form>

Uploads folder block is/was vanwege het feit dat hier 1000'en files in stonden, dus deze zijn al removed + scanned met ClamAV.

Tips?

[SonataArctica]

Taine0 schreef op vrijdag 8 november 2019 @ 22:40:
Tips?

De backup terugzetten?

[xehexehex]

Nah, het speelt al een tijdje en ze wisten dit niet. Blacklisted door sommige partijen (McAfee sigh). Heb ik niet veel aan gok ik.

[ScSi]

Er zijn een aantal goeie wordpress plugins die hierop kunnen scannen. Kijk ook eens naar extra gebruikers (admins) die zijn aangemaakt, of het probleem komt sowieso terug.

[Droefsnoet]

Taine0 schreef op vrijdag 8 november 2019 @ 22:40:

maar obviously zit het in de theme.

Hoe weet je dit zo zeker?

Als de hack is veroorzaakt door het thema helpt alleen code weghalen natuurlijk niet, want het lek blijft zitten. Je zal dan toch echt een nieuw thema moeten gaan gebruiken, anders is het dweilen met de kraan open.

[RobIII]

SonataArctica schreef op vrijdag 8 november 2019 @ 22:43:
[...]


De backup terugzetten?

Je kunt er wel een achter zetten, maar er is weinig aan. Je moet die host beschouwen als compromised. Formatteren, herinstalleren, backup terugzetten. Geen half werk met 'scanners' en onzin. God weet wat er allemaal aan rommel naar binnen gehaald is dat zo'n 'scanner' niet oppikt.
Heb je de site niet in in backup zitten... tja, dan ben je zuur. De site zélf kun je vast nog wel uit het VCS halen maar de inhoud wordt al moeilijker. Gelukkig is dat nog wél enigszins na te pluizen; pak de recentste backup van de DB en onderwerp die aan een grondige inspectie (en fix waar nodig zaken) op een geïsoleerde host voordat je de backup restored op een andere host.

Anyway; dit heeft niets met Webdesign, Markup & Clientside Scripting te maken. Dit gaat naar Privacy & Beveiliging

[ Voor 37% gewijzigd door RobIII op 08-11-2019 22:52 ]

[xehexehex]

Droefsnoet schreef op vrijdag 8 november 2019 @ 22:47:
[...]

Hoe weet je dit zo zeker?

Als de hack is veroorzaakt door het thema helpt alleen code weghalen natuurlijk niet, want het lek blijft zitten. Je zal dan toch echt een nieuw thema moeten gaan gebruiken, anders is het dweilen met de kraan open.

Ik heb een compleet nieuwe droplet gemaakt, hierin de backup + files teruggezet (content/theme etc). Dus in base WP kan het niet zitten tho.

[ScSi]

Ik had goede ervaring met Wordfence - probeer het eens - baat het niet dan schaadt het niet.

[xehexehex]

ScSi schreef op vrijdag 8 november 2019 @ 22:47:
Er zijn een aantal goeie wordpress plugins die hierop kunnen scannen. Kijk ook eens naar extra gebruikers (admins) die zijn aangemaakt, of het probleem komt sowieso terug.

Al geprobeerd, heb wel netjes fail2ban, securi plugin etc, die pakken de 'hack' niet op, immers is de base 'schoon'. Heb geen nieuwe users of whatsoever, doe ook een scan op nieuwe files, enkel de root lijkt nu direct uploads te krijgen.

[xehexehex]

Permissies ook allemaal gechecked, alles is conform security best practice nu. Maar mag dus niet baten, want het is al infected. Meh....

[TomsDiner]

Zelf ooit eens een besmette wordpress installatie mogen aanschouwen. Er zaten meerdere soorten besmetting in, die bij elkaar hoorde. Zo hadden veel bestanden een regel vooraan het php bestand toegevoeggd gekregen, wat met zoeken en vervangen nog wel terug te vinden was. (Regex, want de namen wisselen telkens) Helaas hielp dat niets. Want er bleken ook een paar standaard Wordpress bestanden compleet vervangen te zijn. Daar zat dus niets raars aan het begin, en dus leek er niets aan de hand. Tot ik debugging aanzette, en bleek dat een paar WP files erg veel fouten veroorzaakten. Bij inspectie bleken deze niet bij de echte WP te horen.

Maar het kan nog leuker. Bij het naar mijn computer halen van de hele site om eens met wamp te gaan klooien, sloeg kaspersky aan op gif bestanden. Er waren logo.gif bestanden in de upload map geplaatst, die eigenlijk virussen waren, maar met opzet van een verkeerde extensie waren voorzien. En vanzelfsprekend waren er ook diverse zip bestanden opeens aanwezig met verdachte inhoud.

De boel houdt elkaar in evenwicht, totdat je met één klap alle mogelijke verspreiders stopt. Anders worden al je herstelpogingen gelijk weer teniet gedaan. Overigens praat ik over zomer 2015, en de server beveiliging was toen minder goed als nu. Maar het kan dus goed dat je de hack voor 97% weg had, maar het oude template + de schone installatie weer een prima voedingsbron bleken.

Gooi het domein wel uit de lucht als je niet zeker weet wat er allemaal gebeurt. Als je domein momenteel een negatieve reputatie opbouwt wegens spamverzending of virusverzending, is een verzoek tot whitelisting meestal niet voldoende. Of je tegen een takedown notice aan zit te kijken... En daarnaast kan het domein zelf ook moeilijk gebruikt worden voor gewone mailverzending: het beland bij iedereen in de spambox of wordt geweigerd. Ook is schoonmaken makkelijker bij een domein dat niet actief is.

Daarnaast kunnen WP installaties wachtwoorden van de server bevatten. Database wachtwoorden, maar ook FTP accounts (zie ik tegenwoordig trouwens wel minder). Daarnaast diverse andere secret keys van api's van derden zoals betaals of inlogfunctionaliteit. Zorg dat je weet welke informatie er was, want die moet eigenlijk allemaal vervangen worden.

Uiteindelijk zijn wij met een schone lei begonnen. Dat bleek aanzienlijk minder werk....

[xehexehex]

TomsDiner schreef op vrijdag 8 november 2019 @ 23:08:
Zelf ooit eens een besmette wordpress installatie mogen aanschouwen. Er zaten meerdere soorten besmetting in, die bij elkaar hoorde. Zo hadden veel bestanden een regel vooraan het php bestand toegevoeggd gekregen, wat met zoeken en vervangen nog wel terug te vinden was. (Regex, want de namen wisselen telkens) Helaas hielp dat niets. Want er bleken ook een paar standaard Wordpress bestanden compleet vervangen te zijn. Daar zat dus niets raars aan het begin, en dus leek er niets aan de hand. Tot ik debugging aanzette, en bleek dat een paar WP files erg veel fouten veroorzaakten. Bij inspectie bleken deze niet bij de echte WP te horen.

Maar het kan nog leuker. Bij het naar mijn computer halen van de hele site om eens met wamp te gaan klooien, sloeg kaspersky aan op gif bestanden. Er waren logo.gif bestanden in de upload map geplaatst, die eigenlijk virussen waren, maar met opzet van een verkeerde extensie waren voorzien. En vanzelfsprekend waren er ook diverse zip bestanden opeens aanwezig met verdachte inhoud.

De boel houdt elkaar in evenwicht, totdat je met één klap alle mogelijke verspreiders stopt. Anders worden al je herstelpogingen gelijk weer teniet gedaan. Overigens praat ik over zomer 2015, en de server beveiliging was toen minder goed als nu. Maar het kan dus goed dat je de hack voor 97% weg had, maar het oude template + de schone installatie weer een prima voedingsbron bleken.

Gooi het domein wel uit de lucht als je niet zeker weet wat er allemaal gebeurt. Als je domein momenteel een negatieve reputatie opbouwt wegens spamverzending of virusverzending, is een verzoek tot whitelisting meestal niet voldoende. Of je tegen een takedown notice aan zit te kijken... En daarnaast kan het domein zelf ook moeilijk gebruikt worden voor gewone mailverzending: het beland bij iedereen in de spambox of wordt geweigerd. Ook is schoonmaken makkelijker bij een domein dat niet actief is.

Daarnaast kunnen WP installaties wachtwoorden van de server bevatten. Database wachtwoorden, maar ook FTP accounts (zie ik tegenwoordig trouwens wel minder). Daarnaast diverse andere secret keys van api's van derden zoals betaals of inlogfunctionaliteit. Zorg dat je weet welke informatie er was, want die moet eigenlijk allemaal vervangen worden.

Uiteindelijk zijn wij met een schone lei begonnen. Dat bleek aanzienlijk minder werk....

Thanks, nuttige informatie.

V.w.b. DB passwords heb ik dit al weten te verbeteren door de config te hashen (wachtwoorden) en goede permissions te zetten, daarnaast denk ik ook niet dat ze nog toegang hebben tot de bestanden tho.

Enige wat mij nog logisch lijkt is om de functie multipart te disablen somehow, kon nog niet iets handigs vinden, want het lijkt nergens in mijn config te zitten.

Als die multipart disabled kan worden zijn wat mij betreft de uploads niet mogelijk, maar even verder naar zoeken.

[Droefsnoet]

TomsDiner schreef op vrijdag 8 november 2019 @ 23:08:
Uiteindelijk zijn wij met een schone lei begonnen. Dat bleek aanzienlijk minder werk....

Dat is schoon beginnen altijd. Alleen met alles opnieuw installeren weet je dat er nergens meer schadelijke code zit. En alles opnieuw installeren hoeft niet lang te duren, maar sommige mensen laten het liever nog enkele weken etteren, omdat ze per se willen werken vanuit een backup die net zo lek en/of besmet is.

Ik zou TS ook aanraden om echt alles opnieuw te installeren, maar dat maatwerk thema gooit dan roet in het eten. Als de hack via het thema is gekomen is het sowieso niet verstandig om nog met dat thema te werken.

[HenkEisDS]

Voordat je alles opnieuw installeert, maak wel even een goede backup van je database en bestanden. En check even met https://winmerge.org/ wat de afwijkingen zijn met schone wordpress bestanden en database voordat je je hostingomgeving reset. Troep hoeft niet alleen in je bestanden te zitten, maar kunnen uiteraard ook in je database zitten.

Gratis themas zitten bijna per definitie vol met troep die je SEO waarde omlaag haalt.

[TomsDiner]

Taine0 schreef op vrijdag 8 november 2019 @ 23:13:
[...]
V.w.b. DB passwords heb ik dit al weten te verbeteren door de config te hashen (wachtwoorden) en goede permissions te zetten, daarnaast denk ik ook niet dat ze nog toegang hebben tot de bestanden tho.

Enige wat mij nog logisch lijkt is om de functie multipart te disablen somehow, kon nog niet iets handigs vinden, want het lijkt nergens in mijn config te zitten.

Als die multipart disabled kan worden zijn wat mij betreft de uploads niet mogelijk, maar even verder naar zoeken.

Je weet 100% zeker dat niemand anders door de hack nu backend toegang heeft, of via een script root toegang? Want anders kun je zo weer opnieuw beginnen...

En wat is config hashen? Ik dacht dat ik wel wat van WP wist, maar daar heb ik nog nooit van gehoord. Overigens hebben mensen met root toegang ook toegang tot je config, maar ik neem aan dat dat een open deur is, dat weet je wel.

HenkEisDS schreef op zaterdag 9 november 2019 @ 17:21:

Gratis themas zitten bijna per definitie vol met troep die je SEO waarde omlaag haalt.

Betaalde thema's ook....