Zostać shakowanym. Chcesz zrozumieć jak

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),

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.

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”).

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)?

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!

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.

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.

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.

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.

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.

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.

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