none
Хеши паролей в оперативной памяти RRS feed

  • Вопрос

  • Вопрос по безопасности. Если администратор домена открывает сетевую папку рабочей станции, то попадает ли в оперативную память рабочей станции хеш пароля администратора? Если да, то проникнув в рабочую станцию, какой-нибудь вирус сможет извлечь хеш парля администратора домена и использовать его для распространения по всей сети, верно?

    То-есть, интересует случай не открытия сесси, а именно когда я, находясь на сервере, открыл сетевую папку, расшаренную на рабочей станции.

    Прошу помочь разобраться.


    • Изменено yurybx 6 июля 2017 г. 15:24
    6 июля 2017 г. 15:22

Ответы

  • "Хеш" появляется только там, где вводится логин и пароль. Плюс он может "уехать" на удаленную систему в случае делегирования. Поэтому все способы делегирования (Kerberos, CredSSP) нужно использовать с осторожностью. Например, если вы включили CredSSP для WinRS и подключились к скомпрометированной системе, то все очень плохо.

    Сазонов Илья

    https://isazonov.wordpress.com/

    При делегировании по Kerberos никакой "хеш"(пароль пользователя в любой форме) на промежуточную станцию не "уезжает": у промежуточной станции всего лишь возникает право попросить доступ от имени пользователя к другой станции (или службе, работающей под своими учётными данными). Доступ промежуточная станция имеет право просить либо к любой станции/службе, если разрешено стандартное делегирование (в современных сетях Windows почти не используется),  либо к конкретной станции/службе, согласно тому, что указано в AD, если используется ограниченное делегирование. Причём, если станции разрешено ограниченное делегирование для любого протокола аутентификации (а не только Kerberos), то она может попросить доступ от имени любого пользователя, вне зависимости от того, обращался ли он к ней, или нет. Однако для любой учётной записи пользователя можно запретить любое её делегирование, если указать, что учётная запись не может быть делегирована (есть там такой флажок в свойствах).

    Так что с делегированием надо обращаться действительно осторожно, хотя пароль при этом ни в какой форме на промежуточную станцию и не передаётся.


    Слава России!



    9 июля 2017 г. 10:13

Все ответы

  • Нет, не попадает. При аутентификации на рабочей станции пароль на неё не передаётся. А если используется протокол аутентификации Kerberos (по умолчанию в домене именно он используется), на рабочую станцию предъявляется (в зашифрованном виде, так что расшифровать его может только эта рабочая станция) только выданный контроллером домена билет Kerberos, который cодержит авторизационную информацию (список SID польсователя и групп, в которые он входит, привилегии пользователя и т.д.).

    Более того, пароль и на контроллер домена в каком-либо пригодном для повторного использования виде не передаётся.

    Детали смотрите в описаниях протоколов аутентификации: Kerneros и NTLM.


    Слава России!

    6 июля 2017 г. 15:29
  • я так думаю после пети многие узнали про особенность винды хранить авторизационные данные в оперативе(на хабре вроде или гиктаймс был подробный разбор пару лет назад). Мимикатз очень интересная тулза. (вот козлы, юзабл бекдоры и прочее палят)

    вот тут бы напинать народ по ягодицам про например LAPS, но вот все равно не услышат.

    а читать описалово кербероса скучно и не интересно(особенно в рфц), тем более про тгт и прочее безобразие. вот регулярно спрашивают про обновление членства без рестарта\релогона. хотя даже до этого добирается в лучшем случае каждый сотый винадмин(имхо).

    ---

    ежик птица гордая, пока не пнешь - не полетит. (с) чья то примета, видать к дождю... (ах вот почему погоды такие нынче стоят)

    З.Ы. это просто мысли вслух...

    З.З.Ы есть кто белошапковый? давайте распишем в комиксах чтоль основы?

    6 июля 2017 г. 20:07
  • ... на рабочую станцию предъявляется (в зашифрованном виде, так что расшифровать его может только эта рабочая станция) только выданный контроллером домена билет Kerberos...

    А вот это интересно. Если рабочая станция может расшифровать билет, то значит вирус, заразивший её, может это сделать, верно? Чем, в таком случае, это грозит?

    Аналогична ли эта ситуация известной схеме взлома доменной сети? Схема выглядит примерно так: злоумышленник получает полные права на обычную рабочую станцию (разными способами), после чего извлекает из её оперативной памяти учетные данные, по которым в данный момент из неё открыты сессии (например, учетные данные администратора домена, rdp-сессия которого открыта). 

    Или всё же подключение к файлавым шарам не создает возможность извлечь из памяти учетные данные?

  • Ничем это не грозит. В билете Kerberos содержится только авторизационная информация для данной станции (SID пользователя, групп, в которые он входит, привилегии, утвержения, если есть). Использовать её для аутентификации на другой станции нельзя.


    Слава России!

  • Спасибо за ответы!
  • "Хеш" появляется только там, где вводится логин и пароль. Плюс он может "уехать" на удаленную систему в случае делегирования. Поэтому все способы делегирования (Kerberos, CredSSP) нужно использовать с осторожностью. Например, если вы включили CredSSP для WinRS и подключились к скомпрометированной системе, то все очень плохо.

    Сазонов Илья

    https://isazonov.wordpress.com/

    Модератор
  • "Хеш" появляется только там, где вводится логин и пароль. Плюс он может "уехать" на удаленную систему в случае делегирования. Поэтому все способы делегирования (Kerberos, CredSSP) нужно использовать с осторожностью. Например, если вы включили CredSSP для WinRS и подключились к скомпрометированной системе, то все очень плохо.

    Сазонов Илья

    https://isazonov.wordpress.com/

    При делегировании по Kerberos никакой "хеш"(пароль пользователя в любой форме) на промежуточную станцию не "уезжает": у промежуточной станции всего лишь возникает право попросить доступ от имени пользователя к другой станции (или службе, работающей под своими учётными данными). Доступ промежуточная станция имеет право просить либо к любой станции/службе, если разрешено стандартное делегирование (в современных сетях Windows почти не используется),  либо к конкретной станции/службе, согласно тому, что указано в AD, если используется ограниченное делегирование. Причём, если станции разрешено ограниченное делегирование для любого протокола аутентификации (а не только Kerberos), то она может попросить доступ от имени любого пользователя, вне зависимости от того, обращался ли он к ней, или нет. Однако для любой учётной записи пользователя можно запретить любое её делегирование, если указать, что учётная запись не может быть делегирована (есть там такой флажок в свойствах).

    Так что с делегированием надо обращаться действительно осторожно, хотя пароль при этом ни в какой форме на промежуточную станцию и не передаётся.


    Слава России!



    9 июля 2017 г. 10:13