--}}
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем

Возможно ли админу запустить программу "от имени" пользователя, не зная его пароля?

Сисадминское
608
45
С друзьями на NN.RU
В социальных сетях
Поделиться
Tassadar
22.02.2012
Здравствуйте, господа.
Подскажите, может ли администратор win2008 домена запустить на контроллере домена программу от имени другого пользователя, не зная пароля этого пользователя? Не сбрасывая пароль пользователя.
Что-то типа "запуск от имени", а вместо пароля его кэш подсунуть, или какой-нибудь керберосовский актуальный тикет этого пользователя?
Maksa
22.02.2012
средствами api и через PowerShell как то можно надо читать документацию
Нельзя.
alsarin
23.02.2012
можно :)
Tassadar писал(а)
домена запустить на контроллере домена программу от имени другого пользователя, не зная пароля этого пользователя? Не сбрасывая пароль пользователя. <br> Что-то ..

Нельзя. "Керберосовский актуальный тикет" для запуска программы не используется. "Кэш пароля" (правильно - хэш) ты штатно не выташишь - раз, и не подсунешь - два.
alsarin
23.02.2012
подсунешь: psexec \\remotehost -u <username> -p <хэш пароля> <приложение>
www.windowsecurity.com/articles/PsExec-Nasty-Things-It-Can-Do.html?printversion

Осталось только как-то добыть хэш. Опять же есть описанные варианты, но что из этого работает, а что нет не проверял: www.windowsecurity.com/artic...tml?printversio
админ домена особо не парясь может узнать пароль.
вот только нормальный админ этого делать не станет.
Квартет9 писал(а)
админ домена особо не парясь может узнать пароль.

Только если домен ставил ламерский админ. Фишка с дампом и расшифровкой хэша прокатывала лет, этак, 5 - 7 назад. Лупхт уже не торт, поверьте.
зачем такие сложности?
можно подсунуть нужный софт, камеру подвесить(если место стационарное) и т.д. и т.п. в конце концов внимательный осмотр рабочего места тоже многое может дать.
Tassadar
22.02.2012
Не, камеру не подвесить. Вернее подвесить можно у пользователя и узнать его пароль, да я собственно у него и спросить могу. Но у меня вопрос про контроллер домена, можно ли там запустить программу от его имени, имея полный (удаленный) доступ к контроллеру, или это вообще сделать нельзя. То есть, если всё же таким образом была запущена программа, то железно пароль пользователя знали, или нет?
Tassadar писал(а)
...

Похоже, вы задачу не с того конца решаете.
Все, что сделано от имени конкретной учетки - сделано от имени того пользователя, которому она была выдана. И стало быть вся полнота ответственности на нем.
Tassadar
22.02.2012
Одна из таких учеток, из-под которой запуск произошел -моя. Вот я и копаю - знают пароль, или не обязательно?
Пароль знать надо обязательно. Никакие хэши-кэши и прочие тикеты не помогут. Админу вытащить пароль теоретически можно.
Tassadar
22.02.2012
Ок, спасибо. Более-менее картина обрисовалась.
Я, пожалуй, попробую попортить "обрисовавшуюся" картину.

Запустить программу от вашего имени, не зная пароля, очень легко.
ДядяДима писал(а)
апустить программу от вашего имени, не зная пароля, очень легко. ...

просветите?
Tassadar
22.02.2012
Пояснения будут?
В каком направлении смотрть?
Товарищ имеет в виду случай, когда в адресном пространстве процесса, запущенного от твоего имени и с твоего ведома, появляется "левый" дочерний процесс, который чего-то там "химичит" (на манер внедрения трояна через браузер). Но это не твой случай.
Вопрос был такой - "может ли администратор запустить программу от имени другого пользователя, не зная пароля этого пользователя? Не сбрасывая пароль пользователя."
Да, можно.
Варианты:
1) "Пользователь" выполнил вход на компьютер, "администратор" может
- "украсть" токен пользователя и запустить процесс от его имени ОpenProcessToken\SetTokenInformation\CreateProcessAsUser
- получить хэш пароля пользователя, из памяти lsass
- элементарно добавив в автозапуск запуск программы, "администратор" добьется выполнения ее от имени "пользователя" не зная пароль.
(а эта программа может, например, создать задание на сервере от имени пользователя)

2) "Администратор" знает хэш пароля пользователя, используя его он выполняет задачу на сервере

Таким образом, факт запуска "администратором" процесса от учетки "пользователя" не означает, что его пароль известен.
Дядь Дим, ну вы уж задачу-то читайте внимательно - "Подскажите, может ли администратор win2008 домена запустить на контроллере домена программу от имени другого пользователя, не зная пароля этого пользователя? "
Вот думаю я, думаю - хоть убей не могу придумать, что бы юзер домена логинился на контроллере.
Я задачу прочитал...
Вот скажите, если вы, залогинитесь на любом компьютере, входящем в домен, используя доменную учетную запись, у вас хэш пароля будет отличным от хэша этого же пароля, но при условиви вашего входа на контроллер домена?

