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

В блоге на сайте “Ведомостей” Игорь Ашманов пишет про недавнюю историю с “запретом” Gmail и Skype. В заметке есть занятное высказывание, контекст его – обсуждение инфраструктурных рисков для государства, связанных с Интернетом, цитирую:

Пока браузеры делаются не у нас, через браузер с компьютером можно сделать почти все.

Вот как, выходит. Сильно, да? На мой взгляд, если рассуждать с точки зрения “сделать что-то с компьютером”, то нет разницы, где “делаются браузеры”. Ну то есть происхождение браузера не связано с тем, можно как-то через него отключить (к примеру) компьютер или нет. Значение имеет аудит кода, если уж на то пошло. А сделать браузер с закладкой можно и у нас, и “не у нас”, одинаково успешно.

Похоже, что происхождение подобных предостережений кроется вот в чём. Есть смысл в использовании при создании военной техники элементов, производимых государством самостоятельно. Такая автономность позволит, если вдруг что, обслуживать эти вооружения собственными силами, находясь в изоляции. Разумно? Да, очень разумно, если есть технологическая возможность поступать подобным образом. Но при этом на практике большинство государств закупает зарубежную военную технику и системы, в том числе, сложные системы ПВО и авиацию. Понятно, что зенитно-ракетный комплекс ПВО – это вам не какой-то там браузер для просмотра веб-страничек. И тем не менее – закупают.

Так вот, можно попытаться переводить этот принцип “военной элементной базы” на браузеры, предназначенные для исследования Интернета, созданного и контролируемого США. Правда, это больше похоже на доведение до абсурда. Но, тем не менее, вот эксперты в “Ведомостях” предлагают такое на голубом глазу. Странно читать подобное.

Развитые и гибкие информационные системы сейчас сращиваются с не менее сложными механическими. Эти механические системы – они старые, традиционные, принадлежат другим отраслям, не к ИТ. Живой пример: современные автомобили. С некоторого момента сложность этих информационных систем оказывается достаточной для того, чтобы привлечь специалистов по информационной безопасности.

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

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

Интересно, что станет развиваться быстрее – требования по информационной безопасности или проникновение информатизации во все классические механизмы? Одно дело – взломать компьютерную систему автомобиля при помощи специально подготовленного “музыкального” диска. А совсем другое, если технохакеры возьмутся за какой-нибудь “умный дом”. Вообще, эти “умные дома” – это очевидынй следующий шаг, после автомобилей. При этом в доме куда больше всяких потенциально уязвимых объектов: климатическая система, двери, окна и так далее.

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

Посмотрим-посмотрим.

Тема открытый код против закрытых исходников – не иссякает: вот, например, в работе The Mathematics of Obscurity: On the Trustworthiness of Open Source (найдено в блоге Алексея Лукацкого) авторы, построив некую модель жизненного цикла программного кода, приходят к выводу, что открытый исходный код не улучшает “надёжность и безопасность”. Грубо говоря, уязвимости всё равно найти можно, несмотря на то, что код (теоретически) проверяют многие разработчики. А вот в закрытом коде – найти уязвимости может быть сложнее (ну, выходит, именно из-за того, что такой код сложнее анализировать).

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

Вот сообщают новости из мира разработки ПО:

По словам Перри, в то же время он консультировал ФБР в рамках проекта, занимавшегося внедрением закладок в смарткарты и прочие аппаратные средства защиты. Кроме того, он сообщил, что тогда же ФБР внедрила ряд закладок и в OCF [OpenBSD Crypto Framework], и вот теперь закончившаяся десятилетняя подписка о разглашении перестала мешать раскрытию этого милого факта.

Кстати, там речь о коде, который позже изменяли многократно. Интересный вопрос, как нужно устроить логическую закладку, чтобы она переживала массированное переписывание кода? Теоретически, понятно, что можно спроектировать очень стойкую закладку, наследуемую из версии в версию. Более того, по-моему, очевидно, что плохая закладка будет обнаружена в ходе эволюции кода. При этом закладку разработчики истолкуют как банальную ошибку.

Но можно же и более тщательно спроектировать архитектуру. Да.

В продолжение интересной темы об изготовлении копий ключей по фотографиям. Некоторое время назад обсуждалась специальная компьютерная программа, которая реконструировала важные для замка параметры ключа едва ли не автоматически. Посмотрим на задачу чуть подробнее: какие там есть сложности, и хитрости, позволяющие сложности обойти.

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

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

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

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

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

