CPAU to całkiem popularne narzędzie typu runas. Nazwa programu pochodzi od nazwy funkcji systemowej CreateProcessAsUser, z której co prawda program nie korzysta, ale jest na tyle wymowna i czytelna, że świetnie nadaje się na krótką i treściwą nazwę.
Z CPAU korzystają głównie administratorzy systemów, którzy chcą umożliwić zwykłym użytkownikom uruchomienie niektórych programów w kontekście administratora, rozwiązując w ten sposób wiele różnych problemów z pracą programu w trybie zwykłego użytkownika. Zdarza się również, że CPAU wykorzystywane jest po to, aby uruchomić jakąś aplikację jako ograniczony użytkownik, dzięki czemu można uniknąć problemów z aplikacjami bezstresowo modyfikującymi system, w momencie, gdy standardowo pracujemy na koncie administracyjnym.
Jedną z kluczowych funkcjonalności CPAU jest możliwość zapisania parametrów, a w tym nazwę użytkownika oraz hasło w osobnym, zakodowanym pliku. Algorytm zastosowany do zakodowania tych informacji został stworzony przez autora aplikacji i nie jest dostępny publicznie. Dzięki temu dane są bezpieczne i firmy takie jak Novell zachęcają do korzystania z CPAU oraz plików zadań z zapisanymi parametrami do wykonywania niektórych rutynowych czynności jak np. instalacja patchy, przez użytkowników systemu.
Od jakiegoś czasu obserwuję rosnącą popularność tego narzędzia w ramach serwisu wss i pomyślałem, że warto to i owo wyjaśnić. Czy rzeczywiście dane przechowywane w plikach zadań są bezpieczne?
Wyciąganie hasła bez łamania algorytmu dekodowania, czyli uruchamiamy WinDbg
CPAU w jakiś sposób tworzy nowy proces i przekazuje do niego parametry uruchomieniowe. Krótka zabawa z Dependency Walkerem pozwala nam obstawiać funkcję CreateProcessWithLogonW z biblioteki advapi32.dll. W momencie wywoływania tej funkcji parametry do niej przekazywane muszą znajdować się już w pamięci w postaci zdekodowanej i jest to dla nas najlepszy moment na przyjrzenie się im. Poniżej spisałem kroki, które należy wykonać, żeby dojść do opisywanego momentu i sprawdzić co widać. W ramach testu sięgnąłem do wspomnianego artykułu na stronach Novella i znajdującemu się tam przykładowemu plikowi .job
- Instalujemy WinDbg.
W tym kroku pobieramy WinDbg i instalujemy. Ustawiamy podstawowe parametry takie jak serwer symboli:
>set _NT_SYMBOL_PATH=srv*c:\websymbols\*http://msdl.microsoft.com/download/symbols
-
Uruchamiamy nową sesję WinDbg i ładujemy CPAU.
Zakładam, że cpau znajduje się w katalogu c:\utils, a plik zadań zapisany jest w c:\temp\novell.job. Wobec tego w oknie Command wpisujemy:
.create "c:\Utils\cpau -dec -file c:\temp\novell.job"
Początek zabawy z WinDbg i CPAU
Wciskamy enter i przechodzimy do kolejnego kroku
-
Ładujemy cpau i ustawiamy breakpoint na wspominaną wcześniej funkcję systemową.
W tym celu w oknie poleceń wpisujemy kolejno:
g
bp ADVAPI32!CreateProcessWithLogonW
Ustawienie pułapki na wywołanie funkcji tworzącej nowy process
-
Pozwalamy na dalsze wykonanie programu i czekamy na naszą pułapkę.
Jeszcze raz w oknie poleceń wpisujemy g i chwilę później debugger oddaje nam sterowanie. Sprawdzamy zawartość pamięci wskazywanej przez rejestr eax otwierając okno 'Memory' i wpisując @eax w polu 'Virtual'.
Podglądamy obszar pamięci wskazywanej przez zawartość rejestru eaxNaszym oczom ukazuje się hasełko - w omawianym przypadku jest to 'support' (przykład na stronie Novella błędnie sugeruje, że hasło brzmi 'password'). Funkcja CreateProcessWithLogonW zakończona jest na literkę 'W', co wskazuje na to, że jest to wersja 'szeroka', pracująca na ciągach znaków zapisanych w unikodzie, zakończonych unikodowym nullem.
Doszliśmy do momentu, w którym widzimy zawartość pamięci tuż przed uruchomieniem funkcji tworzącej nowy proces. Obok hasła możemy znaleźć inne parametry - nazwę użytkownika oraz wykonywane polecenie.
Cały proces mogliśmy nieco przyśpieszyć korzystając z faktu, iż polecenia dla WinDbg można oddzielać od siebie średnikiem i pisząc je w jednej linii.
Uwagi na koniec
OK, jednym słowem każdy może odczytać hasełko zakodowane w pliku .job. Czy to znaczy, że należy rozstać się z programem i więcej z niego nie korzystać? Nie! Zabezpieczenie w postaci nic nie mówiącego łańcucha cyfr jest wystarczającym straszakiem dla każdego przeciętnego użytkownika. A i opisana wyżej metoda nie jest dla każdego do powtórzenia, więc wobec braku jawnych dekoderów plików .job, każdy administrator może się czuć bezpieczny wobec znaczącej większości użytkowników.
Przestrzegam oczywiście przed nadmiernym wykorzystywaniem CPAU i raczej unikaniem kodowania haseł takich użytkowników jak administratorzy domenowi, etc., a raczej pozostaniu przy lokalnych kontach 'supportowych', które mają wyższe od standardowych uprawnienia. Zawsze przecież może się znaleźć w sieci ktoś, dla kogo wszelkiej maści tajemnice to osobiste wyzwania i dla kogo sięgniecie po WinDbg to dwa mlaśnięcia myszą...