взлом Гугля

[stas]

Описание китайской атаки на Гугль на слешдоте.

Вкратце:
1. Через дыру в браузере получают локальный доступ к машине
2. Через pass-hash получают права домен-администратора
3. Профит!

Пункт 2 меня несколько поразил - я не знал, что в виндовсе дела так плохо (т.е. что Local Admin настолько несложно превратить в Domain Admin).

Comments

[digest.livejournal.com]

А причем здесь Гугль? (Казалось бы, причем здесь лужков?)
Насчет атаки -- атаки на домены с LM/NTLM аутентикацией лишь демонстрируют тупость, неповоротливость и низкий профессионализм корпоративных админов. Но такие наверное и другие эксплойты годами не закрывают.

[pargentum.livejournal.com]

pass-hash, как я понимаю, нормально работает и против AD. Так что ваша фраза имеет смысл только если под "тупостью, неповоротливостью и низким профессионализмом" вы понимаете сам по себе факт использования Windows.

Как я понимаю, корни проблемы в
1. Большой площади атаки типичной рабочей станции Windows и обусловленной этим легкости получения прав локального администратора.
2. Любви Windows к кэшированию разнообразных credentials и недооценке разработчиками Microsoft того факта, что локальному администратору все эти кэши так или иначе доступны.
3. В том, что во всех редакциях протокола SMB хэш пароля так же хорош, как и сам пароль, поэтому утечка хэша полностью равносильна утечке пароля.

То есть дело не столько в неповоротливости админов, сколько в ошибках в ДНК разработчиков Windows.

[digest.livejournal.com]

Насколько я понимаю, NTLMv2 не подвержена указанным атакам, т.к. использует не только НЕфиксированный server challenge, но еще и nonce клиента, т.е. хранимый хэш действителен только для данного клиента и только в данную сессию.
Уязвимостей в LM и NTLM было столько, что все порядочные администраторы должны были давно от них отказаться и использовать "NTLMv2 only" или цербера.

>> SMB хэш пароля так же хорош
Вы еще вспомните *никсовый crypt() которым шифровались все пароли в /etc/passwd до совсем таки недавних времен :)

>>в ошибках в ДНК разработчиков Windows.
Да, да. Это объясняет все уязвимости в мире. Саксъ и масдай, безусловно.

[stas]

Притом, что, как написано в TFA, этот метод использовали для взлома google.cn.

[digest.livejournal.com]

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

[stas]

Я думаю, правительство тут притом, что Гугль утверждает, что взлом был заказан правительством и данные, которые искали, искали по заказу правительства.
А в самом взломе, технически, конечно, ничего "правительственного" нет. Хотя я, например, был не в курсе, что виндовс хранит хэш любого эккаунта, который когда-либо логинился на машину, и может использовать этот хэш в качестве пароля, если AD разрешает доступ с такими credentials (а большинство конфигураций AD в реале разрешают, потому что большинство админов не в курсе, что это надо специально запрещать).

[kolmanovsky.livejournal.com]

> "тупостью, неповоротливостью и низким профессионализмом"
> вы понимаете сам по себе факт использования Windows

Ну, вобщем, где-то... Я бы не утверждал так грубо и категорично, но... Да!

За все годы администрирования LUW, только Windows и подламывали. Это при том, что я , мягко говоря, не страдаю сисадминовской параноей и не посвящаю свою жизнь борьбе с потенциальным взломом.

[digest.livejournal.com]

А, да, вспомнил. Там говорилось про какие-то почтовые ящики диссидентов.
Касаемо хэшей, да, хранит, и это была осознанная необходимость с тех древних времен, когда domain controller в сети Lan manager выбирался голосованием:). Не знаю про большинство конфигураций, но алертов по этому поводу была масса, Висту даже сдлеали с NTLMv2 only по умолчанию. Многие корпоративные админы изначально избегали всей этой дырявой LM аутентикации и использовали Kerberos или 3d-party auth.модули.

И firewall вообще-то должен не допустить зомбирования внутрикорпоративного компьютера, это-то элементарно сделать.

[stas]

В статье пишут:
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 и т.п. - которые обезопасить значительно сложнее.

[stas]

Справедливости ради, NFS с точки зрения безопасности тоже не сахар... Помню в золотые студенческие годы университетская сеть была под NFS, некоторые продвинутые студенты извлекали много веселья из факта, что для доступа к счёту препода надо всего лишь прописать у себя на PC счёт с таким же UID и присоединиться к университетской сети... Администраторы извлекали из этого факта гораздо меньше веселья.

