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

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

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

О чём эта модель напоминает? О программном обеспечении веб-серверов, например. Или, более конкретно, о CMS. Давно известно, что подавляющее большинство уязвимостей в CMS связано с недостаточным контролем “вводимых данных”, поступающих, опять же, из реального мира. Если проектировавший CMS инженер слишком доверяет поступающим из глубин Интернета данным, считает, что эти данные обязательно будут выглядеть именно так, как задумал инженер, то тут же возникает целая россыпь уязвимостей, потому что умелый хакер подсовывает совсем не те данные.

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

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

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

(Фото к тексту отношения не имеет.)

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

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

Между тем, шумиха про уязвимость DNS, якобы “массово исправленную”, это не более, чем очередная PR-акция в поддержку повсеместного введения DNSSEC. Именно так. С очень забавным пафосом про уязвимость пишут рунетовские интернет-СМИ. Например:

“Уязвимость […], которая могла бы затронуть значительную часть Интернета, исправлена общими усилиями специалистов по сетевой безопасности и крупных корпораций…” – это “Вебпланета“.

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

Давненько мы не касались интернет-технологий. Нужно исправлять упущение. В этот раз – про “Большого брата” и рекламный таргетинг.

Известно, что во многих случаях рекламу лучше покупают у того “рекламного провайдера”, у которого она эффективнее. То есть чем больше товаров/услуг удалось продать в пересчёте на бюджет, тем лучше. Хотя понятно, есть, видимо, множество оговорок, о которых лучше спросить маркетологов. Особенно в свете того, что наша записка о другом.

Так вот, для повышения эффективности рекламы лучше предъявлять “субъекту” именно ту рекламу, которая ему будет максимально интересна. Это банальность. Из банальности выросли системы контекстной рекламы современного Интернета. Эти системы, пользуясь современными технологиями, улучшают качество контекста. Давайте посмотрим на примерах.

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

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

Есть, конечно же, и другие способы. Например, код рекламной сети может отслеживать ссылку, по которой пришёл на данный сайт посетитель, и регулировать выдачу объявлений в соответствии с “тематикой ссылки”. Продвинутая система уже использует запись истории “сёрфинга”, опознавая веб-читателя по кукам и IP-адресам. На основании истории возможен уже “поведенческий таргетинг“, понятно, в автоматическом режиме. Хороший провайдер контекстной рекламы дружит с распространёнными “счётчиками” (то есть с сервисами статистики, устанавливающими свои кнопки на сайтах, например – li.ru). Понятно, что чем больше сайтов охвачено системой учёта, тем более точная возможна слежка.

Но развитие чисто интернет-систем “рекламной слежки” уже подошло к своему пределу, многое съедено, места для развития всё меньше. Что дальше?

Что нужно для того, чтобы сделать идеального “Большого брата”?

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

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

Для чего куки, если провайдер и так видит сетевую активность пользователя? А вот для чего: предположим, что этот провайдер предоставляет доступ по Wi-Fi, в самых разных районах, самым разным, свободно перемещающимся по этим районам, пользователям. Раздача пользователям дополнительных идентификаторов, например, в тех самых куках – очень хорошо поможет различать пользователей в дальнейшем. Особенно тогда, когда пользователь подключится к другому интернет-провайдеру с того же самого компьютера. На этом шаге, кстати, играет решающую партию карманный интернет-ресурс, упомянутый выше в качестве дополнительного инструмента: используя этот ресурс, можно опросить куки и определить, к какому же провайдеру перешёл пользователь.

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

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

Кто первым построит подобную систему в Рунете? Ответ на этот вопрос вынесем за рамки заметки.

Первая уязвимость в официальном релизе Firefox 3 (судя по комментариям, вполне себе критическая) заявлена прямо в тот же день, когда была предпринята попытка установления рекорда скачиваний новой версии браузера. И в этом нет ничего удивительного. (То есть, понятно, что все те дистрибутивы, которые сформировали “рекордное число”, раздавались с критической уязвимостью.)

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

Раньше мы разобрались: многоязычные домены вводят таким образом, что собственно саму систему DNS они вообще не затронут (подробнее – в прошлой заметке). Так что рассказы о том, что “проблемы с поддержкой системой DNS” – это обманные рассказы.

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

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

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

Что делать?

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

Собственно, например в Google, через форму добавления сайтов уже можно отправлять многоязычные URL. А во вполне русскоязычный (вроде бы) “Яндекс”, как, впрочем, не сложно догадаться, – нельзя. Там, конечно же, равно такая ситуация, как и только что описанная:

Очевидно, у Касперских действительно уже есть какие-то хитрые криптологические ходы в запасе, чтобы раскрыть ключи шифрующего пользовательские файлы вируса Gpcode. Иначе публиковать приглашение к факторизации 1024-битного ключа RSA “всем миром” – это несколько странно.

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

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

Понятно, что приступать к факторизации, имея на руках только 1024-битный ключ (если он хороший, конечно) – было бы поспешным решением со стороны специалистов.

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

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

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

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

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

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

А хорошие продукты у сообщества вполне получаются (тот же WordPress, например; или Joomla!, Drupal – отличные продукты). Другое дело, что те, кто хорошее реально создаёт, в бучах, думаю, штампованными мантрами не ругаются.

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

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

Комикс по теме:

(Источник комикса)

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

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

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

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