Поставщик небезопасности. Как Windows раскрывает пароль пользователя

Содержание статьи

• Компоненты безопасности
• Security Package
• SSP/AP (или же просто AP)
• Security Providers
• Credential Providers
• Password Filters
• Как происходит вход пользователя в систему
• Инициализация LSA
• Эксплуатация
• Как дебажить?
• Перехват пароля с помощью внедрения Security Package
• Перехват пароля с помощью внедрения Password Filter
• Перехват пароля с помощью диспетчера учетных данных
• Выводы

Боль­шинс­тво механиз­мов защиты в Windows стро­ится на паролях учет­ных записей поль­зовате­лей. В сегод­няшней статье мы раз­берем нес­коль­ко спо­собов перех­вата паролей в момент авто­риза­ции поль­зовате­ля и напишем код для авто­мати­зации это­го про­цес­са.

Windows име­ет слож­ную сис­тему аутен­тифика­ции со мно­жес­твом ком­понен­тов. Фун­дамен­том этой сис­темы мож­но счи­тать LSA (Local Security Authority) и SSP.

LSA — огромная под­систе­ма, которая слу­жит для про­вер­ки под­линнос­ти поль­зовате­лей, их регис­тра­ции, сме­ны пароля и подоб­ных опе­раций. Еще в LSA хра­нит­ся информа­ция обо всех аспектах безопас­ности локаль­ного компь­юте­ра, нап­ример количес­тве неус­пешных вво­дов пароля для бло­киров­ки учет­ной записи. Пос­редс­твом LSA мож­но даже наз­начать при­виле­гии поль­зователь­ским учет­кам, для это­го раз­работан инс­тру­мент Privileger.

SSP тоже не так прост, как кажет­ся: мы рас­смот­рели его исполь­зование в кли­ент‑сер­верных про­цес­сах в прош­лой статье. Он не толь­ко помога­ет раз­работ­чикам шиф­ровать дан­ные, обес­печивать целос­тность переда­ваемой информа­ции, выс­тра­ивать кон­текст, но и может рас­ширить стан­дар­тную аутен­тифика­цию. Прав­да, для этой цели будет исполь­зовать­ся не прос­то SSP, а SSP/AP, о котором мы погово­рим поз­же.

Компоненты безопасности

Их мож­но счи­тать кир­пичика­ми, из которых стро­ится вся огромная сис­тема аутен­тифика­ции в Windows. Отме­чу, что теория из этой статьи будет рас­простра­нять­ся и на пос­леду­ющий матери­ал. Мы нач­нем с прос­тей­шего перех­вата пароля, а затем будем понем­ногу усложнять себе задачу.

Security Package

Security Package (SP) — прог­рам­мная реали­зация неко­его про­токо­ла безопас­ности. Security Package содер­жатся в SSP (и/или SSP/AP) в виде DLL-фай­лов. Нап­ример, Kerberos и NTLM находят­ся в SSP Secur32.dll. Да, имен­но в Secur32.dll, так как имен­но этот SSP делеги­рует фун­кции безопас­ности нуж­ному SP. Нап­ример, если служ­ба тре­бует аутен­тифика­цию по Kerberos, то Secur32.dll вызовет Kerberos.dll.

Ра­бота SP 

SSP/AP (или же просто AP)

AP — Authentication Package. Пред­став­ляет собой биб­лиоте­ку DLL, которая тоже содер­жит один или нес­коль­ко SP. Глав­ное отли­чие от стан­дар­тно­го SSP зак­люча­ется в том, что SSP/AP может выс­тупать в качес­тве пакета аутен­тифика­ции (AP), то есть про­верять под­линность вве­ден­ных дан­ных при вхо­де поль­зовате­ля в сис­тему.

