Zostać shakowanym. Chcesz zrozumieć jak

40

Ktoś po raz drugi dołączył fragment javascript do strony, którą pomagam uruchomić. Ten skrypt javascript porywa Google Adsense, wstawiając własny numer konta i przyklejając reklamy.

Kod jest zawsze dołączany, zawsze w jednym określonym katalogu (jeden używany przez program reklamowy strony trzeciej), wpływa na liczbę plików w wielu katalogach w tym jednym katalogu reklam (około 20) i jest wstawiany mniej więcej w tym samym czasie z dnia na dzień czas. Konto AdSense należy do chińskiej strony internetowej (znajduje się w mieście niecałą godzinę od miejsca, w którym będę w Chinach w przyszłym miesiącu. Może powinienem pójść na bójki… żartuję, w pewnym sensie), tak dalej… oto informacje na temat strona: http://serversiders.com/fhr.com.cn

Jak mogliby dołączyć tekst do tych plików? Czy ma to związek z uprawnieniami ustawionymi dla plików (od 755 do 644)? Dla użytkownika serwera WWW (jest on w MediaTemple, więc powinien być bezpieczny, tak?)? To znaczy, jeśli masz plik z uprawnieniami ustawionymi na 777, nadal nie mogę po prostu dodawać do niego kodu do woli ... jak oni to robią?

Oto przykładowy kod dla Twojej przyjemności oglądania (i jak widać ... niewiele. Prawdziwa sztuczka polega na tym, jak go tam dostali):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Ponieważ wspomniało o tym wielu ludzi, oto co sprawdziłem (a przez zaznaczone mam na myśli, że rozejrzałem się w czasie, gdy pliki były modyfikowane pod kątem jakiejkolwiek dziwności i przeszukałem pliki na potrzeby instrukcji POST i przechodzenia przez katalog:

  • access_log (nic w tym czasie oprócz normalnego (tj. nadmiernego) ruchu botów msn)
  • error_log (nic oprócz zwykłego pliku nie zawiera błędów dla nieszkodliwych plików)
  • ssl_log (nic oprócz zwykłego)
  • messages_log (tutaj nie ma dostępu do FTP oprócz mnie)

* AKTUALIZACJA: ** OK, rozwiązałem to. Hakerzy z Chin fizycznie umieścili plik na naszej stronie, który pozwala im wykonywać wszelkiego rodzaju czynności administracyjne (dostęp do bazy danych, usuwanie i tworzenie plików i katalogów, nazywacie to, mieli dostęp). Mieliśmy szczęście, że nie zrobili czegoś bardziej destrukcyjnego. Nie było nic w normalnych plikach dziennika apache, ale znalazłem inny zestaw plików dziennika w analizatorze dzienników serwera WWW i były tam dowody. Mieli dostęp do tego pliku z własną nazwą użytkownika i hasłem administratora, a następnie edytowali wszystko, czego potrzebowali na serwerze. Ich plik ma „apache” ustawiony jako użytkownik, podczas gdy wszystkie inne pliki w naszej witrynie mają inną nazwę użytkownika. Teraz muszę dowiedzieć się, jak fizycznie dostali ten plik do naszego systemu. Podejrzewam, że wina za to ostatecznie spocznie na naszym hostie (Media Temple),

Lothar_Grimpsenbacher
źródło
6
Nie wiem, czy dałeś komuś swoje hasło?
4
Jeśli wiesz, kiedy dokładnie to się stanie, przeszukaj dziennik access_log pod kątem wszystkich nietypowych rzeczy w tym czasie. Szczególnie zwróć uwagę na wszystkie żądania POST: dokąd idą, co zrobili.
sanmai
3
Dzięki WhirlWind ... bardzo pomocny.
Lothar_Grimpsenbacher
2
Właściwie jeśli je znasz, to dlaczego nie wkleić ich danych adresowych na stronie antyspamowej. Niech sieć „mówi” do nich i daj im posmakować własnej medyki. :-)
4
@ gaoshan88 - bardziej pomocny niż myślisz. Jednym z wektorów ataku jest trojan wykrywający hasła z klientów ftp deweloperów.
Quentin

Odpowiedzi:

9

Przede wszystkim chmod 744NIE jest to, czego chcesz. Celem chmod jest cofnięcie dostępu do innych kont w systemie. Chmod 700jest znacznie bezpieczniejszy niż chmod 744. Jednak Apache potrzebuje tylko bitu wykonania, aby uruchomić aplikację php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data jest powszechnie używane jako konto Apache, które służy do uruchamiania php. Możesz również uruchomić to polecenie, aby wyświetlić konto użytkownika:

`<?php
print system("whoami");
?>`

FTP jest strasznie niepewny i bardzo prawdopodobne jest, że zostałeś zhakowany tą metodą. Korzystając z FTP, możesz zapisywać pliki, a następnie ponownie je infekować. Upewnij się, że uruchamiasz antywirusa na wszystkich komputerach z dostępem FTP. Istnieją wirusy, które węszą lokalny ruch w poszukiwaniu nazw użytkowników FTP i haseł, a następnie logują się i infekują pliki. Jeśli zależy Ci na bezpieczeństwie, użyjesz SFTP, który wszystko szyfruje. Przesyłanie kodu źródłowego i haseł zwykłym tekstem to totalne szaleństwo.

