Порой плохую фичу сложно отличить от хорошего бага. В каком-то смысле она даже хуже бага – фиксить-то ее не будут. Вот и Microsoft уже шестой год знает о симпатичной возможности перехвата сессии любого пользователя локальным администратором. Погодите, это же админ, ему все можно! Однако давайте разберемся что здесь не так.Началось все с того, что исследователь Александр Корзников опубликовал в своем блоге пост о найденной им возможности перехвата чужой сессии. Все рассказал и показал в видеороликах, доступно и наглядно. Если коротко, утилита Windows tscon.exe позволяет подключаться к чужой сессии. Возможность штатная. Пароль пользователя знать надо. Но если запустить tscon из-под пользователя SYSTEM, пароль другого юзера уже не запрашивается! Ты просто заходишь в чужую сессию like a boss. Для выполнения этого трюка, правда, нужна дополнительная админская утилита вроде psexec или аналогичной, словом, установить такое локальному админу не составит труда.
Автор эксплойта не стал оповещать Microsoft до публикации, так как проблема глубинная, и фикса пришлось бы ждать минимум полгода, а прославиться не терпелось. Однако неожиданно он обнаружил пост от 2011 года, где исследователь Бенджамин Делпи описывает все ту же проблему. Получается, Microsoft давно в курсе дела. Кстати, представитель компании добровольно подтвердил журналисту Threatpost, что «это вообще не уязвимость, так как эксплуатация требует прав администратора».
Как же так, ребята? Если я локальный администратор на компьютере, это вовсе не значит, что мне можно шастать по всей сети и заглядывать во все ее потаенные места. К тому же, в реальных сетях серьезных организаций нередко бывает так, что КТО НАДО работает под локальным админом. Просто потому, что иначе криво пашет какой-нибудь критический для бизнеса софт. Ну, или юзер – закадычный друг сисадмина. И вот если этот ценный сотрудник подцепит что-нибудь неприятное из почты, злоумышленники смогут перехватить сессию, например, администратора домена, и их уже не остановить. Вполне себе такой апокалиптический сценарий целевой атаки на организацию.
Так что отчасти Microsoft права: да, это не уязвимость. Это зияющая дыра в модели безопасности Windows. И нам, кстати, с этим жить. На десерт – список версий, в которых квартирует наша гостеприимная фича:
— Windows 2016
— Windows 2012 R2
— Windows 2008
— Windows 10
— Windows 7.
Китайская команда сбежала из виртуальной машины
Заголовок получился неоднозначный – никто, конечно, не запирал китайцев в виртуальном пространстве, до этого техника пока не дошла
Эксплойт коварные азиаты сварганили на основе цепочки из трех багов: переполнение динамической области (heap overflow) в Microsoft Edge, некорректная проверка типа (type confusion) в ядре Windows и ошибка неинициализации буфера у VMware. Между прочим, в прошлом году эта номинация осталась без победителя, ввиду чего приз вырос с $75 тыс. до $100 тыс.Разогнавшись, китайцы уже не могли остановиться – они походя взломали Adobe Reader с Adobe Flash и оттоптались на MacOS, разработав метод эскалации привилегий. В итоге парни получили первый приз Master of Pwn. Вспомните об этом, если вдруг захочется пошутить на тему квалификации китайских хакеров.
Контроль за HTTPS может сделать канал небезопасным
Капитан Очевидность вновь пришел на помощь недогадливым. US-CERT выпустил бумагу, в которой ответственно заявил, что использование средств исследования HTTPS-трафика снижает защищенность канала. Э-хе-хе, а для чего ж они нам, как не для этого самого?
Посыл US-CERT на самом деле в том, что при наличии в сети такого инструмента пользователь не может контролировать валидность сертификата сервера и стойкость шифрования канала. Железка, инспектирующая HTTPS-трафик, ставится на позицию «человек посередине». Пользователь может проверить сертификаты этого самого шпионского аппарата, а уж сам аппарат – сертификаты сервера. Теоретически схема работает.
На практике средство контроля HTTPS может быть устаревшим и плохо настроенным, и пользователь со своей стороны никак не сможет узнать, что его трафик идет, к примеру, по уязвимому протоколу SSL3, или что сертификат сервера выдан непонятно кем. Это создает возможность для хакера стать тем самым «человеком посередине» и перехватывать весь якобы защищенный траф.
Авторы исследования, послужившего основой для оповещения US-CERT, выявили пониженный уровень безопасности в 62% контролируемых TLS-каналов. Давайте пошлем немножко лучей здравомыслия всем тем, кто отвалил за брендовую железку много долларов США и считает себя неуязвимым.
Древности
«Perfume»
Резидентный очень опасный вирус, стандартно поражает .COM-файлы (COMMAND.COM поражается при старте вируса). Создает свою TSR-копию, ничего не изменяя в блоках MCB, чем может вызвать зависание системы. Периодически стирает случайные секторы на диске A:. При 80-й попытке заражения уже инфицированного файла начинает какой-то диалог с оператором (в моем образце вируса текст стерт). Перехватывает int 21h.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 78.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (56)
crea7or
24.03.2017 21:07+4Давно хочу спросить, вы аудиторию с сайтом хакер.ру не путаете? А то картинки да и слог вообще как-то диссонируют с хабром.
selivanov_pavel
24.03.2017 21:53+9Если я локальный администратор на компьютере, это вовсе не значит, что мне можно шастать по всей сети и заглядывать во все ее потаенные места.
Нет, просто это значит, что на этой машине вы можете всё.
А если вы root на unix-машине, и кто-нибудь зашёл на неё по ssh с пробросом agent, то, пока его сессия активна, вы можете пробросить себе его SSH_AUTH_SOCK и логиниться на все сервера, где он может. Более того, вы можете это делать со всеми ключами в его ssh-агенте, а не только с тем, которым он заходил на сервер.
Ужас-ужас, галектеко опасносте.
d-stream
24.03.2017 21:59+2Как же так, ребята? Если я локальный администратор на компьютере, это вовсе не значит, что мне можно шастать по всей сети и заглядывать во все ее потаенные места
Членство в группе «локальные администраторы компьютера» — ну совсем не означает, что он имеет хоть какие-то права в доменной сети.
То бишь деревенский староста — конечно фигура у себя в деревне, но в соседнем ПГТ — так, кандидат на в морду дать просто так =)
imbasoft
24.03.2017 23:33+2По поводу «бага» в Windows…
Если закрыть этот «баг» то завершение сеансов неквалифицированных пользователей, которые не закрывают RDP-сессии превратиться в сущий ад. Кто не в теме, просто дропать сеансы не всегда можно, там может потребоватьcя еще сохранить мегаважный Excel.
С точки зрения безопасности, доводы не убедительный. В случае компрометации админа или SYSTEM злоумышленики смогут сделать все тоже а даже больше другими инструментами.
Microsoft, пожалуйста, не латай этот «баг» :)Disasm
25.03.2017 10:27А зачем вообще нужно завершать RDP-сессии? Ну висят они и пусть себе висят.
iig
25.03.2017 10:31+1В зависшей сессии может быть, например, открыта база 1С, и повторно подключиться не получится. Когда-то это было актуально.
Andrusha
25.03.2017 13:13Бывает, что они зависают, и пользователь не может переподключиться или наблюдает чёрный экран. Если бы не было возможности их закрывать, приходилось бы перезагружать весь сервер.
to_climb
25.03.2017 15:55Ctrl+Alt+End этому чёрному экрану (аналог Ctrl+Alt+Del, но через RDP) и попробовать подключиться ещё раз.
Обычно спасает от необходимости перезагрузки.
LoadRunner
27.03.2017 09:03Предлагаете дойти до машины пользователя, где запускалась RDP-сессия? Вы настолько неленивый админ? А если пользователь очень удалённый, что и является причиной, по которой он через RDP на сервере работает? Объяснять ему комбинацию клавиш по телефону? А если это работник «простосделайужечтонибудь»?
Быстрее и меньше нервотрёпки взять и с сервера завершить сеанс пользователя.
Contriver
25.03.2017 00:06Членство в группе «локальные администраторы компьютера» — ну совсем не означает, что он имеет хоть какие-то права в доменной сети.
Если на том же компьютере есть доменный пользователь, то делегируем права локальному, запускаем PSHELL и хоть какие-то права права в домене, не только чтение. О подробностях умолчу, тут не хакер, ру .Прочтите и домыслите.
tsklab
25.03.2017 08:53В нормальной корпоративной сети пользователи не имеют прав локального администратора. А если это не так, то перехват чужой сессии — не самое страшное.
Scf
25.03.2017 12:27Они могут его получить в любое время, имея физический доступ к своему компьютеру.
khim
25.03.2017 20:41-1Для этого BitLocker есть. Комп загружается только при наличии специального ключа.
Хотя всё равно, наверняка, можно проломать: эксплоитов подобного сорта в Linux'е обнаруживают по десятку за неделю, не думаю что ядно Windows сильно надёжнее.
Am0ralist
25.03.2017 23:01В «нормальной» корпоративной сети может оказаться туча старого софта, который какого-то фига нормально не работает без полных прав.
Rampages
26.03.2017 08:16Помнится из соображений безопасности удалили локальных админов на всех машинах, далее на одной машине пользователь поменял DNS адреса на гугловские по советам из интернетов, в результате у него компьютер не смог залогиниться в домене, а локального пользователя мы не оставили…
Am0ralist
26.03.2017 16:48А мне чего-то вспомнилось, как в конторе с доменом, сложными паролями и запретом разглашения паролей, чтобы никто не мог войти под чужим пользователем, мой друг, с которым мы там работали в полях, сел за комп техподдержки и от скуки зашел под учеткой «администратор» по энтеру…
Админам после этого случая дали небольшой втык)
Sergey-S-Kovalev
26.03.2017 20:31+1Простите. Расскажите мне, пожалуйста:
1. как Вы удалили не удаляемого build-in Администратора.
2. как с пользовательскими правами поменять DNS-адреса на гугловские?
3. и почему имея физический доступ к машине у Вас не получилось материализовать сколь угодное количество локальных учеток с любыми правами в считанные минуты используя WinPE?
У меня такое ощущение, что Вы пи… приукрашиваете.iig
26.03.2017 22:01Думаю, там все наоборот было. Сначала с правами локального админа подхачили dns… Правда, в этом месте должна сломаться доменная политика…
Или это 2 разных эпизода слились в 1 рассказ.
Am0ralist
27.03.2017 00:091) Его можно отключить. Из под доменного админа.
2) Может у доменного юзера как раз таки были права локального админа? ) Хотя после этого у него было бы пару недель возможности захода на компьютер, а проблемы с днс раньше вылезлиyosemity
27.03.2017 12:22Я вам больше скажу, build-in админ вообще отключен по дефолту, как и гость. Но в безопасном режиме учетка задействована.
Am0ralist
30.03.2017 11:10Если честно, сам не отключал (пароль посложнее ставил всегда, периодически записывая их на наклейку в корпус), однако неоднократно встречал машинки под XP, в которых стандартный админ был выключен нафиг и в безопасном не грузился. Но, обычно, это были всякие сборки а-ля зверьсд, представлявшие собой сплошной твик реестра.
Karpion
26.03.2017 21:44Вы фееричны!
Достаточно навесить IP-адрес гугловского DNS-сервера на локальный DNS-сервер (ну, может, ещё пошаманить с роутингом), и всё прекрасно работает.iig
26.03.2017 21:57Шаманить с роутингом и DNS можно без прав администратора?
LoadRunner
27.03.2017 09:11Речь о том, как админу спасти компьютер пользователя, на котором гугловские DNS.
Админ-то имеет доступ к DNS-серверу организации, где он работает?iig
27.03.2017 10:24Как это ему поможет в данной ситуации?
В ситуации, когда есть проблемы с сетью, пешая прогулка неизбежна.LoadRunner
27.03.2017 10:56Ну вот описана проблема: компьютер в домене, локальный администратор заблокирован, локального пользователя нет, DNS гугловские, под доменным пользователем не залогиниться.
Ваши варианты спасения компьютера?
Можно, конечно, DNS локального компа поправить, просто загрузившись с какого-нибудь WinPE.
Мне кажется, что у Вас некоторое недопонимание ситуации возникает, или я не понимаю Ваших недоуменных вопросов.iig
27.03.2017 11:05Ну, я других вариантов, кроме пешей прогулки и WinPE не вижу.
А чем поможет доступ к DNS-серверу?LoadRunner
27.03.2017 11:22Можно сетевой карте назначить вторым ip-адресом 8.8.8.8 и потерянный компьютер внезапно начнёт стучаться на этот сервер. Когда TTL пройдёт на закэшированную запись. Но ведь никто не говорил, что это единственный вариант и самый оптимальный. И уж тем более, что это должен делать пользователь.
iig
27.03.2017 11:51Да, может получиться ;)
Но я бы так делать не рискнул. Лучше уж роутингом нашаманить правило для ровно одного компа. Вносить изменения в доменную инфраструктуру ради установления контроля над одним компом — нафиг-нафиг.LoadRunner
27.03.2017 12:05Лучше с лайвом дойти до компа и решить проблему, а не городить костыли.
Хотя если для компа включен удалённый доступ, то что мешает подключиться к нему удалённо под доменным админом? Про шлюз и DHCP в исходной задачке ни слова.iig
27.03.2017 12:15Хотя если для компа включен удалённый доступ, то что мешает подключиться к нему удалённо под доменным админом?
Скорее всего, связь с контроллером домена потеряна, ибо DNS всё.
Karpion
27.03.2017 21:14Для шаманства с роутингом надо иметь админские права на совсем другой машине — не на той, на которой «удалили локальных админов». Весьма вероятно, это вообще не писюк, а если писюк — то не факт, что под Windows.
Прочитайте пост, на который я отвечал. Я решал конкретную проблему, описанную там.
varnav
26.03.2017 12:34Поясните про перехват сессии.
Вот давайте представим, у нас есть сервер с какой нибудь «АРМ Фиалка для рассчётам смет согласно приказу Минстроя № 895-9494/2001 и отправки отчётности» — за админство этого сервака отвечает подрядчик, поэтому у него есть админские права на этот сервер и доступ через VPN. Это абсолютно нормально.
И вот на этот сервер заходит самый главный админ нашей корпорации из-под админской учётки с правами администратора домена.
Может ли подрядчик теперь перехватить сессию админа корпорации и получить полную власть над доменом?
lorc
Я давно не имел дела с виндой, так что поправьте меня, если я не прав. Но насколько я помню, код выполняющийся под SYSTEM имеет достаточно прав что бы перечислить все процессы всех пользователей, замапить себе их память, положить туда любой код и делать другие интересные штуки. Так что возможность штатными средствами подключиться к сессии уже не выглядит такой ужасной.
Godless
все что вы описали могут люди, хоть немного понимающие си и подобное. А сабж могут пользовать кулхацкеры и просто продвинутые пользователи обычными утилитами, если я все верно понял.
lorc
Ну окей, пользуясь уже упомянутой psexec пользователь с локальными админскими правами может запустить в чужой сессии кейлоггер и украсть все пароли. Для этого не надо знать системное программирование.
Просто найденная «уязвимость» звучит как «о ужас, пользователь с админскими правами может творить что угодно с компьютером!»
Am0ralist
Все таки получается, что человек с правами локального админа (в домене он может быть обычным пользователем) может сотворить что угодно в сети.
А это да, не есть гуд.
iig
Так и есть. Человек может, например, принести свой собственный ноут (он там админ), и делать в сети что угодно. Доменных прав не будет, да.
yosemity
Что за чушь?
iig
Прошу прощения, невнимательно отвечал на вопрос. К повышению прав доменного юзера с помощью прав локального админа это случай никак не относится.
А «человек с правами локального админа может сотворить что угодно в сети» — да. Не все, но достаточно много.
yosemity
Ничего он не может, на другие компьютеры у него вообще может не быть никаких прав.
iig
Он может исследовать сетку как ему вздумается (сканеры, проверки на уязвимости..).
Он может arp-spoofing.
Это достаточно много.
yosemity
Это конечно, но от таких атак защищает доступ через 802.1x.
varnav
Который встречается нечасто, а NAP из 2016-го сервера вообще убрали.
NoOne
А причем здесь это и уязвимость из статьи?
d-stream
Ну 90% «хакеров» — это просто пользователи, знающие список «хакерских» утилит… так что для этого не надо знать си и подобное, просто почитывать всякие «стань хакером за 20 минут, скачав хакерские тулзы» =)
iig
Человек, знающий си, напишет эксплойт…
Scf
Да, откровенно жёлтая статья.