Zarządzanie hasłami na współdzielonych kontach

Bezpieczeństwo

Autor: Chris Stoneff

Opublikowano: 12 stycznia 2009

Zawartość strony

	Zrozumienie problemu
	Im dłuższe, tym lepsze
	Naruszenie domeny
	Usprawiedliwienia, usprawiedliwienia ...
	Czego wymaga nadzór
	Zautomatyzowane podejście
	Pomyślmy o tym

Jednym z zagadnień, z którymi coraz więcej mają do czynienia wszyscy administratorzy jest regularna zmiana hasła w przypadku współużytkowanych i uprzywilejowanych kont, takich jak wbudowane podstawowe konta administracyjne lub konta główne, konta alarmowe lub nawet konta procesów.

Dla potrzeb definiowania przyjmijmy, że wbudowane podstawowe konta administracyjne i konta główne to te konta, które znajdują się w każdej wersji systemów Windows®, Linux oraz UNIX i które mają ten sam identyfikator bezpieczeństwa (Security Identifier, SID) lub identyfikator użytkownika (User Identifier, UID). Konta alarmowe (ang. firecall account) to te, które są tworzone, aby pomóc w dostępie awaryjnym do zabezpieczonego systemu.

Te konta awaryjne lub administracyjne są czasem używane przez użytkowników, którzy zwykle nie są uprzywilejowani, aby mieli możliwość dostępu do kluczowych systemów w przypadku wystąpienia problemów.

Wreszcie konta procesów to konta używane do uruchamiania usług, zadań, aplikacji COM+ oraz elementów osadzonych, takich jak skrypty lub inne pliki binarne, które wymagają logowania.

Mamy zapewne wdrożony system korzystający ze skryptów lub obrazów instalacyjnych. Ponadto stacje robocze i serwery mają najprawdopodobniej tę samą nazwę konta administratora i to samo ośmioznakowe hasło, które zapewne nie było zmieniane od czasu, gdy system został wdrożony. Dlatego używam tu słowa „hasło” w liczbie pojedynczej, zamiast pisać o „hasłach”.

Administrator może być zmuszony do zmiany tych haseł w ramach korzystania z najlepszych praktyk lub zgodności z narzuconymi wymaganiami, jak te wprowadzone przez takie ustawy, jak Sarbanes-Oxley (SOX), Payment Card Industry (PCI), czy też Health Insurance Portability i Accountability Act (HIPAA).

Czasami administrator jest motywowany tym, że były administrator lub ktoś z personelu technicznego znający hasła odchodzi z firmy, co stwarza zagrożenie naruszenia bezpieczeństwa lub utraty zdolności przetwarzania kart kredytowych.

Pomimo tych czynników, prawdziwym problemem jest konieczność zmiany przez administratora haseł po prostu ze względu na bezpieczeństwo firmy i jej danych, które ma obowiązek chronić.

Zrozumienie problemu

Jest kilka czynników, które trzeba zrozumieć, gdy mamy do czynienia z tymi kontami i hasłami do nich:

1. Im starsze jest hasło, tym mniej jest bezpieczne.
2. Ogólna zasada mówi, że dłuższe hasła są trudniejsze do złamania.
3. Sposób uwierzytelniania przez komputery nie ulega zmianie tylko dlatego, że należą one do domeny. W każdej domenie leży serce grupy roboczej.

„Im starsze jest hasło, tym mniej jest bezpieczne” jest stwierdzeniem mylącym. Oznacza ono, że każdy, kto chce naprawdę włamać się do komputera, potrzebuje tylko czasu. Jeśli ktoś zapyta „Ile czasu zajmuje złamanie hasła?”, mówię zwykle, że nie ma na to jednoznacznej odpowiedzi. W zamian podaję kilka wskazówek, które mogą pomóc w udzieleniu odpowiedzi dla konkretnego systemu:

• Ile osób zna hasło?
• Czy wszystkie te osoby nadal pracują w firmie?
• Jeśli są osoby znające hasło do konta, które odeszły z firmy, to czy rozstały się z pracą w przyjaźni?
• Czy zabroniony jest dostęp do uruchamiania systemu z dyskietki, CD lub DVD oraz z sieci?
• Czy użytkownicy komputerów pełnią także rolę administratorów lokalnych?
• Czy wszystkie systemy używają tego samego hasła przy dostępie do uprzywilejowanych kont?

Analizując tę listę od góry, można stwierdzić, że im więcej ludzi zna sekret, tym większa możliwość jego upublicznienia.

