Kilka słów o tym jak WebCake.pl padło ofiarą trojana js:Redirector-MR[Trj]

Poniedziałek rano, rozpoczyna się pracowity tydzień. Dostaję wiadomość od odwiedzających blog o tym, że na blogu hulają trojany, które są wychwytywane przez programy antywirusowe. Cała sytuacja wyglądała dosyć dziwnie… na blogu nie nie publikuje od kilku dni a tu nagle alerty o złośliwym oprogramowaniu. Dodatkowo najnowszy Norton Internet Security 2012 całkowicie milczy.

Trojan (js:Rediector-MR[Trj]) w WordPress wykryty przez KasparskyTrojan (js:Rediector-MR[Trj]) wykryty przez Avasta

Sprawa o tyle poważna, że strona www, która zawiera tego typu szkodniki traci potrójnie:

  • Użytkownicy narażeni są na straty lub szkody wyrządzone działaniem trojana
  • Wiarygodność strony www drastycznie spada
  • Strona może znaleźć się na liście witryn, które są szkodliwe dla użytkowników, przez co przeglądarki mogą całkowicie blokować ładowanie się strony www.

Problem, więc był naprawdę poważny,  trzeba było się z nim szybko uporać.

Przekopałem sporą część internetu, ustaliłem kilka faktów i zacząłem zabierać się za usuwanie js:Redirector-MR[Trj]

 

Kilka faktów o trojanie js:Redirector-MR[Trj]

  •  Trojan dostaje się na blog poprzez protokół  FTP w wyniku wykradnięcia danych do logowania.
  • Program generuje linki do zewnętrznych serwisów
  • Trojan wyświetla się losowym odbiorcom. To znaczy, że odwiedzając 1 podstronę kilka razy może on się  wyświetlić lub nie.
  • Przeglądając źródło strony wygenerowanej w przeglądarce bardzo często nie widać Robaka, ponieważ kod jest przesunięty kilka stron w prawo, więc łatwo przegapić.
  • kod źródłowy jest zaszyforwany

 

Jak usunąć js:Redirector-MR [Trj]

[adsenseyu1]

Jest to mój autorski mix  na usunięcie trojana. Prawdopodobnie, jeśli korzystasz  z VPS lub serwera dedykowanego całość da się wykonać szybciej wykorzystując możliwości linii poleceń linuxa. Do eliminacji  zagrożenia będzie Ci potrzebny NotPad++

  • Zgraj z serwera na dysk Twojego komputera wszystkie pliki bloga
  • Otwórz wyszukiwarkę  systemową z ustawionym przeszukiwaniem katalogu bloga i w polu wyszukaj wpisz: *.php
  • Wszystkie znalezione pliki zaznacz za pomocą: Ctrl + A
  • Kliknij prawym przyciskiem myszy i wybierz opcje otwórz za pomocą: Notepad++ (jeśli twój blog składa się z wielu plików php cała operacja może potrwać kilka dobrych sekund; wszystko zależy od mocy obliczeniowej komputera)
  • Po wczytaniu wszystkich plików naciśnij: Ctrl+F. Pojawi się okno: Szukaj… jako szukany tekst wpisz: eval.
  • Przejrzyj dokładnie wyniki wyszukiwania w poszukiwaniu kodu podobnego do poniższego (najczęściej kod dodaje się do większości plików index.php bloga lub jak to miało w moim przypadku do pliku functions.php znajdującego się w katalogu theme). Piszę o kodzie podobnym, ponieważ zauważyłem, że na przestrzeni czasu Robak ewoluował a jego kod się zmieniał. Doklejony kod znajduje się na samym końcu pliku lub jego początku.

Kod trojana js Redirectort-MR

  • wystarczy usunąć z plików niechciany kod a następnie wgrać na serwer „zdrowe pliki”.
Koniecznie przeskanuj swój komputer w poszukiwaniu szkodliwego oprogramowania oraz zmień dane dostępowe FTP  do swoich serwerów. Tle wystarczy Twój blog znowu jest bezpieczny.
Na zakończenie pragnę podziękować Mariuszowi Kołaczowi oraz Mikołajowi Zych za zwrócenie uwagi na pojawienie się problemu oraz udostępnienie zrzutów informacji o Trojanie.

 

[Edycja 02.04.2012]

Dziś problem pojawił się ponownie. Trojan ponownie dodał swój kod do pliku functions.php w katalogu thema. Dokładna analiza plików pozwoliła na wykrycie nowego złośliwego  pliku w katalogu:  wp-admin/js/revisions-js.php. Jak widać robak dodał plik php do katalogu js. Dodatkowo skorzystałem z pluginu TAC którym przeskanowałem skórkę pod kątem złośliwego oprogramowania.

Usunołem także, prawa dostępu do zapisu do plików functions.php, katalogu wp-admin/js oraz kilku innych kluczowych miejsc. Zobaczymy, czy te zmiany spowodują rozwiązanie problemu.  Na sam koniec wgrałem wtyczkę która informuje poprzez e-mail o wszelkich zmianach w plikach WP.

Wpis zaktualizuje za kilkanaście dni o informacje czy dodatkowe moje działania były skuteczne.

[adsenseyu4]

[Edycja 16.04.2012]

Minęły dwa tygodnie. Jest już to wystarczający termin aby ocenić, czy solucja była skuteczna. Problem już więcej się nie pojawił i Trojan  js:Redirector-MR[Trj] odszedł skutecznie na wieczny odpoczynek 🙂

Zobacz także:

11 komentarzy do “Kilka słów o tym jak WebCake.pl padło ofiarą trojana js:Redirector-MR[Trj]

  1. Bardzo dobry, solidny poradnik. Widziałem na kilku innych stronach podobne przypadłości, mogę się założyć że admini tych witryn będą ci wdzięczny za ten poradnik 😉

  2. 2 tygodnie temu sam miałem spore problemy z tym dziadostwem.  Szkoda, że wcześniej nie opisałeś tego problemu. Zaoszczędził bym masę czasu na szukaniu rozwiązania 😉

  3. 2 tygodnie temu sam miałem spore problemy z tym dziadostwem.  Szkoda, że wcześniej nie opisałeś tego problemu. Zaoszczędził bym masę czasu na szukaniu rozwiązania 😉

  4. Ostatnio chyba mamy plagę tego typu zagrożeń.

    Również miałem z tym problem.

    Okazało się, że bot uzyskał dostęp do klienta FTP (w moim przypadku total commandera). Hasła miałem zapisane w formie gwiazdek i to wystarczyło. Rozwiązaniem problemu okazała się zmiana haseł do FTP oraz nadpisanie kilku plików, np. index.php.

    Zdecydowanie odradzam trzymać hasła w programie, lepiej za każdym razem przy połączeniu wpisywać je ręcznie.

  5. U mnie to ze 3 razy były trojany na jednej ze stron. Dwa razy z tego samego powodu – przez skórkę – skórka profesjonalna typu premium. Co się później okazało wszytko przez plik timthumb.php – czasami ten plik jest wykorzystywany w skórkach i często ma luki w bezpieczeństwie. Dlatego warto aktualizować skórki, bo często przez nie są problemy. Jak później się okazało jedną z aktualizacji owej skórki było pozbycie się właśnie tego pliku ze względu na znane problemy z bezpieczeństwem.

    No ale jeśli ktoś używa skórki z tym plikiem to jest wtyczka, która sprawdza jego aktualność:
    http://wordpress.org/extend/plugins/timthumb-vulnerability-scanner/

    Kolejna rzecz to nie wiem jak inni, ale ja nie ściągam na swój komputer zarażonych plików – nigdy nie wiadomo co tam jest i jakie szkody może nam wyrządzić. Mam za to wersje lokalne stron. Nie zawsze są zbieżne idealnie z tym co jest w sieci, bo wiadomo tam są aktualizacje, ale pliki z trojanami zwykle są znacznie większe, więc można to rozpoznać po wielkości pliku. Wówczas można nadpisać lokalnym plikiem. Osobiście poradziłem sobie w taki sposób, że nadpisałem plikami z komputera – właściwie to cały szablon wgrałem nowy + usunąłem jakiś plik, który trojan stworzył. Ponadto ściągnąłem najnowsze wersje wtyczek, które też zostały zainfekowane. Głównie miałem pliki js zainfekowane – bo tam też najczęściej umiejscawiają się trojanki.

    A w bieżącym miesiącu miałem kolejnego trojana – znalazłem go przypadkiem, bo przeglądałem statystyki strony i wyszło, że mam od jakiegoś czasu zero wejść. Zero wejść miałem z tego względu, że przez tego trojana Googiel dopisał mnie na czarną listę – taki widok też nie jest zbyt miły gdy w wynika wyszukiwania pod Twoją stroną jest link z wiadomością, że Twoja strona jest potencjalnie niebezpieczna i nie można na nią wejść, bo po kliknięciu pojawia się kolejna strona z ostrzeżeniem od Googla Wszedłem na nią i chyba jeszcze jedno ostrzeżenie było (to takie czerwone, że witryna dokonuje ataków).

    Tym razem trojan dopisał się do .htaccess. Tym razem ściągnąłem plik i awast nawet nie krzyczał. Chciałem zobaczyć co w nim jest i nie było nic niestandardowego poza większą ilością miejsca przed kodem WP. No, ale nadpisałem ten plik swoim lokalnym i problem zniknął. W narzędziach dla webmastera wysłałem info o ponowne sprawdzenie strony w G i po dwóch dniach strona nie jest już na blackliście.

    Do odnajdywania szczegółów co jest nie tak i gdzie polecam ten skaner:
    http://sitecheck.sucuri.net/scanner/
    Dzięki niemu pozbyłem się trojanów za każdym razem. Ma tylko jedną wadę (no może więcej o których nic nie wiem): nie znajdzie trojanów w plikach admina – bo WP nie korzysta z nich podczas normalnego używania strony.

    Dzięki Krystian za linki. Ten ze sprawdzaniem zmian i informacjami na maila wydaje mi się przydatny. Muszę przetestować.

    Wow… ale się napisałem 😛

    1. Woow gdybym ogłosił konkurs na najlepszy komentarz wygrał
      byś w cuglach 😛 Dzięki za masę ciekawych informacji rozszerzających
      temat.  Odkąd wprowadziłem ograniczenia do edycji plików problem znikł
      całkowicie.

      Również mogę potwierdzić ż timthumb.php to zło z którym
      trzeba się liczyć albo po prostu nie używać .

  6. Jeszcze jedna ważna wskazówka… po wszelkich zabiegach warto jeszcze czasem opróżnić cash w przeglądarce… 

      1. usuń od echo… do ostatniego średnika .. czyli cały kod z linii 443 który wkleiłeś. Monitoruj pliki w których znalazłeś złośliwy kod. Jak wspomniałem w artykule problem powracał kilka razy. Dopiero przeskanowanie wszystkich plików php + zablokowanie możliwości edycji pliku rozwiązało problem.  

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *