Bezpieczeństwo Windows – czym jest LSASS dump. Jak się przed nim chronić?

Możliwość wykonania zrzutu danych uwierzytelniających systemu Windows przez grupy APT (ang. Advanced Persistent Threat) i innych threat actors jest poważnym zagrożeniem szczególnie dla przedsiębiorstw i innych organizacji. Baza wiedzy MITRE ATT&CK, która jest tworzona głównie dla wspierania obrony przed zagrożeniami w cyberprzestrzeni zawiera opisy technik i taktyk pochodzących z obserwacji rzeczywistych ataków. Niniejszy tekst dotyczy techniki o identyfikatorze T1003.001, czyli metody poznania danych uwierzytelniających systemów z rodziny Windows za pomocą zrzutu pamięci procesu LSASS (ang. Local Security Authority Subsystem Service).

Pamięć procesu LSASS może zawierać dane uwierzytelniające takie jak m.in. skróty haseł (ang. hash), kody typu PIN, a nawet hasła w postaci czystego tekstu. Przeglądając np. witrynę stigviewer.com (STIG to skrót od ang. Security Technical Implementation Guide), można znaleźć zalecenie, aby dezaktywować uwierzytelnianie WDigest poprzez wyzerowanie (0x00000000) wartości o nazwie UseLogonCredential w kluczu:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Wdigest\

Ma to na celu złagodzić (ang. mitigation) możliwość odczytania haseł w postaci czystego tekstu z pamięci procesu LSASS. Jako przykład zrzutu haseł z pamięci, będący wynikiem  złej konfiguracji WDigest (a dokładnie dokonanej przez atakujących zamiany dobrej konfiguracji na złą) można przytoczyć atak ransomware BlackCat.

Na wstępie spróbujemy zrozumieć, czym jest uwierzytelnienie, a czym autoryzacja, oraz uświadomić sobie, że nie są to pojęcia do stosowania zamiennie. Poznamy strukturę sieci komputerowej w organizacji korzystającej z systemów operacyjnych firmy Microsoft. Dowiemy się też, czym są procesy systemowe i jak wykonać zrzut pamięci takiego procesu. Po tym może nieco długim wstępie przejdziemy do metod odczytywania danych uwierzytelniających z procesu LSASS oraz sposobów obrony przed tymi technikami.

Uwierzytelnianie i autoryzacja

Pojęcia uwierzytelnienia (ang. authentication, AuthN) oraz autoryzacji (ang. authorization, AuthZ) nie powinny być używane zamiennie. Nie są to synonimy. Za pomocą danych uwierzytelniających (ang. credentials) następuje weryfikacja, czy dana osoba jest tą, za którą się podaje. Dopiero po uwierzytelnieniu można przyznać odpowiedni dostęp do systemu, sieci czy zasobu albo go odmówić. To właśnie autoryzacja określa, jakie uprawnienia ma dana osoba. Dla przykładu można przytoczyć tu następujące zdanie: „Nieetyczny haker uzyskał nieautoryzowany dostęp do katalogu i podmienił plik”, czyli jako zwykły użytkownik mógł np. przeglądać katalog, ale dokonał czegoś ponadto, czyli zmiany danych, co było działaniem nieautoryzowanym (jako zwykły użytkownik nie powinien mieć prawa do takich czynności).

Sieć komputerowa oparta na systemie Windows

W strukturach organizacyjnych (np. przedsiębiorstwa) środowiska oparte na systemach z rodziny Windows korzystają z Active Directory (lub chmurowego odpowiednika Azure Active Directory) — jest to usługa katalogowa, do której zadań należy m.in. łączenie komputerów w domeny oraz scentralizowane zarządzanie środowiskiem domenowym (rysunek 1). Komputery połączone w domenę są zarządzane przez kontroler domeny. Takie rozwiązanie znajduje zastosowanie szczególnie w rozległych środowiskach, w których do domeny mogą być podłączone nawet tysiące komputerów. Konta komputerów w domenie są przechowywane na lokalnym serwerze (kontroler domeny) lub w chmurze (Azure Active Directory).

Przeciwieństwem domen komputerów z systemem Windows są grupy robocze, w których poszczególne komputery nie mają np. wspólnego uwierzytelniania. Pozwala to na decentralizację i niezależność. Grupy robocze znajdują zastosowanie w małych sieciach, np. w domu lub małej firmie. W przypadku grupy roboczej konta użytkowników są przechowywane lokalnie, a nie na serwerze (jak w środowisku domenowym).

Rysunek 1. Domeny, drzewa i lasy urządzeń z systemem Windows

W tym tekście przyglądamy się procesowi lsass.exe, którego nazwę rozwija się jako Local Security Authority Server Service, i który jest odpowiedzialny za uwierzytelnianie zarówno w środowisku domenowym, jak i w niezależnych komputerach grupy roboczej. Proces LSASS odpowiada też za zarządzanie usługą katalogową Active Directory oraz m.in. za:

• usługę Security Accounts Manager (SAM),
• protokół uwierzytelniający Kerberos,
• protokół uwierzytelniający NTLM,
• protokół SSL,
• usługę NetLogon.

Możliwe jest załadowanie do LSA także innych komponentów uwierzytelniających. Nie rozwijając dalej tego tematu, już teraz widać z tych skrótowych informacji, jak ważnym procesem jest LSASS.

Zrzut pamięci procesu LSASS (ang. memory dump)

Zarządzać procesami można za pomocą wbudowanego w system Menedżera zadań oraz innymi narzędziami takimi jak np. Process Explorer z pakietu Windows Sysinternals czy Process Hacker.

Zrzut pamięci procesu to zapisanie fragmentu pamięci operacyjnej na dysk komputera w celu dalszej analizy. Otrzymany plik danych będzie zawierał kod maszynowy procesu, zmienne w pamięci, takie jak np. napisy czy wartości liczbowe, oraz inne dane zawarte w procesie. Warto dodać, że zrzut zachowa stan pamięci procesu z “określonego momentu”. Na przykład jeśli wykonamy zrzut pamięci przed zalogowaniem się użytkownika, to nie będzie tam danych uwierzytelniających. Natomiast, gdy zrzut zostanie wykonany po zalogowaniu, to przy odrobinie szczęścia będzie możliwość znalezienia w nim np. skrótów haseł (ang. hash).

Rzeczywistym przykładem wydobycia z pamięci procesu LSASS danych uwierzytelniających może być atak ransomware BlackCat, podczas którego atakujący zrzucili przez protokół SMB legalne oprogramowanie do zdalnego pulpitu, zmienili konfigurację WDigest i odczytali hasła do kont użytkowników poprzez zrzut pamięci procesu LSASS i użycie narzędzia Mimikatz.

Uruchomienie narzędzia, które wykonuje zrzut pamięci LSASS, ma miejsce w fazie poexploitacji i pozwala na lateral movement, czyli penetrację środowiska przez uzyskanie nieautoryzowanego dostępu do wielu urządzeń. Atakujący chce przeważnie dostępu do kontrolera domeny komputerów w organizacji.

Przykładowe narzędzia, które może zastosować to m.in.:

• PPLdump, 
• HandleKatz,
• nanodump,
• Mimikatz. 

Sukces w zastosowaniu konkretnego narzędzia omijającego zabezpieczenia zależy od wersji systemu operacyjnego oraz aktywnych zabezpieczeń. Gdy narzędzia ofensywne nie są skuteczne to należy wziąć pod uwagę napisanie własnego narzędzia lub modyfikację istniejących.

Warto dodać, że wymienione narzędzia powinny być uruchamiane po podniesieniu uprawnień (ang. privilege escalation), czyli na koncie lokalnego administratora lub koncie SYSTEM (posiada najwyższe uprawnienia).

Zrzut pamięci procesu LSASS za pomocą Menedżera zadań

Przykładem dość trywialnego sposobu na zrzut pamięci procesu jest użycie systemowego Menedżera zadań (rysunek 2). Jednak szybki eksperyment na Windows 11 z włączonym Defenderem pokazał, że podnoszony jest alarm antywirusowy (rysunek 3).

Rysunek 2. Wykonanie zrzutu pamięci procesu LSASS do pliku z pomocą Menedżera zadań

Rysunek 3. Alarm antywirusowy programu Defender po rozpoznaniu podejrzanego zachowania (ang. behavior), jakim jest zrzut pamięci procesu LSASS