Pamiętam, jak pracowałem dla firm, w których administratorzy stwierdzali, że wygodnie jest ustalić wspólne hasło o tej samej wartości i podać go do wiadomości personelu IT i pracowników, zamiast wpisywać za nich hasło, gdy będzie im to potrzebne. Oczywiście w miarę upływu czasu w firmie było coraz więcej komputerów z różnymi niezatwierdzonymi ustawieniami, zaś zwykli użytkownicy sieci mogli logować się na te konta.

Jeśli wszyscy, którzy znają hasło nadal pracują w firmie i są zadowolonymi, pełniącymi obowiązki pracownikami, ryzyko wynikające z ich dostępu jest nieco ograniczone. Ale nigdy nie wiemy, w jakim momencie możemy mieć do czynienia ze szkodliwym użytkownikiem. Jeśli którakolwiek z osób znających hasło opuści firmę w złej atmosferze, mamy do czynienia ze swobodnym, wrogim czynnikiem, który wie, jak włamać się do sieci za pomocą konta, które powinno być niedostępne.

Jeśli nie zabronimy uruchamiania systemu z innego nośnika niż twardy dysk, to tym samym pozwolimy użytkownikom na uruchamianie z nieautoryzowanych obrazów systemu, jak Windows PE i różne wersje systemu Linux, które mogą czytać bezpośrednio z systemu plików komputera i uzyskać dostęp do chronionej pamięci komputera. (Muszę podkreślić, że jest wiele zagrożeń, które mogą pochodzić ze źródeł wewnętrznych. Nawet jeśli cały personel i pracownicy tymczasowi są nadal zatrudnieni w firmie, nie ma żadnej pewności, że hasła i systemy są bezpieczne.)

Znam wielu ludzi, którzy logują się do sieci poprzedniego pracodawcy, tylko dlatego, że mogą to robić. Jest dość zabawne, że pokazują oni w ten sposób złe skutki pozostawiania haseł bez zmian, lecz także jest to dość przerażające, jeśli pomyślimy jakich szkód mogliby oni dokonać, gdyby mieli złe zamiary.

Jeśli dopuścimy możliwość ładowania systemu z DVD lub z sieci, to możemy stracić możliwość śledzenia tego, co robią ludzie. Chodzi o to, że dysk startowy systemu Linux lub sieciowy obraz systemu mogą często dać bezpośredni dostęp do systemu plików. Jeśli systemy korzystają z tej samej nazwy użytkownika i hasła w odniesieniu do swoich uprzywilejowanych kont, to narażamy system na poważny upadek. Dalej podam nieco szczegółów na ten temat.

Wiek i długość hasła są istotne w zależności od używanej metody łamania haseł. Jeśli mamy do czynienia z atakiem siłowym (ang. brute force), to istotnym czynnikiem jest tu czas. Im rzadziej zmieniamy hasło, tym dłuższy czas ma do dyspozycji haker, który chce uzyskać hasło.

Z kolei dłuższe hasła mają więcej możliwych wariantów w skali potęgowej, a więc złamanie ich zajmuje więcej czasu. Ważne jest też, czy hasła składają się z mniej niż 7 znaków, czy mają od 8 do 14 znaków, czy też 15 lub więcej znaków długości. Przy hasłach krótszych niż 15 znaków i przy korzystaniu z systemu Windows, trzeba wiedzieć, czy funkcje skrótu LAN Manager (LM) są wyłączone w konfiguracji systemu, czy przez Zasady grupy (Group Policy).

Jak długość hasła wpływa na cokolwiek? W przypadku systemu Windows odpowiedź jest prosta. Pomijając historię procesu stosowania skrótów przez Microsoft, firma ta implementuje dla haseł dwa rodzaje funkcji skrótu, skróty LM oraz skróty Message Digest 4 (MD4). Domyślnie Microsoft używa skrótów LM, zaś wartości są zapisywane dla wszystkich haseł, które mają do 14 znaków, o ile jawnie nie wyłączymy przechowywania tych skrótów. Hasła te są dzielone na dwie części po 7 znaków – pierwsza dla 7 pierwszych znaków i druga dla kolejnych 7 znaków, jak to widać na rysunku 1.

Rysunek 1 Przykładowa tabel skrótów

Wynika stąd, że jeśli hasło ma tylko 7 znaków, będzie ono zawarte w jednym skrócie LM. Przez całe lata firma Microsoft zalecała używanie haseł nie krótszych niż 8 znaków. Wynikało to stąd, że hasło, które ma 8 znaków, wymusza podział na dwie wartości skrótu LM.

Warto jednak zauważyć, że skróty LM są szeroko znane i bardzo łatwe do obejścia. Jedynym powodem utrzymywania ich w obecnych rozwiązaniach jest zapewnienie wstecznej kompatybilności z wcześniejszymi systemami, takimi jak Windows NT 4.0.