Тем не менее SSP/AP выпол­няет и все фун­кции стан­дар­тно­го SSP (выс­тра­ивать кон­текст, шиф­ровать дан­ные и про­чие). Что­бы SSP/AP мог фун­кци­они­ровать и в качес­тве пакета аутен­тифика­ции, и в качес­тве обыч­ного SSP для кли­ент‑сер­верных про­цес­сов, при запус­ке сис­темы он заг­ружа­ется в прос­транс­тво про­цес­са lsass.exe.

Так­же, если тре­бует­ся работать лишь с кли­ент‑сер­верны­ми фун­кци­ями кон­крет­ного SSP/AP, он без проб­лем может быть заг­ружен в кли­ент‑сер­верное при­ложе­ние. Нап­ример, методом динами­чес­кого (фун­кция LoadLibrary()) либо ста­тичес­кого свя­зыва­ния (pragma comment), то есть без заг­рузки в про­цесс lsass.exe. В таком слу­чае фун­кции пакета аутен­тифика­ции исполь­зовать­ся не будут.

SSP/AP в lsass.exe и кли­ент­ских про­цес­сах 

Security Providers

Security Providers не сто­ит путать с Security Package. Они все‑таки раз­лича­ются.

Про­вай­деры безопас­ности реали­зова­ны в виде DLL и поз­воля­ют выпол­нить так называ­емую вто­рич­ную аутен­тифика­цию. То есть пос­ле того, как поль­зователь про­шел аутен­тифика­цию на одной машине, он может прой­ти аутен­тифика­цию и на дру­гой машине, нап­ример на сер­вере Linux. Таким обра­зом, поль­зователь получа­ет дос­туп к ресур­сам UNIX-сер­вера с машины Windows без допол­нитель­ной аутен­тифика­ции. Это называ­ется Single Sign-On.

Ра­бота Security Providers 

Credential Providers

Про­вай­деры учет­ных дан­ных — COM-объ­екты, слу­жащие для бес­пароль­ного дос­тупа к сис­теме. Реали­зова­ны тоже в виде динами­чес­ких биб­лиотек DLL. Нап­ример, для рас­позна­вания лица исполь­зует­ся FaceCredentialProvider.dll, для смарт‑карт — SmartcardCredentialProvider.dll.

Так­же может исполь­зовать­ся сто­рон­ний пос­тавщик учет­ных дан­ных. Все дос­тупные пос­тавщи­ки учет­ных дан­ных перечис­лены здесь:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionAuthenticationCredential Providers


Каж­дый ключ по это­му пути реес­тра иден­тифици­рует опре­делен­ный класс пос­тавщи­ка безопас­ности по его CLSID. Сам CLSID дол­жен быть зарегис­три­рован в HKCRCLSID, так как явля­ется клас­сом COM. Для изу­чения всех дос­тупных пос­тавщи­ков так­же мож­но вос­поль­зовать­ся инс­тру­мен­том CPlist.exe.

Password Filters

С помощью Password Filters мож­но рас­ширить стан­дар­тную пароль­ную полити­ку на кон­крет­ных хос­тах. Ког­да соз­дает­ся зап­рос на сме­ну пароля, LSA вызыва­ет все пакеты уве­дом­лений, что­бы про­верить, удов­летво­ряет ли новый пароль филь­трам, реали­зован­ным внут­ри пакета. При­чем каж­дый пакет уве­дом­лений вызыва­ется дваж­ды:

Password Filter мож­но счи­тать час­тным слу­чаем Notification Package.

Notification Package в слу­чае про­вер­ки пароля 

Как происходит вход пользователя в систему

Пе­ред тем как мы смо­жем перех­ватить пароль, сле­дует разоб­рать­ся с про­цес­сом вхо­да поль­зовате­ля в сис­тему. В этой статье мы не будем вда­вать­ся в под­робнос­ти ини­циали­зации Winlogon, соз­дания рабочих сто­лов, GINA. Прос­то знай, что имен­но бла­года­ря про­цес­су Winlogon.exe осу­щест­вля­ется инте­рак­тивный вход. Сис­тема запус­тилась, поль­зователь сел за кла­виату­ру.