Zrzut pamięci procesu LSASS za pomocą Process Explorer

Wykonanie zrzutu pamięci za pomocą narzędzia Process Explorer jest bardzo podobne do poprzedniej metody. Narzędzie można pobrać z adresu:

https://live.sysinternals.com/procexp.exe

Istnieją jednak zabezpieczenia, które mogą przeszkodzić w zrzucie pamięci.

Zabezpieczenie LSA (RunAsPPL)

Zgodnie z dokumentacją firmy Microsoft proces LSASS jest zawarty w procesie LSA (Local Security Authority). Zabezpieczenie nazywane LSA Protection lub RunAsPPL (skrót PPL od ang. Protected Process Light) polega na ochronie wspomnianych procesów. Samouczek od Microsoftu prezentuje, że zabezpieczenie włącza się (rysunek 4) przez utworzenie wartości 0x00000001 o rozmiarze podwójnego słowa (DWORD) w kluczu:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Rysunek 4. Wartość 0x00000001 o nazwie RunAsPPL związana z zabezpieczeniem LSA Protection

Nie zawsze włączanie i wyłączanie tego zabezpieczenia jest tak trywialne. Jeśli maszyna ma Secure Boot, to wartość ta jest przechowywana w oprogramowaniu układowym (ang. firmware) i niezależnie od zmian w rejestrze będzie aktywna. W celu weryfikacji, czy LSA Protection jest włączone, można otworzyć Podgląd zdarzeń (rysunek 5) i sprawdzić, czy jest w nim wpis:

Program LSASS.exe został uruchomiony jako proces chroniony z poziomem: 4.

Rysunek 5. Weryfikacja w Podglądzie zdarzeń, czy zabezpieczenie LSA (RunAsPPL) jest aktywne (tutaj jest aktywne)

Aby sprawdzić, czy światło procesu LSASS jest chronione, należy włączyć dodatkową kolumnę w programie Process Explorer (rysunek 6).

Rysunek 6. Wybranie kolumny Protection w narzędziu Process Explorer

Rysunek 7. Kolumna Protection informuje, że pamięć procesu LSASS jest chroniona

Rysunek 8. Próba zrzutu pamięci procesu chronionego kończy się błędem odmowy dostępu

Omijanie LSA Protection (RunAsPPL) za pomocą Mimikatz

Mimikatz to narzędzie autorstwa Benjamina Delpy do pozyskiwania danych uwierzytelniających systemu Windows na różne sposoby.

Ważna informacja: Możliwe, że uruchomienie Mimikatz na Windows 10 zakończy się błędem:

kuhl_m_sekurlsa_acquireLSA ; Key import

Pomocne może być użycie starszej wersji, a dokładnie Mimikatz v2.1.1 stąd:

https://github.com/gentilkiwi/mimikatz/files/4167347/mimikatz_trunk.zip

Do rzeczy: W celu ominięcia LSA Protection (RunAsPPL) program Mimikatz stosuje załadowanie sterownika (.sys) poleceniem:

!+

oraz usunięcie ochrony procesu poleceniem:

!processprotect /process:lsass.exe /remove

Załadowanie sterownika pozwala usunąć ochronę pamięci procesu (rysunek 9).

Rysunek 9. Załadowanie sterownika przez narzędzie Mimikatz oraz usunięcie ochrony procesu LSASS

Gdy proces LSASS nie jest chroniony, możliwe jest wykonanie zrzutu pamięci. Dla uproszczenia użyjemy programu Process Explorer (rysunek 10).

Rysunek 10. Zrzut pamięci procesu LSASS po usunięciu ochrony przez Mimikatz

Jeśli plik zrzutu jest utworzony, to za pomocą poleceń:

sekurlsa::minidump C:\Users\n\Desktop\lsass.dmp

sekurlsa::logonpasswords

możliwe jest odczytanie danych uwierzytelniających w postaci skrótów haseł (rysunek 11).

Rysunek 11. Dane uwierzytelniające wydobyte z pliku zrzutu pamięci procesu LSASS

W pamięci mogą być różne dane uwierzytelniające zależnie od rodzaju konta czy ustawień systemowych. Przykładowy schemat przedstawiono na rysunku 12.