Dziś należy używać haseł (w zasadzie są to wyrażenia hasłowe), które mają nie mniej niż 15 znaków lub, co jest zalecane, są dłuższe, gdyż wtedy z definicji nie będzie generowany skrót LM.

Jeśli wymuszenie haseł zawierających 15 znaków nie jest w naszym środowisku możliwe, trzeba wyłączyć przechowywanie skrótów LM, zarówno w procesie tworzenia obrazu (za pomocą zasad lokalnych), jak i w Zasadach grupy Active Directory.

Zasady te można znaleźć w Computer Configuration\Windows Settings\Security Set­tings\Local Policies\Security Options (Konfiguracja\Ustawienia Windows\Ustawienia zabezpieczeń\Zasady lokalne\Opcje zabezpieczeń). Trzeba po prostu ustawić na „włączone” zasadę: „Network security: Do not store LAN Manager hash value on next password change” (Zabezpieczenia sieci: Nie zapisuj skrótu LAN Manager przy następnej zmianie hasła).

 Do początku strony

Im dłuższe, tym lepsze

Jedna z najnowszych metod włamywania się do komputerów nosi nazwę Tęczowe tablice (ang. Rainbow Tables) i wykorzystuje skróty LM jako tzw. exploity. Jednak dłuższe hasła mogą zanegować efektywność tej metody.

Zaskakuje mnie, jak wielu administratorów zajmujących się bezpieczeństwem niewiele wie (lub nic nie wie) na temat Tęczowych tablic. Jest wiele sposobów tworzenia Tęczowych tablic zajmujących się różnymi algorytmami. Jednak tu są one po prostu listą obliczonych wcześniej skrótów znaków od 0 do 14.

Ograniczenie Tęczowych tablic stanowi fakt, że napastnik musi najpierw otrzymać skróty LM. Prowadzi to do wcześniejszych pytań o to, jak system może zostać uruchomiony (z płyt CD lub DVD) oraz czy użytkownicy są lokalnymi administratorami, czy też nie. Wreszcie te skróty LM można wyciągnąć w kilka minut za pomocą darmowych narzędzi, takich jak pwdump. Przy wykorzystaniu Tęczowych tablic, skróty są następnie przeszukiwane w celu znalezienia hasła.

Aby zaspokoić swoją własną ciekawość, ustawiłem hasło na wbudowanym w systemie koncie administratora. Miało ono 14 znaków i zawierało wielkie i małe litery oraz znaki specjalne i cyfry. Następnie skorzystałem z Tęczowych tablic, które załadowałem za darmo z Internetu, co pozwoliło mi na uzyskanie skrótów haseł dla wszystkich kont mojego systemu i określenie hasła administratora w czasie krótszym od 2 minut.

Muszę przyznać, że miło było patrzeć na pokonanie pierwszego skrótu LM, potem drugiego, a następnie złożenia ich w celu uzyskania naszego hasła. Gdybym wcześniej wyłączył skróty LM za pomocą omówionej wcześniej zasady, ten rodzaj ataku zostałby poważnie ograniczony, a może nawet całkiem zablokowany.

 Do początku strony

Naruszenie domeny

Pozostawanie w domenie nie usuwa problemu. Komputery w obrębie domeny uwierzytelniają się nadal w ten sam sposób. Zaś, jak wspomniałem, w każdej domenie leży serce grupy roboczej. To proste stwierdzenie nie zawsze jest oczywiste. Odbyłem wiele rozmów na ten temat i okazało się, że często trzeba przypominać administratorom, czego wymaga dostęp do maszyny – nazwy użytkownika i hasła. Potem trzeba przejść do dyskusji na temat sposobu działania systemu Windows w grupie roboczej.

Jeśli próbujemy dostać się do systemu, musimy podać zdalnemu systemowi nazwę użytkownika i hasło. Poprzez wykorzystanie zintegrowanego uwierzytelniania, system Windows spróbuje zrobić to za nas. Oznacza to, że jeśli chcemy uzyskać dostęp do innego systemu Windows, Windows użyje nazwy i hasła aktualnie zalogowanego użytkownika. Tak więc przy próbie dostępu do innego systemu Windows, nie otrzymamy nigdy pytania o nazwę użytkownika i hasło, jeśli system zdalny używa takich samych wartości.

Jest to określane nazwą uwierzytelnienia przekazującego (ang. pass-through authentication). Proces ten działa w grupach roboczych, a także pomiędzy domenami. W najgorszym przypadku system zapyta nas o nazwę użytkownika i hasło, co oznacza, że trzeba będzie ponownie wpisać te informacje.

