Wstęp

Nie da się ukryć, że w dzisiejszym świecie Counter-Strike’a ciężko o zdrową rywalizacje. Niektórzy postanowili ją eliminować w nielegalny sposób, a jeszcze inni postanowili bawić się w super-hackerów niczym z filmu Mr Robot. Zdecydowanie częściej słyszymy ten drugi scenariusz. Jednak pierwszą i najważniejszą rzeczą jest to, że sami siebie nazywają „hackerami”. Tak na prawdę żaden z ich dotychczasowych „ataków” nie był wysublimowany, wyszukany lub, który wymagałby odkrycia czegokolwiek nowego. Każda osoba, atakująca serwer 1.6 posługuje się dotychczasowymi dziurami, błędami, a przede wszystkim – zaniedbaniem osób, które tworzą serwer. W zdecydowanie większej liczbie przypadków zawodził czynnik ludzki: słabe hasła, te same hasła stosowane do wielu platform, uploadowanie podejrzanych pluginów bez kodu źródłowego czy nawet podejmowanie współpracy z ludźmi, którzy od samego początku mają jeden cel: zaszkodzić nam, jak najbardziej się da. Artykuł ten tylko częściowo ma na celu pokazanie sposobów na zabezpieczenie serwerów. Jego meritum jest to, jak radzić sobie już po dokonanym włamaniu.

Pierwsze kroki

Przede wszystkim zachowajmy spokój i zimną głowę. Nie róbmy wszystkiego na raz. Lepiej analizować wolniej – a dokładniej. Zacznijmy od spraw banalnych.

Zmień hasło do własnego konta na hostingu. Odbierz innym subkonta, do czasu rozwiązania sprawy (poleć im zmianę hasła). Jak najszybciej zmień dane do wszelkich baz danych, które wykorzystuje serwer oraz FTP. Musisz ustalić w jaki sposób włamywacz zdobył flagi. Na początku sprawdź logi. Znajdź pierwsze połączenie atakującego z serwerem. Jeśli będziesz widział tam taki wpis: [amxbans_core.amxx] Login: "Nick<27855><>" became an admin (account "STEAM_0:0:1234") (access "abcdefijmnopqru") (address "IP") (static 0) to znaczy, że włamywacz miał już flagi przed wejściem na serwer i nie posłużył się on RCON’em (bo przykładowo mógł go odgadnąć co też się zdarza).

Jeśli jest to obcy Ci nick – trzeba szukać. Pamiętaj, jeśli zdiagnozujesz problem – wyłącz serwer, tak aby po Twoich interwencjach atakujący nie mógł z powrotem dodać sobie flag czy zmienić hasła RCON. Ewentualnie, dobrym rozwiązaniem, które polecam jest założenie hasła na ten serwer.

Diagnozowanie

Sprawdź czy nie pojawił się w Twoim FTP jakiś nowy plugin, którego pochodzenia nie znasz. Jeśli tak, usuń go czym prędzej. Koniecznie upewnij się, że każdy plugin był kompilowany lokalnie. Oznacza to, że masz do niego swobodny dostęp i możesz przeglądać kod źródłowy. Pobieranie i wgrywanie pluginów od nieznanego, mało zaufanego autora jest bardzo ryzykowne. Istnieje możliwość, że zostawił on tam tzw. backdoora, dzięki któremu przykładowo przypisywane są mu flagi, czy ustawia hasło RCON komendą.

Jeśli atakujący dostał się na serwer pod nickiem admina, który posiada flagi, to znaczy, że zna jego hasło setinfo. W jaki sposób zostaje pozyskane setinfo? No to już jest problem admina, jak dysponował hasłem. Czy używa je gdzieś jeszcze, czy podawał komuś, czy nawet wszedł na inny serwer – istnieje możliwość zapisywania haseł graczy przy wchodzeniu na serwer. Jeśli atakujący będzie miał hasło setinfo admina wystarczy, że wejdzie na jego nicku. Dlatego tak złe jest przypisywanie adminów na nick+hasło. Posiadanie setinfo admina gwarantuje dostęp do flag adminowskich, bo przecież potem to już kwestia połączenia się z serwerem na nicku admina. Usuń wszystkich adminów zapisanych na nick + hasło, nie tylko tego, z którego padł włam.