Rysunek 12. Rodzaje danych uwierzytelniających, które można znaleźć w pamięci Windows

W celu przywrócenia ochrony procesu oraz usunięcia sterownika (rysunek 13) należy wykonać polecenia:

!processprotect /process:lsass.exe

!-

Rysunek 13. Przywrócenie ochrony procesu LSASS i usunięcie sterownika w Mimikatz

Łamanie skrótu hasła NTLM

Zaprezentowany eksperyment dostarczył skrót hasła w formacie NTLM. Ktoś może zapytać: Dlaczego Microsoft nadal przechowuje dane uwierzytelniające w słabych formatach takich jak np. hashe NTLM?

Otóż często jest to wymaganie tzw. kompatybilności wstecznej. Nie zawsze w organizacji można wyłączyć określone rozwiązania, gdy inne procesy są od niego zależne.

MITRE ATT&CK zaleca wyłączenie lub ograniczenie NTLM i przejście na Kerberosa, który mimo podatności (np. Pass the Ticket, Sub-technique T1550.003 – Enterprise | MITRE ATT&CK®) jest bezpieczniejszy, a przynajmniej aktualny w roku 2022. Kryptografia NTLM jest przestarzała. Skróty haseł protokołu NTLM nie zawierają soli oraz nie istnieje wsparcie dla uwierzytelniania wieloskładnikowego (NTLM Explained: Definition, Protocols & More | CrowdStrike).

Szybkość łamania NTLM na naszym sprzęcie możemy zweryfikować, uruchamiając np. narzędzie hashcat poleceniem: hashcat -b -m 1000 (rysunek 14).

Notebook, na którym pisany jest ten tekst, łamie ponad 2 miliardy hashy NTLM na sekundę. Dokładnie jest to wartość 2162.7 MH/s. Dla kontrastu zmodyfikowany hashcat na o wiele mocniejszym sprzęcie osiągnął 102.8 GH/s (tj. ponad 100 miliardów hashy NTLM na sekundę). Przykład ten doskonale obrazuje słabość zabezpieczenia w postaci NTLM.

Rysunek 14. Przykładowy test wydajności łamania hashy NTLM za pomocą hashcata

Jak rozpoznać, jakie hasło kryje się za hashem NTLM? Można zastosować narzędzie do ich łamania, takie jak np. hashcat czy John the Ripper. Użyjmy przykładowo hashcata z adresu:

https://hashcat.net/hashcat/

Skrót hasła NTLM jest następujący:

fd32194cec3fe17dd29e38cf29b19065

Po pobraniu narzędzia hashcat należy uruchomić Wiersz polecenia (cmd.exe) i przejść do katalogu z programem za pomocą:

cd C:\Users\iamda\Desktop\hashcat-6.2.5

Łamanie skrótu hasła możemy wywołać poleceniem:

hashcat.exe -m 1000 -a 3 hash.txt

Parametr -m określa rodzaj skrótu (1000 to NTLM). Pełny wykaz rodzajów hashy znajduje się tutaj:

https://hashcat.net/wiki/doku.php?id=example_hashes

Parametr -a określa metodę ataku. Wartość trzy (3) to atak siłowy. Istnieją jeszcze m.in. ataki: słownikowy, hybrydowy czy siłowy z zastosowaniem maski.

Natomiast hash.txt to ścieżka do pliku zawierającego hash do złamania.

Przykładowe hasło jest proste i złamanie go zajęło 26 sekund (rysunek 15).

Rysunek 15. Łamanie skrótu hasła NTLM za pomocą narzędzia hashcat

W rzeczywistości często można spotkać mocniejsze hasła. Z tego powodu warto wspomnieć o trybie ataku siłowego, ale z użyciem maski w narzędziu hashcat. Przykład na stronie programu hashcat prezentuje hasło Julia1984. Atak siłowy dla tego rodzaju hasła wymaga 13.537.086.546.263.552 (62^9) kombinacji, co z prędkością łamania 100 M/s wymaga czasu 4 lat. Natomiast atak z użyciem maski w formie imię + rok urodzenia zmniejsza liczbę kombinacji do 237.627.520.000 oraz skraca czas łamania do 40 minut!

