Регистрация08.04 // Уязвимость в OpenSSL может подвергать опасности пользователей Tor и других программ
Новая уязвимость в OpenSSL 1.0 — 1.0.1 может быть использована для раскрытия данных, находящихся в памяти клиента, соединяющегося с сервером — CVE-2014-0160. Верно и обратное — раскрытие данных в памяти сервера, использующего OpenSSL, если с ним способен установить соединение злонамеренный клиент.
Использование более старых версий OpenSSL безопасно.
Проверка системной версии (не из пакета TBB):
Уязвимые на данный момент версии: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1. В состав дистрибутивов Linux и др. операционных систем после исправления уязвимости могут входить версии с таким же номером, но с добавлением номера патча из пакета. Проверьте установленную версию средствами своего пакетного менеджера.
Следующие сведения имеют отношения к компонентам Tor:
- Клиенты: Непосредственно браузер из состава Tor Browser Bundle не должен быть уязвимым, т.к. использует libnss, а не openssl. Но клиенты Tor способны отправлять информацию о том, какие сайты они посещали в пределах данной сессии своим входящим узлам. Для TBB
будутнезамедлительно выпущены новые версии Tor Browser 3.5.4 is Released; для пользователей системного тор-демона необходимо будет обновить OpenSSL и вручную перезапустить Tor. - Релеи и бриджи: узлы Tor и бриджи могут производить утечку своих среднесрочных onion-ключей (меняющихся раз в неделю) или долговременных аутентификационных ключей узлов. Атакующий, который знает идентифицирующий ключ вашего релея, может опубликовать новый дескриптор сообщающий о смене вашего местоположения (не слишком опасная атака). Если при этом атакующий может перехватывать трафик до релея, знает onion-ключ, то он может перехватывать трафик от вас до вашего релея, подменяя его адрес на свой подставной. Из-за многохоповой конструкции Tor такая атака только на один узел также не слишком опасна. В любом случае, это требует обновления OpenSSL, обновления данных в DataDirectory узла и перезапуска Tor для генерации новых ключей.
- Скрытые сервисы: у них происходит утечка долговременных аутентификационных ключей к их гвард-узлам. Как и в предыдущем крупном баге в OpenSSL
это не позволит атакующему определить местоположение скрытого сервиса, но знание его ключа позволит производить его подмену. По обновлённым сведениям IP-адрес скрытого сервиса также может быть раскрыт. Рекомендуется сменить адрес скрытого сервиса после обновления.
- Корневые авторизующие диектории: у них, помимо вышеописанных утечек узловых и мостовых ключей, может происходить утечка среднесрочных ключей подписи статистики. После обновления OpenSSL их владельцам потребуется создать новые ключи подписей. Долговременные ключи находятся в оффлайне и неподвержены атаке. Из-за прописывания отпечатков ключей в код клиентов пока не выработана стратегия смены ключей с минимальным ущербом для пользователей сети.
- Tails: использует Debian oldstable и неподвержен уязвимости.
- Orbot: уязвим; детали будут опубликованы позднее.
- Большинство серверов https://www.torproject.org потребуют обновлений и смены сертификатов.
| ! | [WWW] Как сообщает ведущий разработчик Tor, Роджер Динглдайн, последствия Heartbleed-уязимости для сети Tor до конца не выяснены. На данный момент установлено, что она позволяет раскрывать IP-адреса скрытых сервисов. Также подозревается существование возможности проведения Heartbleed-атаки на пользователя не только со стороны сторожевых узлов, но и производя MiTM в локальной сети — например со стороны провайдера или путём перехвата беспроводного соединения. |
Источник: Torproject Blog.
комментариев: 9796 документов: 488 редакций: 5664
Как я понимал ранее и как повторил Роджер: НИСТовские кривые — это обёртка трафика снаружи, чтобы он не сильно выделялся на фоне обычного SSL, это было введено для совместимости с режимами бриджей. А основная нагрузка идёт через бернштейновские кривые. Насколько там всё конкретно на каком уровне в протоколе реализовано и как это точно повлияет в случае недоверия к НИСТовским кривым — сказать трудно.
Где-то в рассылке упоминалось, что проще всего было бы попытаться вытащить ключи из узлов с флагом HS-dir, которые раздают сведения о скрытых сервисах — к ним якобы можно делать массу запросов. На примере клиентов есть смысл выуживать не ключи, а расшифрованные обрывки трафика и сведения о построенных цепочках. Но, пока на примере Tor-софта практических примеров действительно нет.
А как долговременные-то утекают? Они же по сути должны использоваться только для подписи и только вручную. Типа сейчас у владельца Tor-ноды нет никакого ключа, заверяющего его идентичность, в оффлайне? Все имеющиеся ключи доступны Tor-клиенту?
Почему бы не сделать управление ключами нод так, как это сделано для DA? Пусть каждый имеет оффлайновые ключи и использует их для подписи временных ключей своих Tor-нод, а сами временные должны меняться раз в неделю, например.
Судя по вашим аргументам, максимум — престанет работать маскировка трафика под SSL, что совершенно некритично для большинства, которое факт использования Tor'а вообще не скрывает.
Клиенты легко пропатчить, намного интересней вопрос с релеями. Более того, клиент выбирает релеи случайным образом. Если оставить пока за рамками скрытые сервисы, то цель — например, расшифровать трафик (или узнать адреса), воспользовавшись уязвимостью (или предварительной кражей ключей) самих релеев. Ну, и главное — можно ли такое сделать массово.
С кражей ключей у Tor-нод, впрочем, наверно, не всё так просто. Если оператор узла поменял ключ, атакующий может использовать предыдущий, т.к. он не отозван, но придётся MITM'ить. Однако, статистика обновится, и за конкретным IP будет числится уже новый, обновлённый ключ. Получается, MITM работать не будет? А два коммита, утверждающих, что на одном IP сидят две Tor-ноды с разными ключами, будут подозрительны, поэтому вряд ли атакующих захочет что-то коммитить в статистику. Какие-то такие сумбурные мысли.
комментариев: 9796 документов: 488 редакций: 5664
Именно так. Узел же должно быть запустить и обслуживать просто. Хоть парой щелчков мыши в бывшей Видалии на винде.
Какие-то узлы могут выключаться хоть на несколько дней, затем включаться. А посылать пользователю уведомление: возьми флэшку с ключом, а то текущий временный ключ просрочен — да большинство на это забьют. Вон, в обычных веб, почтовых и прочих серверах SSL-ключи лежат на самом сервере и доступны без пароля. И вообще, большинство серверов управляется по SSH, где ключи тоже просто на сервере лежат, а иначе как с ним соединиться?
Или кто-то должен вовремя загружать на сервер по SSH недельный ключ?
Есть чья-то неофициальная сборка Tor в виде рамдиска, который можно записать на CD-R(W), где все ключи заново генерируются после каждого ребута. Для узлов, которые не стремятся к стабильности.
Верно. Узлы, которые стёрли долговременный ключ, в статистике будут числиться как новые, старая история на них не переносится.
Вообще, вроде как раз на одном IP можно запустить не более двух узлов, для баланса нагрузки. Они получат флаг "Family" — родственных узлов, принадлежащих одному владельцу. Истинный владелец узла может заметить, что его записали к кому-то в семью и посмотреть по текущей статистике и её истории, публично доступной с Torpoject за все годы, что на его IP есть двойник, да ещё с его старым ключом.
Т.е. из-за фичи с двумя торами на одном IP, владелец узла может заметить предупреждение в логе. В такой конфигурации ещё и порты должны быть разные.
Этот флаг можно получить только если в дескрипторах участников семьи есть перекрестные ссылки. Если Алиса укажет Боба в документах как мужа, но у Боба в документах ничего, то они не в браке.
DA не выдаст флаг Running узлу в своём vote-документе пока не подключится туда и не проверит, что идентичность указана верно. Дескриптор для нерабочего узла даже в consensus-документе (принимается по результату содержимого vote-документов) не появится, ибо ради экономии места туда без флага Running не пускают. Без проверок, все подряд заливали бы тонны дескрипторов с фейковыми адресами.
Аналогия не слишком хорошая. Во-первых, SSH-сервер, как правило, или принадлежит мне или я имею непосредственную связь с его администратором, а для Tor-нод это не так. Я вообще не в курсе, через какие сервера проходит мой трафик, и кто ими управляет. Затем, есть малый шанс, что кто-то захочет компрометировать лично мой SSH-сервер, но есть большой шанс, что кто-то захочет скомпрометировать Tor-ноду. Разница, прежде всего, в том, что Tor-нода защищает/анонимизирует трафик неограниченного числа лиц (особенно высокопропускная), поэтому владение её ключом, компрометация — важный стратегический ресурс для атакующего. Наконец, в SSH можно сделать аутентификацию по ключу (других практически никогда не использую) и, может быть, даже сделать так, чтобы не только сервер аутентифицировался перед клиентом, но и клиент перед сервером.
Я часто знаю, где стоят физически SSH-сервера, кто ответственен за доступ к ним... но на таком сервере не поднять Tor-ноду, т.к. мало кто захочет нести связанные с этим риски и дополнительную плату за трафик. В итоге Tor-нода поднимается, как правило, где-то в облаках и на хостингах, где кто угодно может получить как программный, так и физический доступ к серверу, поэтому единственная полумера, на которую остаётся надежда — рекейинг (при условии, что долговременные ключи на сервере вообще не хранятся). С другой стороны, да, я понимаю, что домохозяек не приучить к своевременному обновлению ключей, но можно было бы такую штуку сделать поддерживаемой хотя бы опционально. Есть же люди, которые готовы ради большей безопасности немного заморочиться.
Немного странное требование. В естественной природной среде может так получиться, что на одном IP два разных человека независимо подняли Tor-ноды? Это если только один за NAT'ом, и ему сделали проброс портов, как я понимаю. IMHO, разработчики Tor могли бы в этом случае выдавать флаг Family принудительно, т.к. это более, чем странно — строить цепочку из трёх узлов, два из которых — один и тот же компьютер физически. Это нарушает всю философию, стоящую за разделением секрета между многими участниками сети.
Клиент не строит цепочки если узлы находятся в одной ip_addr/16 сети, поэтому построить цепочку из трёх узлов, два из которых — один и тот же компьютер физически невозможно. И этот фильтр независим от Family флаг, который конечно тоже учитывается. Family доброволен и имеет лишь один плюс на сегодня: можно пометить свои узлы, даже если они находятся в разных AS не говоря уж про подсеть, и тем самым помочь клиенту не спалиться на узлах подконтрольных одному владельцу. Но если агенство не захочет пометить свои узлы, то кто-ж его заставит?
И кстати, его не получают. Такое поле есть только в дескрипторе, DA в семейные дела не вмешивается. Клиент решает для себя сам, кто есть семья и как с участниками семьи взаимодействовать.
Уже было, кажется, в комментах на хабре.
комментариев: 9796 документов: 488 редакций: 5664
Другое соображение по поводу атаки, касающееся клиентов.
Атака на узлы сети Tor могла проходить незамеченной, т.к. они пропускают большое количество трафика. А чтобы атаковать клиента, нужно также послать к нему множество запросов. Продвинутый пользователь может заметить, что, допустим, он пользовался только небольшим числом посещений, а трафика прошло много. И может запустить снифер, логирование через файрволл, визуализацию трафика (в той же видалии такая оция была), IDS и пр.
Да и какой смысл проводить атаку на пользователя, если она требует большого числа запросов? У обычного пользователя нет никаких долговременных ключей, можно только пытаться выуживать состояние цепочек и обрывки расшифрованного трафика, которые могут успеть поменяться, пока шлются потоки запросов. Т.е. в сегодняшнем представлении об атаке только что-то ловить наудачу, с не очень большими шансами. Или очень плотно доставать пользователя запросами, что может быть заметно.
Гвард или человек посредине могли бы попытаться атаковать пользователя, если бы подозревали, что под ним прячется узел скрытого сервиса.
Т.е. наиболее вероятна атака против SSL-сервисов в интернете, против Tor-узлов и против соединений, подозреваемых по характеру паттернов трафика на скрытые сервисы. Отдельных пользователей стали бы атаковать только при очень большой необходимости, если нет сокращённой версии атаки с малым числом запросов.
У меня vidalia-bundle-0.2.2.35 была скачана в апреле 2012, чуть-чуть задевает. Как проверить версию OpenSSL зашитую в этот exe-файл?
Есть какие-то особые причины использовать эту версию?
В vidalia-bundle-0.2.2.35-0.2.17 версия OpenSSL библиотеки 1.0.0g 18 Jan 2012
комментариев: 9796 документов: 488 редакций: 5664
В старых версиях TBB были дырки в самом торбраузере, включая утечку запросов к DNS в обход Tor и получение сведений о системе, а также всякие мелочи, вроде узнавания сайтом и исходящим узлом используемых шрифтов.
Поэтому, версии нужно регулярно обновлять до последней стабильной. Хотя бы с учётом того, что со старой версией ваш трафик будет выделяться и профилироваться на общем фоне, даже если никто активно не будет использовать прицельные уязвимости.
Есть. С новыми версиями мой FF и плагин torbutton не хочет работать. Например с vidalia-bridge-bundle-0.2.3.25 уже не грузит страницу.
Версию 0.2.2.35 я скачал когда она была новой, потому именно эта версия. 0.2.3.25 тоже качал когда она была новой, но она уже не подошла. Сейчас ни одну старую версию не скачать, только самую последнюю.
Значит все в порядке. Моя ставка на устарешие версии сработала. В старых версиях меньше дыр и говнокода. Меньше вероятность что проект уже слили АНБ. FF у меня тоже старый.
TBB я никогда не использовал, доверия к нему меньше, и к самому FF17 тоже доверия меньше. Свой FF я настраиваю отдельно. Про утечку запросов к DNS давно знал, об этом везьде предупреждают. Про утечку используемых шрифтов знаю меньше года, тоже исправил.
Профилироваться версией TBB или версией vidalia-bundle? У меня помимо того плагины RefControl и Ghostery работают.