id: Гость   вход   регистрация
текущее время 18:33 29/03/2024
Владелец: ressa (создано 05/10/2013 14:31), редакция от 05/10/2013 14:50 (автор: SATtva) Печать
Категории: софт, tor
http://www.pgpru.com/Новости/2013/ОпубликованыМатериалыОМетодахАНБПоПолучениюКонтроляЗаПользователямиTor
создать
просмотр
редакции
ссылки

05.10 // Опубликованы материалы о методах АНБ по получению контроля за пользователями Tor


В новой порции приданых огласке документов, переданных СМИ Эдвардом Сноуденом, раскрыты сведения о попытках проведения Агентством Национальной Безопасности США (АНБ) атак по деанонимизации деятельности пользователей сети Tor. Имея возможность выделять запросы, отправленные пользователями Tor, в общем объёме трафика, АНБ построило сеть из точек внедрения вредоносного ПО, нацеленную на поражение клиентского ПО пользователя Tor, в том числе а именно развиваемого проектом Tor специализированного браузера Tor Browser.


В рамках проекта Quantam, АНБ удалось разместить серию своих серверов контроля трафика в сетях ряда крупных магистральных провайдеров. При выявлении обращения через сеть Tor к сайтам, представляющим интерес для спецслужб, трафик перебрасывается с подконтрольных АНБ транзитных узлов в на специальные серверы FoxAcid, предназначенные для проведения атаки на системы пользователей. Атака осуществляется путём применения эффекта гонки (race condition), через генерацию сервером Quantam фиктивного ответа с редеректом на сервер FoxAcid, который за счёт того, что оборудование АНБ находится ближе к клиенту, приходит раньше реального ответа сервера, к которому обращается пользователь. После успешного переброса на сервер FoxAcid, пользователю от имени сервера FoxAcid отображается страница с вредоносным ПО.


Уязвимости эксплуатируются в том числе и в Tor Browser, основанном на Firefox, что позволяет получить контроль за машиной пользователя Tor. Для пользователей Tor, не использующих Tor Browser, упоминается техника отслеживания активности пользователя через установку и контроль за Cookie, которые при использовании одного и того же браузера при работе через Tor и без Tor не меняются. Сама сеть Tor не была скомпрометирована, контроль за трафиком производился за счёт внедрения троянского ПО на систему клиента.


Более того, в документе указано, что АНБ никогда не обладало возможности деанонимизации всех пользователей сети Tor. Лишь в отдельных случаях ручной труд аналитиков мог раскрыть отдельных пользователей Tor, но деанонимизации на лету добиться не удалось. В качестве целей также отмечается получение контроля за шлюзами Tor, но на момент подготовки документа АНБ имело контроль лишь за несколькими шлюзами из тысяч.


Источник: http://www.opennet.ru/opennews/art.shtml?num=38087


 
На страницу: 1, 2, 3, 4, 5, 6, 7 След.
Комментарии [скрыть комментарии/форму]
— Гость (07/10/2013 00:52)   <#>
Потрудился, и вот что выяснил для Intel D945GNT:
– на фото видна LPC http://savepic.su/3472184.jpg, но джампер только на положения "Нормальный", "Конфигурирование" и "Восстановление", а блокировки записи нет. Т.е. требуется как минимум выпаивание одной ножки.
К тому же эта материнка уже засвечена при обычной работе, т.е. без Tor, поэтому полагаться на ее анонимность не приходится.

PS. Может, это и глупо, но через свою паранойю считаю, что настоящую анонимность под Tor можно обеспечить, если не выходить в Интернет с материнкой, хоть раз побывавшей в нем без Tor.
— Гость (07/10/2013 01:20)   <#>
хоть раз побывавшей в нем без Tor
а есть гарантия, что какой либо из процессов не проскочит мимо? комп в помойку? или замена материнки?
— Гость (07/10/2013 01:33)   <#>

Это не глупо, если на кону стоит жизнь, свобода или нечто подобное. В менее драматичных ситуациях, пожалуй, глупо, нелепо и не нужно.
На мой взгляд, в любом случае желательно иметь парк машин. С связи с чем можно активно скупать барахло старые модели материнских плат, CPU и др. комплектующих первой половины-середины 2000-х, чтобы и производительность была более-менее и уши АНБ не торчали из-под шлейфов.
Это удобно и для экспериментальных целей и для работы, тем более если работа хобби возня с железом.


Есть. Имя ей — фаервол. Плюс опционально прямые руки.
— Гость (07/10/2013 03:16)   <#>