Być może problem nie leży po żadnej z w/w stron. Jeśli korzystasz ze sklepu sms, który znajduje się na stronie www to włam mógł paść również z tamtego sektora. Sprawdź czy delikwent nie przypisał sobie flag na nick, ip czy nawet sid (w sid wątpie) w sklepie. Ale zaraz zaraz… W jaki sposób miało by to być? Tutaj również nie pojawia się żadna zaawansowana technika, albo atakujący wrzucił shell’a na naszą stronę, albo odgadł hasło administratora. Upewnijmy się, że nasze oprogramowanie webowe jest zabezpieczone i nie jest podatne na shelle. Jeśli jest zabezpieczone – atakujący dostał się na konto administratora przy wcześniejszym odgadnięciu hasła. Reszta to już czysta formalność: zostaje stworzona usługa dodająca wszystkie flagi, włamywacz przypisuje ją do danego serwera i dodaje ją sobie.

Jeśli admini są czytani z AmxBans’a, a nie z pliku users.ini to oczywiście sprawdź go. Jestem prawie pewny, że to właśnie tam będzie ukryty admin i flagi atakującego. Wiele osób używa dziurawych AmxBans’ów, które są podatne na shelle, możesz być jedną z nich! Dlatego warto dowiedzieć się jaka konkretnie wersja jest najlepsza, aby uniemożliwić następne ataki.

Atakujący wykorzystał RCON’a – co dalej?

Jeśli admini mają dodaną flagę „l” to przeważnie „zabawa” nie kończy się tak szybko. Dzięki temu atakujący ma swoim zanadrzu potężne narzędzie jakim jest RCON. Dzięki niemu może zmieniać ustawienia serwera, jak można się domyśleć – na gorsze. Zmienia on tzw. cvary, przez co psuje całą rozgrywkę. Znacznie poważniejszym problemem jest, jeśli odczytuje on cvary, które służą do łączenia się z jakąś bazą danych, która w jakikolwiek sposób ingeruje we flagi graczy. Pobiera on host’a, login, hasło co pozwala mu na późniejsze dodanie się do PhpMyAdmin’a i dodania tam sobie flag nawet na kilka/kilkanaście nicków, żebyś męczył się z usuwaniem ich. Warto, na prawdę warto sprawdzić plik cmdaccess.ini znajdujący się w cstrike/addons/amxmodx/configs/ Znajdują się tam wszystkie możliwe komendy do użycia na naszym serwerze. Być może jakaś komenda zapisuje flagi gracza. Atakujący może strzelać, że taki plugin z taką komendą znajduje się na serwerze i wpisze – skutkuje to dodaniem flag w kolejno miejsce, do jakiegoś pliku. Zweryfikuj to.

Poskładaj wszystko do kupy

Wiesz już jak padł włam, jak flagi zostały przypisane. Pozostaje Ci posprzątanie tego. Pamiętaj, że ważne jest, aby robić to w odpowiedniej kolejności. Pamiętaj, że musisz się upewnić, że włamywacz nie ma już nigdzie flag (pkt. Diagnozowanie)! W innym przypadku ten akapit może okazać się bezużyteczny i wykonanie go będzie bezskuteczne. Pamiętaj, że serwer ma być wyłączony lub z hasłem.

• Usuń wszystkim adminom (w tym sobie) flagę „l” > flaga zarządzania RCON’em.
• Usuń hasło rcon. Sprawdź server.cfg, amxx.cfg czy nie ma go nigdzie. Zrestartuj serwer, jeśli chcesz sprawdzić czy prawidłowo usunąłeś rcona wpisz w konsole rcon_password, wyprintuje Ci rcon_password is „”
• Pozmieniaj jeszcze raz hasła do wszelkich baz danych.
• Jeśli włam padł przy użyciu amxbansa – zmień na taki, który jest bezpieczniejszy + najlepiej jeśli będziesz odczytywał flagi adminów z pliku.

Włącz serwer i monitoruj go przez pierwsze kilkanaście minut. Pamiętaj, że cenne informacje znajdziesz zawsze w logach/konsoli serwera.

Przykładowy incydent włamania

Ostatnio byłem świadkiem, kiedy to włamywacz dostał się na serwer z flagami przy użyciu sklepu SMS. Krótki opis, jak to wszystko się działo.

