Появилась новая работа, посвящённая быстрому вычислению секрета протокола Диффи-Хеллмана (DH) из записанного трафика – популярная статья Arstechnica, – речь идёт о том, что можно, и это показано на практике, за обозримое время вычислить секрет, полученный в рамках обмена DH, используя даже университетское оборудование. Под “университетским” имеется в виду, что это не супердорогой специализированный вычислитель. Для успешной атаки требуется, чтобы модуль DH был коротким – 1024 бита, – и имел специальный вид. При этом обнаружить “специальный вид” снаружи и использовать для ускорения вычислений – нельзя, откуда и предположение о закладках.

О том, что найти секреты DH в произвольной короткой, 1024-битной группе, можно, если у вас есть достаточно мощный, но доступный на уровне современных технологий, компьютер и вы предвычислили нужную “арифметическую структуру” группы, известно довольно давно. Сейчас решение продемонстрировали на практике, подтвердив, что если правильно выбрать модуль, то объём вычислений ещё сокращается на несколько порядков.

Для того, чтобы атака сработала, требуются типовые группы. В более строгом случае, с подготовленным модулем, используемую группу нужно прямо задать. (Более мягкий вариант – работает с любой заранее известной 1024-битной группой, но для каждой потребуется большой объём предварительных вычислений и большой объём памяти для хранения результатов.)

Самое занимательное, что с типовыми группами проблем как раз нет. Например, в Рунете (.RU, .РФ) около 280 тыс. имён аресует узлы, поддерживающие HTTPS/TLS и классический вариант DH, которые используют всего две различных группы с разрядностью 1024 бита. Одна – это группа по умолчанию из mod_ssl, а вторая, насколько я понимаю, из настроек по умолчанию модуля SSL в nginx. Обе группы, очевидно, потенциально уязвимы. (Пояснение, 12/10/16: я скорректировал текст – изначально было написано, что 280 тыс. серверов, но речь идёт о числе доменов – имён TLS-хостов.)

Про то, что генерация общего секрета по протоколу Диффи-Хеллмана вовсе не является эквивалентом симметричных ключей, которые “есть только на узлах”, я не раз писал ранее. Например – в записке про извлечение секрета DH из трафика.



Комментарии (12) »

1.

MitM – атака “Человек посередине”. Это атака уровня аутентификации, а не “шифрования”. Смысл атаки, в случае TLS (на клиентской стороне), состоит в том, что подменяется узел, с которым клиент пытается устанавливать соединение. А для того, чтобы клиент не догадался о подмене – используется сертификат, выпущенный для имени исходного узла. История с сертификатами в основном касается как раз TLS, для других протоколов ситуация может быть иной.

2.

Возьмём для примера HTTPS (работает на базе TLS), а также браузер в качестве клиента. Если подменный сертификат для удостоверяемого узла выпущен от корневого ключа, которого браузер не знает, то браузер выдаст предупреждение системы безопасности. (К сожалению, ситуация такова, что для многих пользователей такое предупреждение означает примерно следующее: “Нажмите “Продолжить” для получения доступа к вашему любимому сайту”. Соответственно, пользователи привычно игнорируют предупреждение.) Важный момент: если соответствующий корневой ключ, в составе корневого сертификата УЦ, будет штатным образом импортирован пользователем в браузер, то никаких предупреждений браузер больше выдавать не будет. Это штатное поведение – импорт сертификатов требуется в корпоративных средах, а также в ряде других случаев (скажем, вы хотите использовать собственный УЦ для собственных сайтов). После успешного импорта, работа по HTTPS снова станет прозрачной. Но это относится только к браузерам, да и то, в случае, если они не используют каких-то дополнительных мер по отслеживанию ключей (плагины и пр.).

3.

На уровне промежуточного провайдера доступа (интернет-провайдера) можно потребовать, чтобы для успешного соединения с сайтами по HTTPS использовался именно тот набор параметров (в этот набор входит подменный сертификат), который разрешается. Детектировать параметры нетрудно – в действующих версиях TLS достаточно признаков: например, сертификаты передаются в открытом виде, поэтому легко проверить, какая цепочка используется в данном соединении (можно также привязать сессии к отпечаткам открытых ключей перехватывающего узла). Соответственно, оборудование DPI сможет предотвращать попытки установления HTTPS-соединений с недопущенными для применения параметрами. Все эти схемы давно отработаны на практике в корпоративных сетях, а оборудование и программное обеспечение – есть готовое.

4.

