Wyszperać konsolę

Narzędzia administracyjne oparte na przeglądarkach oferują tyleż wygody, co dodatkowej pracy i ryzyka. Przez nieuwagę, a najczęściej niewiedzę, witryny konsol bywają indeksowane przez wyszukiwarki. Stąd już tylko mały krok do udanego włamania.

Narzędzia administracyjne oparte na przeglądarkach oferują tyleż wygody, co dodatkowej pracy i ryzyka. Przez nieuwagę, a najczęściej niewiedzę, witryny konsol bywają indeksowane przez wyszukiwarki. Stąd już tylko mały krok do udanego włamania.

Narzędzia administracyjne wykorzystujące przeglądarkę internetową, jakkolwiek oferowane przez producentów od dawna, w poważnych instalacjach były dotychczas rzadkością, opcją występującą obok standardowych konsol mających postać aplikacji oraz konsol znakowych wykorzystujących połączenia telnet lub SSH. Poszukując sposobów na zmniejszenie kosztów, wielu producentów systemów i aplikacji doszło jednak do wniosku, że interfejs przeglądarkowy może zastąpić oba pozostałe.

Rzeczywiście, uniwersalności interfejsu przeglądarkowego producentom trudno się oprzeć. Może być lekki i opierać się wyłącznie na prostych skryptach, albo może też wykorzystywać komponenty Java lub ActiveX osadzane w kodzie HTML. Elastyczność przeglądarkowych narzędzi administracyjnych ma jednak swoją ciemną stronę. Wystarczy, by nieświadomy (bądź tylko nieuważny) administrator udostępnił konsolę przeglądarkową jako serwis widoczny z Internetu - nawet jeśli szyfrowany i chroniony hasłem - i kłopot gotowy.

Działające automatycznie programy-agenci wyszukiwarek internetowych zaindeksują serwer i w ten sposób jego zawartość zostanie na stałe wpisana do ich indeksów, by ułatwić wyszukiwanie. W indeksach wyszukiwarek zarejestrowane zostanie każde słowo, które pojawiło się na stronie WWW. Tak oto wyszukiwarki stały się idealnym narzędziem wykorzystywanym przez hakerów do wyszukiwania celów ataku i, przyznać trzeba, robią to skutecznie.

Poszukiwania wykonywane przez amatorów łatwych włamań nie są szczególnie skomplikowane - wystarczy wiedzieć, jaki konkretnie napis powinien się znajdować na witrynie administracyjnej aplikacji lub serwera. Może nim być informacja o wersji, zainstalowanych modułach dostępowych do baz danych, błędach w konfiguracji, podawane przez samą aplikację informacje o jej wersji, względnie typowe dla tego programu błędy w napisach (czasami są to literówki w tłumaczeniach lub inne ludzkie błędy).

Nieraz można znaleźć informacje o katalogach oraz plikach, które są udostępniane do publicznego dostępu, chociaż nie powinny. Typowym przykładem jest dość długa lista plików konfiguracyjnych (czasami są to autentyczne pliki konfiguracyjne routerów wraz z hasłami!), automatycznie generowany indeks katalogów C:\WINDOWS albo /etc!

Szczęśliwy numerek

Informacje o wersji serwera lub aplikacji od razu wskazują cel ataku. Typowym przykładem jest tzw. sygnaturka serwera - stopka dodawana przez serwer w stronach przezeń generowanych, a także informacje o wersjach aplikacji. Na szczęście dla niefrasobliwych administratorów Google obecnie filtruje część takich zapytań, ale nadal można znaleźć wiele sygnaturek obwieszczających wszem i wobec, ni mniej ni więcej, że serwer jest dziurawy jak sito. Jak to się mówi, "dwa ruchy i root... względnie administrator bazy danych".

To samo dotyczy aplikacji pracujących w środowisku WWW - koronnym przykładem jest phpBB (popularne oprogramowanie do tworzenia serwerów list dyskusyjnych), którego starsze wersje zawierały błędy typu SQL Injection. Występował on w tak wielu instalacjach, że ktoś w końcu napisał skrypt do automatycznych włamań.

Aplikacje pracujące w środowisku PHP są naturalnym celem takich ataków - prostota języka skryptowego PHP zjednała mu bardzo szerokie wsparcie wśród twórców małych i średnich aplikacji WWW. Wiadomo, które wersje zawierają błędy w zabezpieczeniach - wystarczy je znaleźć. To samo dotyczy środowiska ASP, niemniej błędy w korporacyjnych aplikacjach pracujących w środowisku Microsoftu są potencjalnie dużo poważniejsze w skutkach niż proste SQL Injection w PHP. Możliwe jest nawet uzyskanie dostępu do całej domeny Windows (były takie przypadki).

Jeszcze ciekawszy przypadek stanowią strony WWW generowane po wystąpieniu błędu aplikacji. To prawdziwy przysmak włamywaczy - na podstawie takiej strony można od razu stwierdzić nie tylko to, że serwer jest "dziurawy", ale także jakich technik warto użyć do włamania. Numerem jeden jest tutaj lista błędów baz MySQL (prym wiodą Warning: mysql_query(): Access denied lub invalid query) oraz Oracle (choćby błąd ORA-00936 oraz ORA-00921: unexpected end of SQL command), Informix ("A syntax error has occurred" filetype:ihtml) oraz połączeń z dziurawego serwera IIS do MS SQL (długa lista błędów różnego rodzaju).

Paradoksalnie, wykorzystanie przez hakerów stron generowanych po wystąpieniu błędów jest możliwe pomimo faktu, że serwer bazodanowy jest skonfigurowany prawidłowo - błąd tkwi bowiem zazwyczaj w źle napisanej aplikacji korzystającej z jego usług. Włamanie wymaga wprawdzie pewnej wiedzy i nie jest automatyczne, ale daje dużo większe możliwości niż zastosowanie prostego skryptu.