1. Pozyskanie setinfo jednego z adminów i połączenie się z serwerem na jego nicku.
2. Ustawienie hasła RCON. (admin miał dostęp do RCON’a w swoich flagach).
3. Odczytanie cvarów służących do łączenia się bazy <-> sklep SMS.
4. Zalogowanie się do PhpMyAdmina sklepu SMS, dodanie tam nowej usługi ze wszystkimi flagami, przypisanie jej do serwera i dodanie na jakiś nick.
5. Połączenie z serwerem na nicku, na którym przypisał sobie flagi.
6. Bawienie się RCONem: zmienianie ustawień serwera, takich jak roundtime, hostname, gravity i wiele innych. W tym momencie następuje także sprawdzenie przez atakującego czy można dodać gdzieś jeszcze flagi.
7. Przykładowym miejscem, gdzie włamywacz może dodać sobie flagi jest plugin nVaultAdmins.amxx Służy on do odczytywania flag graczy zakupionych na serwerze. Jego komendy to między innymi na_addadmin, na_setadmin – może dzięki nim dodać sobie wszystkie flagi, które są później zapisywane jako plik .vault w katalogu addons/amxmodx/data/vault/ Jednak nie możemy bezpośrednio z tego pliku sprawdzić, czy są tam dodane flagi włamywacza. Trzeba posłużyć się programem NVault Reader, który odkoduje nam wszystko i będziemy mogli to przejrzeć.

Podsumowanie

Jak widzisz, wszystko dzieje się w oparciu o zaniedbanie ludzi. To właśnie tutaj najczęściej zaczyna się włamanie. Czasami to my zaczynamy atak na samych siebie nie wiedząc o tym. Pamiętajmy, że hasła to można powiedzieć rzecz święta.

Niedługo pojawi się wpis mający na celu pomoc w zabezpieczeniu serwerów tak, aby takie artykuły jak ten nie były potrzebne.

Mini wstęp

Od kilku lat w naszym rodzimym internecie działa sobie grupa profesjonalnych hakerów o nonszalancko i groźnie brzmiącej nazwie „Morda Team” (czy jakoś tak) z różnymi wariacjami tejże nazwy, szczepami, odmianami, klanami i kij wie czym. Do jej największych osiągnięć można zaliczyć włamanie do głównej bazy danych pentagonu w 2019 roku, skuteczny atak na elektrownię jądrową w Szwajcarii z wykorzystaniem zaawansowanej socjotechniki, a także podmianę strony głównej witryny cs-stronka.xaa.pl. Oczywiście dwa spośród tych trzech zostały zmyślone, co bystrzejsi czytelnicy będą wiedzieli które.

Ponieważ sposób ich działania nie zmienił się od początku mojej pamięci (czyli jakoś od dobrych 5 lat), a cały czas przy użyciu tej samej techniki udaje im się bezsensownie dokładać pracy innym – postanowiłem opublikować ten artykuł. Jeśli nie zamierzasz poświęcić 30 minut swojego czasu na przeczytanie go powoli słowo po słowie – odpuść sobie – z pewnością pominiesz sporo istotnych szczegółów i wykonasz co trzeci punkt, tym samym nie pomagając sobie w niczym.

Na początku warto uświadomić sobie jedno. Ich działanie nie ma nic wspólnego z żadnym zaawansowanym hakerstwem. Grupa nie wynajduje żadnych nowych dziur, co więcej nawet z nich nie korzysta. Nie ma zbyt wielkiego doświadczenia ani możliwości, dlatego za cel wybrali sobie równie prostą grupę – środowisko gier w którym dominują hobbyści i ludzie poświęcający na to wolny czas. Gdyby postawić im retoryczne pytanie „dlaczego hakujeta stronki z grami, a nie jakieś banki, organizacje terrorystyczne, czy coś takiego?” albo „co udało wam się zrobić oprócz deface’a strony o csie?” będzie można usłyszeć jakieś (XD) wzniosłe teksty o cholera wie czym – że misja, że cośtam. Prawda jak się nietrudno domyślić jest taka, że nie ograniczają ich wzniosłe cele, tylko wiedza, możliwości intelektualne i wizja pasa. Nie mniej jednak są dość upierdliwi, a co za tym idzie szkodliwi.

Jak dochodzi do ataku

Finalnym krokiem (zaczniemy ciut od końca) jest zawsze deface strony – podmiana indexu na jakiś mrocznie brzmiący napis z jakimś gifem + jakaś śmieszna muzyczka. W niektórych wariantach dochodzi jeszcze do usuwania losowych plików. Sam profesjonalizm wykonania nowego face’a (zazwyczaj ze słabo dobranym kodowaniem znaków) nie pozostawia raczej złudzeń co do staranności przeprowadzenia ataku.

Żeby do takiego deface’u mogło dojść konieczne będzie uzyskanie dostępu do plików leżących na hostingu strony. Po raz kolejny warto zaznaczyć że niemal nigdy (a konkretnie dokładnie nigdy) nie następuje to poprzez jakieś zaawansowane włamanie, tylko przez:

• Zalogowanie się, znając hasło, do hostingu / SFTP / FTP / SSH / cokolwiek. Ta opcja jest tak zwyczajna że tylko wspomnę o niej słowem.
• Wrzucenie web-shella gdzieś do plików stronki który daje nam takie możliwości jak punkt powyżej. To w 100% był przypadek który miałem okazję oglądać i dlatego na nim się skupimy.

Wrzucony shell to niemal zawsze jakiś polski twór (domyślam się że Państwo Hakerstwo ma problem z językami obcymi, w końcu czego wymagać od ludzi w gimnazjum zajmujących się włamaniami na stronki o csie), np. „hauru”, „devil team shell”, „b374k” czy coś takiego. Prawie zawsze to samo, prawie zawsze pod nazwą „huj.php” leżącą w jakimś losowym miejscu na serwerze. O tym jak takiego shella znaleźć – będę pisał w dalszej części artykułu, póki co skupmy się na źródle ataku.

Wstawienie takiego shella na stronkę nie jest bezpośrednio możliwe (w końcu gdyby było – byłby armagedon). Po raz kolejny warto zaznaczyć że nasi bohaterscy hakerowie nie wykorzystują do tego żadnego exploita, 0-daya czy czegokolwiek co wymaga obsługi terminala albo mózgu. Skąd więc taki shell bierze się na wśród plików? Warto zauważyć że wszystkie zhackowane strony łączy jedno – działają pod kontrolą silnika IPS. Czy silnik jest dziurawy (czy jak to wszyscy mądrze krzyczą – „zbugowany”)? Otóż nie. W każdym obejrzanym przypadku shell został wrzucony za pośrednictwem „PHP & Text Widget” – wtyczki do IPS pozwalającej z poziomu panelu administratora dodać blok kodu do strony głównej. Uruchamiany kod można wyedytować z poziomu administratora strony. Istnienie takiej wtyczki pozwala więc, po jej zainstalowaniu, na dodanie dowolnego kodu do strony głównej forum. I tak się dzieje. Nadsztygar hakerski instaluje z poziomu ACP forum wtyczkę PHP & Text Widget przy użyciu której dodaje „dropper” – kawałek kodu który pobiera i instaluje shell w wybranym katalogu. Wtyczkę i dropper albo usuwa albo zostawia – bez znaczenia. Przy użyciu powyższej metody można wywołać dowolny kod PHP, który ma niemal nieograniczone możliwości – w tym pobranie z serwera, odczyt i zapis dowolnych plików, którym dokładnie zazwyczaj staje się nasz groźny „huj.php”. I co teraz? O tym też napiszę dalej.

No dobrze, ale w końcu żeby coś takiego zrobić trzeba mieć dostęp do ACP. Czy da się bez niego? Nie da się. Czy hakerzy w magiczny sposób przełamują jakieś zabezpieczenia? Nope. Tu niestety głównym i najważniejszym czynnikiem jest niefrasobliwość osób zarządzających takimi stronami. W każdym z przypadków które widziałem doszło do wykorzystania uprawnień jakiegoś z istniejących kont administracji. Administratorzy techniczni bardzo frywolnie podchodzą zazwyczaj do kwestii uprawnień. Co z tego że użytkownikowi z grupy „Junior Admin” nie daliśmy możliwości dodawania wtyczek, skoro daliśmy mu możliwość podniesienia sobie uprawnień do grupy „Senior Admin”? Tak, serio, to nie żart. Wszystko co widziałem opierało się o ten banalny schemat. W tym miejscu pewnie można pomyśleć „spoko spoko, u mnie są git ustawienia”. Otóż znów nie – na 99% nie są. System uprawnień IPS jest dość pogmatwany i istnieje kilka sposobów żeby podnieść sobie uprawnienia do wyższych. Złota zasada jest taka, aby domyślnie wyłączyć wszystkim wszystkie uprawnienia i włączyć tylko te których na pewno potrzebują. Po co grupie „Junior Admin” możliwość edycji plików na serwerze albo możliwość instalacji wtyczek czy edycji grup? Po nic. Czy jak ktoś dostanie się do hasła takiego juniorka – podniesie sobie uprawnienia do maksimum? Tak. Czy z tymi uprawnieniami wgra wtyczkę „PHP & Text Widget”? Wgra. Co dalej – wiadomo.