Nawet jeśli dołączymy stację roboczą lub serwer do domeny, a Active Directory stanie się centralnym repozytorium kont, to wszystkie lokalne systemy zarządzania zabezpieczeń (Security Account Managers, SAM) czy też lokalne składy kont w tych systemach nie znikną w magiczny sposób.

Jedyna różnica będzie polegać na tym, że te lokalne systemy SAM nie będą już zarządzane i zabezpieczone, a to powoduje podstawowe problemy. Kiedy ostatni raz zmienialiśmy wbudowane konta admin lub root w swoim systemie? Albo załadujmy dowolne narzędzie raportowania, które potrafi pokazać wiek haseł dla wszystkich kont, aby sprawdzić, czy wyniki zostałyby zatwierdzone przez inspekcję.

Jeśli dalej nie wiecie, co mam na myśli, to weźcie jedną ze stacji roboczych domeny i zalogujcie się jako konto domeny z uprawnieniami administratora. Otwórzcie zarządzanie komputerem w swoim systemie i utwórzcie lokalnego użytkownika o nazwie ToldYouSo. Nadajmy mu hasło i dodajmy konto do grupy lokalnych administratorów systemu. Powtórzmy ten proces w systemie drugiej domeny.

Teraz z dowolnego z tych dwóch systemów zalogujmy się lokalnie z kontem ToldYouSo i spróbujmy uzyskać dostęp do drugiej maszyny, przechodząc do \\systemName\c$. Będziemy mogli mieć dostęp do udziału administracyjnego i nikt nas nawet nie zapyta o hasło!

Mam nadzieję, że przykład ten nie jest dla nikogo niespodzianką. Jeśli jednak jest nowością, to warto się z niego czegoś nauczyć. Pozwólcie mi powtórzyć: sama przynależność systemu do domeny nie zmienia faktu, że wszystkie te systemy działają tak, jakby należały do grupy roboczej.

Wynika stąd, że jeśli do współdzielonych i uprzywilejowanych kont używamy haseł, które rzadko lub nigdy nie są zmieniane, to nasze współdzielone i uprzywilejowane konta są zagrożone. Do ujawnienia całej naszej sieci potrzeba tylko czasu.

 Do początku strony

Usprawiedliwienia, usprawiedliwienia ...

Gdy rozmawiam z administratorami lub nawet z kierownictwem, często słyszę te same podstawowe powody, dla których nie są zmieniane hasła:

Wprawdzie z dwiema pierwszymi przyczynami mogę się zgodzić, ale nie stanowią one wiarygodnego wytłumaczenia. Wzdrygam się na myśl o tym, że moje dane mogą być przechowywane w firmach, które z jakichkolwiek przyczyn nie zajmują się tym zagadnieniem.

Prawdą jest, że nie każdy system zawiera poufne informacje, ale użytkownicy tych komputerów mają potencjalnie dostęp do poufnych informacji, jak numer ubezpieczenia, dane medyczne lub dane finansowe.

Działając jako administrator systemu użytkownik może instalować programy rejestrujące znaki podawane z klawiatury i przechwytujące ekrany, uniemożliwiać stosowanie Zasad grupy, wprowadzać programy szpiegujące (ang. shims) do różnych podsystemów w celu przechwytywania i transmisji danych i tym podobne. A gdy użytkownik robi to na poziomie pojedynczego komputera, możliwość złapania takiego szkodliwego użytkownika jest znacznie trudniejsze, gdyż działa on pod nazwą Administrator.

Czy wiecie, że dezaktywacja wbudowanego konta administratora w Windows nie zatrzymuje możliwości zalogowania na to konto? Spróbujcie tego: restartujcie system w trybie bezpiecznym i zalogujcie się na wbudowane konto administratora. Można będzie zapewne użyć hasła wydanego dla tego konta w oryginalnym obrazie systemu i z powodzeniem się zalogować . Więcej informacji na temat tego postępowania można znaleźć w artykule Microsoft ® Knowledge Base „How to Access the Computer after You Disable the Administrator Account” ( support.microsoft.com/kb/814777 ).

 Do początku strony

Czego wymaga nadzór

Przy korzystaniu z SOX, PCI, HIPAA i innych regulacji możemy dostać zawrotu głowy. Zrozumienie wymagań może być trudne, gdyż są one szerokie i niezbyt jasne. Wymagania poszczególnych regulacji można podsumować jak poniżej.

