Защита на привилегировани акаунти на домейн, изтриване на шифровани пароли от паметта
Останалата част от поредицата:
Последният път, когато разгледах факта, че единственият начин да се предотврати зареждането на LM хешове в паметта по време на интерактивни влизания е да се използват пароли от 15 знака или повече. Освен това, тъй като Rainbow LM хешовете могат да разбият парола само за няколко секунди, нападателите, които попаднат в тези LM хешове, ще научат пароли почти моментално.
Днес ще направим нещо по-добро. Ще разгледаме метод за получаване на потребителски пароли директно от паметта, който не изисква никакви междинни стъпки.!
Шифровани пароли в паметта ... сериозно ли говорите?
Точно. Оказва се, че по подразбиране интерактивните влизания зареждат криптирани потребителски пароли в паметта. Това се прави, за да се осигури единичен вход (SSO) за услуги, които не поддържат протоколи за автентификация на собствена мрежа (т.е. Kerberos, NTLM/LM предизвикателство/отговор). За да ви удостовери за тези услуги, Microsoft съхранява в паметта криптирана версия на вашата парола.
Ако сега се чудите дали има някаква реална разлика между криптирана парола в паметта и хеш парола в паметта, тогава отговорът определено е налице. Хешът се счита за еднопосочна функция, тоест след като данните преминат през алгоритъма за хеширане, не можете да възстановите оригиналните данни, като знаете резултата (вземете паролата). Криптирането, от друга страна, е обратимо, тоест позволява да се извърши дешифриране. Следователно, тъй като паметта съдържа криптирана версия на вашата парола, има начин да я дешифрирате. Това не предвещава нищо добро. Вече знаем, че разбиването на LM хеш е тривиална задача, което прави LM хеш еквивалент на обикновена парола - и това също не е добре. Но ако зададете парола, по-дълга от 15 знака, ще бъде невъзможно да се изчисли LM хеш: ще бъде наличен само NT хеш, а NT хешът на силна парола е много по-труден за разбиване, както би трябвало да бъде.
Извличане на парола
Очевидно проблемът е открит от разработчика на помощната програма mimikatz. Той е известен с прякора „Gentil Kiwi“ (не можах да намеря истинското му име) и живее във Франция. Неговите статии (+ Google Translate) дават добър преглед на проблема и описват най-общо как неговата помощна програма извлича пароли в ясен текст.
WDigest осигурява механизъм за "удостоверяване на дайджест". Това е разширение за HTTP, документирано в RFC 2069 и по-късно в RFC 2617. Дайджест удостоверяването е по-добро от основното удостоверяване, което изпраща идентификационни данни в чист текст. WDidgest изпълнява RFC 2617, както и RFC 2831, който описва по-общ механизъм за удостоверяване (приложим не само за HTTP), наречен Simple Authentication and Security Layer (SASL). Общата идея тук е, че споменатите спецификации описват удостоверяване на предизвикателство-отговор, при което отговарящият отговаря на предизвикателството, като изпраща съобщение, генерирано с помощта на хеш функция, която приема ясен текстов парола като вход. Статията в Уикипедия за Digest Authentication е много интересна и тя подчертава няколко проблема с този метод за удостоверяване. Един от тях е, че сървърът, използващ тази схема, може да съхранява паролите на клиента в чист текст, за да провери отговора. Ние обаче сме по-загрижени за това, че клиентът трябва да съхранява паролата в чист текст, за да отговори на обаждането на сървъра.