IPS jest jednak dość „tricky” pod tym względem ponieważ nie wystarczy zablokować możliwości edycji grup, aby ktoś z ograniczonym dostępem do ACP nie mógł się podnieść do pełnego. Zmiana grupy w IPS następuje przez kilka mechanizmów. Dostęp do edycji któregokolwiek z nich daje praktycznie nieograniczone możliwości administracyjne, dlatego warto pilnować wszystkich. Do najciekawszych z nich należą:

• Edycja użytkowników – pozwala po prostu zmienić komuś (na przykład sobie) grupę z „Junior Admin” na „Senior Admin”. Każdy kto ma takie uprawnienie – ma praktycznie nieograniczoną władzę.
• Grupy podrzędne (to chyba funkcja dodawana jakąś wtyczką). Możliwość edycji grup podrzędnych daje takie same możliwości jak możliwość edycji grup podstawowych (patrz wyżej).
• Edycja grup – nie muszę tłumaczyć.
• Zasady promocji grup. To dość ciekawy mechanizm – możliwość ustawienia zasady przykładowo „kto przekroczy X postów – dostaje grupę Y”. Nic więc nie stoi na przeszkodzie aby ustawić „kto przekroczy 0 postów i ma grupę Użytkownik dostaje grupę Senior Admin”. Czym to się kończy? Tym samym co dwa punkty wyżej. Bardzo często widziałem ataki wykorzystujące ten mechanizm. Przyznam że nawet mi trochę zaimponował.
• Instalacja wtyczek. Daje prawie nieograniczone możliwości dłubania w kodzie, a co za tym idzie – wiadomo.
• Dostęp do SQL. Ludzie… Serio. To prawie jak zabezpieczyć kasę w banku hasłem albo wystawić każdemu chętnemu pełnomocnictwo do konta.
• To oczywiście nie wszystkie problematyczne uprawnienia. Z chęcią dowiem się (w komentarzach przykładowo) o innych ciekawych przypadkach i z pewnością postaram się je tu dodać.

W ramach samo-audytu należałoby zatem sprawdzić czy każda osoba / grupa mająca dostęp do ACP na pewno nie ma dostępu do tych narzędzi, którymi w ciągu kilku sekund może zmienić sobie grupę na najwyższą. Z podejściem „jest spoko, nie muszę sprawdzać” można odpuścić sobie dalsze czytanie i za 3 dni płakać że znów się włamali.

Prześledziliśmy właśnie (od końca) drogę pomiędzy defacem strony a dostępem do ACP. Wiemy już zatem że dostęp zwykłego użytkownika do ACP + głupio nadane uprawnienia (muszą być spełnione oba warunki, nie wystarczy jeden) pozwala na niemal nieograniczone zabawy ze stroną. Druga możliwość to dostęp bezpośrednio do konta już uprawnionego administratora (np. Seniora czy jakiegoś Head Admina czy jakkolwiek sobie ktokolwiek to nazwie). Finalny efekt jest ten sam. Albo Junior Admin + podniesienie uprawnień, albo Senior Admin bezpośrednio.

No właśnie, ale jak to się dzieje? Tu właśnie wylewa się największa głupota użytkowników. Czy następuje jakieś magiczne „zhakowanie” konta? Nie. Czy to jakiś (znów to słyszałem) „keylogger” albo „exploit” – nope. Tu mamy po prostu do czynienia z głupotą użytkowników którzy używają na wszystkich stronkach tego samego hasła. Warto zauważyć że o ile profesjonalne CMS’y hashują hasła (uniemożliwiają ich odkodowanie nawet w przypadku wykradnięcia bazy danych) o tyle wystarczy że podamy takie hasło w sklepie w grze, jako konfiguracja administratora czy chociażby zarejestrujemy się tym loginem i hasłem na podejrzanej stronce – osoba która za nią stoi ma je na tacy (po prostu może je sobie odczytać). Czy to jest aż takie głupie? Tak, serio. Wymuszenie trudnych haseł na swojej stronie niewiele da. Dlaczego? Bo co z tego że ktoś zrobił sobie super trudne hasło do Twojej strony, skoro hasło „dupa” ma do maila przy użyciu którego ktoś mu zrobi „reset hasła”? Głupota użytkowników to największy problem z którym trzeba walczyć. Nawet jeśli jednomyślnie krzyczą „tak, zmieniłem hasło wszędzie”, „tak, mam inne hasło do maila” – nie ma co im wierzyć. To zazwyczaj będzie dupa2 zamiast dupa1.