[kolmanovsky.livejournal.com]

Ну, NFS ни с какой точки зрения не сахар. Может даже, правильная расшифровка "Not F...ing Sugar" :)

Но на самом деле, думается мне, что ваши университетские админы не самым лучшим способом сконфигурировали NFS. У нас это стандартная заморочка - ты можешь иметь какой хочешь UID, но доступа к чужим данным не получишь - сервер на котором живет NFS никому не верит. А то у меня все пользователи на своих тестовых серверах имеют достур root'а... Мне только пары тысяч root'ов на основных серверах не хватало...

[digest.livejournal.com]

не обязательно означает refuse NTLM (иначе там не было бы отдельного пункта с refuse). T.e. если каким-то образом добыть NTLM hash

Да, это уже зависит от настройки DC или AD, но добыть NTLM hash на клиенте уже не получится.

Файрволл не работает против пункта 1 (дыра в браузере)

Не работает, но после того, как malware утвердился в жертве и сумел добиться rights escalation, он должен дать злоумышленнику контроль для того, чтобы тот полазил по интересным местам и стянул чего искал. Как это сделать без incoming connection я не знаю.

[stas]

root как раз отсекать NFS хорошо умеет, а вот с остальными юзерами было похуже. Впрочем, это было-то 15 лет назад, сейчас, надеюсь, всё-же получше.

[stas]

Элементарно, Ватсон - все ботнеты с этим справляются легко. Посылается пакет на сервер sunhuivchai.cn, в котором написано "я новый бот с ID=X, жду инструкций". Дальше сгружается страница http://sunhuivchai.cn/bots-instructions/ID=X, в которой будет написано, куда этому боту идти и что делать. Никаких incoming connections не надо.
То же самое можно делать, например, через IRC - при этом преимущество в том, что никакой прямой связи между контролируемой машиной и контроллером нет, всё идёт через IRC-server - т.е. вычислить, кто именно командовал, пост-фактум практически невозможно, да и в процессе потребует нетривиальных усилий.

[pargentum.livejournal.com]

NFS 1/2 - да.
NFS3/TCP + керберос или NFS4 - там уже далеко не все так ужасно.

[pargentum.livejournal.com]

Как я понимаю, если взломщик получил локального администратора, он может распотрошить не только хэш паролей, но и nonce клиента.

AD использует цербера, ну и что? Если я церберовские тикеты получаю на основе того же самого SMB hash - задача сводится к предыдущей.

Проблема не в алгоритме вычисления хэша. Проблема в том, что SMB - в том числе, как я понимаю, и NTLMv2 - использует в качестве разделяемого секрета именно хэш, а не собственно пароль. Поэтому хэш-функция не добавляет к безопасности почти ничего, она только несколько затрудняет определение пароля путем прослушивания сети. Но при доступе к хэшам - ...

[pargentum.livejournal.com]

Подождите, вот с этого момента подробнее.

Я неоднократно наблюдал такую картину: стоит у меня XP SP2 или SP3 (как я понимаю, они используют NTLMv2). Домен контроллер отвалился. Я пытаюсь залогиниться на станцию и, если я на эту станцию раньше логинился, она радостно принимает у меня логин, правда бурчит про то, что используется cached credentials. И потом, даже еще до того, как домен контроллер поднялся, мне доступны сетевые ресурсы. То есть cached credentials вполне хороши для авторизации на member серверах домена. Как это совместить с вашим утверждением, что добыть NTLM hash на клиенте не получится???

[digest.livejournal.com]

Прикольно, ботнет поллингом :) Действительно, сгодится для одноразовой немедленной акции, хотя для законспирированного долговременного подполья не пойдет: слишком часто за инструкциями будет стучаться.

[digest.livejournal.com]

тикеты получаю на основе того же самого SMB hash

Дык, никто не заставляет, более того -- не советует использовать SMB hash. Используйте любой из десятков EAP-XXXX на выбор, или любую имплементацию Radius-сервера, если корпорация разбросана по разным континентам.

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

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

[digest.livejournal.com]

(как я понимаю, они используют NTLMv2).

Кстати, не факт. XP умеет NTLMv2, но все зависит от настройки сети.

Как это совместить с вашим утверждением, что добыть NTLM hash на клиенте не получится???

