Od zainfekowanej witryny do poważnego incydentu bezpieczeństwa – studium przypadku

Poważne wycieki danych i incydenty bezpieczeństwa niekoniecznie muszą być efektem świadomego działania intruzów wymierzonego w konkretny cel. Nie zawsze też są od razu zauważone przez ofiary ataku. Często do poważnego naruszenia bezpieczeństwa dochodzi w wyniku splotu kilku zdarzeń a jego wykrycie może być efektem dociekliwości przypadkowej osoby. Poniżej przedstawiamy zapis ciekawego dochodzenia, w wyniku którego odkryliśmy bardzo poważne zagrożenie dla danych klientów dużej firmy hostingowej.

UWAGA:
W poniższym opisie zawarte są linki do stron internetowych, które padły ofiarą ataków lub są utrzymywane przez organizacje o podejrzanej reputacji. Ich otwarcie może się wiązać z zagrożeniem.

Studium przypadku

Na jednej ze stron Internetowych utrzymywanych w AZ.pl (firma hostingowa należąca do Home.pl obsługująca w Polsce największą ilość domen wg http://top100.wht.pl/) zauważyłem podejrzane zachowanie: wpisanie adresu strony w przeglądarce powodowało przekierowanie na adres http://semanticore.com.pl/admin/dropbox/proposal/, pod którym otwierała się strona udająca Dropboxa i prosząca o zalogowanie się – klasyczny phishing. Pierwsze co mi przyszło do głowy, to że przegapiłem odnowienie domeny i ktoś ją przejął. Ale nie, domena opłacona. Loguję się więc do panelu hostingowego i sprawdzam pliki strony. Kilka z nich posiada dzisiejszą datę modyfikacji, mimo iż żadnych zmian w dniu dzisiejszym nie wprowadzałem. Strona została więc zmodyfikowana w sposób nieautoryzowany. Szybka analiza możliwych wektorów ataku:

1. Nieaktualny, dziurawy CMS – odpada, najnowsza wersja WordPressa, zaktualizowana kilka dni wcześniej
2. Zainfekowany komputer i wyciek hasła zapisanego w kliencie FTP – odpada, pomijając fakt, że coś tam wiem o bezpieczeństwie i swojego komputera jestem raczej pewien, nie korzystałem w ogóle z dostępu do strony przez FTP a hasło do niego zapisane miałem tylko w KeePassX
3. Wyciek hasła do konta hostingowego (cPanel) – odpada z powodów j.w., hasło nigdzie nie zapamiętane poza KeePassX.
4. Atak siłowy lub słownikowy na hasło FTP lub cPanel – jak wspomniałem trochę o bezpieczeństwie wiem, hasło niesłownikowe i dosyć silne (kilkanaście znaków) więc prawdopodobieństwo raczej małe.
5. Ktoś jeszcze znał hasła i nie zachował odpowiedniej ostrożności – odpada, stroną zarządzałem tylko ja

Do rozważenia pozostaje więc chyba tylko 0-day na WordPressa, ale bądźmy poważni, kto by zapłacił za niego żeby uskutecznić phishing na stronie o zerowej oglądalności? Nie mając chwilowo lepszych pomysłów zerkam do katalogu innej strony, którą mam na tym samym koncie hostingowym i tu niespodzianka: w folderze strony składającej się tylko z pliku index.html pojawił się nie wiadomo skąd plik wp-apps.php. Co ważniejsze do tej strony nie mam nawet konta FTP więc w zasadzie jedyną możliwością wrzucenia tam pliku był dostęp przez cPanel. A może kompromitacja serwera hostingowego? Dosyć odważna teza, ale prawie w tym samym czasie zauważam, że strona z phisingiem, do której następuje przekierowanie okazuje się mieć to samo IP co moja, leży więc na tym samym serwerze. I nagle odważna teza staje się bardziej prawdopodobna. Pora zadzwonić do AZ i podzielić się spostrzeżeniami. Rozmowa przebiega mniej więcej tak:

– przedstawiam problem punkt po punkcie, jak to opisałem powyżej

– na jaki adres następuje przekierowanie gdy wchodzi Pan na swoją stronę?

– http://semanticore.com.pl – odpowiadam

– ok, zablokujemy temu użytkownikowi konto za złamanie regulaminu

– ??? Ale zaraz, przecież to nie jego wina, że ktoś mu stronę zmodyfikował. A co ze mną?

– Możemy Panu przywrócić pliki z backupu sprzed 4-5 dni, proszę przesłać takie zgłoszenie.

– A jeżeli ktoś je znowu podmieni w ten sam sposób?

– Proszę sobie dla pewności uruchomić skanowanie antywirusowe

– Ale tłumaczę Panu, że jestem pewien, że problem nie leży po mojej stronie. Może to coś u was, skoro ten phishing ma miejsce na tym samym serwerze? Może to jakiś masowy problem?

– Niemożliwe, nie mamy podobnych zgłoszeń

Przesłałem więc zgodnie z prośbą zgłoszenie o przywrócenie plików z backupu opisując tam jeszcze raz cały problem.

W międzyczasie zacząłem przeglądać zmodyfikowane pliki i oceniać szkody. Znaleziony wp-apps.php okazuje się odmianą dosyć popularnego web shella o nazwie „WSO”. W pierwszych paru linijkach dostęp do niego zabezpieczono hasłem zapisanym w postaci skrótu MD5 „9cdfb439c7876e703e307864c9167a15” (pierwszy z brzegu łamacz online znajduje hasło w parę sekund, brzmi ono „lol”) . Reszta pliku to kod zaciemniony przez dosyć prostą i popularną technikę:

eval(gzinflate(base64_decode(„HZ3HkqPagkX/5Y3uDQZ4Fx09wA………itd.”)))

czyli wykonanie kodu php, który jest najpierw zakodowany za pomocą base64 a następnie spakowany w standardzie deflate. Warto wspomnieć, że dobrą praktyką w hardeningu serwerów webowych jest zablokowanie funkcji eval(). Tutorial PHP ostrzega przed nią, a w pierwszym komentarzu sprzed 12 lat czytamy:

If eval() is the answer, you're almost certainly asking the
wrong question.

Ale wróćmy do web shella. Wchodzę pod adres http://moja_strona/wp-apps.php żeby sprawdzić co ciekawego mamy do dyspozycji. Parę kliknięć i znajduję się w katalogu /backup/sqlbackup/mysql/ !!! a w nim zrzuty wszystkich baz z serwera z uprawnieniami „644”! (odczyt dla wszystkich). Trochę nie dowierzam, więc odnajduję swoją bazę do wordpressa i ściągam żeby się upewnić. Rozpakowuję, zaglądam do środka, jest wszystko, a nawet więcej. W tabeli wp_users oprócz swojego konta administracyjnego znajduję jakieś drugie o nazwie „-” z ustawionym hasłem i pełnymi prawami do bazy. I w tym momencie dociera do mnie co się tak na prawdę stało. Wystarczyło, że jedna z tysięcy stron utrzymywanych na serwerze została skompromitowana (dziurawy CMS, słabe hasło, wirus, cokolwiek) a intruz uzyskał dostęp do wszystkich baz danych z całego serwera. Mógł je sobie pobrać i ze spokojem łamać hasła, po czym logować się do CMS-ów jako admin i dodawać tam swoje konta, za pomocą których później modyfikował zawartość stron i przeglądał bazy. Prawdopodobnie w którejś z baz trzymane są też hasła wszystkich klientów do ich kont hostingowych. Jeżeli intruz uzyskał do niej dostęp i zaczął łamać hasła to w każdej chwili może przewrócić do góry nogami usługi tysięcy klientów.

Następnego dnia postanawiam to sprawdzić. Wchodzę ponownie do katalogu ze zrzutami baz i szukam jakiejś nazwy wskazującej na bazę użytkowników cPanelu. Większość baz ma nazwy rozpoczynające się od loginu klienta, co oznacza, że są to bazy użytkowników. Jest zaledwie kilka o innych nazwach, a wśród nich „mysql”, czyli główna baza serwera bazodanowego. Sprawdźmy. Ale zaraz, tutaj uprawnienia nie pozwalają na odczyt (600). Spoglądam na inne bazy, uprawnienia również ograniczone. Czyżby ktoś się zorientował i poprawił skrypty do backupu? Zostawiam sprawę otwartą na parę dni bo natłok różnych obowiązków nie pozwala mi chwilowo wrócić do tematu. Któregoś wieczora jednak postanawiam sprawdzić czy coś się nie zmieniło. Odwiedzam katalog z backupami i znowu niespodzianka: ponownie uprawnienia do wszystkich baz mają postać 644. Ale przy okazji zauważam też, że baz w katalogu jest znacznie mniej. Może trafiłem w moment powstawania plików ze zrzutami baz? Odświeżam katalog, kilka plików przybyło. Bingo. Przyglądam się procesowi powstawania plików i ich datom. Pierwsze powstają o 23.30, ostatnie około 04.30. Zrzut ponad 1800 baz trwa jakieś pięć godzin, po czym prawa dostępu do wszystkich plików zostają zmodyfikowane z 644 na 600. I już wszystko jasne. Skrypt backupowy modyfikuje prawa po wykonaniu zrzutu, ale wraz z przyrostem klientów i baz proces ten zaczął trwać kilka godzin. I te kilka godzin każdej nocy każdy z użytkowników serwera oraz intruzi, którzy przejęli dowolną stronę na nim, mają możliwość skopiowania sobie wszystkich baz. Wracam do punktu, w którym poszukiwałem bazy użytkowników cPanelu. „Mysql” okazuje się dobrym tropem. Tabela „user” zawiera loginy i hasła wszystkich klientów do ich własnych baz oraz głównego panelu hostingowego. Jeżeli ktoś poza mną to odkrył to skutki mogą być katastrofalne.

W międzyczasie znajduję na swoim koncie hostingowym plik „.lastlogin”. Szybki przegląd logu i potwierdzają się niestety przypuszczenia. Na moje konto hostingowe logowano się kilka razy z adresu IP, który nie należy do mnie. Czyli ktoś już pobrał sobie bazy i korzysta z ich zawartości. Whois pokazuje, że podejrzany adres IP należy do sieci Home.pl – większościowego udziałowca AZ.pl. Może tam też mają podobny problem? Może infrastruktura jest wspólna albo zarządzana przez ten sam zespół? Pora zgłosić problem ponownie do AZ.pl. Z racji późnych godzin nocnych i nieczynnej infolinii korzystam z formularza kontaktowego:

Wykryłem na Państwa serwerach krytyczny błąd w zabezpieczeniach, który umożliwia przejęcie m.in. wszystkich kont hostingowych oraz baz danych i wyciek danych osobowych na ogromną skalę. Proszę o potraktowanie tej informacji bardzo poważnie (posiadam dowody) i przekazanie jej do osoby odpowiedzialnej w spółce za bezpieczeństwo (CISO) lub bezpośrednio do zarządu. Jestem gotów podjąć współpracę w zakresie wskazania i usunięcia źródła problemu. Oczekuję kontaktu ze strony osoby umocowanej do podjęcia odpowiednich kroków.

Kontakt następuje po ponad 32 godzinach. Dzwoni do mnie pan z infolinii pytając czy mam jakieś dowody, bo podobnych zgłoszeń mają setki. Informuję, że mogę przesłać zrzut głównej bazy mysql albo dowolnej innej dowolnego użytkownika. Pan prosi zatem o mój login do panelu hostingowego i informuje, że administratorzy prześledzą historię działań na nim. Otrzymuje ode mnie dodatkową wskazówkę, że bazy danych dostępne są w trybie odczytu dla wszystkich. Po kolejnych 30 godzinach dostaję krótką informację mailem:

Na podstawie naszej rozmowy i przekazanych przez Pana informacji, jak również na podstawie weryfikacji ustawień na serwerach, zostały wprowadzone zmiany mające na celu poprawienie zabezpieczeń serwerów AZ.pl.

Przydałoby się jakieś „dziękujmy” ale mniejsza o to, pozostaje mi sprawdzić efekty. Wrzucam ponownie na serwer web shella, którego wcześniej usunąłem i stwierdzam, że dali radę. Tym razem nie mogę już wyjść poza swój katalog home. Pozostaje jednak dosyć istotna kwestia do załatwienia. Odpowiadam więc na ostatniego maila:

Czy zamierzają Państwo poinformować swoich klientów o tym incydencie? Moim zdaniem należy im się informacja o tym, co mogło, już się zdarzyło lub jeszcze może się zdarzyć:

1. Możliwości przejęcia ich baz danych

2. Możliwości nieautoryzowanego utworzenia użytkowników w bazach

3. Możliwości nieautoryzowanego dostępu do CMS-ów i modyfikacji serwisów webowych

4. Możliwości nieautoryzowanego dostępu do konta hostingowego i modyfikacji usług

5. Możliwości nieautoryzowanego dostępu do poczty

6. Możliwości wycieku danych osobowych i płatniczych

Odpowiedzi na razie nie ma. Pozostają natomiast dwa bardzo istotne pytania: od jak dawna miał miejsce taki stan rzeczy i czy problem występował tylko na jednym serwerze, na którym ja mam konto, czy na wszystkich (wówczas nie tysiące, a dziesiątki albo i setki tysięcy klientów mogło utracić swoje dane). W ustaleniu odpowiedzi dosyć szybko pomaga Google. Wpadam na pomysł, że skoro jakieś strony na AZ zostały skompromitowane i umieszczano na nich tego samego web shella, to może Google zdążył je zaindeksować. Jedną z informacji zwracanych przez web shell jest wynik linuksowej komendy 'uname -a’. Na moim serwerze jest to: „Linux az0103.srv.az.pl 4.0.6 brocade-gut #31 SMP Fri Nov 20 22:05:10 CET 2015 x86_64„. Odpytuję więc Google o ciąg „srv.az.pl 4.0.6 brocade-gut” i już pierwsze wyniki zwracają linki do skompromitowanych stron leżących na serwerach AZ, nie tylko z web shellem WSO, ale kilkoma innymi. W większości z nich web shell został już jednak podmieniony na plik options.php, który ładuje demo flashowe informujące o przejęciu strony przez niejaki AYYILDIZ TIM (przykładowa strona: http://www.poczta.kukow.pl/options.php ). Są też downloadery i uploadery ( http://hosting6203918.az.pl/ , http://www.hosting3298174.az.pl/loc ). Ale najciekawszy okazuje się wpis na forum RedTurk: http://redturk.org/konu-12-site-hacked.html datowany na 13.05.216, o następującej treści:

Zone adresleri http://golgeler.net/shadow!Tar.gz!1

Linux az0014.srv.az.pl 4.0.6 brocade-gut #31
Easy server 🙂

http://ostpol.pl/c1/1/backup/sqlbackup/

Pod pierwszym linkiem znajdziemy listę przejętych stron, z których większość leży na serwerach AZ. Komentarz i drugi link (chociaż już niedziałający) są niestety potwierdzeniem moich obaw. Ponad cztery miesiące temu na forum o wątpliwej reputacji podał ktoś linka, który przez web shella listował zawartość katalogu z bazami i to na innym serwerze, niż mój. Można więc założyć, że problem dotyczył wszystkich serwerów AZ. Kto jest w posiadaniu tych baz i co z nimi robi możemy się jedynie domyślać.

Spisanie notatek i utworzenie z nich niniejszego artykułu zajęło mi na raty kilka wieczorów. W międzyczasie wnikliwie przyglądałem się swoim usługom na AZ mając świadomość, że w każdej chwili ktoś może się do nich dobrać. Zauważyłem jeszcze jedną niepokojącą rzecz: Loginizer (wtyczka do WordPressa wykrywająca nieudane próby logowania) raportowała mi ogromną ilość prób dostępu z różnych adresów IP. Do tego w logach stron znajdują się równie duże ilości wpisów świadczących o próbach ataków siłowych na hasło do WordPressa przez xmlrpc.php. Można zatem przypuszczać, że intruzi, którzy odkryli podatność na dowolnym serwerze AZ atakowali hurtowo wszystkie strony leżące na innych serwerach aby uzyskać dostęp również do baz tam leżących. Dziwi mnie trochę, że AZ.pl nie dysponuje narzędziami do wykrywania tego typu działań. Takie próby powinny chyba zostać odnotowane chociażby przez WAF-a (Web Application Firewall)?

Nie do końca przekonany też jestem czy AZ.pl zdaje sobie sprawę z powagi sytuacji. A może liczą, na to, że wszyscy ich klienci posiadają na tyle silne hasła, że ataki słownikowe i siłowe na nic się nie zdadzą? Moim zdaniem klientom zdecydowanie należy się informacja, że w wyniku nieostrożności po stronie AZ.pl w każdej chwili możliwy jest dostęp do wszystkich ich usług, m.in. konfiguracja DNS, przeglądanie poczty e-mail, modyfikacja stron WWW. Utrzymywane są tam m.in. sklepy internetowe, fora, blogi… Ilość danych osobowych w bazach klientów jest pewnie niezliczona. Mogą się tam też znajdować dane płatnicze, może nawet numery kart?

Na koniec mała wskazówka dla osób, które korzystają z usług AZ.pl. Lista kroków, które każdy użytkownik powinien wykonać w celu zabezpieczenia swoich usług:

1. Zmiana hasła do konta hostingowego (cPanel).
2. Zmiana haseł do wszystkich usług powiązanych z danym kontem (poczta, ftp, bazy danych).
3. Przegląd baz danych pod kątem obecności nieznanych użytkowników. W moim przypadku była to nazwa „-„, ale mogły również pojawić się inne.
4. Przegląd serwisów www pod kątem obecności web shelli lub zmodyfikowanych w sposób nieautoryzowany plików.
5. W przypadku sklepów i innych serwisów usługowych – powiadomienie swoich klientów o możliwości kradzieży ich danych osobowych oraz zalecenie / wymuszenie zmiany haseł.