Czy da się przed tym jakoś zabezpieczyć? Można próbować. Warto pamiętać że należy uznać konto email użytkownika z góry za „zhackowane”. Mamy niemal 100% pewności że użył tego hasła w 2004 roku na jakiejś stronce, którą w 2007 jakiś rzeczywisty hacker złamał i hasło lata sobie gdzieś po necie. Po prostu wyjdźmy z założenia że każdy ma dostęp do jego maila – tak będzie łatwiej myśleć. Jeśli więc damy takiemu użytkownikowi mechanizm resetu hasła przez pocztę – w zasadzie można mu dać logowanie bez hasła. I tak hakiery sobie zresetują. I co teras? Problem robi się szczególnie ciekawy kiedy dostęp do konta głównego administratora jest strzeżony w ten sposób. W końcu każdy może wejść? Może. To tak jakby każdy był adminem.

Mamy już zatem (opisany od końca) pełny obraz tego w jaki sposób dochodzi w 99% przypadków do tego niezwykle zaawansowanego ataku. Dla lubiących grafiki postarałem się narysować to od a do z w postaci jednego bloku.

Patrząc na to podsumowanie nasuwają się tylko dwie reakcje: facepalm / pogarda dla głupoty. Wiemy już w jaki sposób dokładnie zawsze dochodzi do ataku. W następnym kroku postaram się w kilku punktach przytoczyć w jaki sposób można się przed nim uchronić.

Co zrobić aby nie dać się nadziać

Nic. Bo się nie da. Problemy na którymkolwiek z wyżej rozrysowanych etapów oznaczają problemy całości. Należy zatem wyjść od punktu że nie da się w pełni ochronić i każdego z nas czeka starcie ze script kiddies. Jak jednak minimalizować ryzyko niepowodzenia? Zacznijmy od kilku uniwersalnych podstaw.

1. Czy mam backup? Czy jestem w stanie go odzyskać? Czy jestem w stanie odzyskać jego części bez zajeżdżania całej strony? Czy to na pewno jest backup czy może tylko kopia? Jeśli włamywacz dostanie się do mojej strony – czy będzie mógł usunąć backup?
2. Ile osób ma dostęp administracyjny? Czy mam nad tym kontrolę? Czy zdaję sobie sprawę że każda osoba znająca dane dostępu do hostingu i/lub bazy danych ma praktycznie pełną i nieograniczoną władzę na stronie?

To takie dość uniwersalne prawdy, których pewnie dałoby się wymienić więcej, ale bardzo chcę tego uniknąć. Przyjrzyjmy się zatem jak bezpośrednio ochronić swoją stronę przed atakami.

Tę listę należy potraktować jako „muszę zrobić wszystko na 100%”, a nie jak to niektórzy lubią (serio, to przypadek z życia, ręce mi opadły tak że mogłem dotknąć jądra ziemii) „zrobiłem punkt 1 i 5 bo reszty mi się nie chciało i znów mi się włamali”.

Wyłączenie shellowych funkcji PHP

Żeby php-shell miał pełną władzę na serwerze, musi mieć dostęp do PHP’owych funkcji emulujących powłokę systemu operacyjnego. Znaczna większość tego wymaga do pełnego funkcjonowania, są choć takie które działają bez. Te funkcje nie są potrzebne bezpośrednio IPS’owi i można je śmiało wyłączyć. Zestaw od którego można śmiało zacząć to.

exec,system,popen,proc_open,shell_exec,passthru

Funkcje te można zablokować zazwyczaj bezpośrednio z poziomu hostingu (i należy zrobić to dla wszystkich domen które mamy). W przypadku problemów i/lub niewiedzy warto poprosić support hostingu o pomoc. Tym sposobem skutecznie odcinamy etap „zabawa shellem”.

Dostosowanie uprawnień kont administratorów niższych rangą

Niezwykle ważny punkt o którym nie wolno zapomnieć. Po co komu Junior Admin, skoro trzema klikami może sam mianować się Senior Adminem? Należy zatem sprawdzić i samodzielnie przetestować wszystkie znane i możliwe ustawienia w panelu które mogłyby mu na to pozwolić. W tym oczywiście obowiązkowo listę wyżej.

Administratorzy niższego szczebla z poprawnie ustawionymi uprawnieniami mają mniejsze możliwości zaszkodzenia stronie w przypadku kiedy ich konto zostanie „zhakowane”.

Bez dostępu do szkodliwych ustawień atak zatrzymuje się na braku uprawnień do wgrania PHP & Text Widget. Voi La.

Uwierzytelnianie dwuskładnikowe dla wszystkich grup z dostępem do panelu administratora

Arcyważne.Nie, pytanie kontrolne „jaka jest moja ulubiona strona” serio nie ma sensu.

