Zły wpływ środowiska

Kolejną warstwą infrastruktury, w stosunku do której zasada najmniejszych przywilejów ma zastosowanie, jest środowisko, w którym działają aplikacje (baza danych, serwer aplikacyjny itd.). Implementacja ZNP w tym przypadku powinna polegać przede wszystkim na ograniczeniu do niezbędnego minimum funkcjonalności udostępnianej przez środowisko aplikacyjne. W pierwszej kolejności należy zwrócić uwagę na serwisy sieciowe dostępne na serwerach, które powinny zostać ograniczone do niezbędnego minimum. Zarówno serwery Unix/Linux, jak i Windows w podstawowej konfiguracji udostępniają mnóstwo zbędnych usług. Jeśli serwer jest serwerem dedykowanym do pełnienia określonej funkcji, wszystkie pozostałe serwisy, może poza zaporą IP (wszystkie współczesne systemy operacyjne posiadają taką funkcjonalność), powinny zostać wyłączone lub wręcz zdeinstalowane. Dodatkowe zabezpieczenie zewnętrzną zaporą może okazać się niezbędne.

Naturalnie, najlepszą metodą jest użycie wszystkich powyższych mechanizmów jednocześnie. Weźmy pod uwagę sytuację, w której bank udostępnia klientom oprogramowanie klienckie, za pośrednictwem którego księgowi mogą dokonywać przelewów. Dane o przelewach są gromadzone w lokalnej bazie danych Microsoft Data Engine (MSDE) i raz na jakiś czas oprogramowanie klienckie łączy się przez modem lub Internet z systemem bankowości elektronicznej, wysyłając mu "paczkę" transakcji. Użytkownik uwierzytelnia się w aplikacji bezpiecznymi metodami, np. za pomocą certyfikatu na karcie procesorowej, a aplikacja klienta komunikuje się z systemem bankowym w sposób bezpieczny.

Na pozór wszystko wygląda na zorganizowane zgodnie z zasadami bezpieczeństwa, ale...

W domyślnej konfiguracji silnik bazodanowy MSDE umożliwia komunikację z bazą poprzez sieć (otwiera port TCP o numerze 1433). Funkcjonalność ta jest w tym przypadku zupełnie zbędna. Biorąc pod uwagę, że w domyślnej konfiguracji hasło administratora bazy (konto "sa") jest puste, powstaje możliwość bezpośredniej manipulacji danymi, z pominięciem wyszukanych mechanizmów uwierzytelniania użytkownika. Gdyby funkcjonalność oprogramowania tworzącego środowisko aplikacji (w tym przypadku MSDE) została ograniczona zgodnie z zasadą najmniejszych przywilejów, podatność ta nie wystąpiłaby.

Ograniczanie funkcjonalności oprogramowania, które tworzy środowisko aplikacji, jest bardzo ważne, zwłaszcza w kontekście współczesnych narzędzi. Zaawansowane systemy bazodanowe czy serwery aplikacyjne posiadają mnóstwo modułów, które służą do realizowania bardzo wyszukanej i rzadko stosowanej funkcjonalności. Standardowa instalacja powoduje włączenie wszystkich możliwych funkcji, więc nawet jeśli wadliwa funkcja nie jest wykorzystywana, całość środowiska jest podatna na atak.

Weźmy pod uwagę inne narzędzie, np. Oracle Listener, który służy do komunikacji bazy danych Oracle z klientami. W standardowej instalacji można nim zdalnie zarządzać, wydając odpowiednie komendy protokołu TNS. Jeśli dla dostępu administracyjnego Listener nie wymaga uwierzytelniania hasłem, albo też jeśli intruzowi uda się odgadnąć hasło lub obejść zabezpieczenia, konsekwencje mogą być bardzo poważne. W szczególności możliwe będzie skopiowanie bądź zniszczenie dowolnego pliku na serwerze, atak DoS, a nawet przejęcie kontroli nad serwerem. Zdalne zarządzanie mechanizmem Oracle Listener jest w większości sytuacji całkowicie zbędne i bez szkody dla codziennych obowiązków administracyjnych można tę funkcję wyłączyć (flaga admin_restrictions w pliku listener.ora). Problem w tym, że większość administratorów nie jest nawet świadoma tego typu możliwości.

Złudna wygoda programisty

Nieświadomość bądź niechęć do stosowania zasady najmniejszych przywilejów jest najbardziej widoczna w samych aplikacjach (tworzonych na konkretne potrzeby). Twórcy aplikacji często niedoceniają konieczności zaprojektowania spójnego mechanizmu zarządzania przywilejami, co ma opłakane skutki. Bardzo często zdarza się, że mechanizmy kontroli dostępu pojawiają się nie w trakcie powstawania zrębów projektu, lecz dopiero na którymś z kolei etapie rozwoju aplikacji. Co więcej, są implementowane ad hoc w różnych miejscach - tam, gdzie akurat są potrzebne. W rezultacie system kontroli dostępu jest niespójny i daje się łatwo obejść.

Częstym błędem jest kontrola praw dostępu jedynie w momencie pierwszego uwierzytelnienia, zamiast wymuszania kontroli autoryzacji przy każdej próbie dostępu do zasobu. Ta drobna "wygoda" powoduje, że cały system uwierzytelnienia daje się bardzo prosto obejść poprzez bezpośrednie odwołanie do zasobu, który (teoretycznie) powinien być dostępny jedynie dla uwierzytelnionych użytkowników. W przypadku aplikacji internetowych atak polega na bezpośrednim wpisaniu ścieżki URI charakterystycznej dla modułów dostępnych po "zalogowaniu się". Wniosek z tego taki, że użytkownik nieuwierzytelniony nie powinien mieć możliwości odwoływania się do zasobów, nawet jeśli nie wiąże się to z bezpośrednim zagrożeniem.

Innym, bardzo często spotykanym przykładem braku stosowania zasady najmniejszych przywilejów jest funkcjonowanie interfejsów administracyjnych aplikacji. Pierwszy błąd projektantów polega na założeniu, że administrator może komunikować się z narzędziem administracyjnym aplikacji tym samym kanałem, co zwykli użytkownicy z jej innymi modułami. Przykładowo, jeśli aplikacja WWW jest dostępna pod adresem http: //serwer/aplikacja, a interfejs administracyjny pod adresem http: //serwer/aplikacja/admin/ to zwykły użytkownik może bez trudu dostać się do interfejsu administracyjnego - wystarczy, że zgadnie lub podsłucha ścieżkę URI. Jest to sytuacja groźna nawet wtedy, gdy dostęp do takiego interfejsu administracyjnego wymaga uwierzytelnienia. Wymaganiem minimum jest to, by interfejs administracyjny aplikacji dostępny był pod innym adresem IP niż usługi udostępniane przez aplikację użytkownikom.