Inną możliwością jest użycie starej biblioteki lub aplikacji. Odwiedź witrynę producenta oprogramowania i upewnij się, że korzystasz z najnowszej wersji.

Wieża
źródło
6
+1, unikaj plagi jak FTP. Trojan przechwytujący hasła może zainfekować komputer i użyć poświadczeń do zmiany plików. Lub może zainfekować router. Lub komputer sąsiada w sieci z niezabezpieczoną siecią Wi-Fi. Wysłanie hasła w clearext to zły, zły pomysł.
Tgr
1
Wiesz, FTP zawiera SSL.
grawitacja
1
@ Grawity większość ludzi nie używa „ftps”, ale to powstrzyma cię przed włamaniem. sftp jest bardziej popularny.
Wieżowiec
2
Dane www NIE powinny posiadać plików w twoim katalogu internetowym. Wszystko, co dane www mogą być aktualizowane przez źle napisany skrypt na serwerze.
Zoredache,
9

Konta My Media Temple Grid Server zostały „zhakowane” kilka razy w ten sposób. Ich bezpieczeństwo jest bardzo słabe ... zaczęło się od HASŁA PLAIN TEXT w zeszłym roku i trwa do dziś (możesz zadzwonić do pomocy technicznej, a oni mówią „jakie jest twoje hasło?”). Wiem, ponieważ otrzymuję comiesięczne wiadomości e-mail o tym, jak zmieniły wszystkie hasła do mojego konta, i faktycznie wchodzą i zmieniają hasła do bazy danych za każdym razem, gdy zostają zhakowane. Ta firma na powierzchni wygląda błyszcząco jak diabli, ale serwer gridowy to bałagan. Polecam natychmiastowe przełączenie .

Zobacz ten post z zeszłego roku na temat oryginalnego fiaska (ostrzeżenie, że cię to wkurzy). Stamtąd poszło w dół. W zeszłym roku spędziłem Święto Dziękczynienia z dala od rodziny i usuwając linki pornograficzne z moich stron internetowych. Śliczny.

Śledź zabawę na ich stronie statusu : pokaże ci wszystko o najnowszych exploitach (i tak, w tej chwili jest tam „możliwy exploit”).

typoneerror
źródło
ha ha. wszystkie moje strony gs są teraz wyłączone. brak e-maila weblog.mediatemple.net/weblog/category/system-incident/…
typeoneerror
2

Biorąc pod uwagę brak aktywności w dziennikach dostępu itp. Oraz fakt, że dzieje się to mniej więcej w tym samym czasie, wydaje się, że naruszyli serwer i uruchomili jakiś skrypt powłoki, aby wykonać dołączanie.

Czy sprawdziłeś crontab pod kątem czegoś dziwnego?

Czy próbowałeś zmienić nazwę katalogu i odniesień do niego (może to spowodować uszkodzenie skryptu powłoki)?

abarax
źródło
zmiana nazwy jest dobrym pomysłem. Spróbuję, gdy zobaczę, jakie to będzie miało wpływ na stronę. Crontab miał jedną nieco dziwną rzecz: istnieje czas na zmianę plików, ale jest to menedżer kopii zapasowych Plesk ... skompilowana aplikacja. Jeśli to zostanie zagrożone, wtedy Media Temple ma duży problem.
Lothar_Grimpsenbacher
1

Tak, może to być zdecydowanie związane z uprawnieniami do plików. Dzięki plikom, które mogą być zapisywane przez proces sieciowy, jesteś otwarty na wszelkie luki w zabezpieczeniach w uruchomionych aplikacjach internetowych. Zablokuj wszystko, aby proces sieciowy nie mógł czytać ani pisać niczego więcej niż to konieczne.

Drugi komponent śledzi dokładnie, w jaki sposób modyfikują pliki. Sprawdzanie dzienników dostępu do serwera WWW jest dobrym miejscem do rozpoczęcia. Sprawdź czasy ostatniego logowania dla różnych użytkowników. Możesz także skonfigurować skrypt, który monitoruje pliki w celu modyfikacji i powiadamia cię, abyś mógł spróbować złapać przestępców na gorącym uczynku!


źródło
1

Brzmi to strasznie znajomo w hackach Wordpress, które ostatnio trafiły do ​​wielu witryn Network Solutions. Ponieważ korzystasz z Media Temple, możliwe jest, że niektóre pliki pozostaną widoczne dla innych użytkowników udostępniających Twój komputer. To by tłumaczyło brak śladów POST lub wszystkich śladów dziennika Apache. W takim przypadku byłoby śmiertelnie proste wstrzyknięcie kodu w wierszu polecenia.