Тем не менее, при устройстве тотального MitM – много чего сломается: например, перестанут работать сервисы, использующие клиентскую авторизацию; возникнут проблемы с различными VPN; перестанут работать решения, которые используют привязку к конкретным открытым ключам на стороне сервера (это относится к приложениям для смартфонов, к различным клиентам онлайн-сервисов, начиная от месcенджеров, интернет-телефонии, систем телеконференций и заканчивая клиентами онлайн-игр).

5.

Главная проблема с перехватом TLS при помощи MitM в том, что такое решение полностью уничтожает смысл аутентификации узлов на стороне клиента. Дело в том, что клиент больше не может проверять валидность сертификатов оконечного узла, с которым пытается установить соединение: клиент просто не видит этого подлинного узла и сертификатов – он обменивается данными с перехватывающим, подменным узлом и вынужден доверять ему. Если на пути от подменного узла до узла, соединение с которым перехватывается, что-то пошло не так, то обнаружить это “не так” должен перехватывающий узел. Однако, он может этого не делать: вообще, ситуация, когда перехватывающий узел просто не валидирует сертификаты перехватываемого – встречается нередко. Более того, не в интересах перехватывающего прокси заниматься такими проверками. Так, этот узел не может видеть всего контекста установления соединения (часть контекста – у клиента: например, только клиент знает, какие ключи и сертификаты он ожидает получить от сервера), а поэтому в принципе не может надёжно проверить подлинность соединения.

6.

Технически, выпускать подменные сертификаты может тот или иной хорошо известный УЦ, то есть, УЦ, корневые ключи которого включены в стандартный дистрибутив браузера. Однако попытка массово реализовать подобное для большого числа ничего не подозревающих пользователей – скорее всего приведёт к тому, что ключи УЦ будут отозваны из браузеров. Тем не менее, УЦ попадались на подобных штуках.

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)



Комментарии (7) »

Я уже как-то писал на эту тему: сенсорам автомобилей-роботов можно ставить активные помехи. Собственно, до этой задачи потихоньку добрались публично – Wired рассказывает о том, как исследователи ставят помеху радару автомобиля Tesla, а также и ультразвуковым датчикам препятствий этого же автомобиля. (Не ясно, почему выбрали Tesla – возможно, из-за максимальной медийной узнаваемости.)

Эта тема имеет историю в несколько десятков лет. Правда, она касается не автомобилей, а военных радиолокационных комплексов самого различного назначения. Помехи ставили и ставят бортовым РЛС истребителей и радарам наземных комплексов ПВО. В тексте Wired, впрочем, ничего про военные системы не сказано, но это не отменяет истории разработок. Постановка помех – довольно хитрая область, где наряду с передовыми методами обработки сигналов и сложной микроэлектроникой применяется такая математическая дисциплина, как теория игр. В случае с военной техникой от искусственных помех специально пытаются отстраиваться (про естественные – и так понятно). Например, радары могут использовать сигналы сложной структуры (и во временной, и в частотной области), которые сложно обнаружить (LPI) и, соответственно, сложно поставить активную помеху, вводящую систему в заблуждение. Для автомобильной техники этот вариант, скорее всего, просто не рассматривается: максимум, система управления учитывает естественные помехи и пытается обнаружить ситуацию потери точности измерения, чтобы сигнализировать об “отключении автопилота” (именно так действует Tesla из статьи). Проблема в том, что активный помехопостановщик может создать картинку, неотличимую от настоящей, с точки зрения системы управления. И это большая проблема, потому что автомобиль с таким помехопостановщиком может находиться в потоке транспорта, хоть это и похоже на сюжет из киберпанковского кинофильма.

Роботам может помочь использование пассивных систем, например, видеокамер. Развитому машинному зрению помеху ставить сложнее. Однако на практике, без дополнительного инструмента измерения расстояния, которым является тот или иной сонар (радар, лидар), роботу сейчас довольно трудно – моделирование сцен только по данным камер представляет собой сложную вычислительную задачу. Впрочем, такие системы есть.

Несомненно, активные помехи автомобилям-роботам – это одна из перспективных тем, так что в ближайшее время мы тут увидим ещё много интересного, потому что вряд ли разработчики беспилотных автомобилей заблаговременно озаботятся защитой от такого рода атак. Просто потому, что такая озабоченность была бы ненормальной: хорошего инженера-робототехника заботят совсем другие задачи.



Comments Off on Автомобили-роботы и помехопостановщики

В контексте новой волны обсуждений разных “шпионских приложений – игр для смартфонов” особенно занятно то, что сам по себе смартфон, оказывается, мало кого пугал. Пока там не появилась очередная сверхпопулярная игра (специально не называю). Сошлюсь, пожалуй, на свою записку, опубликованную почти три года назад: “Эволюция телефонного аппарата как персонального жучка“.



Комментарии (1) »

