![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Описание китайской атаки на Гугль на слешдоте.
Вкратце:
1. Через дыру в браузере получают локальный доступ к машине
2. Через pass-hash получают права домен-администратора
3. Профит!
Пункт 2 меня несколько поразил - я не знал, что в виндовсе дела так плохо (т.е. что Local Admin настолько несложно превратить в Domain Admin).
Tags:
no subject
Касаемо хэшей, да, хранит, и это была осознанная необходимость с тех древних времен, когда domain controller в сети Lan manager выбирался голосованием:). Не знаю про большинство конфигураций, но алертов по этому поводу была масса, Висту даже сдлеали с NTLMv2 only по умолчанию. Многие корпоративные админы изначально избегали всей этой дырявой LM аутентикации и использовали Kerberos или 3d-party auth.модули.
И firewall вообще-то должен не допустить зомбирования внутрикорпоративного компьютера, это-то элементарно сделать.
no subject
The default in Windows Vista is "Send NTLMv2 responses only"; however, in
Windows 7 this policy is not defined.
Однако, если я правильно понимаю, send NTLMv2 only не обязательно означает refuse NTLM (иначе там не было бы отдельного пункта с refuse). T.e. если каким-то образом добыть NTLM hash (сконфигурировать клиент на NTLM?), то им потом можно будет воспользоваться.
Файрволл не работает против пункта 1 (дыра в браузере) - особенно это касается 3-rd party plugins типа PDF, flash и т.п. - которые обезопасить значительно сложнее.
no subject
Да, это уже зависит от настройки DC или AD, но добыть NTLM hash на клиенте уже не получится.
Файрволл не работает против пункта 1 (дыра в браузере)
Не работает, но после того, как malware утвердился в жертве и сумел добиться rights escalation, он должен дать злоумышленнику контроль для того, чтобы тот полазил по интересным местам и стянул чего искал. Как это сделать без incoming connection я не знаю.
no subject
То же самое можно делать, например, через IRC - при этом преимущество в том, что никакой прямой связи между контролируемой машиной и контроллером нет, всё идёт через IRC-server - т.е. вычислить, кто именно командовал, пост-фактум практически невозможно, да и в процессе потребует нетривиальных усилий.
no subject
no subject
no subject
А вообще covert channels миллион, я описал самые простые, а настоящие суровые парни делаю cover channels хоть через DNS, хоть через неопределённые биты в сетевых пакетах и прочий хардкор. Закрыть или отловить такой канал, не зная, куда смотреть, и не отключая весь офис от сети напрочь - практически невозможно. Конечно, пропускная способность у него будет не очень, но куда нам торопиться? Ну своруем мы документы не сегодня, а через неделю - и ладненько. Всё равно ботов никто за ручку не держит - их миллион, а хозяева одни.
no subject
no subject
Я неоднократно наблюдал такую картину: стоит у меня XP SP2 или SP3 (как я понимаю, они используют NTLMv2). Домен контроллер отвалился. Я пытаюсь залогиниться на станцию и, если я на эту станцию раньше логинился, она радостно принимает у меня логин, правда бурчит про то, что используется cached credentials. И потом, даже еще до того, как домен контроллер поднялся, мне доступны сетевые ресурсы. То есть cached credentials вполне хороши для авторизации на member серверах домена. Как это совместить с вашим утверждением, что добыть NTLM hash на клиенте не получится???
no subject
Кстати, не факт. XP умеет NTLMv2, но все зависит от настройки сети.
Как это совместить с вашим утверждением, что добыть NTLM hash на клиенте не получится???
Добыть получится, делов-то - registry прочитать, только что с этим хэшем потом делать? По хэшу пароль не подобрать (если мы отложим пока в сторону precomputed hash атаки), поэтому дыра в NTLM была в том, что хэш был статическим. Скомпрометировав кэш (узнав его при помощи другой дыры в окнах) я могу использовать его вместо пароля. Достаточно усложнить протокол всего лишь на одну динамическую величину (timestamp, отдельный chanllegne-response, каждый раз меняющий хэш), чтобы с таким трудом обнаруженный хэш оказался бесполезным.
no subject
no subject
Да, стандартные инструменты для работы с AD хэш вместо пароля не примут. Но вот сформировать пакетики, которые примет сервер, как показано в той же статье, вполне можно. И вытащить таким образом содержимое AD.
Как я понимаю, все изменения в ntlmv2 сводятся к тому, что хэш больше не передается по сети открытым текстом. Но все равно при проверке challenge/response сервер опирается на тот же самый хэш (у него же нет плэйнтекстового пароля), поэтому все изменения, внесенные временными штампами, должны однозначно восстанавливаться на основе этого значения хэша.