i386 пойдет, или уже поздновато? :)
— unknown (07/10/2013 10:34, исправлен 07/10/2013 10:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

2 /comment71493:


Во-первых, слайды могут действительно пересобираться/перепечатываться журналистами.


Во-вторых, есть и более поздние слайды (см. подборку на cryptome.org), они не похожи по содержимому на 2007 год. В 2007 TorBrowser отсутствовал или только появлялся. На слайдах обсуждается TorBrowser на основе FF-ESR-10 и более поздние версии, а это 2011-2012 годы.

— Гость (07/10/2013 10:43)   <#>

Может быть уже встроено было тогда. Лучше собирать свой процессор на транзисторах, тише едешь теплее будешь.
— Гость (07/10/2013 11:58)   <#>
настоящую анонимность под Tor можно обеспечить, если не выходить в Интернет
В цитатник! :)
— unknown (07/10/2013 13:30)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
/comment18132 — это вариант второй цитаты в комментарии.
— unknown (17/10/2013 10:19, исправлен 17/10/2013 10:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

К этой новости с форума подходит появившийся за месяц до неё /comment70253, вроде его ещё не упоминали в этом треде:


>it has the option to query "Tor events"
Как вариант: перенаправить трафик от эксита через себя, сделать MITM, применить эксплоит против TorBrowser'а и попытаться вытянуть с него всю информацию. Звучит очень реально, что-то такое даже ФБР делало на скрытых ресурсах, и никакая мистика не требуется.
— Гость (18/10/2013 23:00)   <#>
Эта новость как-то прошла здесь незамеченной, а, тем временем, проекту Tor 8-го октября исполнилось 10 лет — ровно столько прошло времени со времени первого релиза. Погружаясь в глубь времён и всоминая, каким был интернет в 2003-ем году, даже слабо в это верится. Я узнал про Tor в 2005-ом, в 2004-ом — про proxy и цепочки проксей. В те времена про Tor знали только самые гики из гиков, информации на русском на эту тему не было как класса, да и на английском ничего толком не гуглилось, во всех инструкциях по анонимности речь шла исключительно о публичных и не совсем списках прокси и составлении из них цепочек проксей.

В Tor-блоге вышла длинная новость не тему guard'ов, данные про «несколько недель» в качестве времени их жизни уже устарели:

In Tor 0.2.4, we've changed it to "two or three months". But I think changing the guard rotation period to a year or more is probably much wiser, since it will slow down the curves on all the graphs in the above research papers.
— Гость (19/10/2013 21:54)   <#>
FastFirstHopPK 0|1

When this option is disabled, Tor uses the public key step for the first hop of creating circuits. Skipping it is generally safe since we have already used TLS to authenticate the relay and to establish forward-secure keys. Turning this option off makes circuit building slower.

Note that Tor will always use the public key step for the first hop if it’s operating as a relay, and it will never use the public key step if it doesn’t yet know the onion key of the first hop. (Default: 1)

Когда всплывали предыдущие новости от АНБ, народ заинтересовался, и выяснилось, что DH далеко не во всех SSL и не во всех VPN. А насколько надёжный DH/PFS в Tor? Читаю man к вышепроцитированной опции и не понимаю, что они этим хотят сказать.

When this option is disabled, Tor uses the public key step for the first hop of creating circuits.

FastFirstHopPK=0 ⇒ Tor генерирует симметричный ключ и отсылает его на first hop? Симметричный ключ не вырабатывается по DH в этом случае?

Skipping it is generally safe since we have already used TLS to authenticate the relay and to establish forward-secure keys.

Если опция отключена, то это всё равно сравнительно безопасно, потому что PFS есть за счёт TLS? Там двойное шифрование и двойная атуентификация, где снаружи TLS, а внутри сам протокол Tor? Отключение опции точно не влияет на PFS? Skipping it: it — это что? Skipping опции в конфиге (не указывать) или skipping аутентификации по публичному ключу? Но ведь и при DH публичный ключ тоже используется, хоть и для заверения параметров сессии? Или всё не так?

Turning this option off makes circuit building slower.

Наверно, имелось в виду, что если надо вырабатывать общий симметричный ключ по DH, то это будет медленнее, чем если клиент просто шифрует им выбранный симметричный ключ и отсылает его первому хопу? Но это противоречит условию FastFirstHopPK=0 — т.е., дословно, не использовать публичный ключ с первым хопом.

Note that Tor will always use the public key step for the first hop if it’s operating as a relay

Кто такой первый хоп, если Tor — это relay? Следующий узел в цепочке, куда ему нужно переслать трафик? И в этом случае никакого DH, получается, нет?

and it will never use the public key step if it doesn’t yet know the onion key of the first hop.

Казалось бы, при чём тут onion. Если это не onion-протокол и не роль IP/RP/ещё чего-то такого, то обычный сервер в цепочке вообще не знает, какой трафик он пересылает — идущий наружу или на onion'ы.

Иными словами говоря, что получит противник, скомпрометировавший ключ одной Tor-ноды? Туманное шифрпанковское изложение man'а намекает, что DH там далеко не везде.
— unknown (20/10/2013 00:08, исправлен 20/10/2013 00:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Они сильно оптимизировали протокол, но PFS был изначально, об этом неоднократно упоминалось в разных материвалах и сообщениях проекта. Например, при обнаружении дыры в Debian OpenSSL. Поскольку Tor устроен посложнее, чем просто TLS/SSL-соединение между хостами, то там могут быть разные нюансы насчёт PFS на разных шагах и PFS для шифрования и аутентификации нод.


В самом начале была ещё проблема согласования параметров DH, при которой противник мог навязать сторонам предопределённый ключ. Это исправили. Затем вышла работа, где протокол Tor был проанализирован с точки зрения доказуемой безопасности и задним числом показано, что если бы делали по этому подходу, то дырка бы выявилась сразу. В этой же работе было показано, как переводить Tor на ECC.

— Гость (21/10/2013 00:43)   <#>
Unknown, спасибо за объяснение, но конкретный вопрос «что получит противник, скомпрометировавший ключ одной Tor-ноды?», я так понимаю, пока остаётся открытым. С учётом того, что хостеры имеют физический (для дедиков), а также программный (для VPS) доступ к множеству Tor-нод, а АНБ — к хостерам, этот вопрос достаточно актуальный.
— unknown (21/10/2013 09:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Можно сказать, что он не получит. Он не получит возможность расшифровать ранее прошедший (до момента момента перехвата ключа или установления контроля над нодой) через эту ноду трафик, даже если он его где-то перехватывал и записывал. Не считая случаев, наподобие фатальных дырок в OpenSSL, когда всё PFS идёт лесом.
— Гость (21/10/2013 14:10)   <#>

Даже если остальные 2 ноды полностью подконтрольны атакующему?
На страницу: 1, 2, 3, 4, 5, 6, 7 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3