dxdt.blog: занимательный интернет-журнал

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

В декабре прошлого года я описывал тонкости реализации прозрачного перехвата TLS. Кроме прочего, в той записке есть и фрагмент про перехват с участием УЦ, но когда УЦ секретные ключи на отдаёт третьей стороне (чтобы меньше нарушать требования). Цитата:

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

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

В 2008 году я предположил, что ввести рельсотрон (электромагнитную пушку) в строй удастся лет через пять-семь, “как минимум”. Что ж, прогноз хоть и “сбылся” (ну, да, там же было сказано “как минимум”), но всё же оказался слишком оптимистичным: прошло восемь лет, а рельсотрон как был лабораторным изделием, так им и остался. Но зато отлично работает для создания шумихи в прессе.

Интересно, чем же именно должна стрелять такая пушка. Стрельба простой болванкой, конечно, занимательна, но на дальностях более 200 км точность будет невысокой. Учитывая, что болванка, в случае попадания, оказывает сугубо “локальное воздействие”, смысл стрельбы вообще теряется. Снаряд должен быть корректируемым. Управлять быстрым снарядом в полёте можно при помощи небольших аэродинамических поверхностей. Есть отработанные схемы. Проблему представляет размещение на борту микроэлектроники: она должна пережить и ускорение, и электромагнитное воздействие при выстреле. Впрочем, General Atomic рапортуют, что справились и сделали подходящую электронную начинку, а также продолжают её испытывать.

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

Update (20/02/19): реализовал преобразования блока на ассемблере для платформы x86-64/amd64, это даёт прирост производительности в несколько раз – доступна новая версия, использовать лучше её.

“Кузнечик” это новый российский блочный шифр, в прошлом году стандартизованный ГОСТ Р 34.12-2015. Шифр работает с блоками в 128 бит, ключ имеет длину 256 бит. (Текущим аналогом является шифр AES.) На досуге я реализовал “Кузнечик” на языке Go. Это, конечно, реализация пока далёкая от оптимальной и строгой (в смысле “криптокода”). Например, работа с блоками написана “побайтово”, не используются другие достаточно очевидные оптимизации и штатные языковые конструкции Go (я пока не очень освоился с данным языком). Так сказать, альфа-версия. Приветствуются комментарии, поправки. Возможно, имеет смысл развивать дальше.

Исходники выкладываю на dxdt.ru:

исходный код модуля grasshopper (Kuznyechik, GOST R 34.12-2015);
небольшая программа для проверки работоспособности (реализован стандартный вектор проверки и один дополнительный);
оба файла в .tar.gz.

(Внутри исходников комментарии на английском.)

Некоторые технические пояснения. Работу данного шифра можно ускорить, если использовать достаточно большие таблицы с предвычисленными преобразованиями. Именно этот вариант и реализован. Впрочем, функций Decrypt – две. Одна версия использует все таблицы, вторая – только одну, в которой содержатся предвычисленные значения линейного преобразования. Сами таблицы не содержатся в исходном коде, а вычисляются вызовом функции инициализации. В Go есть штатная библиотека, реализующая режим аутентифицированного шифрования GCM. Обычно этот режим используют в связке с AES, но годится и другой шифр подходящей разрядности. Соответственно, есть идея реализовать связку Kuznyechik-GCM, которая уже является практически полезным инструментом (update: реализовал режим GCM).

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

Англоязычное пояснение:

This post describes GOST R 34.12-2015 Kuznyechik reference implementation in Golang. More comments – in Go source code for Kuznyechik. There is a different version available.

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

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

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

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

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

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

О системах противоракетной обороны я периодически писал на dxdt.ru, вот, например, три старые заметки по этой теме:

• ПРО по слоям (краткий разбор работы ПРО на разных уровнях-эшелонах);
• Управляемая боеголовка МБР и тип топлива (коррекция траектории нужна не только для преодоления ПРО);
• Планирование траекторий боеголовки (о непредсказуемости траектории).

DARPA заказывает новую программу POSYDON, результатом которой должно стать построение в океане опорной навигационной сети для подводных аппаратов. В качестве подрядчика выбрали Draper (это известная Лаборатория Чарльза Старка Дрейпера, вышедшая из Массачусетского технологического института).

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

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

Что касается подводной передачи навигационных сигналов, то, естественно, вряд ли будет использована радиосвязь, по понятным причинам. Акустический сигнал под водой может распространяться на достаточно большие расстояния. Так что, учитывая возможности по цифровой обработке и то, что для передачи навигационных данных не требуется большая информационная ёмкость, схема вполне реальна. Другое дело, что для противодействия могут быть использованы помехопостановщики.

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

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

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

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

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

Positive Technologies подтвердили известную вещь: при помощи перехвата SMS можно получить доступ к аккаунтам мессенджеров, даже тех, которые продвигаются как особенно защищённые. В ответ появляются статьи, где пишут, что сами мессенджеры всё равно защищённые, это виноват транспорт, канал связи (все показывают в сторону операторов). Например, подзаголовок статьи The Register гласит: WhatsApp, Telegram secure – but the transport isn’t (хотя цитаты в самой статье об этом не говорят).

Картина полностью копирует давнюю ситуацию, когда считалось, что пароли можно передавать по HTTP в открытом виде, потому что должны быть защищены от прослушивания каналы связи, по которым “работает Интернет”. Вообще, в GSM есть проблемы, в том числе, происходящие из того, что система межоператорского взаимодействия (откуда и растёт набор сигналов SS7), использующаяся для обмена данными об абонентах и для управления сетью, построена на доверии (то же самое, кстати, касается и маршрутизации в Интернете – BGP). Это всё давно известно. Также как давно известно, что можно прослушать телефонный разговор по обычному проводному телефону, если подключиться к проводам. Но разработчики “защищённых” мессенджеров должны бы учитывать эту возможность. Ведь они научились использовать шифрование при передаче сообщений, признали, так сказать, открытые каналы открытыми. Операторы связи вряд ли станут исправлять ситуацию в обозримом будущем – в этом нет смысла. А полагать, что оператор должен защищать все мыслимые сервисы своего абонента, которые прямо или косвенно используют сеть GSM, – несколько наивно.

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

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

Предположим, что пользователь применяет для работы с некоторым сервисом приложение (программу-клиент), предлагающее ввести пару логин/пароль и дополнительный код. Нередко, протокол, реализующий проверку данного кода, позволяет имитировать сессию. В локальном случае – пользователю показывается имитатор приложения, где он указывает все “факторы”. Удалённая схема работает иначе: перехватывается начало сессии, внешним узлом имитируется работа авторизационного сервера (делается, например, при помощи подмены DNS силами взломанного роутера), а уже этот узел собирает валидный набор параметров аутентификации (их предъявляет приложение); в чуть более продвинутом случае, когда используется схема “запрос-ответ”, перехватывающий узел проксирует и запросы, и ответы. (Да, очевидно, что схема сработает только в случае недостаточно защищённого канала.)

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

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