Некоторое время назад выяснилось, что в Symasntec выпустили для Blue Coat промежуточный сертификат УЦ, который мог быть использован в SSL-прокси (для систем инспектирования трафика) – этот момент вызвал довольно живое обсуждение, так как прозрачный перехват TLS остаётся горячей темой в сообществе разработчиков браузеров. Следующее событие про эти две компании: Symantec покупает Blue Coat.



Comments Off on Symantec и Blue Coat

Недавно очередной раз опубликовали базу аккаунтов “ВКонтакте”, по которой построили распределение паролей по частоте использования. Результат там вполне предсказуемый, лидирует что-то вроде “123456”. Интересно другое. Немалое число людей, публикующих эту статистику, делают вывод, что всё плохо с безопасностью у пользователей, и дают советы и рекомендациями о том, как же нужно выбирать “неугадываемый” пароль, чтобы, мол, не оказаться в “верхушке данного списка”. Да, у пользователей с безопасностью плохо, а пароли нужно выбирать стойкие. Эти банальные советы, в данном контексте, выглядят особенно забавно. Посудите сами: причиной для раздачи советов является статистика, построенная по базе, где пароли уже содержатся в открытом виде. И какая разница, насколько “неугадываемый” пароль вы выбрали, если через два дня этот пароль будет опубликован вместе с остальными данными аккаунта, утекшими от провайдера сервиса?



Комментарии (2) »

Credit: https://www.flickr.com/photos/midpath/Что бы там ни писали в СМИ, но анонимность не является необходимым свойством той или иной криптовалюты. Если в качестве примера взять биткоины, то там анонимности транзакций не предусмотрено. Отправитель и получатель средств не скрываются, адреса кошельков могут быть сопоставлены с пользователями Интернета через анализ информации о маршрутизации пакетов, содержащих транзакцию (IP-адреса и пр.). Транзакционный трафик легко обнаруживается, блокчейн – доступен всем в открытом виде. Но, естественно, анонимизировать транзакции в биткоинах – возможно. Но для этого нужно использовать дополнительные надстройки, не входящие в протокол криптовалюты (например, сеть TOR или ещё что-то подобное). Существование технологий анонимизации, работающих с открытым и неанонимным протоколом криптовалюты, означает, что эти технологии переносятся на любую криптовалюту, в том числе, и на централизованную, лицензированную. Это весьма интересная особенность. (Отмечу, что разрабатывались и разрабатываются действительно анонимные криптовалюты – не биткоин! – но подобные алгоритмы, пока что, не получили распространения.)

Посмотрим в этом контексте на другой механизм (ограниченной) анонимизации платежей, работающий и для биткоинов, – специальные перемешивающие прокси. Принцип довольно прост: прежде чем воспользоваться своими средствами, клиент системы перечисляет их на прокси-кошелёк, то же самое делает большое число других клиентов; средства, таким образом, объединяются, перемешиваются. Клиенты прокси имеют дополнительные аккаунты, позволяющие распоряжаться их частью перемешанных в общем кошельке средств. Платежи осуществляются из прокси-кошелька: анализ блокчейна не позволяет понять, кто именно из клиентов прокси произвёл данную транзакцию – в качестве источника записывается проксирующий кошелёк. Естественно, если известны логи прокси, то можно сопоставить входящие кошельки и аккаунты внутри прокси, деанонимизировав платежи. Поэтому данная схема не даёт сколь-нибудь сильной анонимизации, но, тем не менее, работает и скрывает персонализированные пути движения средств в публичном блокчейне.

Почему это интересно в плане регулирования? Вот почему: если некий “эмитент” запустил центральную криптовалюту, обставленную внешним регулированием, то внутри этой криптовалюты кто-то может организовать прокси-сервис, который работает по описанной выше схеме. Таким образом, система, казавшаяся прозрачной, получит непрозрачный элемент. Естественно, сервис-прокси может быть быстро выявлен и заблокирован – у нас же криптовалюта имеет центральное управление, а это означает, что транзакции с конкретного адреса можно легко “перекрыть” (вот средства вернуть – уже сложнее, но это другая история). Тут-то и начинается самое интересное: оказывается, для обеспечения работы системы, которую продвигали как “дешёвую и самодостаточную”, требуется внутренний аудит и служба безопасности, выявляющие “отклонения” – в противном случае система быстро перестаёт соответствовать ключевым заявленным требованиям, например, вдруг становится анонимной.



Комментарии (2) »