А если заготовка нестандартная? Тогда параметры оптической системы можно определить по каким-то другим объектам, геометрия которых известна, при условии, что их изображения находятся на том же снимке. А кроме того, современные объективы и фотокамеры – тоже вполне себе стандартные. Получив тип устройства из сопутствующей информации (EXIF), часть нужных параметров можно взять из справочника, а не вычислять.

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

Достаточно давно я писал (в том числе, на страницах dxdt.ru) и рассказывал, что главный шаг на пути развёртывания DNSSEC – это массовое внедрение поддержки проверки подписей DNS на клиентские машины, а вовсе не подписывание корневой зоны. Понятно, что без подписи корня нет смысла продвигать DNSSEC на клиентов Интернета, потому что теряется возможность центрального контроля адресации в разросшейся Сети. Но важен как раз следующий шаг – новые резолверы на клиентских машинах (а не на серверах DNS), которые, например, не позволят интернет-провайдерам подмешивать всякую ерунду в DNS-ответы своим клиентам.

Собственно, теперь, когда зону успешно подписали, о втором шаге рассказывает уже ICANN: в официальном блоге пишут про предложенный Деном Камински (Dan Kaminsky) инструментарий, внедряющий поддержку DNSSEC на стороне браузера (например, упоминают “частную” версию Google Chrome, полностью поддерживающую DNSSEC) и почтового клиента. Собственно, это правильно.

До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.

В ночь с 15 на 16 июля корневую зону DNS подписали настоящим ключом и опубликовали открытые ключи для проверки подписей DNSSEC. Таким образом, Минторг США, компания VeriSign и ICANN завершили развёртывание DNSSEC в корневой зоне. Собственно, теперь DNSSEC можно использовать в глобальной DNS. Ключи каждый может взять на сайте IANA.

Теперь поддержку DNSSEC начнут массово вводить в доменах первого уровня.

Напомню, что следующие шаги на пути к новому Интернету – внедрение IPv6 и модернизация принципов маршрутизации (через внедрение криптографических механизмов).

В продолжение темы про охрану автомобилей: есть ещё задача “дистанционного информирования” владельца о каких-то проблемах с охраняемым авто, например, сработал какой-нибудь там датчик.

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

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

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

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

Интересно, что применение для передачи сообщений “о состоянии автомобиля” особых “широкополосных” и “шумоподобных” сигналов, которым сложнее ставить помеху, не выглядит оправданным: ведь ту же задачу решает GSM.

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

В схеме (по правилам), администратор домена отправляет скан паспорта регистратору через Интернет (как один из способов, который, наверняка, наиболее распространён). Но администратор не получает гарантий, что его скан был получен и принят (с учётом даты и времени получения). То есть, при возникновении спорной ситуации, недобросовестный регистратор может заявить, что скана вообще не получал. При этом у администратора домена нет возможности как-то доказать, что скан передавался.

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

Реализовать подтверждение можно и чисто электронными средствами: электронный скан подписывается закрытым ключом регистратора и возвращается подавшему его администратору.

В продолжение темы про привязку авторизации к адресам e-mail. Как должна работать правильная напоминалка пароля от того или иного интернет-сервиса по e-mail?

Очевидно, нельзя высылать почтой пароль (новый/старый) в открытом виде. Высылать нужно специальную ссылку на интерфейс смены пароля. Ссылка работает по https и содержит одноразовый ключ, действующий определённое время. К счастью, эта схема уже фактически стала стандартным вариантом. Тем не менее, иногда можно от разработчиков услышать возражения такого типа: какая разница, что высылать, сам пароль или ссылку? если кто-то посторонний читает почту, то он одинаковым образом сможет получить и то, и другое. Возражение ошибочное. Схема со ссылкой существенно безопаснее. Судите сами.

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

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

А в дополнение к одноразовым ссылкам нужна капча в самом интерфейсе смены пароля.

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

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

Можно воспользоваться анализом служебного GSM-трафика. Суть сводится вот к чему. Наверняка у разыскиваемого абонента есть другой, вполне официальный мобильный телефонный аппарат. Требуется найти этот аппарат, и идентифицировать абонента по нему. Предположим, что оператор связи ведёт подробные логи перемещения аппаратов между сотами и логи звонков этих аппаратов (доставки/отправки SMS, передачи данных и т.п.). В общем, понятно, что такие логи нужны и на практике имеются за какой-то период.

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

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

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