Добыть получится, делов-то - registry прочитать, только что с этим хэшем потом делать? По хэшу пароль не подобрать (если мы отложим пока в сторону precomputed hash атаки), поэтому дыра в NTLM была в том, что хэш был статическим. Скомпрометировав кэш (узнав его при помощи другой дыры в окнах) я могу использовать его вместо пароля. Достаточно усложнить протокол всего лишь на одну динамическую величину (timestamp, отдельный chanllegne-response, каждый раз меняющий хэш), чтобы с таким трудом обнаруженный хэш оказался бесполезным.

[tejblum.livejournal.com]

Зачем же часто? Раз в сутки, или хотя бы в несколько часов, вполне достаточно, и как отличать такие HTTP-запросы от обычного веб-серфинга, не очень понятно.

[stas]

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

А вообще covert channels миллион, я описал самые простые, а настоящие суровые парни делаю cover channels хоть через DNS, хоть через неопределённые биты в сетевых пакетах и прочий хардкор. Закрыть или отловить такой канал, не зная, куда смотреть, и не отключая весь офис от сети напрочь - практически невозможно. Конечно, пропускная способность у него будет не очень, но куда нам торопиться? Ну своруем мы документы не сегодня, а через неделю - и ладненько. Всё равно ботов никто за ручку не держит - их миллион, а хозяева одни.

[stas]

Очевидно, если хэш работает на мемберах домена - что, скорее всего, значит, что они не залочены по последнему слову техники, и что таких чуть менее, чем 95% - то практически профит в этой сети уже достигнут.

[pargentum.livejournal.com]

Вам же хозяин журнала целую статью выложил про то, что можно делать с хэшем пароля.
Да, стандартные инструменты для работы с AD хэш вместо пароля не примут. Но вот сформировать пакетики, которые примет сервер, как показано в той же статье, вполне можно. И вытащить таким образом содержимое AD.
Как я понимаю, все изменения в ntlmv2 сводятся к тому, что хэш больше не передается по сети открытым текстом. Но все равно при проверке challenge/response сервер опирается на тот же самый хэш (у него же нет плэйнтекстового пароля), поэтому все изменения, внесенные временными штампами, должны однозначно восстанавливаться на основе этого значения хэша.

[pargentum.livejournal.com]

active directory умеет авторизоваться через радиус? Я, наверное, сильно отстал от жизни.

Систем, которые используют plain пароли, в мире вагон и маленькая тележка. Из наиболее распространенных - ssh, plain http authorization.
Кроме того, есть системы, в которых пароль не хранится даже в виде хэша - ssl/tls, Lotus Notes/Domino, тот же самый ssh при авторизации по ключу.

[pargentum.livejournal.com]

Там же в статье все написано: первичный взлом осуществлялся в полуавтоматическом режиме, потом, вытащив базу ad и получив реальные доменные привилегии бот поднимал наружу vpn и - ...

[alexcohn.livejournal.com]

Спасибо за ссылку, я ее пропустил.

Вообще-то, не вижу проблемы с пунктом 2: не настолько уж несложно выйти на Domain Admin, и судя по статье и комменариям, это статистическая атака, т.е. на некоторых из взломанных машин удается найти нужный хэш в кэше.

Хотя, если пароль Domain Admin введенный для того, чтобы присоединить PC к домену, вообще оказывается в локальном кэше, это безобразие.

Вот чего я понять категоричски не готов - какое отношение это всё имеет к взлому почтовых ящиков китайских диссидентов на gmail. Потому что, если домен-админ китайского отдела Гугля имеет доступ к моему почтовому ящику, это просто ужас. Даже если это супер-домен-админ американского отдела Гугля. Потому что privacy не может зависеть лишь от того, что лично этому админу совершенно не интересно содержимое моего почтового ящика.

[stas]

Я думаю, там взломали не только почтовые ящики. А от домен-админа можно получить доступ к разным документам и мейлам, к внутренним VPNам и т.п., в которых может быть и способ доступа к ящикам, например. По факту, внутренние системы зачастую защищены слабее, чем внешние, особенно те, для доступа к которым нужны права домен-админа.

[alexcohn.livejournal.com]

Внутренние системы защищены слабее, конечно. Но в этом-то и вопрос: если GMail для них - внутренняя система, we're fucked anyway. Если же нет, то даже захватив полностью контроль над Google.cn, хакер ни на йоту не приближается к почтовому ящику китайского диссидента.