Groźny wirus, antywirus śpi. imgdd.net w plikach index…

Od jakiegoś czasu coraz więcej widać w sieci prób rozwiązania problemu związanego z atakiem na serwery ftp i umieszczaniem kodu „imgdd.net….” Sam słyszałem o problemie ale wypuszczałem wszystko drugim uchem do momentu kiedy nie dotknęło to też mnie.

Problem staje się o tyle spory i można powiedzieć globalny, że infekcja rozprzestrzenia się w ramach całych serwerów ftp – nie tylko poszczególnych folderów/serwisów/cms. „Jakąś” dziurą dostaje się nam na serwer trojan, który zaszywa w plikach index.* (najczęściej php, html – nie radzi sobie natomiast z py i innymi). W jaki zaszywa się sposób? Najgorszy i najcwańszy z możliwych – dodając fragment kodu, który po odpaleniu owego pliku index. zainfekuje kolejny komputer.

W tym momencie widać jednak, że infekcja przygotowana jest stricte pod pliki typu htm i html, kod bowiem wygląda najczęściej tak:

< img heigth=”1″ width=”1″ border=”0″ src=”http:// imgaaa . net /t.php?id=11137647″ >
appears somewhere, usually after the </html>

Jak łatwo sobie wyobrazić z taką postacią nie poradzi sobie od ręki składnia pliku php – tu pojawia się bowiem kolejny problem, gdyż taki fragment kodu „na siłę” upchnięty w pliku index.php wysypuje nam witrynę, pomimo tego, że główny cel de facto nie jest spełniony – trojan nie będzie się teoretycznie rozprzestrzeniał.

Zdiagnozować należy przede wszystkim wspomnianą „jakąś dziurę” którą wchodzi do nas owe badziewie. Źródłem infekcji są po prostu odwiedziny zainfekowanej strony. Powiecie – proste, wystarczy mieć dobrego antywirusa. Też tak myślałem. Mój sprzęt zabezpieczony jest bardzo dobrze – wiądącym, korporacyjnym rozwiązaniem, znanego producenta. I co z tego? A no tyle, że cały ostatni weekend walczyłem z zainfekowanymi ftp`ami.

Jak się okazuje większość wiodących rozwiązań AV nawet przy wymuszonym skanowaniu pliku index. z wirusem nic nie wykywa. Dlaczego? Może dlatego, że wg. systemu AV kod <img> jest zupełnie normalny w tego typu plikach. Dlaczego więc aplikacje te nie wykrywają infekcji po odwiedzeniu felernej witryny? Nie wiem. Antywirusem, który w jakimś stopniu diagnozuje przynajmniej problem jest Avast. Tak, tak – ten Avast. Też nigdy nie uważałem, że jest dobry ale tutaj sobie poradził. Poradził – ale nie do końca. W zasadzie to średnio. No dobrze – zupełnie sobie nie poradził. On zdiagnozował tylko problem – pliki takie może nam usunąć albo wyrzucić do kwarantanny. Super. 60 000 plików, wśród nich zainfekowane index.`y, a on może je usunąć – rewelacja.

Co nam pozostaje? Avast może nam wyszukać zainfekowane pliki a my możemy zmienić wpisy (usunąć ręcznie), możemy też przy odrobinie umiejętności programistycznych napisać skrypt, który automatycznie zamieni skrypt na pustą linijkę. I w sumie po problemie, ale… Co zrobić, żeby sytuacja się nie powtórzyła?!

Po pierwsze sprawdźcie plik .htaccess. Nie ma tam czegoś takiego?
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /dd.php?q=$1 [L]

Jeżeli jest, to powinno wam to wiele wyjaśnić. Możecie też sprawdzić narzędzie: (mi ono niczego nie urwało i w niczym nie pomogło).

Spora część autorytetów w webmasteringu radzi też przy tej infekcji pozmieniać wszystkie hasła do ftp`ów które zostały zainfekowane. Wydaje się to sensowne ale nie potrafię znaleźć bezpośredniego zagrożenia – kod zaszywa się raczej z poziomu luki w uprawnieniach a nie po autoryzacji, ale bezpieczeństwa nigdy za wiele. Nie zapomnijcie jeszcze o jednym – folder LOG lub LOGS. Zaczął ważyć podejrzanie dużo? To też sprawka infekcji imgdd.net… Takie foldery przy naszym antywirusowym sprzątaniu najlepiej usunąć. Chyba, że interesują Was faktyczne logi – można pogrzebać – jest jednak tam tak wiele efektów infekcji, śmieci typu puste pliki itd, że pozostaje mi tylko życzyć powodzenia.

Temat tego malware jest cały czas dość mocno niedookreślony. Sam sobie z tym poradziłem ale mam świadomość, że jest to działanie trochę „na piechotę”. Jeżeli macie lepsze pomysły, piszcie.