Po pierwsze, trzeba mieć gwarancję, kto ma w każdej chwili dostęp do wszystkich uprzywilejowanych kont oraz informacji i zapewnić metodę udowodnienia tego. Jest to dobre postępowanie w każdym scenariuszu – konto uprzywilejowane jest kontem z uprawnieniami do dowolnych działań w systemie. Jest to wbudowany administrator i konto awaryjne. I takie konta zna cały zespół pomocy i każdy administrator pracujący w firmie.

Gdy wybierzemy rozwiązanie do zarządzania hasłami współdzielonych kont, tworzymy ścieżkę inspekcji do wbudowanego konta administratora w miejscu, w której jej nie było. Otrzymujemy hasło, które jest płynne. A ponieważ rozwiązanie to jest zautomatyzowane, nie tracimy całych tygodni pracy przy zmianie haseł. Wreszcie, ponieważ rozwiązanie to daje możliwość inspekcji, firma może zbliżyć się o krok do przejścia procedury inspekcji.

 Do początku strony

Zautomatyzowane podejście

Najbardziej efektywnym sposobem postępowania z tego rodzaju kontami jest regularna zmiana kont, aby dwa konta nigdy nie współdzieliły tego samego hasła. Przy współdzielonych hasłach ujawnienie jednego systemu oznacza ujawnienie drugiego. Innymi słowy, nie powinno być wspólnych kont lokalnych i dla domeny.

Gdy mamy do czynienia z rozwiązaniami zautomatyzowanymi, które pozwalają na zarządzanie hasłami w sposób losowy, nie trzeba ograniczać się do minimum wymaganego przez inspektorów. Na przykład dlaczego mamy używać haseł zawierających 8 znaków, jeśli możemy bez dodatkowego wysiłku zastosować hasła mające 15, 20 czy 127 znaków (patrz rysunek 2)?

Rysunek 2 : Używajmy zautomatyzowanych metod do tworzenia bardzo długich haseł

Rozważmy też codzienne losowe ustalanie uprzywilejowanych kont, co pokazano na rysunku 3. Nie ma powodu, aby wykonywać to działanie co 90 dni, gdy można to robić co dwa miesiące, co miesiąc, a nawet codziennie.

W końcu, jeśli cała procedura jest zautomatyzowana, nie wymaga od nas dodatkowej pracy. Ponadto, jeśli wykonujemy działanie regularnie, wymuszamy na użytkownikach pobieranie hasła z nadzorowanego interfejsu narzędzia, tworząc dodatkową ścieżkę inspekcji tam, gdzie jej wcześniej nie było. (Jeśli obecnie przechowujemy wszystkie zapisane hasła w kopercie zamkniętej w sejfie, który znajduje się w czyimś biurze, to nie mamy żadnej ścieżki inspekcji do tych haseł, w przeciwieństwie do rozwiązań zarządzania hasłami.)

Rysunek 3 : Codzienne losowe ustalanie kont uprzywilejowanych.

Wreszcie sprawmy, aby pobierane hasła były na nowo losowane w ustalonym czasie po ich pobraniu. Nie mam tu na myśli zaplanowanych zadań związanych z losowaniem, ale tworzenie jednorazowych haseł ważnych tylko przez kilka godzin, a nie przez kilka miesięcy. Metoda ta także wymusi na użytkownikach pobieranie haseł z interfejsu narzędzia, który podlega inspekcji, zapewniając w ten sposób ścieżkę inspekcji.

 Do początku strony

Pomyślmy o tym

Zagadnienie zarządzania hasłami współdzielonych kont musi być rozwiązane. Oznacza to, że trzeba wybrać metodę niezawodnej i regularnej zmiany haseł. Rozwiązanie musi być skalowalne i elastyczne. Musi też zapewniać bezpieczny dostęp do haseł, pozwalając na inspekcję każdego działania wykonywanego przez narzędzie, a także każdego działania użytkownika tego narzędzia. Ponadto generowane hasła musza być unikatowe w każdym systemie, aby uniknąć włamań wynikających z informacji o współdzielonych kontach.

Wielu dostawców zajmuje się tym problemem od wielu lat, zaś ostatnio pojawiło się w tej dziedzinie wiele nowych firm. Trzeba sprawdzić i wypróbować nowe narzędzia, przed ich zakupem, aby sprawdzić, czy są odpowiednie dla naszego środowiska.

Chris Stoneff jest menedżerem produktów w Lieberman Software ( liebsoft.com ), firmie zajmującej się tworzeniem oprogramowania do zarządzania systemami i bezpieczeństwem. Wyzwanie stanowi dla niego stwierdzenie, dlaczego określone narzędzia działają w dany sposób, a nie tylko, jak one działają.

Do początku strony