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

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

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

Сейчас на борту боевых самолётов уже есть разные лазерные системы. И эти лазеры планируют использовать для создания каналов обмена информацией. При достаточной мощности и добротном приёмнике не обязательно использовать стекловолокно, луч уверенно распространяется в атмосфере. Наверное, вы уже догадались, что по сравнению с радиосвязью у лазерной системы есть то же самое преимущество, что и у ИК-порта перед Bluetooth: лазерный луч очень узкий, переносит информацию только в направлении приёмника. Чтобы подслушать сигнал нужно очень постараться: если оставить фантастику с фиксированием всяких вторичных процессов в атмосфере, то для перехвата потребуется разместить приёмник непосредственно внутри луча. Что непросто, в случае с находящимся в воздухе самолётом, который, к тому же, маневрирует. А вот радиосвязь, даже при использовании направленных антенн, всё равно работает во все стороны, просто, для разведки потребуется более чувствительный приёмник. И при этом лазерная система ещё и позволяет построить гораздо более широкий канал, в смысле объёма передаваемой информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интересную штуку сделали Mike Tassey и Richard Perkins: беспилотник, обнаруживающий и анализирующий точки доступа Wi-Fi с воздуха. Да и не только Wi-Fi: как пишут, бортовое оборудование умеет прикидываться базовой станцией GSM и перехватывать трафик мобильных телефонов. При этом всё реализовано на открытых платформах: ОС – Linux (тут, как известно, есть богатый инструментарий для, так сказать, радиоприложений); система управления, автопилот – на Arduino (проект ArduPilot).

В общем, это такой “кустарный” беспилотник, использующий общедоступные технологии и способный решать задачи радиоэлектронной разведки. А если чуть развить идею, то и задачи партизанской РЭБ такая платформа решает: разработчиками сразу заявлено, что на борту есть ПО для взлома защищённых сетей Wi-Fi, что не должно удивлять, если учесть наличие отличного инструментария под Linux.

Вот именно поэтому сейчас набирает популярность тема средств перехвата небольших беспилотных летательных аппаратов. Но это уже другая история.

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати, поисковые машины, которые пытаются дотянуться до всего в Вебе, уже научились автоматически фильтровать и изменять собранный контент таким образом, чтобы не раскрывать личные данные тех или иных людей. Например, Google замазывает лица и автомобильные номера на панорамах улиц в Street View. Примерно то же можно сделать и с персональными данными, поиск утечек которых в “Яндексе” сейчас довольно популярное занятие, освещаемое СМИ.

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

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