Jedyna rozsądna na dzień dzisiejszy opcja ochrony dwuskładnikowej to Google Authenticator. Ustawia się to w 15 sekund, nic nie kosztuje i wymaga bezpośredniego dostępu do telefonu komórkowego aby się zalogować.

Jak działa Google Authenticator – łatwo sprawdzić. Przy pierwszym logowaniu skanujemy bezpłatną aplikacją Google Authenticator kod QR który wyświetli nam się na naszej stronie. Za każdym razem kiedy się potem chcemy zalogować, oprócz podania loginu i hasła będziemy musieli podać kod z aplikacji. Nasze konto staje się więc mało wrażliwe na wyciek hasła, pod warunkiem że:

• Wyłączymy możliwość pominięcia kodu dwuskładnikowego i resetu go przy pomocy maila. W ten sposób don hakierro wykorzysta to że zna hasło do maila i sobie go zresetuje.
• Wyłączymy możliwość edycji ustawień uwierzytelniania bez podania kodu. Inaczej arcymistrz hakerski zaloguje się na nasze konto (kod wymagany jest tylko do wejścia do ACP, na stronę forum nie), wyłączy sobie kod w ustawieniach i wracamy do punktu wyjścia.
• Zabezpieczymy kodem wszystkie grupy które mają choć minimalny dostęp do ACP.

Wszystkie te ustawienia są natywnie wspierane przez IPS i wystarczy je po prostu w dobrej kombinacji wyklikać.

Należy wyłączyć wszystkie inne alternatywne metody uwierzytelniania dwuskładnikowego.

Ustawiając 2FA należy zrobić to tak, aby mając dostęp do maila, ale nie mając dostępu do kodu nie dało się dostać do ACP. To wystarczy. Koniec kropka. Najważniejsze zdanie całego artykułu.

Średniej jakości oprogramowanie wymieszane z forum

O ile sam IPS jako oprogramowanie światowej klasy można raczej uznać za bezpieczny, o tyle za bezpieczne nie można uznać wgrywanych jak leci innych programów, np. amxbans. Typowa izolacja bezpieczeństwa w hostingu nie stawia żadnej bariery pomiędzy domenami i uzyskanie dostępu do shella w jednej domenie pozwala uzyskać dostęp do plików w innej.

Osobne konta hostingowe / osobne hostingi są od siebie odizolowane. Warto zatem trzymać forum, jako rzecz o najwyższej wartości zupełnie osobno.

Polityka haseł

Od której robi mi się czasem lekko niedobrze. Czy to serio jest taki problem żeby każda baza danych miała inne, losowo wygenerowane hasło? „dupa” jako główne hasło wszędzie i do wszystkiego też widziałem na żywo.

O ile to de facto nie chroni samo w sobie, o tyle pozwala zminimalizować efekt rażenia po uzyskaniu do niego dostępu.

Zrobili mi deface, co teraz?

Jeśli zrobili deface – jakoś się dostali. Trzeba zacząć od początku łańcucha co wcale może nie być łatwe.

Zabezpieczenie własnej poczty to bezwzględnie pierwszy krok. Istnieje spora szansa (o której pisałem wyżej) że ktoś się do niej dostał i wykorzysta (albo właśnie wykorzystuje) aby dostać się dalej. Zmiana hasła + sprawdzenie historii logowań to absolutnie niezbędny krok. Włączenie 2FA jeśli nie było włączone – również niezbędny. Jeśli mamy choć cień podejrzeń że ktoś mógł przebić się dalej (mieliśmy takie samo hasło / widać kogoś w historii logowania / nie mieliśmy 2FA na poczcie) – kaskadowo zmieniamy hasła do wszystkiego (w szczególności hostingów, kaskadowo kont ftp, baz danych, WSZYSTKIEGO).

Na czas przywracania warto wyłączyć stronę aby nie eksponować naszych działań skoro shell dalej gdzieś tam sobie wisi. Kiedy strona jest zablokowana (np. poprzez wrzucenie hasła do htaccess wszystkich subdomen) można działać dalej.

Po ustaleniu szczegółów skontaktuj się z hostingiem, podaj im szczegóły i zapytaj jak mogą pomóc aby nie doprowadzić do takiej sytuacji ponownie. Podaj link do tego artykułu. Wbrew pozorom im też na tym zależy.

Poproś o pomoc. Nie mnie, ale zaufane osoby. W świecie CS’a sobie pomagamy, każdy kto przechodził przez starcie z drużyną los debilos będzie chętny by pomóc.