Эта фун­кция ничего осо­бен­ного не тре­бует. LsaHandle — хендл, получен­ный вызовом LsaRegisterLogonProcess(); PackageName — имя пакета аутен­тифика­ции, нап­ример MSV1_0_PACKAGE_NAME; AuthenticationPackage — получен­ный иден­тифика­тор жела­емо­го для исполь­зования Winlogon пакета аутен­тифика­ции.

Воз­можно, у тебя сра­зу появи­лась ковар­ная мысль: «А могу ли я сам генери­ровать токены?» Как бы да и как бы нет. Для успешно­го соз­дания токена тре­бует­ся при­виле­гия SeCreateTokenPrivilege, которой обла­дает толь­ко lsass.exe. Если у нас есть эта при­виле­гия, то мы смо­жем нафан­тазиро­вать что душе угод­но. Абсо­лют­но любой токен — любые груп­пы, при­виле­гии, вне зависи­мос­ти от каких‑либо гло­баль­ных нас­тро­ек и кон­фигура­ций. Нап­ример, я получал пра­ва на выпол­нение кода от лица груп­пы.

Вы­пол­нение кода от лица груп­пы

И ста­вил SID = 0.

Null sid

Про­цесс аутен­тифика­ции 

Инициализация LSA

Имен­но LSA игра­ет клю­чевую роль в про­цес­се аутен­тифика­ции поль­зовате­ля. Каким обра­зом LSA будет ини­циали­зиро­вать наши вре­донос­ные SP, AP и NP?

При запус­ке устрой­ства LSA авто­мати­чес­ки под­гру­жает все зарегис­три­рован­ные SP, реали­зован­ные в виде DLL, в свое адресное прос­транс­тво. Все зарегис­три­рован­ные DLL находят­ся по сле­дующе­му пути:

HKLMSYSTEMCurrentControlSetControlLsaSecurity Packages


Ключ со все­ми SP

Ес­ли этот ключ пус­той, то исполь­зует­ся зна­чение по умол­чанию:

kerberos""msv1_0""schannel""wdigest""tspkg""pku2u"


Все эти DLL ука­зыва­ются без пол­ного пути. Microsoft рекомен­дует помещать SP в пап­ку %systemroot%/system32. Далее у каж­дого SP вызыва­ется фун­кция SpLsaModeInitialize(), бла­года­ря которой LSA получа­ет спе­циаль­ную таб­лицу SECPKG_FUNCTION_TABLE, содер­жащую ука­зате­ли на фун­кции. Они реали­зуют дан­ный пакет безопас­ности. Выг­лядит это при­мер­но вот так:

SECPKG_FUNCTION_TABLE SecurityPackageFunctionTable[] ={ { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, SpInitialize, SpShutDown, SpGetInfo, SpAcceptCredentials, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL }};NTSTATUS NTAPI SpLsaModeInitialize(ULONG LsaVersion, PULONG PackageVersion, PSECPKG_FUNCTION_TABLE * ppTables, PULONG pcTables){ *PackageVersion = SECPKG_INTERFACE_VERSION; *ppTables = SecurityPackageFunctionTable; *pcTables = 1; return 0;}

Ес­ли SpLsaModeInitialize() успешно вер­нула таб­лицу, то LSA вызыва­ет SpInitialize(), которой переда­ет струк­туру LSA_SECPKG_FUNCTION_TABLE. В этой струк­туре содер­жатся ука­зате­ли на фун­кции, которые пре­дос­тавля­ет LSA для исполь­зования внут­ри SP. Нап­ример, фун­кцию CreateToken() мож­но исполь­зовать для соз­дания токена (это не токен дос­тупа, а токен, который генери­рует­ся во вре­мя выс­тра­ива­ния кон­тек­ста в кли­ент‑сер­верных при­ложе­ниях).

Треть­ей вызыва­ется SpGetInfo(), бла­года­ря которой LSA получа­ет информа­цию о пакете. Нап­ример, его имя, опи­сание и вер­сию. Эта информа­ция будет отоб­ражать­ся при вызове фун­кции EnumerateSecurityPackages():

