Пишут, Израиль официально подтвердил, что в 2007 году нанёс удар по “ядерному объекту” на территории Сирии. Речь про удар 6 сентября 2007 года, когда разрушили большое защищённое строение. С этим событием связана первая волна сообщений о сверхсовременных средствах РЭБ, которые использовали израильские ВВС для противодействия силам ПВО: обсуждалось, что эти комплексы РЭБ не просто позволяют ставить активные помехи, но даже “перехватывать управление” комплексом. Правда, подразумевались сильно устаревшие советские комплексы. Я, кстати, писал на сходную тему, но позже, в 2010 году: Сигнатуры, ПВО и утечки информации по побочным каналам.



Комментировать »

Немного теорий заговора. Сетевого уровня.

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

Интересно, как можно обнаруживать подобные действия?

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

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

IP или, например, UDP, оказываются универсальными в силу того, что работают на общем для всех узлов IP-сети логическом уровне. При этом другие протоколы спускаются на несколько уровней ниже. Так, есть инструменты VLAN (виртуальные сети) и другие логические элементы, невидимые для IP. Связанные с ними протоколы также можно было бы использовать для передачи недокументированных сигналов. Однако из-за того, что свойства даже соседствующих сетей на соответствующих уровнях очень сильно разнятся, тут встречаются трудности. С другой стороны, можно представить ситуацию, когда использование расширений стандарта Ethernet (например) позволяет скрывать от анализаторов трафика, работающих параллельно маршрутизаторам, целый пласт ходящих по физической линии связи данных. Элементарный пример, понятный каждому: представим, что для анализа трафика используется обычный компьютер и Wireshark, но продвинутая сетевая карта – игнорирует часть пакетов, например, обнаружив в заголовке Ethernet некоторый заранее зашитый в процессор карты индекс (заметьте, что такое поведение аналогично штатной функции, позволяющей разграничивать VLAN-ы). Понятно, что Wireshark в таком случае не будет видеть часть трафика, и обнаружить, что видны не все пакеты, вряд ли получится. Конечно, пакеты могло бы прятать и ядро ОС, но аппаратная фильтрация сетевой картой – куда как более эффективна: зафиксировать передачу данных теперь можно только при помощи логического анализатора, подключенного непосредственно к проводам. А вот уже представить себе логический анализатор, который прячет сигналы, гораздо сложнее, чем только что описанную конфигурацию с продвинутой сетевой картой. Но многие ли мониторят сети при помощи логических анализаторов? (Вопрос даже не риторический, а скорее похож на шутку.)

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



Комментировать »

SpaceX начали выводить на орбиту спутники связи, предназначенные для реализации проекта глобального беспроводного доступа к Интернету. А нам, конечно, интересно подумать над занимательными побочными эффектами данного масштабного начинания. Один из этих эффектов такой: так как это спутники связи, на борту у них есть приёмники, передатчики и антенны. При этом, так как требуется организовать широкополосную многоканальную качественную связь, все эти элементы обладают высокой гибкостью в плане управления: на дворе двадцать первый век, так что, скорее всего, на борту будет система с полностью перенастраиваемой логикой, способная быстро и точно генерировать весьма сложные сигналы. Все эти параметры необходимы для эффективного кодирования и оптимизации использования радиоканала.

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

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



Комментарии (2) »

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

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

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



Комментировать »

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

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

Простой поиск, опять же, легко реализуется штатными средствами нашего условного ПО. Однако нужно ожидать большого процента ложных срабатываний. Понятно, что если к интересным относить все файлы, содержащие слово missile, то даже при ограничении выборки на определённые ПК, в ответ приедет слишком много мусора, и не приедет слишком много интересного, потому что, например, действительно интересные файлы программный комплекс неправильно преобразовал, перепутав кодировку. Перепутать что-то довольно легко: предполагается, что программа работает на самых разных конфигурациях ОС и прикладных пакетов.

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

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

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

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

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



Комментировать »

Ещё немного о навигации: из NASA сообщают, что успешно на практике использовали рентгеновские пульсары для определения положения аппарата в космическом пространстве. В качестве приёмника сигналов послужила рентгеновская обсерватория NICER, установленная на борту Международной космической станции, а сам эксперимент называется SEXTANT (Station Explorer for X-ray Timing and Navigation Technology).

Логика работы данного прототипа навигационной системы такая же, как описана в научной фантастике: периодические сигналы пульсаров обладают высокой стабильностью, соответственно, если их правильно подобрать, то можно вычислять положение приёмника. Что и продемонстрировали для МКС – отклонение (радиус) получилось лучше 10 миль, для космической навигации вполне достаточно (обещают улучшить).

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



Комментарии (3) »


Комментировать »

Год 2018, новый

Время традиционной новогодней записки на dxdt.ru. На этот раз завершается 2017 год, в котором число записок, опубликованных на dxdt.ru, уменьшилось радикально. Мне это не нравится, но что с этим делать я пока не придумал. Я не придумал даже какого-то существенного объяснения данному “феномену”. Обычно, в новогодней записке я пишу, что хорошо бы как-то увеличить число (содержательных) публикаций здесь, вернувшись к старым показателям. Но вернуться пока не получилось. Так что в данной записке этот момент постараюсь обойти. Будем считать, что, в принципе, какие-то занятные публикации всё же выходили. Например – вот, и ещё вот, и ещё про смартфон.

В общем, если кто-то ещё читает, то спасибо вам и с наступающим Новым Годом!



Комментарии (5) »

Прошло три года с тех пор, как я сделал на dxdt.ru HTTPS основным протоколом. До сих пор на запросы по URL, начинающимся с http://, веб-сервер отвечает редиректом (301) на соответствующий HTTPS-адрес. То есть, HTTP всё ещё поддерживается в качестве “точки входа”. При этом в ответах сервера присутствуют заголовки HSTS, соответственно, браузер, однажды обратившись по HTTPS, уже не должен использовать HTTP для доступа к dxdt.ru (формально – в течение длительного времени, которое определено в заголовке HSTS). Обращения по http:// всё ещё видны в логах (всякие старые ссылки и пр.), поэтому отключать HTTP совсем – я пока не планирую. Идея такая, тем не менее, есть. Вообще, учитывая весьма небольшой трафик на dxdt.ru и тот факт, что те, кто сайт читает, очевидно, имеют возможность подключаться по HTTPS, отключение HTTP не выглядит абсурдным.

Кстати, за три года общее проникновение HTTPS выросло весьма и весьма заметно. Если взглянуть на статистику по зоне .RU, то даже с 2015 года число узлов с корректной настройкой TLS для HTTPS выросло в 12 раз (прописью: в двенадцать раз). Ни одна другая фундаментальная технология доставки контента не демонстрирует сейчас подобного роста.



Комментарии (5) »
Навигация по запискам: « Позже Раньше »