Если вы залогинились на компьютер домена, используя доменную учетную запись, вы не можете запустить программу или обратиться к ресурсам контроллера домена?

Или вы имеете в виду, что доступ к КД должен был быть только с консоли?

Я что-то не пойму...
ДядяДима писал(а)
Вот скажите, если вы, залогинитесь на любом компьютере, входящем в домен, используя доменную учетную запись, у вас хэш пароля будет отличным от хэша этого же пароля, но при условиви вашего входа на контроллер домена?

Да господь с вами! Конечно же, РАЗНЫЙ.
Я понимаю, что в М$ дураки сидят, но не настолько же. Почитайте как любой challenge-response протокол работает, например, тот же NTLM.
тестовый юзер писал(а)
Да господь с вами! Конечно же, РАЗНЫЙ.
Я понимаю, что в М$ дураки сидят, но не настолько же. Почитайте как любой challenge-response протокол работает, например, тот же NTLM.


Вы сами то читали? Я вот например уверен, что хэш пароля ОДИНАКОВЫЙ.
Так как НТЛМ аутентификация работает примерно так:
Юзер ввел "пароль"
нтхэш=хэш("пароль")
лмхэш=хэш("пароль")
Сервер -> нам "челлендж"
Ответ1 = дес("нтхэш", "челленж")
Ответ2 = дес("лмхэш", "челлендж")
Мы -> Сервер Ответ = Ответ1 хор Ответ 2
Сервер -> нам "Все ОК!"
Мы:
Сохраним на всякий случай хэши!
А то вдруг надо будет при разлочке проверить пароль, или там КД недоступен.

Сохраняем хэши в памяти lsasss
Сохраняем хэши в реестре
Куда бы еще запихнуть??? А, еще по сети передадим на всякий случай!

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

Какие ваши возражения!?
Первое: ЛМ-хэш и "чистый" NT-хэши из NTLMv1 давно запрещены по-дефолту, не используются и обсуждать их не имеет смысла.
Второе: что означает фраза "нтхэш=хэш("пароль")" ?
В качестве хэш-функции в алгоритме NTLMv2 используется функция одностороннего преобразования HMAC-MD5, которая имеет на входе ДВА аргумента. Одним аргументом является преобразованный пароль, вторым некий случайно сгенерированный в момент входа blob. Отсюда уже видно, что итоговое значение хэша зависит от blob, который генерируется каждый раз заново.
Ну и по поводу cached logon credentials: хэша пароля там нет. Там лежит, грубо говоря, некий "хэш от хэша". Последняя тулза (hashpipe), которая могла это достать, прекратила свое развитие на NT4\2К и под всем что выше уже не работает.
тестовый юзер писал(а)
Первое: ЛМ-хэш и "чистый" NT-хэши из NTLMv1 давно запрещены по-дефолту, не используются и обсуждать их не имеет смысла. <br> Первое: ЛМ-хэш и "чистый" NT-хэши из NTLMv1 давно запрещены по-дефолту, не используются и обсуждать их не имеет смысла.
Второе: что означает фраза "нтхэш=хэш("пароль")" ?
В качестве хэш-функции в алгоритме NTLMv2 используется функция одностороннего преобразования HMAC-MD5, которая имеет на входе ДВА аргумента. Одним аргументом является преобразованный пароль, вторым некий случайно сгенерированный в момент входа blob. Отсюда уже видно, что итоговое значение хэша зависит от blob, который генерируется каждый раз заново.

С первым я частично согласен. ЛМ хэш забудем.
Второе.
Что хранится в САМ или в АД?
Насколько я знаю, хранится там NTHash.
И в момент, когда "в качестве хэш-функции в алгоритме NTLMv2 используется функция одностороннего преобразования HMAC-MD5, которая имеет 2 аргумента" в качестве первого аргумента используется именно NTHash.
Т.о., зная NTHash мы можем провести аутентификацю по NTLMv2:
получаем ваш блоб, хешируем все это и отправляем серверу.
ДядяДима писал(а)
Что хранится в САМ или в АД?

1) База САМ - это кусок реестра. Там действительно лежит НТ-хэш. Если админ не предпринял мер по защите в виде дополнительного шифрования(syskey) он действительно может этот хэш вытащить. Проблема в том, что там лежит хэш ЛОКАЛЬНОЙ учетки, заходить с которой на КД бесполезно :))))
А так - да, может вытащить.
2) Про хранение паролей в АД на базе 2К8, если честно, не в курсе.

Апд. Если в п.1) про cached logon credentials - там я не знаю что. Вот Владимир Дубровин ака 3APA3A в своем известном исследовании утверждает, что там прямых хэшей MD4 нет.
У меня просто нет больше слов.
Я использовал на практике описанные мной способы (только в исследовательских целях и для проверки защищенности своей системы), у меня они работали.

В сэм лежит nt-hash он же md4(pass)
В кэшед лежит md4(nt-hash, username)

Зная username,domain,nt-hash можно авторизоваться на контроллере.
ДядяДима писал(а)
В сэм лежит nt-hash он же md4(pass)