redaktor
źródło
Dzienniki pokazują ruch w czasie, gdy pliki te były modyfikowane, ale są to nieszkodliwe rzeczy, takie jak: 207.46.13.43 - - [05 / May / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 i strona = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher
Czy wiesz, jak działał hack Wordpress? Może mi powiedzieć, jak rozwiązać mój własny problem.
Lothar_Grimpsenbacher
2
Tak, to złe uprawnienia do współdzielonych urządzeń, prawdopodobnie spowodowane złymi domyślnymi konfiguracjami ze strony Network Solutions. Zalecaną poprawką było zablokowanie uprawnień jako 755 w folderach i 644 w plikach.
1

Kod jest zawsze dołączany, zawsze w jednym określonym katalogu

Czy ma to związek z uprawnieniami ustawionymi dla plików (od 755 do 644)? Do użytkownika serwera WWW

Czy jesteś na serwerze współdzielonym? Jeśli tak (a nawet jeśli nie), ktoś mógł brutalnie wymusić hasło FTP i załadować skrypt, który dołączał wszystkie pliki, które mógł zdobyć.

jeden używany przez program reklamowy strony trzeciej

A może ten program ma exploita.

webbiedave
źródło
Zakładam, że być może kod innej firmy ma exploita. Jest na serwerze współdzielonym, ale znalazłbym wszystkie przesłane skrypty (chyba że je załadowały, wykorzystały, a następnie usunęły, ale nawet wtedy znalazłbym coś w plikach dziennika pokazujące ich połączenie ftp)
Lothar_Grimpsenbacher
1
Jeśli twoje pliki są zapisywalne przez serwer sieciowy, możliwe, że przesłali skrypt do dowolnej witryny na serwerze i nadpisali twoje pliki. Ale przyjrzałbym się również tej aplikacji innej firmy.
Kod osoba trzecia ... jest to plik wykonywalny skrypt lub po prostu fragment JavaScript? JavaScript nie może modyfikować plików na serwerze.
Salman A
@Salman A - jest to zbiór skryptów PHP zarządzających reklamą.
Lothar_Grimpsenbacher
OK, więc mam nadzieję, że sprawdziłeś ten kod.
Salman A
1

Jeśli masz odpowiedni dostęp (i obsługę jądra), możesz spróbować uruchomić demona monitorującego na podstawie inotify lub dnotify, aby obserwować zmiany w swoich plikach, a następnie (szybko) użyj „lsof”, aby zobaczyć, z jakim procesem plik jest otwarty dostęp do zapisu. Możesz również użyć strace do monitorowania. To powinno dać wskazówkę co do tego, który plik wykonywalny jest wykorzystywany.

outis
źródło
1

Dzienniki kontroli FTP to pierwsze miejsce, od którego można zacząć. Dziennik powinien zawierać większość, jeśli nie całą aktywność, wraz ze znacznikami czasu, więc jeśli wiesz, o której godzinie pliki zostały zmodyfikowane, możesz ustalić, czy Twoje konto FTP zostało naruszone, czy nie.

Następnie może to być skrypt na twoim serwerze, który wstrzykuje ten kod. W scenariuszu hostingu dzielonego myślę, że można to zrobić cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Może to działać pod pewnymi warunkami, np. Polecenie wykonywane przez użytkownika httpd i plik index.php jest również własnością / zapisywalny przez tego użytkownika. W takim przypadku powinieneś poprosić swojego dostawcę usług hostingowych o śledzenie konta używanego do wstrzykiwania skryptów.

Salman A.
źródło
1

Większość plików witryny musi być odczytywana przez serwer WWW. W witrynie tylko do odczytu serwer WWW musi zapisywać tylko dzienniki. ustaw właściciela na osobę inną niż używana przez serwer WWW. Ustaw ochronę 640 na wszystkie pliki oprócz skryptów. Ustaw skrypty i katalogi 750. W przypadku plików lub katalogów, które muszą być napisane przez serwer WWW, możesz zmienić właściciela na serwer WWW lub ustawić chmod g + 2 odpowiednie pliki lub katalogi.

BillThor
źródło
Skrypty inne niż CGI mogą często mieć tryb 600 lub 640 (w zależności od właściciela pliku i grupy oraz tego, jakiego użytkownika używa serwer WWW), ponieważ wiele skryptów jest przekazywanych do tłumacza.
poza
0

Istnieje wiele możliwych sposobów na złamanie witryny. Mogli wykorzystać lukę w skrypcie, skradzić hasło, wykorzystać lukę w hostowanej witrynie (jeśli korzystasz z taniego hosta), wykorzystać lukę w zabezpieczeniach niektórych usług niezwiązanych z siecią na serwerze. .

W pierwszej kolejności sprawdź datę modyfikacji pliku i sprawdź dzienniki dostępu, błędów i ftp pod kątem wszelkich podejrzanych działań w tym czasie.

Tgr
źródło
0

To samo przytrafiło mi się jakiś czas temu. Wordpress był jedynym oprogramowaniem, które, o ile wiem, spowodowałoby coś takiego.

Joe Phillips
źródło
Nie bierze w tym udziału Wordpress.
Lothar_Grimpsenbacher