GAO (это такой контролирующий правительственный орган в США) опубликовали отчёт, касающийся перспектив обновления государственных информационных систем. В нём, в частности, сказано, что в минобороны США до сих пор используют 8-дюймовые дискеты, в системе, связанной с планированием и управлением ракетно-ядерными силами. Тему дискет (которые сейчас принято считать 3D-принтерными версиями иконки Save из интерфейсов офисных программ), конечно, подхватили СМИ. При этом некоторые схожие системы в других странах (в США, впрочем, наверняка тоже) до сих пор используют перфокарты. И в этом нет ничего особо страшного. Строго говоря, большая дискета с низкой плотностью записи, при правильном использовании, достаточно надёжна. Но перфокарта, несомненно, лучше, потому что хранит данные чисто механическим способом.

Кстати, в GAO не упустили повода и заметили, что “современный флеш-накопитель по объёму хранимых данных эквивалентен более чем 3,2 млн дискет”. Сложно было бы придумать более банальное пояснение. Ну, ясное дело, если вы передаёте полётное задание для МБР на подводную лодку, очень важно упаковать его в какую-нибудь новомодную софтверную обёртку из встроенных процедур и свернуть вместе с NoSQL-СУБД и прочим ПО в контейнер Docker, который как раз влезет на флешку, если, конечно, удастся грамотно подобрать окружение. (Да, естественно, в отчёте названа и основная актуальная проблема дискет – их “сейчас сложно достать”.) Если вы военная система и передаёте примерно тысячу октетов в качестве полётного задания, то использовать вместо дискеты флешку, только потому, что это модно среди пользователей “офисных пакетов”, несколько неразумно. Я бы вернулся к перфокарте, но реализованной на современном уровне.

Другой неплохой пример “отсталых технологий” – линия голосовой связи на двух древних аппаратах ТА-57. Это старые, самодостаточные аппараты, оснащённые операционной системой типа “Ручку покрутил”. Соединяют их между собой проводами. В сравнении с современным смартфоном, ТА-57 имеет целый ряд преимуществ. Главное из них в том, что восстановить линию, если что, можно даже не при помощи пассатиж и монтажного запаса кабеля, но и лишь задействовав гвоздь и куски проводов с ближайшей, извините, свалки. Восстановить же с похожим инвентарём работу базовой станции GSM – получается, так сказать, далеко не во всех случаях (проверено, некоторые пробовали). А чинить смартфон в ситуации, когда может потребоваться ТА-57, – вообще нет смысла.



Comments Off on Дискеты в минобороны США

Flickr:  flickr.com/photos/nate/В “Коммерсанте” пишут, что InfoWatch открыто предлагает коммерческую систему для перехвата GSM, с автоматическим прослушиванием, записью и распознаванием. Цель – всё та же: корпоративная защита от утечек информации. (Занятно, кстати, что анализ разговоров не связан прямо с защитой от утечек: если сотрудник что-то наболтал, а система это запротоколировала, то это означает, что утечка уже произошла, налицо недоработка по предотвращению; впрочем, полученная информация может помочь предотвратить другие утечки, но чисто теоретически – так как серьёзные каналы, естественно, маскируются.)

Как сказано в статье, система представляет собой базовую станцию, которая принимает телефонные аппараты в зоне действия, расшифровывает данные и анализирует их. Подобные решения сейчас можно реализовать на базе открытого ПО и открытого аппаратного обеспечения. Например, годится пакет OpenBTS и подходящий модуль SDR (Software-Defined Radio). Проблему представляет прозрачность перехвата: для неё требуется участие “целевого” оператора связи. Но, вообще говоря, по причине отсутствия в GSM аутентификации сети в сторону абонентского устройства, возможны и варианты без участия оператора, однако они будут выглядеть топорно, а кроме того, у перехватываемого оператора должны возникнуть вопросы.

Вопросы внедрение подобной системы должно вызвать не только у операторов, но и у абонентов. Дело в том, что даже если “корпоративный абонент” дал согласие на подобный перехват, то такое согласие нужно ещё получить у тех, кто ему звонит (например, сообщая о записи разговоров перед установлением соединения). Но внедрение системы в таком открытом и очевидном формате существенно снижает (и так незначительный) смысл её использования. Скрытое же прослушивание телефонных разговоров – требует специальной лицензии, санкций и разрешений.

Систему можно установить только на территории компании, поэтому она никак не помогает в случае, когда сотрудник вышел поболтать в кафе. А если речь идёт о защите некоторого помещения или территории, то сложившаяся практика такова: устанавливается запрет на использование телефона, то есть, его либо нужно отключить, либо – вообще сдать на хранение при проходе КПП. Так или иначе, возможность использования связи GSM в защищаемом помещении блокируется. Это, действительно, предотвращает утечки.



Comments Off on InfoWatch и прослушивание GSM
Навигация по запискам: « Позже Раньше »