Да с этим никто и не спорит. Только он от локальной учетки - что вы с ней будете на контроллере домена делать?

В кэшед лежит md4(nt-hash, username)

А вот тут поподробнее.
тестовый юзер писал(а)
подробнее

openwall.info/wiki/john/MSCash
Вообще, давайте вернемся к нашим баранам. Дано: контроллер 2К8 + известный NT-хэш от учетки. Как вы собираетесь запустить от имени этой учетки таск? Стандартная оснастка (вроде run as или планировщика задач) потребуют от вас ввода пароля в явном виде. Вообще, LSA потребует от вас пароль в явном виде. Т.е., остается задача реверса хэша. Далее. Мы со всеми этими challenge-response упустили одну вещь: аутентификация в домене происходит по керберосу.
1) Использовать нестандартную (модифицированный psexec, позволяющий вводить не пароль, а хэш, ряд других инструментов).

2) А что, как вы думаете, использует Керберос для шифрования таймштампа при получении тикета? NThash в чистом виде.
ДядяДима писал(а)
2) А что, как вы думаете, использует Керберос для шифрования таймштампа при получении тикета? NThash в чистом виде.

Если ориентироваться на rfc, то сильно в этом сомневаюсь:
Encryption and Checksum Methods
The following encryption and checksum mechanisms MUST be supported: Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Checksums: HMAC-SHA1-96-AES256 [RFC3962]
Implementations SHOULD support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals known to also support them. The following mechanisms from [RFC3961] and [RFC3962] SHOULD be supported:
Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

Еще: "Как уже отмечалось, долговременный ключ пользователя создается на основе его пароля. Когда <пользователь> проходит регистрацию, клиент Kerberos, установленный на его рабочей станции, пропускает указанный пользователем пароль через функцию хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате формируется криптографический ключ."
www.oszone.net/4188_2/Kerberos

Учитывая интероперабельность микрософтовского KDC c другими платформами, предположу, что там все же НЕ NT-хэш.
Хотя, с другой стороны, если мы можем вытащить ключ, нам уже пофиг, каким образом он получен.
<quote>тестовый юзер писал(а)
Про хранение паролей в АД на базе 2К8
</quote>

The users′ password hash is stored in the Active Directory on a user object in the unicodePwd attribute. Instead of storing your user account password in clear-text, Windows generates and stores user account passwords by using two different password representations, generally known as ″hashes.″ When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory.

LM & NT Hashes are used to store password in both active directory and local computers, this model gives a huge compatibility potential but at the same time it gives a huge risk factor in terms of weak encrypted passwords just like you describe it.
It is not possible to disable the storage of NT hashes in Windows today!
Это достаточно старая статья. Хотя, с другой стороны, есть политика "Хранить пароли используя обратимое шифрование", упрощающая задачу.
.
Пароль знать не надо.
Квартет9 писал(а)
зачем такие сложности? <br> можно подсунуть нужный софт,

Например?
punto switcher
Кхм. А ничего, что я пароль пользователя набираю задолго ДО того, как пунто свитчер вообще запустится?
а если ево сервисом стартануть?
А толку? Он из окна логина все равно ничего не вытащит.
я предложил один из множества вариантов. имея неограниченный доступ к компу админ ограничен только своей совестью...
Квартет9 писал(а)
я предложил один из множества вариантов.

Ваш вариант неработоспособен.

имея неограниченный доступ к компу админ ограничен только своей совестью... ...

... а также своей квалификацией, что еще важнее. Теоретически пасворд вытащить можно, но придется сереьзно подломать процесс winlogon. Сильно нетривиальная задача.
Кстати, начав просматривать новости по теме, в связи с нашим спором с тестовый юзер, обнаружил что в паблике появилась утилита позволяющая получить, как вы и говорили, "керберосовский актуальный тикет этого пользователя", TGT и на основе него создавать различные тикеты для доступа к сервисам.
Tassadar
23.02.2012
Да уж. Битва титанов. Внушает.
Для себя массу нового почерпнул, даже скорее разложил по полочкам.
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем
Последние темы форумов
Оперативная память Corsair XMS3 CMX8GX3M2A1600C9

Оперативная память Corsair XMS3 CMX8GX3M2A1600C9 Отправка в регионы после оплаты. Продаются сразу обе. Цена за обе 2000 руб....
Цена: 1 000 руб.

Принтер лазерный HEWLETT PACKARD HP-6L

Принтер лазерный HEWLETT PACKARD HP-6L Отправка в регионы после оплаты. 3штуки БУ. Внешний вид из магазина простояли на складе...
Цена: 4 500 руб.

Материнские платы на запчасти и не только

Материнские платы на запчасти и не только Материнские платы и другие комплектующие Отправка в регионы после оплаты. Транспортной...
Цена: 3 000 руб.

Сетевой фильтр APC Surge Arrest

Сетевой фильтр APC Surge Arrest для радиолюбителя.и не только Отправка в регионы после оплаты. ЦЕНА 3000 руб. В рабочем состоянии....
Цена: 3 000 руб.