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

А занятно читать шумиху о том, что хакеры, поломавшие очередной удостоверяющий центр, смогли выпустить даже “сертификаты сайта ЦРУ” или, скажем, “даже сертификаты для доменов com и org”. Ну раз уж есть доступ к соответствующему закрытому ключу, то какая разница, что подписывать? Можно любой домен подписать. И это не будет иметь отношения к HTTPS на сайте ЦРУ.

Да, тут есть проблема: успешное коммерческое развитие SSL привело к тому, что за ключами и центрами следить уже не успевают, поэтому уводить ключи и ломать центры будут и дальше, это понятно. Тем более, что правила хранения ключей нарушаются постоянно.

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

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

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

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

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

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

Стартовал приём заявок на конкурс WebHiTech по версии 2011 года. Заявки принимаются до 3 ноября (включительно), потом состоятся два этапа судейства жюри конкурса, которое определит победителей и призёров. О результатах объявим, ориентировочно, в середине декабря.

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

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

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

Если в .ru сейчас более 3.3 млн имён, то в .рф – только около 880 тыс. Это свидетельствует о том, что богатое (в теории) разнообразие кириллических имён ещё не востребовано на практике. Да, конечно, нужно учитывать, что домен .ru много лет набирал свои миллионы и сейчас темп регистраций в нём тоже снижается. Но домену .рф, похоже, грозит уже не снижение темпов роста, а заметная убыль числа имён. (Ну если не запустить какую-то программу поддержки.)

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

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

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

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

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

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

Скажем, приложение от поисковика умеет определять координаты пользователя по точкам доступа Wi-Fi. Соответствующий сервер геолокации – открыт и общедоступен. Поэтому всякий достаточно квалифицированный специалист может определить местоположение любого чужого компьютера, для которого известны MAC-адреса близлежащих точек Wi-Fi. Узнать MAC-адреса можно с помощью трояна, засланного на компьютер атакуемого пользователя. Для того, чтобы получить координаты, понятно, не нужно взламывать сервера геолокационного сервиса: достаточно взять подходящее приложение, – хоть бы вот мобильные “Яндекс.Карты”, – и подсунуть этому приложению нужные MAC-адреса, что можно сделать с помощью соответствующих SDK (инструментариев разработчика). В ответ – получить на экране примерное местоположение искомого компьютера, обозначенное на карте. Очень удобно. И не требуется GPS, поддержки которой может и не быть.

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

В продолжение темы про Chrome, который, якобы, переправляет в Google контент закрытых страниц из корпоративных интранетов: интересно подумать, как можно было бы устроить подобный шпионский браузер. Понятно, что едва ли Google что-то подобное делает, потому что не ясны стратегические выгоды: ну чего там интересного для массового пользователя можно найти в интранетах? Тем более, что и ссылку-то не покажешь: сервер же закрыт. В исходном вбросе, направленном на тематические СМИ, по той или иной причине не разработан технический аспект: то есть нет легенды, как именно Chrome “сливает инфу”. А ведь это был бы самый занимательный кусочек истории.

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

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

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

Другой вопрос: что взять за основу для построения канала утечки? А тут годятся любые сервисы, принимающие некие персонализированные настройки (например, проверка посещаемых URL на “фишинговость и вредоносность”). Сжатый текст будем передавать так: небольшие блоки подмешиваются в токены, которые браузер генерирует при формировании запроса на сервер. Пусть токен содержит 64 байта. Предположим, что 16 из них – это данные утечки. Тридцать запросов с токенами (не много) – 480 байт. Хорошим кодированием можно ужать сюда примерно 2500 знаков текста (можно и заметно больше). Необязательно поддерживать канал открытым, пока не передан весь собранный текст (см. ниже). Вообще, нет никакой необходимости, создавая такой браузер, встраивать в него излишнюю надёжность. Механизмы обеспечения такой надёжности только выдадут затею. Центр посеял много браузеров в окружающее киберпространство. Какие-то из них что-то приносят, какие-то – нет, они сломались. Нестрашно, многочисленность источников компенсирует (для центра) ненадёжность каждого из них.

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

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

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

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

(Продолжение про риски и политику.)

Кстати, успешный вброс истории о том, как браузер Chrome отсылает содержимое (да, именно, они так и написали) веб-страниц из закрытых интарнетов в Google для индексации, – см. например, бурное обсуждение на roem.ru, где активность поддержала редакция, – это неплохой задел в подготовке почвы для обоснования разработки “своего безопасного браузера”. То есть, потом, в рамках информационной кампании, можно ссылаться: были публикации в специализированной прессе, “продемонстрировавшие нам”, ну и так далее.

В общем, нужно последить за новостями. Это интересно.

Наверное, многие уже слышали про популярную сейчас охоту за утечками персональных данных в поисковиках. Тут очень весело читать, как следом за пресс-службой “Яндекса” в тематических СМИ поминают веб-мастерам файл robots.txt, обвиняя в том, что веб-мастера, дескать, не подготовили “правильное описание сайта”. Robots.txt никак не является инструментом для разграничения доступа на веб-сайте. И не может оправдать слишком любопытного бота, выкладывающего данные из закрытых разделов серверов в общий доступ.

Если посмотреть на ситуацию с технической стороны, то элементы URL-а (грубо говоря, вся часть после имени хоста) – это специальные параметры, предназначенные для изменения состояния веб-сервера. Веб-сервер – это программа, которая извлекает с диска некоторые файлы. Доступны ли эти файлы всем обратившимся на сервер, не доступны ли – регулируется это вовсе не неким robots.txt. В современной веб-разработке вполне себе нормальна передача секретных ключей доступа в параметрах URL-ов. Ну так вот сложилось. Например, так передают одноразовые ключи в системах восстановления паролей по e-mail. И это правильно, потому что является эффективным и безопасным методом, учитывающим подготовку и технические возможности среднего пользователя. Особенно актуально для сайтов, ориентированных на массового клиента.

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

(Да, а ещё можно устроить робота-паука так, что он станет подбирать ключи в URI; надеемся, что “Яндекс” так не поступает.)

Поэтому, когда “Яндекс” или другой поисковик индексируют “секретные URL”, которые узнали тем или иным способом, – их действия, в общем-то, аналогичны ситуации, когда робот-паук передаёт веб-серверу с помощью метода POST логин и пароль. И не нужно тут пенять на веб-мастера, что он robots.txt не написал.