Ograniczanie możliwości logowania użytkowników z pełnymi przywilejami może być tylko doraźnym rozwiązaniem, które zahamuje dużą liczbę standardowych ataków, ale nie ma znaczenia uniwersalnego mechanizmu obronnego.

Przez większość specjalistów ds. bezpieczeństwa powtarzana jest opinia, że gros typowych zadań wykonywanych przez użytkowników nie wymaga uprawnień administratora i dlatego, z punktu widzenia minimalizacji zagrożeń, warto praktykować, a nawet wymuszać logowanie z ograniczonymi uprawnieniami. Jednocześnie opinia ta często jest koronnym argumentem zwolenników Linuxa, który ma świadczyć, że jest to system bardziej bezpieczny niż Windows. Z czasem zalecenie to nabrało magicznego znaczenia i często jest traktowane jako uniwersalna zasada, która z definicji pozwala na zabezpieczenie systemu przed większością ataków. Niestety przekonanie takie jest błędne, uważa Roger Grimes, autor kolumny poświęconej bezpieczeństwu w Infoworld: „Jeśli nawet użytkownicy nie będą się logować w systemie jako administrator lub root, nie zahamuje to ataków oprogramowania malware”.

Standardowy administrator

Choć idea ograniczonego wykorzystywania przywilejów administratora jest popularna i chyba wszystkim dobrze znana, niestety często pozostaje na papierze i nie jest używana w praktyce. I jest to prawda, dotycząca nie tylko domowych użytkowników Windows, ale równie powszechna w systemach wykorzystywanych w przedsiębiorstwach. W wypadku Windows dotyczy to logowania z przywilejami administratora lub osoby podobnie uprzywilejowanej (np. Power User). W systemach Unix/Linux/BSD oznacza to możliwość zalogowania do podstawowego katalogu systemowego – ROOT, BIN itp., w AS/400 jako Qsysop lub Qsecofr, a w przypadku mainframe najczęściej dotyczy to tzw. superusera lub logowania jako terminal 0.

A gdyby ktoś miał wskazać osobę, która w firmie jest przez cały czas zalogowana z najwyższymi przywilejami administracyjnymi, to z dużym prawdopodobieństwem trafiłby w dziesiątkę, wskazując któregokolwiek pracownika działu IT, zajmującego się bezpieczeństwem systemu, którego hasłem dla innych użytkowników mogłoby być „dbajcie o bezpieczeństwo, jak wam zalecam, ale nie bierzcie przykładu z tego, jak sam postępuję”. Ostatnio nawet Microsoft zaczął zachęcać użytkowników i programistów do korzystania z Windows Vista w trybie pracy, dającym mniejsze przywileje administracyjne, wprowadzając funkcję UAC (User Account Control). Znacznie wcześniej, blisko 10 lat temu, ludzie zajmujący się systemami Unix/Linux/BSD zaczęli promować tę zasadę i wykorzystanie funkcji SU (Switch User).

Nie ma panaceum

Jak zauważa Roger Grimes, nawet gdyby któregoś dnia wszyscy użytkownicy komputerów z zasady przestali się logować do systemu z uprawnieniami administratora, to wcale nie rozwiązałoby to problemów z bezpieczeństwem. Trzeba oczywiście przyznać, że uniemożliwiłoby to działanie wielu rozpowszechnionych, szkodliwych programów (niestety także znacznej liczby użytecznych aplikacji), które zostały zaprojektowane przy założeniu, że użytkownik pracuje z przywilejami administratora systemu. Jak dotąd, było to zresztą w większości, zwłaszcza w wypadku Windows, dobrze uzasadnione i naturalne założenie.

Ale przekonanie, że wrogie kody do efektywnego działania zawsze wymagają dostępu do systemu z najwyższymi przywilejami administracyjnymi byłoby błędem. Już obecnie jest wiele przykładów oprogramowania, które może modyfikować konfigurację aplikacji i systemu, wykradać hasła i informacje identyfikujące użytkownika, bez potrzeby uzyskiwania przywilejów administratora lub dostępu do podstawowego katalogu systemowego root. I nie dotyczy to tylko tak znanych i popularnych technik ataku, jak przepełnienie bufora, inżynieria socjologiczna, wyłudzanie informacji (phishing) itp., których autorzy w ogóle nie muszą się troszczyć o to, z jakimi uprawnieniami użytkownik jest zalogowany do komputera.

Nie ulega wątpliwości, że brak dostępu do systemu z przywilejami administratora ogranicza możliwości hakerów, ale dotyczy to tylko łatwości, z jaką mogą oni zaatakować. Oczywiste jest, że jeśli oprogramowanie systemowe umożliwia wykorzystanie względnie prostych, znanych i standardowych mechanizmów dostępu, to nie warto się trudzić nad rozwijaniem bardziej zaawansowanych technik ataku, przynajmniej w skali masowej.

Dziurawe lokalizacje

Roger Grimes pisze: „Zawsze zastanawiałem się, dlaczego tak wiele programów atakujących Windows, za wszelką cenę z uporem stara się zmodyfikować pliki lub zainstalować własne moduły w systemowym katalogu System32”. Najczęstszą odpowiedzią na takie pytanie jest po prostu stwierdzenie, że chodzi o modyfikację działania systemu operacyjnego. I choć jest to prawda, prawdą jest też to, że katalog System32 wcale nie jest do tego niezbędny. Podobnie jest w innych systemach, gdzie dostęp np. do katalogu root nie jest niezbędnym warunkiem powodzenia ataku. Roger Grimes znalazł w systemie Windows przynajmniej 130 różnych lokalizacji, które równie efektywnie mogą zostać wykorzystane przez złośliwe oprogramowanie.

Podobna analiza w wypadku Linux/Unix/BSD wykazała, że lista miejsc, gdzie można zainstalować malware liczy kilkadziesiąt pozycji. Należy w tym miejscu podkreślić, że wiele z tych lokalizacji nie wymaga uprzywilejowanych uprawnień administratora systemu do instalacji lub modyfikacji plików. Na przykład jednym z najczęstszych celów ataku złośliwych programów jest chroniony klucz rejestru Windows – HKey\Local_Machine\ Software\Microsoft\Windows\Run, ale do uruchomienia kodu znacznie łatwiej można wykorzystać wiele innych kluczy, jak te zapisane we własnym profilu użytkownika. Z zasady, nawet bez uprawnień administratora użytkownik ma pełną kontrolę i możliwość konfiguracji tych kluczy rejestru w jego profilu, które odpowiadają za automatyczne uruchamianie programów w momencie startu systemu. Nie ma obecnie żadnego powodu do stwierdzenia, że jest coś, czego autorzy wrogich kodów nie mogliby osiągnąć bez uzyskania dostępu do systemu z uprawnieniami jego administratora.

Nie chodzi tu oczywiście o możliwość samej modyfikacji systemu, ale o jej rezultat. Bo złośliwy haker może mieć problem ze zmianą plików w katalogu System32 lub sbin, ale nie oznacza to, że nie będzie mógł wykraść danych identyfikacyjnych lub wrażliwych informacji bez potrzeby modyfikacji istotnych plików systemowych, a w wypadku znanych już kodów rezydujących w pamięci operacyjnej RAM – w ogóle bez konieczności zapisu w komputerze jakiegokolwiek programu lub pliku.?