Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Интересно, зачем хранить пароль в памяти. Только для логина на другие машины в сети? Но для этого надо хранить пароль только текушего пользователя.
Цитата в студию — «Особенности реализации механизма HTTP Digest Authentication для поддержки SSO (Single Sign On) требуют знание вводимого пароля, а не только его хеша. Поэтому, разработчики Windows решили хранить пароли пользователей в открытом виде.
Подробнее: www.securitylab.ru/news/420431.php»
Подробнее: www.securitylab.ru/news/420431.php»
Ну мой вопрос остается открытым. Зачем разработчики Windows хранят ВСЕ пароли? В том числе, и системных пользователей? Ведь логично было бы просто запомнить пароль пользователя после логина. Т.е. мы храним только хеши паролей, но когда пользователь логинится, мы запоминаем его пароль и используем его для SSO.
Digest — в принципе фигня. Используется далеко не всеми, да и отключить можно. Куда веселее, что пароль в открытом виде нужен для обновления тикета Kerberos.
Ну и абсолютно непонятно, зачем хранятся пароли пользователей, которые вышли из системы. Либо я что-то не так понимаю, либо это натуральный эпик фэйл. Но MS, судя по отсутствию реакции в течение уже почти трех лет, так не считает — очень интересно узнать, чем они это мотивируют.
Ну и абсолютно непонятно, зачем хранятся пароли пользователей, которые вышли из системы. Либо я что-то не так понимаю, либо это натуральный эпик фэйл. Но MS, судя по отсутствию реакции в течение уже почти трех лет, так не считает — очень интересно узнать, чем они это мотивируют.
Ну для эксплуатации уязвимости необходимы права админа. Что в принципе снижает опасность.
Профили пользователей кэшируются для ускорения повторного входа. Видимо пароль не исключение.
Для пролонгации пользовательского Kerberos-тикета пароль не нужен, он нужен только для получения первоночального или нового, если пролонгация больше невозможна.
Для пролонгации пользовательского Kerberos-тикета пароль не нужен, он нужен только для получения первоночального или нового, если пролонгация больше невозможна.
Отлично, спасибо.
Пароли разве не должны удаляться при уходе в сон и гибернацию?
Ещё интересно, что и в каком виде можно найти в разделе 30 days standby от Lenovo.
Ещё интересно, что и в каком виде можно найти в разделе 30 days standby от Lenovo.
Нет, при гибернации на жёсткий диск сохраняется всё содержимое оперативной памяти, в т.ч. пароли, тикеты, ключи шифрования и т.д. При уходе в сон сохранения памяти на диск не происходит.
Я вообще давно задумывался, почему во время гибернации, не замутить хотя бы простейшее сжатие данных.
Например простой быстрый проход по аллокейтед мемори и сохранять только реально используемые участки, заполняя «сжатыми нулями» неиспользуемые.
Возможно в этом случае пароли разлогиненных пользователей чистились, или они хранятся в активной памяти до ребута?
С момента прихода suspend-to-ram наверное уже никто не будет гибернацию дорабатывать, а жаль.
Например простой быстрый проход по аллокейтед мемори и сохранять только реально используемые участки, заполняя «сжатыми нулями» неиспользуемые.
Возможно в этом случае пароли разлогиненных пользователей чистились, или они хранятся в активной памяти до ребута?
С момента прихода suspend-to-ram наверное уже никто не будет гибернацию дорабатывать, а жаль.
На сколько я понимаю, суть гибернцаии в быстроте загрузки, зачем тратить ресурсы на сжатие?
В некоторых случаях сжатие может ускорить процесс (если алгоритм сжатия быстрее чем скорость записи) но увеличить расход энергии (особенно критично при работе от батареи). Видимо в данном случае разработчики решили пойти по пути наименьшего сопротивления.
Как раз именно сжатие может дать прирост, там же не обязательно максимальное сжатие — самые простейшие алгоритмы, и как раз проход по malloc вообще почти не потребует ресурсов, но если на ноуте 4гб оперативки а занято всего 2, то IMHO вдвое быстрее.
По маленьку набираем пунктики, что в обязательном порядке нужно отключать в корпоративных сетях:
1. Гибернацию (могут вытащить пароли с украденного ноута)
2. Включение залипания клавиш (сброс паролей локальных пользователей через замену исполняемого файла)
1. Гибернацию (могут вытащить пароли с украденного ноута)
2. Включение залипания клавиш (сброс паролей локальных пользователей через замену исполняемого файла)
причем тут залипание клавиш?
Сброс пароля на Windows 7+ погуглите. Там заменяется файл, который система запускает по пятикратному нажатию клавиши Shift на CMD. Комбинация работает до ввода пароля, программа запускается с админскими правами. Из командной строки можно поменять пароль/заблокировать/разблокировать любого локального пользователя.
При наличии физического доступа к ПК можно сделать гораздо более страшные вещи, чем эскалация привилегий.
Имеется в виду accesibility options?
Ну так для этого нужно загрузиться с другого диска. Если есть возможность загрузиться с другого диска — то сбросить пароль можно и через специальные утилиты, не заморачиваясь с подменой файлов.
FDE вас спасёт.
Еще заблокировать локального админа вообще, чтобы сбросив его пароль загрузкой со стороннего девайса, не могли залогиниться и насетапить кейлоггеров…
В корпоративных сетях достаточно влючить BitLocker и вопрос украденного ноута и дампа с него решается тут же.
Кстати способ не новинка и фигурирует еще в 2012 году, с более простой инструкцией:
blog.lostpassword.com/2012/11/extraction-of-windows-login-passwords-from-hibernation-file-or-memory-image/
blog.lostpassword.com/2012/11/extraction-of-windows-login-passwords-from-hibernation-file-or-memory-image/
Не новинка, не спорю, автор mimikatz продемонстрировал пруф ещё в 2013 году.
Passware Kit, да штука удобная, но не всегда справляется с этой задачей (попробуйте сами), плюс это платное ПО.
Passware Kit, да штука удобная, но не всегда справляется с этой задачей (попробуйте сами), плюс это платное ПО.
Я просто нашел эту статью, когда пытался нагуглить каким образом скопировать hiberfil.sys на работающем ПС, кстати не мешало бы добавить в статью наверное? :)
Бесплатная версия WinHEX не позволяет восстановить файлы больше 200 Кб, есть альтернативный инструмент DMDE, у которого нет этого ограничения (Его ограничение бесплатной версии, нельзя вытащить файлы группой, или каталоги, только по одному файлу).
Рекомендую также посмотреть в сторону FTK Imager.
А есть мысли насчет аналогов Windows Memory toolkit? Бесплатная версия не умеет x64 файлы и не поддерживает Windows 8 и выше.
А что конкретно вы хотите сделать? В данном примере я использовал из этого пакета только только hibr2dmp. На скринах видно, что hiberfil.sys взят с 64-х битной системы.
Бесплатная версия же не поддерживает 64 разряда?
Я вытащил hiberfil.sys (x64, 6.5Gb), но не могу конвертировать его в dmp.
hibr2dmp.exe выдает следующее:
При этом файл однозначно никем не используется, поиском нашел что проблема скорее всего в разрядности, или формате хранения отличном от Windows 7 и более ранних.
Пробовал через двойную конвертацию утилитой volatility, сначала в raw потом в dmp, в raw проходит успешно, но raw2dmp выдает что не может понять данные которые я хочу конвертировать. В том числе не может отнести их к данным файла гибернации.
hibr2dmp.exe выдает следующее:
При этом файл однозначно никем не используется, поиском нашел что проблема скорее всего в разрядности, или формате хранения отличном от Windows 7 и более ранних.
Пробовал через двойную конвертацию утилитой volatility, сначала в raw потом в dmp, в raw проходит успешно, но raw2dmp выдает что не может понять данные которые я хочу конвертировать. В том числе не может отнести их к данным файла гибернации.
Интересно, есть какая-либо возможность запретить lsass.exe хранить пароли в открытом виде?
Нет, нету, это by design.
Можно отключить использование Wdigest SSP в реестре: «HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages», т.е. по сути отключить Digest Authentication
Это не поможет. Дело в том, что пароли в открытом виде хранятся не только для digest, но и для других способов аутентификации, в том числе для Kerberos. Не пробовал отключать Kerberos на недоменном компе, но в сети это, очевидно, не слишком разумная идея. :)
Посты автора mimikatz на французском, но вот тут немного на английском есть — digital-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords.
Похоже, единственный способ что-то сделать — не использовать вход по паролю (сертификаты, биометрия, и т.п.), но это надо проверять.
Посты автора mimikatz на французском, но вот тут немного на английском есть — digital-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords.
Похоже, единственный способ что-то сделать — не использовать вход по паролю (сертификаты, биометрия, и т.п.), но это надо проверять.
Надо будет проверить этот файл сервера. Вдруг кроме паролей пользователей на вход и для почты что-то еще найдется…
Подождите…
То есть получается, что вот например, я пригласил подрядчика поднять сервис на вин-сервере. Сервис большой, энтерпрайзный, и, как у них заведено, хочет работать от учетки с правами локал админа и от нее же устанавливаться.
То есть я дал подрядчику учетку с правами локал админа на сервере в домене.
И теперь подрядчик может так вот «запросто» угнать пароли всех доменных пользователей, которые логинились на сервер после последней перезагрузки?
Итого это еще один повод админам иметь две учетки: с правами админа везде, кроме контроллера и с правами админа на контроллере; или что еще делать-то? О.о
То есть получается, что вот например, я пригласил подрядчика поднять сервис на вин-сервере. Сервис большой, энтерпрайзный, и, как у них заведено, хочет работать от учетки с правами локал админа и от нее же устанавливаться.
То есть я дал подрядчику учетку с правами локал админа на сервере в домене.
И теперь подрядчик может так вот «запросто» угнать пароли всех доменных пользователей, которые логинились на сервер после последней перезагрузки?
Итого это еще один повод админам иметь две учетки: с правами админа везде, кроме контроллера и с правами админа на контроллере; или что еще делать-то? О.о
А админ может легко так ломиться в память ОС?
hiberfil.sys-то отключаем.
hiberfil.sys-то отключаем.
Админ может загрузить драйвер. Конечно, политика MS в том, чтобы не подписывать подозрительные драйвера, но нам поможет ReactOS, которая подписала драйвер для опен-сорсной утилиты Process Hacker, в которой масса возможностей по манипулированию чужой и системной памятью.
Простыня, поэтому спрячу
Можно и нужно запретить группе администраторов грузить драйвера, такое правило есть в локальных политиках безопасности в назначениях прав пользователю («Загрузка и выгрузка драйверов устройств»).
Пусть загрузкой драйверов занимается отдельный специальный пользователь. Это чрезвычайно опасное право, им кстати пользуется Unlocker.
Кроме этого администраторам можно запретить отладку программ (не менее опасное право) и включить им «Блокировать страницы в памяти» чтобы всё запущенное от администраторов никогда не выгружалось в файл подкачки (злоупотреблять выставляя всем пользователям запускающим жирные приложения не стоит, а то получится как с линуксом — №12309, может и не хватить терпения дождаться отвиса системы).
Однако администратор может поставить в планировщик задач или в качестве службы зловредное приложение в режиме запуска от СИСТЕМЫ (рут) и такой программе уже класть на ограничения администратора насколько я понимаю (впрочем в Windows есть свои тонкости).
По крайней мере пользователь СИСТЕМА в ФС может сбросить любые права и любому объекту назначить себя владельцем (даже не смотря на запрет ей это делать, хотя все остальные запреты на неё работают — можно запретить ей писать и читать и будет действительно отказано в доступе, но ничто не мешает ей разрешить себе это делать).
Поэтому запускать службы от пользователя системы очень опасно и для всяких таких энтерпрайз служб надо выделять отдельного пользователя ровно с теми правами которые ему фактически нужны (даже не те что он запрашивает — его можно и обмануть).
Обычным админам надо как-то перекрыть краники с возможность запуска от пользователя система, я сильно глубоко ещё не копался, но возможно такая настройка где-то запрятана.
Группе администраторов кстати ещё можно запретить становиться владельцем тех объектов где им явно не разрешено это делать, выставляется через «Смена владельцев файлов и других объектов», только это делать надо с умом, например мной замечено что без него не будет работать откат на точку восстановления, пока не вернёшь это право пользователю.
Вообще система безопасности Windows навороченная, гибкая и к сожалению сложная, очень хотелось бы в ReactOS сделать её более понятной и предсказуемой, но не уверен что этот день настанет своевременно.
Например в Windows есть права для процессов которыми почти никто не пользуется. Можно определить какой пользователь что сможет сделать с определённым процессом, разрешено ли ему его убивать, приостанавливать, менять владельца, читать разрешения, писать и/или читать память и ещё разное (прав много). Эти права есть и для потоков/нитей процессов. Этими правами можно покрутить через Process Explorer (наверное и через Process Hacker но я уже не помню) и менять автоматизировано через subinacl.
Я например не очень понимаю почему по умолчанию (сужу по 8.1 Pro) один пользователь может убивать процессы другого пользователя (даже админа, если приложение не запущено как админское, админские-то да не даёт), при этом админ (от приложения запущенно с админскими правами) не может даже понизить приоритет процесса другого пользователя, данные потоков тоже закрыты от него, хоть убивать конечно может. Но это я возможно где-то случайно изменил что-то, надо будет проверить на другой системе.
Права существуют и для служб, для DCOM-объектов, реестра само собой, прочих системных объектов (можно увидеть их через WinObj от Руссиновича).
Где-то как я понимаю в дебрях реестра скрыты многие права и поведение по умолчанию менеджера безопасности (чего недоступно из локальной/групповой политики безопасности), но пока ещё до них не добрался. Знаю что не все ветки реестра показываются админу, если залезть в реестр от пользователя системы появится ветка SAM где можно крутить учётками, в том числе встроенными.
Как-нибудь доразберусь и напишу статью о разных тонкостях в правах (вроде про это подробно и понятно новичкам ещё никто не писал), возможно заодно сравню с решениями Linux, где к сожалению с правами как по мне заметно хуже и только костыли кое-как спасают положение. Кстати Руссинович как-то предупреждал что права по умолчанию в Windows до сих пор недостаточно безопасны. Давно можно было сделать права более удобными и предсказуемыми, но почему-то воз и ныне там. Внутренний дизайн прав мне нравится, а вот конечное решение для пользователей нет, очень не хватает возможности видеть и задавать только нужные права отдельным процессам не плодя при этом для них отдельных пользователей.
Касаемо подписанного драйвера, что мешает админу запретить этот сертификат (или же оставить/добавить свои только необходимые) через хранилище сертификатов? Ну и поменять политику добавления по умолчанию. Я пока только начал с сертификатами разбираться, но где-то вычитал вскользь что можно запретить совсем их добавление.
Пусть загрузкой драйверов занимается отдельный специальный пользователь. Это чрезвычайно опасное право, им кстати пользуется Unlocker.
Кроме этого администраторам можно запретить отладку программ (не менее опасное право) и включить им «Блокировать страницы в памяти» чтобы всё запущенное от администраторов никогда не выгружалось в файл подкачки (злоупотреблять выставляя всем пользователям запускающим жирные приложения не стоит, а то получится как с линуксом — №12309, может и не хватить терпения дождаться отвиса системы).
Однако администратор может поставить в планировщик задач или в качестве службы зловредное приложение в режиме запуска от СИСТЕМЫ (рут) и такой программе уже класть на ограничения администратора насколько я понимаю (впрочем в Windows есть свои тонкости).
По крайней мере пользователь СИСТЕМА в ФС может сбросить любые права и любому объекту назначить себя владельцем (даже не смотря на запрет ей это делать, хотя все остальные запреты на неё работают — можно запретить ей писать и читать и будет действительно отказано в доступе, но ничто не мешает ей разрешить себе это делать).
Поэтому запускать службы от пользователя системы очень опасно и для всяких таких энтерпрайз служб надо выделять отдельного пользователя ровно с теми правами которые ему фактически нужны (даже не те что он запрашивает — его можно и обмануть).
Обычным админам надо как-то перекрыть краники с возможность запуска от пользователя система, я сильно глубоко ещё не копался, но возможно такая настройка где-то запрятана.
Группе администраторов кстати ещё можно запретить становиться владельцем тех объектов где им явно не разрешено это делать, выставляется через «Смена владельцев файлов и других объектов», только это делать надо с умом, например мной замечено что без него не будет работать откат на точку восстановления, пока не вернёшь это право пользователю.
Вообще система безопасности Windows навороченная, гибкая и к сожалению сложная, очень хотелось бы в ReactOS сделать её более понятной и предсказуемой, но не уверен что этот день настанет своевременно.
Например в Windows есть права для процессов которыми почти никто не пользуется. Можно определить какой пользователь что сможет сделать с определённым процессом, разрешено ли ему его убивать, приостанавливать, менять владельца, читать разрешения, писать и/или читать память и ещё разное (прав много). Эти права есть и для потоков/нитей процессов. Этими правами можно покрутить через Process Explorer (наверное и через Process Hacker но я уже не помню) и менять автоматизировано через subinacl.
Я например не очень понимаю почему по умолчанию (сужу по 8.1 Pro) один пользователь может убивать процессы другого пользователя (даже админа, если приложение не запущено как админское, админские-то да не даёт), при этом админ (от приложения запущенно с админскими правами) не может даже понизить приоритет процесса другого пользователя, данные потоков тоже закрыты от него, хоть убивать конечно может. Но это я возможно где-то случайно изменил что-то, надо будет проверить на другой системе.
Права существуют и для служб, для DCOM-объектов, реестра само собой, прочих системных объектов (можно увидеть их через WinObj от Руссиновича).
Где-то как я понимаю в дебрях реестра скрыты многие права и поведение по умолчанию менеджера безопасности (чего недоступно из локальной/групповой политики безопасности), но пока ещё до них не добрался. Знаю что не все ветки реестра показываются админу, если залезть в реестр от пользователя системы появится ветка SAM где можно крутить учётками, в том числе встроенными.
Как-нибудь доразберусь и напишу статью о разных тонкостях в правах (вроде про это подробно и понятно новичкам ещё никто не писал), возможно заодно сравню с решениями Linux, где к сожалению с правами как по мне заметно хуже и только костыли кое-как спасают положение. Кстати Руссинович как-то предупреждал что права по умолчанию в Windows до сих пор недостаточно безопасны. Давно можно было сделать права более удобными и предсказуемыми, но почему-то воз и ныне там. Внутренний дизайн прав мне нравится, а вот конечное решение для пользователей нет, очень не хватает возможности видеть и задавать только нужные права отдельным процессам не плодя при этом для них отдельных пользователей.
Касаемо подписанного драйвера, что мешает админу запретить этот сертификат (или же оставить/добавить свои только необходимые) через хранилище сертификатов? Ну и поменять политику добавления по умолчанию. Я пока только начал с сертификатами разбираться, но где-то вычитал вскользь что можно запретить совсем их добавление.
Касаемо подписанного драйвера, что мешает админу запретить этот сертификат (или же оставить/добавить свои только необходимые)
Идея интересная, но для запрета одного сертификата центральный админ должен про него узнать. Запрет загрузки драйверов локальный администратор сервера так или иначе может обойти. Например, подменив бинарник ненужного драйвера своим и дождавшись перезагрузки.
но для запрета одного сертификата центральный админ должен про него узнатьТак пусть оставит только самые необходимые и если надо добавит свой сертификат которым подпишет требуемые приложения. Ну и для надёжности запретит запуск приложений без цифровых подписей.
Например, подменив бинарник ненужного драйвера своим и дождавшись перезагрузки.А на что права ФС? Можно запретить подменять файлы драйверов (да и вообще туда писать) админам и запретить им брать на себя права любого объекта, кроме явно разрешённых. Помимо этого я встречал групповые политики связанные с драйверами, но не помню конретики, там может что-то дополнительно поможет.
А чтобы админ себе не вернул это право через локальную политику надо глянуть (через тот же procmon) куда лезет mmc.exe и просто задать нужным записям запрет изменения обычным админам. Только тут нужно быть осторожным (если предварительно ещё и обрубили краник запуска служб от системы), а то так можно и создать чёрный ящик, а если ещё диск зашифрован, без уязвимости сделать ничего не получится.
На сервере гибернация не используется. По вполне понятным причинам.
Электричество вырубили, ИБП умирают — есть 2 варианта — «заснуть» или «удавиться». По появлению питания BIOS/UPS разбудит машину сам. Если сервер большой (виртуальный) или их несколько в цепочке — время загрузки будет не коротким.
Боюсь, вариант только выключать сервера. Я лично не ручаюсь за то, как поведет себя месиво гостевых систем в кластере виртуализации с использованием SAN сети. Я думаю, получим bootstorm, и как отреагирует vCenter, когда heartbeat от неуспевших загрузиться виртуалок не пройдет, хосты начинут перехватывать гостевые системы друг у друга.
В случае корректного выключения, сначала по классике стартуют СХД, затем хосты с инфраструктурой авторизации, а дальше уже все остальное в запланированном порядке.
Плюс с большинстве случаев гибернация на серверах недоступна :) там просто нет такого пункта.
В случае корректного выключения, сначала по классике стартуют СХД, затем хосты с инфраструктурой авторизации, а дальше уже все остальное в запланированном порядке.
Плюс с большинстве случаев гибернация на серверах недоступна :) там просто нет такого пункта.
Виртуалки бывают разные. И опция сна не обязательно должна быть в самой гостевой ОС: принудительно делается из материнской.
Живой пример: ESXi 5.5 + 4 VM (Ubuntu x64, 2 x KeriOS, FreeBSD)
Еще один: Win2k3 + 3 VM Win98 (очень старое железо и дрова писались еще под NT 3.1)
СХД в данных случаях вообще не нужны — достаточно встроенных накопителей (что под линукс — до 20 ГБ, что под 98-ю — до 2 ГБ)
Контроллер домена для них вообще не сдался (98-й на него просто накашлять — видит все и вся — еще не встроили кучу глупых ограничений на путешествия по сетке, а у Линуха свои тараканы)
Живой пример: ESXi 5.5 + 4 VM (Ubuntu x64, 2 x KeriOS, FreeBSD)
Еще один: Win2k3 + 3 VM Win98 (очень старое железо и дрова писались еще под NT 3.1)
СХД в данных случаях вообще не нужны — достаточно встроенных накопителей (что под линукс — до 20 ГБ, что под 98-ю — до 2 ГБ)
Контроллер домена для них вообще не сдался (98-й на него просто накашлять — видит все и вся — еще не встроили кучу глупых ограничений на путешествия по сетке, а у Линуха свои тараканы)
Оу. Кхм. Кхе. В указанной конфигурации это несомненно допустимо :) у нас с вами просто очень разного уровня проблемы :)
Если у подрядчика админские права, он (сюрприз!) и без этой «фичи» может слить с вашего сервера практически всё, что угодно, и бороться с этим тяжело. Не подрядчиков надо бояться. :)
Как-то, простите, не ново.
Windows Memory toolkit free edition;
Как указали выше — не работает с x64, и видимо не поддерживает системы выше 8, у меня на win 10 TP выдает:
Initializing memory descriptors… Failed.
Cannot open file. Please check if the file is not being used.
Есть какие-то варианты, кроме как пробовать на x32 системах?
Как указали выше — не работает с x64, и видимо не поддерживает системы выше 8, у меня на win 10 TP выдает:
Initializing memory descriptors… Failed.
Cannot open file. Please check if the file is not being used.
Есть какие-то варианты, кроме как пробовать на x32 системах?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Восстанавливаем локальные и доменные пароли из hiberfil.sys