W pierwszej kolejności szukamy wrzuconych już shelli. Zaczynamy od prostego poszukania plików „huj.php”. Trzeba to oczywiście zrobić automatycznie, bo mogą być zagnieżdżone gdziekolwiek. W drugiej kolejności przeszukujemy wszystkie pliki pod kątem najbardziej znanych shelli. Jeśli mamy dostęp do SSH – wystarczy puścić grepa, jeśli nie mamy – pobieramy sobie pliczki do siebie i szukamy lokalnie.

Na hostingach z SSH (mydevil na przykład) logujemy się do SSH (zakładając że już zmieniłeś hasło!), i zapuszczamy polecenie:

base64 -D <<< Z3JlcCAiKGhhdXJ1fGIzNzRrfHNoZWxsKSIgLWlybCAtLWluY2x1ZGUgJyoucGhwJw== | sh

Warto sprawdzić też listę ostatnich zmodyfikowanych plików, osoby na tyle zaawansowane żeby to zrobić będą wiedziały jak.

Dla mniej zaawansowanych najprościej będzie pobrać sobie wszystko na dysk, otworzyć narzędzie typu Notepad++ albo AstroGrep i zrobić przeszukiwanie katalogu pod kątem podejrzanych plików. W notepad++ jest to bardzo proste – otwieramy program, ctrl+shift+f albo „Szukaj -> Szukaj w plikach” i uzupełniamy:

W pole „Szukany tekst” należy wrzucić to:

(\x68\x61\x75\x72\x75|\x62\x33\x37\x34\x6b|\x73\x68\x65\x6c\x6c)

Jeśli cokolwiek nam wypluje – sprawdzamy co to jest i potencjalnie usuwamy takie pliki z hostingu.

Być może część plików została usunięta w trakcie włamania – pozostaje nam przywrócić je z kopii którą mamy na dysku. Jeśli cała strona została usunięta i odwijamy pełny backup – warto sprawdzić czy nie został już zainfekowany wykonując kroki powyżej.

Kiedy znaleźliśmy i usunęliśmy zarażone pliki – w logach hostingu można sprawdzić jakie IP ich używało. Samo w sobie nie będzie jakoś niesamowicie potrzebne, ale można przejrzeć jakie inne operacje wykonywało przed/po, sprawdzić logi administracyjne.

Możemy teraz włączyć stronę i usunąć PHP & Text Widget. Możliwe że dostęp do strony znów zapisał shelle w tych samych (albo innych miejscach), sprawdzamy ponownie.

Logi mogły zostać usunięte, co nie jest ani trochę trudne. Przez czyje konto nastąpiło zatem włamanie? Jeśli nie mamy jawnej odpowiedzi (na przykład w postaci logu o instalacji PHP & Text Widget) każdy jest potencjalnym podejrzanym. Warto zacząć od ręcznego resetu hasła każdemu z uprawnieniami administracyjnymi i skontaktowaniem się z nim w jakiś bezpieczny sposób celem ustawienia nowego hasła.

Włamywacze bardzo często wykorzystują też zwykłe konta do dokończenia ataku – z włamanego konta admina dodają uprawnienia / grupę / zasady promocji i do przeprowadzenia ataku wykorzystują już normalne konto z uprawnieniami Senior Admina. Konieczne będzie sprawdzenie – listy użytkowników, ich przynależności do grup, zmienionych ustawień, w szczególności tych „tricky” opisanych wyżej.

Teraz pozostaje już tylko zabezpieczyć stronę wykorzystując wskazówki z akapitu wyżej. Poradnik jest bardzo skrótowy, ale powinien dać ogólny obraz „co jak i gdzie”. Każdorazowa sytuacja wymaga pełnych oględzin i warto powierzyć je zaufanej osobie.

Zakończenie

Szacunek ludzi ulicy i podhalańskiej grupy anonymous ze szkoły podstawowej numer 1337 już spływa z całego świata dla tak zaawansowanych hakerów.

A tak serio to w świecie prawdziwych specjalistów osoby z którymi miałem okazję rozmawiać krztusiły się ze śmiechu, szczególnie z tych „stronek hacked by”.

Konkursy CTF oferują nagrody idące w dziesiątki tysięcy złotych. Bug bounty ma prawie każda firma. Dlaczego Państwo Hakerstwo nie bierze w nich udziału? To pytanie pozostawiam do samodzielnej analizy.

Mam nadzieję że ten artykuł przysłuży się większej ekipie.

Artykuł by puchatek team opublikowany gościnnie za zgodą właściciela strony.