Ktoś może zapytać: Jakie hasła można realnie złamać w rozsądnym czasie? Otóż przykład powyżej dowodzi, że nie zawsze czas łamania jest zależny od skomplikowania hasła (różnorodności znaków). Dużą rolę odgrywa metoda ataku. Atak siłowy z użyciem maski będzie często skuteczniejszy, niż zwykły atak siłowy.

Dość skrajnym, ale realnym przykładem może być sytuacja, w której atakujący generuje słownik haseł ze słów znalezionych np. na blogu ofiary. Nawet trudne hasło (biorąc pod uwagę atak siłowy) takie jak jakiś cytat w stylu: fas_est_et_ab_hoste_doceri!1999 będzie nieskuteczne, jeśli znajdzie się w wygenerowanym słowniku haseł.

Omijanie LSA Protection (RunAsPPL) bez użycia sterownika (.sys)

Zabezpieczenie światła procesu (ang. PPL, Protected Process Light) w uproszczeniu powoduje, że chroniony proces może zostać otwarty (np. funkcją OpenProcess z WinAPI) tylko przez proces, który jest równo lub wyżej w hierarchii. Narzędzie Mimikatz omija to zabezpieczenie przez zejście do trybu jądra (ang. kernel mode), gdzie kod ma wyższy poziom uprzywilejowania.

Innym sposobem jest zastosowanie exploita opisanego na blogu Project Zero przez Jamesa Forshawa w 2018 roku. Różnica w porównaniu do metody z załadowaniem sterownika jest ogromna, gdyż exploit działa w trybie użytkownika.

Przykładowe implementacje to np.:

• https://github.com/itm4n/PPLdump
• https://github.com/helpsystems/nanodump

Zrzut pamięci procesu LSASS za pomocą nanodump

Jeśli nie chcemy używać gotowych plików wykonywalnych narzędzia nanodump, to możemy samodzielnie zbudować kod z pomocą Microsoft Visual Studio.

W tym celu należy uruchomić konsolę x64 Native Tools Command Prompt for VS 2022 (rysunek 16) lub jej odpowiednik.

Do folderu z kodem źródłowym możemy przejść poleceniem:

cd C:\Users\n\Desktop\nanodump-main

Natomiast budowanie kodu wywołuje się poleceniem:

nmake -f Makefile.msvc

Po chwili otrzymamy gotowe pliki wykonywalne.

Rysunek 16. Budowanie kodu narzędzia nanodump za pomocą konsoli Visual Studio

W celu wywołania narzędzia nanodump należy przejść do folderu /dist poleceniem:

cd C:\Users\n\Desktop\nanodump-main\dist

Zrzut pamięci procesu LSASS chronionego przez PPL (rysunek 17) można wykonać poleceniem:

nanodump_ppl.x64.exe –write C:\Users\n\Desktop\nanodump-main\dist\lsass2.dmp

Rysunek 17. Zrzut procesu LSASS chronionego przez PPL za pomocą nanodump

Sygnatura zrzutu pamięci procesu LSASS na początku pliku zrzutu (rysunek 18) jest jasnym i łatwo zauważalnym wskaźnikiem kompromitacji (ang. IoC, Indicator of Compromise).

Rysunek 18. Poprawna sygnatura pliku zrzutu pamięci procesu LSASS

Z tego powodu narzędzie nanodump tworzy plik z nieprawidłową sygnaturą (rysunek 19).

Rysunek 19. Niepoprawna sygnatura pliku zrzutu pamięci procesu LSASS (losowe wartości)

Kiedy zrzut pamięci LSASS zostanie wyprowadzony poza atakowane środowisko (np. przez serwer Command&Control) można naprawić sygnaturę (rysunek 20) poleceniem:

restore_signature.exe C:\Users\n\Desktop\nanodump-main\dist\lsass2.dmp

Aby następnie przetworzyć plik zrzutu programem Mimikatz (lub odpowiednikiem pypykatz).

Rysunek 20. Naprawa sygnatury pliku zrzutu pamięci procesu LSASS

Zabezpieczenie Credential Guard