Także sam serwer WWW wiele mówi o sobie, jeśli administrator nie zmieni stron błędów, takich jak domyślny Error 404, oraz nie wyłączy całkowicie raportowania błędów przez serwer aplikacyjny. To pierwsza rzecz do zrobienia przed wdrożeniem serwera testowego do środowiska produkcyjnego. Wpisy powinny wskazywać na nieistniejące aplikacje albo zupełnie inny serwer, który jednak może wykorzystywać pliki o danym typie i rozszerzeniu. Warto pomyśleć o scaleniu poprawek dla serwera WWW Apache już na poziomie kodu źródłowego, by wyświetlał tekst w rodzaju My Web Server version 1.0, zamiast szczegółowych informacji o wersji. Serwer może także "udawać" IIS lub Zope. Ubocznym skutkiem "udawania" IIS jest wzmożona ilość ataków. Ataki oczywiście nie powiodą się, ale już sama liczba wpisów w logach budzi grozę.

Są takie strony...

Są strony, których w ogóle na serwerze nie powinno być, np. popularny plik phpinfo.php zawierający tylko jedno polecenie phpinfo(); stosowany do testów serwera z motorem PHP. Trudno znaleźć lepsze źródło informacji o serwerze niż takie właśnie testowe strony administracyjne, które wyświetlają nie tylko autentyczne informacje o wersji serwera, konfiguracji systemu, zastosowanych poprawkach, ale także zmienne środowiskowe, takie jak ORACLE_SID czy PATH! To samo dotyczy wersji testowych aplikacji, często umieszczanych w katalogu /test głównego serwera. Wersje testowe należy instalować na wydzielonym serwerze testowym, a nie na serwerze produkcyjnym dostępnym z Internetu.

Opisywane tu "kwiatki" nie wyczerpują oczywiście pomysłowości programistów i administratorów w robieniu krzywdy własnym systemom. W Internecie za pośrednictwem dowolnej wyszukiwarki (nie tylko Google) można znaleźć pliki zrzutów z programu DrWatson (błędy w środowisku Microsoft Windows), pliki rejestru Windows, gotowe raporty z korporacyjnych skanerów sieciowych, pliki typu include zawierające na przykład dane potrzebne do zalogowania się do serwera bazodanowego, a nawet pliki konfiguracyjne routerów i bram VPN, zawierające skróty haseł gotowe do zaimportowania do klienta VPN.

Narzędzia do zarządzania bazami to aplikacje, których na serwerze produkcyjnym obsługującym zewnętrznych klientów nie powinno być pod żadnym pozorem. Niektóre z nich w domyślnej konfiguracji (np. phpOracleAdmin) nie są zabezpieczone hasłami albo mają bardzo poważne luki w zabezpieczeniach.

Ostrożnie z plikami!

Na serwerze dostępnym z Internetu nie powinno być żadnych narzędzi do . Mając dostęp do takiego narzędzia, w większości instalacji udaje się przeczytać bardzo wiele plików z serwera, czasami można nawet podrzucić plik PHP lub ASP z dowolnym kodem! Najbardziej dziurawym przykładem jest aplikacja w rodzaju File Upload Manager - Google zwraca tu blisko tysiąc trafień, z których znacząca część działa!

Zagrożeniem dla bezpieczeństwa sieci mogą być pliki log zostawiane przez niektóre programy - m.in. niektóre implementacje oraz SFTP, narzędzia do połączeń zdalnych itp. Numerem jeden jest oczywiście WS_FTP.LOG - zapis z programu WS_FTP firmy Ipswitch. Poszukiwania takiego pliku - zawierającego konkretne słowa, np. phpinfo, admin, MySQL, password, htdocs, root, Cisco, Oracle, IIS, resume, inc, sql, users, mdb, frontpage, , backend, https, editor, intranet - dają wiele ciekawych trafień. Dzięki nim można np. odkryć konkretne instalacje poszczególnych aplikacji, a także strukturę ich katalogów. Korzystanie z klienta FTP zostawiającego jakiekolwiek logi w tym samym katalogu, z którego są transferowane dane, to proszenie się o kłopoty. Możliwość zapisu plików log klienta na serwerze FTP to też zła praktyka.

Kolejny ważny przykład to pliki typu core występujące w systemach Unix, które zawierają zawartość pamięci w momencie wystąpienia błędu aplikacji (typowy komunikat segmentation fault, core dumped). Analiza takich plików za pomocą debuggera może potencjalnie ujawnić znacznie więcej informacji niż wszystkie powyższe typy plików razem wzięte. Pliki core należy bezwzględnie usuwać lub przenosić do katalogu poza strukturą widoczną z Internetu. Niektóre systemy (np. FreeBSD) są wyposażone w odpowiednie skrypty do usuwania plików core - może warto z czegoś takiego skorzystać albo samodzielnie napisać stosowny skrypt.

Ostrożne logowanie

Nie można tu nie wspomnieć o stronach logowania do portali. Zwykle wskazują one miejsce, w którym aplikacja jest zainstalowana, to zaś bardzo ułatwia włamanie. Jedynym sposobem wyłączenia tej strony z indeksowania przez przeglądarki jest edycja pliku robots.txt. Strony logowania wykorzystujące uwierzytelnienie przez obiekty Flash to również bardzo zły pomysł.

1500 - tyle typów ataków można przeprowadzić na różne systemy, korzystając ze wsparcia wyszukiwarki Google


TOP 200