13 августа компания Microsoft выпустила очередной апдейт безопасности (обзорная новость) для операционных систем Windows и офисных программ, и на этот раз патч оказался по-настоящему гигантским: кому-то явно не удалось сходить этим летом в отпуск. Всего было закрыто 93 уязвимости, из которых 23 квалифицированы как критические. Закрыты серьезные баги в Remote Desktop Services, в клиенте DHCP, в обработчике .LNK-файлов, две уязвимости в Hyper-V с побегом из песочницы.
Столь монументальная работа над ошибками — это очень хорошая новость. Помимо прочего, несколько уязвимостей интересны сами по себе, а еще у одной интересная история обнаружения. Помимо уже упомянутых проблем в Remote Desktop Services, сегодня мы подробнее рассмотрим уязвимость в сервисе MSCTF. Исследователь Тавис Орманди из Google Project Zero, обнаруживший последнюю, утверждает, что проблема существует уже 20 лет. Ну и заодно оценим уязвимость в Bluetooth, которая затрагивает не только Windows.
Уязвимость в сервисе MSCTF была обнаружена Тависом Орманди почти случайно (новость, пост в блоге Тависа). Все началось с изучения механизмов Windows, позволяющих разным программам взаимодействовать друг с другом. Такое взаимодействие ограничивается системой User Interface Privilege Isolation, которая не позволяет, например, пользовательским процессам вмешиваться в системные. Изучая странные случаи, когда, несмотря на ограничения, сообщения все же проходили, Тавис и наткнулся на модуль MSCTF.
Этот модуль относится к Text Services Framework, который в свою очередь управляет раскладками клавиатуры и подобным. К нему подключаются все запущенные приложения. Зачем? Ну, например, для облегчения процесса ввода текста на китайском или японском языках.
Для таких языков отдельная программа обрабатывает ввод в окне приложения и меняет введенное на иероглифы. По сути MSCTF — это отдельный канал коммуникации между приложениями, который, как выяснилось, недостаточно защищен. Самая ранняя версия MSCTF, которую удалось найти Тавису, входит в комплект офисного пакета Microsoft Office XP, совместимого еще с Windows 98. Начиная с Windows XP, MSCTF является частью операционной системы. Возможности взаимодействия с другими приложениями через MSCTF весьма широкие, а главное — нет никакой авторизации. В итоге Тавис написал утилиту для работы с CTF и занялся поиском уязвимостей:
Уязвимости, пусть и не сразу, были найдены. В «лучшем» случае, на системе с одним из языков, требующих расширенные инструменты ввода (японский, китайский, корейский и некоторые другие), можно подменять текст в приложении, отправлять команды в консоль с правами администратора, не будучи при этом привилегированным пользователем, или красть пароли пользователей. В худшем (правда, вышеперечисленное — уже достаточно плохо) можно получить права системы, то есть повысить свои привилегии до максимальных. Такой Proof of Concept показан на видео:
Уязвимость имеет ограниченное применение, и скорее всего, большинство сценариев доступно только при наличии доступа к системе. Тем не менее, потенциально возможны варианты, когда пользователь без привилегий получает, скажем, права администратора домена на предприятии. Уязвимость закрыта августовским обновлением для всех ОС, начиная с Windows 7.
Проблемы в Remote Desktop Services (новость, бюллетень на сайте Microsoft) отчасти похожи на обнаруженную в мае этого года уязвимость Bluekeep. Дыры в сервисе удаленного доступа (но не в самом протоколе RDP) теоретически позволяют распространять атаку на все компьютеры в сети, без участия пользователей: есть определенный риск повторения ситуации с шифровальщиком WannaCry в 2017 году, когда масштабно эксплуатировалась проблема в реализации протокола SMB.
Впрочем, есть и отличия от BlueKeep. Более ранняя проблема не распространялась на последние версии ОС, сейчас же, наоборот, ей подвержены все ОС от Windows 7 до Windows 10 (но не Windows XP, Server 2003 и 2008). Баги были выявлены в ходе внутреннего аудита Microsoft, реальных атак пока не было замечено. И Bluekeep, и четыре новые проблемы нейтрализуются включением Network Level Authorization. Но NLA на непропатченной системе не до конца спасает от ряда сценариев выполнения кода на удаленной машине. В худшем случае (нет NLA, не установлен августовский патч, включен удаленный доступ) появляется возможность обойти авторизацию и получить контроль над системой путем отправки подготовленного запроса.
Проблему, известную как KNOB Attack (Key Negotiation of Bluetooth), обнаружили исследователи из Сингапура, Германии и Великобритании (новость, сайт исследования, научная работа). В отличие от других уязвимостей из набора патчей Microsoft, эта распространяется не только на Windows, но и вообще актуальна почти везде, где используется Bluetooth. Большой список апдейтов от производителей смартфонов, ноутбуков, IP-телефонов, отреагировавших на проблему, есть здесь.
В спецификациях Bluetooth два устройства, устанавливающие между собой защищенное соединение, могут выбирать длину ключа в пределах от 1 до 16 байт. В случае «восьмибитного» ключа взломать его можно достаточно быстро простым перебором: если такое «слегка защищенное» соединение будет по каким-то причинам установлено, атакующий может расшифровать обмен данными. Например, между клавиатурой и настольным компьютером. Вопрос в том, как именно реализовать такую атаку, и исследовательская работа доказывает, что есть как минимум два умеренно реалистичных варианта.
В первом случае находящийся поблизости от двух жертв атакующий может заставить их использовать шифрование с длиной ключа в 1 байт. Дело в том, что в процессе установки соединения отсутствует шифрование и даже контроль целостности данных. Во втором случае исследовался сценарий атаки на цепочку поставок: подмена прошивки устройства обеспечивает слабое шифрование во всех случаях. Вторая атака была проведена на телефон Nexus 5: меняем несколько байт в прошивке, ограничиваем длину ключа, подключаемся к другому смартфону, который вынужден принять условия для установки соединения.
Это серьезная уязвимость, которая существует благодаря изначально слабым спецификациям стандарта Bluetooth. Кроме того, множество устройств будут и дальше подвержены атаке KNOB, так как для них просто не выпустят обновление. С другой стороны, реализация такого сценария на практике достаточно сложна: в первом случае требуется оказаться неподалеку от жертвы в нужное время, во втором — вмешиваться в цепочку поставок и потом, опять же, быть рядом с атакуемым устройством, когда по нему передаются конфиденциальные данные. Во всех случаях патч устанавливает минимальную длину ключа так, чтобы атака стала практически неприменимой.
Disclaimer: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.
Столь монументальная работа над ошибками — это очень хорошая новость. Помимо прочего, несколько уязвимостей интересны сами по себе, а еще у одной интересная история обнаружения. Помимо уже упомянутых проблем в Remote Desktop Services, сегодня мы подробнее рассмотрим уязвимость в сервисе MSCTF. Исследователь Тавис Орманди из Google Project Zero, обнаруживший последнюю, утверждает, что проблема существует уже 20 лет. Ну и заодно оценим уязвимость в Bluetooth, которая затрагивает не только Windows.
WTF is CTF?
Уязвимость в сервисе MSCTF была обнаружена Тависом Орманди почти случайно (новость, пост в блоге Тависа). Все началось с изучения механизмов Windows, позволяющих разным программам взаимодействовать друг с другом. Такое взаимодействие ограничивается системой User Interface Privilege Isolation, которая не позволяет, например, пользовательским процессам вмешиваться в системные. Изучая странные случаи, когда, несмотря на ограничения, сообщения все же проходили, Тавис и наткнулся на модуль MSCTF.
Этот модуль относится к Text Services Framework, который в свою очередь управляет раскладками клавиатуры и подобным. К нему подключаются все запущенные приложения. Зачем? Ну, например, для облегчения процесса ввода текста на китайском или японском языках.
Для таких языков отдельная программа обрабатывает ввод в окне приложения и меняет введенное на иероглифы. По сути MSCTF — это отдельный канал коммуникации между приложениями, который, как выяснилось, недостаточно защищен. Самая ранняя версия MSCTF, которую удалось найти Тавису, входит в комплект офисного пакета Microsoft Office XP, совместимого еще с Windows 98. Начиная с Windows XP, MSCTF является частью операционной системы. Возможности взаимодействия с другими приложениями через MSCTF весьма широкие, а главное — нет никакой авторизации. В итоге Тавис написал утилиту для работы с CTF и занялся поиском уязвимостей:
Уязвимости, пусть и не сразу, были найдены. В «лучшем» случае, на системе с одним из языков, требующих расширенные инструменты ввода (японский, китайский, корейский и некоторые другие), можно подменять текст в приложении, отправлять команды в консоль с правами администратора, не будучи при этом привилегированным пользователем, или красть пароли пользователей. В худшем (правда, вышеперечисленное — уже достаточно плохо) можно получить права системы, то есть повысить свои привилегии до максимальных. Такой Proof of Concept показан на видео:
Уязвимость имеет ограниченное применение, и скорее всего, большинство сценариев доступно только при наличии доступа к системе. Тем не менее, потенциально возможны варианты, когда пользователь без привилегий получает, скажем, права администратора домена на предприятии. Уязвимость закрыта августовским обновлением для всех ОС, начиная с Windows 7.
Bluekeep или не Bluekeep
Проблемы в Remote Desktop Services (новость, бюллетень на сайте Microsoft) отчасти похожи на обнаруженную в мае этого года уязвимость Bluekeep. Дыры в сервисе удаленного доступа (но не в самом протоколе RDP) теоретически позволяют распространять атаку на все компьютеры в сети, без участия пользователей: есть определенный риск повторения ситуации с шифровальщиком WannaCry в 2017 году, когда масштабно эксплуатировалась проблема в реализации протокола SMB.
Впрочем, есть и отличия от BlueKeep. Более ранняя проблема не распространялась на последние версии ОС, сейчас же, наоборот, ей подвержены все ОС от Windows 7 до Windows 10 (но не Windows XP, Server 2003 и 2008). Баги были выявлены в ходе внутреннего аудита Microsoft, реальных атак пока не было замечено. И Bluekeep, и четыре новые проблемы нейтрализуются включением Network Level Authorization. Но NLA на непропатченной системе не до конца спасает от ряда сценариев выполнения кода на удаленной машине. В худшем случае (нет NLA, не установлен августовский патч, включен удаленный доступ) появляется возможность обойти авторизацию и получить контроль над системой путем отправки подготовленного запроса.
Уязвимость в Bluetooth
Проблему, известную как KNOB Attack (Key Negotiation of Bluetooth), обнаружили исследователи из Сингапура, Германии и Великобритании (новость, сайт исследования, научная работа). В отличие от других уязвимостей из набора патчей Microsoft, эта распространяется не только на Windows, но и вообще актуальна почти везде, где используется Bluetooth. Большой список апдейтов от производителей смартфонов, ноутбуков, IP-телефонов, отреагировавших на проблему, есть здесь.
В спецификациях Bluetooth два устройства, устанавливающие между собой защищенное соединение, могут выбирать длину ключа в пределах от 1 до 16 байт. В случае «восьмибитного» ключа взломать его можно достаточно быстро простым перебором: если такое «слегка защищенное» соединение будет по каким-то причинам установлено, атакующий может расшифровать обмен данными. Например, между клавиатурой и настольным компьютером. Вопрос в том, как именно реализовать такую атаку, и исследовательская работа доказывает, что есть как минимум два умеренно реалистичных варианта.
В первом случае находящийся поблизости от двух жертв атакующий может заставить их использовать шифрование с длиной ключа в 1 байт. Дело в том, что в процессе установки соединения отсутствует шифрование и даже контроль целостности данных. Во втором случае исследовался сценарий атаки на цепочку поставок: подмена прошивки устройства обеспечивает слабое шифрование во всех случаях. Вторая атака была проведена на телефон Nexus 5: меняем несколько байт в прошивке, ограничиваем длину ключа, подключаемся к другому смартфону, который вынужден принять условия для установки соединения.
Это серьезная уязвимость, которая существует благодаря изначально слабым спецификациям стандарта Bluetooth. Кроме того, множество устройств будут и дальше подвержены атаке KNOB, так как для них просто не выпустят обновление. С другой стороны, реализация такого сценария на практике достаточно сложна: в первом случае требуется оказаться неподалеку от жертвы в нужное время, во втором — вмешиваться в цепочку поставок и потом, опять же, быть рядом с атакуемым устройством, когда по нему передаются конфиденциальные данные. Во всех случаях патч устанавливает минимальную длину ключа так, чтобы атака стала практически неприменимой.
Disclaimer: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.
Dr_Faksov
На обычном компьютере ( без спецкорпусов/конторллеров HDD) при наличии физического доступа к телу — возможны практически любые манипуляции с Windows. Смена пароля админа и последующий вход, к примеру, выполняется штатными средствами системы, если мне память не изменяет.
shteyner
Про отсутствие шифрования забыл. Зашифрованные системы намного защищеннее.
Dr_Faksov
Явно не указал, согласен. Думал, что упоминания спецконтроллера HDD будет достаточно.
shteyner
Ну, это всё же несколько разные вещи. Шифрование дисков не требует никаких дополнительных затрат, доступно из коробки даже домашней редакции винды и особо не влияет на скорость работы. При этом дают достаточный уровень защищенности для обычного пользователя. При этом не получится ни сбросить пароль админа, ни посмотреть файлы, ни модифицировать систему. Как по мне, для ноутов это уже обязательное действие при покупке ноутбука — зашифровать систему.
Думаю в ближайшие годы шифрование будет включено по умолчанию, при первичной настройке и нужно будет снимать галочку, что бы его отключить.
saege5b
На ноуте лучше иметь два винта. И учитывая аппетиты: гигов на 512 — терабайт. И второй на 256-512 гигов.
А то: случись чего, и до раздела просто будет не достучаться.
Правда, это надо что бы производители такие ноуты выпускали, и разработки научились следовать стандартам и писали по стандартным/системным путям.
Тут бэкап вещь такая… обидно потерять кучу документов, которые переписались недавно и не ушли в бэкап.
shteyner
Это сразу не правильный подход, винта и одного хватит, просто нужно делать бекапы, можно даже и в onedrive или завести свой собственный сервер бекапов. Это намного надежнее чем просто два винта. Вообще, ssd достаточно надежная штука и на его поломку расчитывать не нужно, но резервные данные лучше создать. Часто хватает даже тех 5 бесплатных гигов на вандрайве на все ценные файлы.
Если есть реально критичные вещи, которые долго изменяются в офлайн режиме, то можно и второй винт запилить и туда лить бекапы в режиме реального времени. Но это крайне редкий метод применения.
У меня, в нормальном режиме работы, ноут почти всегда в сети, когда я на нём работаю. Поэтому бекапы файлов после изменения сразу идут в облако. Если параноишь, можно их шифровать.
saege5b
Не у всех есть скоростной инет.
Не все ИТешники, и рулить всем этим добром будет «друг» или «спец».
И дело не в физической поломке носителя, а скорее в «кошка прыгнула на клаву, комп выключился, и при включении ругается» / «дети что-то потыкали и вот оно ....».
shteyner
Ну, от такого и два диска не помогут.
Для начала, нужно определиться с тем, что вообще ценное у тебя на компе.
Обычно как: всё что не изменяется, но хочется хранить на компе, вроде фоток и видео с воспоминаниями — дублируем на внешний жесткий диск или пару флешек (и проверяется раз в пол года на то, что бы не испорченно было, обычно вместе с тем, что туда доливаются новые)
Дальше идут документы, они весят совсем не много и их можно отправлять в облако, интернет почти не нужен. И всё настраивается по инструкции за 10-15 минут. Если человек не хочет их потратить на это дело, хотя бы один раз то ССЗБ. Еще не плохо было бы включить shadow copy для диска/папки с документами, что бы обезопасится от детей, которые могут перезаписать файл какими-то данными, просто поиграв за компом.
Для всего этого не нужен быстрый интернет и не нужно быть айтишником, достаточно почитать потратить пол часика — пару часиков (в зависимости от компьютерной грамотности пользователя) для однократной настройки компьютера и еще часик в год для отправки бекапов на внешний жесткий диск, да потратить чутка денег на внешний, в зависимости от потребностей.
Зато теперь ваши файлы будут заметно лучше защищены. И вы не будете горевать от потери любимых фоток или доклада, который вы готовили последнюю неделю.
И да, я понимаю, что не всем это нужно, скажем комп для ВК можно вообще ничего с ним не делать. Или если это игровой комп, тоже нафиг всё нужно. Но, если это рабочий комп, стоимость информации на котором больше пары часов…
saege5b
Я сейчас взглянул на екаталоге, в диапазоне 20-30 тыс.руб. у ноутов на ссд винт в 128 (оооочень редко в 256 Гб), жестянка на 500 (очень редко на 1000)Гб.
На ссд, теневую копию будет весело вкорячивать.
Бэкап в раз в год — слишком редко.
Я про другое, если система упала, то незашифрованный раздел легко прочитать и легко вытащить те данные, с которыми пользователь работал вот только-что. А с зашифрованным разделом, я даже не знаю с какой стороны к этому фаршу подходить.
shteyner
Бэкап в раз в год — слишком редко.
Я вообще-то написал это только для фоток и видео, и только проверять то что он еще работает. Заливать его на диск нужно по возможности, вот отобрали фотки, сделали бекап на недельке, как время будет.
На ссд, теневую копию будет весело вкорячивать. — в плане? Отлично заработает, а ресурса ssd хватит на пяток лет минимум нормальной работы. На все диски не нужно ставить теневые копии, если нет лишнего места.
И, как обычно, безопасность и удобство использования — это 2 крайности. Нужно искать баланс. Выбрать уровень, который больше подходит и жить с этим.
С зашифрованным разделом — тут всё просто, несите в сервис. Все данные можно перетащить на новый диск и расшифровать
ключом восстановления, который должен лежать дома или еще где. Операция крайне редкая, скорее всего за всю жизнь ноута даже одного раза не будет. Не обязательно уметь всё делать самому.
Это всё простые решения, которые как-то работают. Если нужно что-то понадёжнее, то это и больших навыков требует или денежных затрат.
saege5b
Блин, мне пару дней назад звонили в 23, и спрашивали что делать, — кошка прыгнула на клаву ноута и отвалились вайфай с блюпупом.
У большинства пользователей, уровень знаний примерно на этом уровне.
shteyner
Ок, и что дальше? Это как бы их проблемы, а не общественные. Ну и в данном случае немного твои.
Не нужно думать слишком много за других людей, не маленькие. А за звонок в 23, если это по работе, можно и сверхурочные попросить/отказать.
Кому нужно, должны сами думать что им нужно или просить/нанимать тех, кто умеет. Почему я иду к автомеханику, если машина сломалась, но с компом должен сидеть и ахреневать? + почему на машину можно отдать 10к в месяц, хотя ей ты пользуешься по паре часов в день, но на комп от сердца отрываешь 1к, хотя сидишь за ним по 5-6 часов в день. Собственно это просто восприятие так работает.