Oparte na technologii wirtualizacji izolowanie sekretnych danych od systemu operacyjnego (rysunek 21) jest dostępne dla wersji Enterprise, czyli w Windows 10 Enterprise i nowszych oraz w wersji Server, czyli Windows Server 2016 i nowszych.

Rysunek 21. Zabezpieczenie Credential Guard (schemat ogólny)

Zabezpieczenie Credential Guard ma za zadanie chronić skróty haseł (hashe NTLM), bilety Kerberos oraz dane uwierzytelniające do domeny. Jednym ze sposobów włączenia Credential Guard jest użycie Edytora lokalnych zasad grupy (rysunek 22). Wymuszenie przetworzenia nowych ustawień grupy można uzyskać poleceniem:

gpupdate /force

Rysunek 22. Zabezpieczenie Credential Guard w Edytorze lokalnych zasad grupy

Aby sprawdzić, czy zabezpieczenie Credential Guard zostało pomyślnie włączone i działa, można posłużyć się aplikacją msinfo32.exe, która wyświetla różne informacje o systemie (rysunek 23).

Rysunek 23. Informacje o zabezpieczeniu Credential Guard w narzędziu Informacje o systemie

Ochrona przed zrzutem pamięci LSASS i kradzieżą danych uwierzytelniających

Ktoś może zapytać: Czy włączone LSA Protection  (RunAsPPL) i Credential Guard chroni przed kradzieżą danych uwierzytelniających?

W pełnym stopniu nie chroni., ale łagodzi (ang. mitigation) too zagrożenie. Powstają nowe zabezpieczenia i poprawki, ale i narzędzia ofensywne są dostosowywane do ich pokonywania. Przykładem może być opisana w maju 2022 roku metoda, która pozwala na ominięcie Credential Guard przez dokonanie modyfikacji dwóch zmiennych globalnych w procesie LSASS. 

~Dawid Farbaniec

Wykaz literatury

Matthew Hickey, Jennifer Arcuri, Warsztat hakera. Testy penetracyjne i inne techniki wykrywania podatności, Gliwice 2022

OS Credential Dumping: LSASS Memory, Sub-technique T1003.001 – Enterprise | MITRE ATT&CK® | https://attack.mitre.org/techniques/T1003/001/

Configuring Additional LSA Protection | Microsoft Docs | https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

Critical System Services – Win32 apps | Microsoft Docs | https://docs.microsoft.com/en-us/windows/win32/rstmgr/critical-system-services

Do You Really Know About LSA Protection (RunAsPPL)? | itm4n’s blog | https://itm4n.github.io/lsass-runasppl/

Bypassing LSA Protection in Userland – Sec Team Blog (scrt.ch) | https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/

Protect derived domain credentials with Windows Defender Credential Guard (Windows) – Windows security | Microsoft Docs | https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard

Revisiting a Credential Guard Bypass | itm4n’s blog | https://itm4n.github.io/credential-guard-bypass/

Pass The Hash – Defense/Offense/Fix | https://blog.zsec.uk/path2da-pt3/

Domain vs workgroup accounts in Windows 10 – Infosec Resources | https://resources.infosecinstitute.com/topic/domain-vs-workgroup-accounts-in-windows-10/

WDigest Authentication must be disabled. | https://www.stigviewer.com/stig/windows_server_20122012_r2_member_server/2020-06-16/finding/V-72753

The many lives of BlackCat ransomware – Microsoft Security Blog | https://www.microsoft.com/security/blog/2022/06/13/the-many-lives-of-blackcat-ransomware/

Memory usage considerations in AD DS performance tuning | Microsoft Docs | https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/memory-usage-considerations

Use Alternate Authentication Material: Pass the Ticket, Sub-technique T1550.003 – Enterprise | MITRE ATT&CK® | https://attack.mitre.org/techniques/T1550/003/

hashcat na Twitterze: „hand-tuned hashcat 6.0.0 beta and 2080Ti (stock clocks) breaks NTLM cracking speed mark of 100GH/s on a single compute device https://t.co/aVRMpbap4H” / Twitter | https://twitter.com/hashcat/status/1095807014079512579

NTLM Explained: Definition, Protocols & More | CrowdStrike | https://www.crowdstrike.com/cybersecurity-101/ntlm-windows-new-technology-lan-manager/