NTSTATUS NTAPI SpGetInfo(PSecPkgInfoW PackageInfo){ PackageInfo->fCapabilities = SECPKG_FLAG_ACCEPT_WIN32_NAME | SECPKG_FLAG_CONNECTION | SECPKG_FLAG_LOGON; PackageInfo->Name = (SEC_WCHAR*)L"MishaSSP"; PackageInfo->Comment = (SEC_WCHAR*)L"SSP with a wide Russian soul"; PackageInfo->wRPCID = SECPKG_ID_NONE; PackageInfo->cbMaxToken = 0; PackageInfo->wVersion = 1337; return 0;}

Да­лее LSA заг­ружа­ет все дос­тупные пакеты аутен­тифика­ции (AP). Их спи­сок извле­кает­ся из сле­дующе­го клю­ча реес­тра:

HKLMSYSTEMCurrentControlSetControlLsaAuthentication Packages


Ключ со все­ми AP

В каж­дом из них будет выз­вана фун­кция LsaApInitializePackage(), в ней LSA передаст таб­лицу LSA_DISPATCH_TABLE, содер­жащую все фун­кции LSA, которые может дер­гать AP. AP, в свою оче­редь, дол­жен запол­нить пос­ледний параметр фун­кции, ука­зав свое имя. Это имя LSA исполь­зует, что­бы опре­делить, к какому AP хочет получить дос­туп прог­рамма, путем вызова LsaLookupAuthenticationPackage().

LSA_DISPATCH_TABLE DispatchTable;NTSTATUS LsaApInitializePackage(_In_ ULONG AuthenticationPackageId, _In_ PLSA_DISPATCH_TABLE LsaDispatchTable, _In_opt_ PLSA_STRING Database, _In_opt_ PLSA_STRING Confidentiality, _Out_ PLSA_STRING* AuthenticationPackageName){ // Сохраняем адреса функций DispatchTable.CreateLogonSession = LsaDispatchTable->CreateLogonSession; DispatchTable.DeleteLogonSession = LsaDispatchTable->DeleteLogonSession; DispatchTable.AddCredential = LsaDispatchTable->AddCredential; DispatchTable.GetCredentials = LsaDispatchTable->GetCredentials; DispatchTable.DeleteCredential = LsaDispatchTable->DeleteCredential; DispatchTable.AllocateLsaHeap = LsaDispatchTable->AllocateLsaHeap; DispatchTable.FreeLsaHeap = LsaDispatchTable->FreeLsaHeap; DispatchTable.AllocateClientBuffer = LsaDispatchTable->AllocateClientBuffer; DispatchTable.FreeClientBuffer = LsaDispatchTable->FreeClientBuffer; DispatchTable.CopyToClientBuffer = LsaDispatchTable->CopyToClientBuffer; DispatchTable.CopyFromClientBuffer = LsaDispatchTable->CopyFromClientBuffer; // Возвращаем имя нашего AP (*AuthenticationPackageName) = (LSA_STRING*)LsaDispatchTable->AllocateLsaHeap(sizeof(LSA_STRING)); if (NULL != (*AuthenticationPackageName)) { (*AuthenticationPackageName) = (LSA_STRING*) LsaDispatchTable->AllocateLsaHeap(sizeof(LSA_STRING)); (*AuthenticationPackageName)->Buffer = (char*) LsaDispatchTable->AllocateLsaHeap((ULONG)strlen ("myssp") + 1); if (NULL != (*AuthenticationPackageName)->Buffer) { (*AuthenticationPackageName)->Length = strlen("myssp"); (*AuthenticationPackageName)->MaximumLength = strlen("myssp") + 1; strcpy( (*AuthenticationPackageName)->Buffer, "myssp"); return 0x00000000L; // STATUS_SUCCESS } return 0xC0000002; // STATUS_NOT_IMPLEMENTED }} 

Эксплуатация

Источник: xakep.ru