Можно ли создать такой ключ реестра, который будет виден в Windows в составе активного (подключенного) реестра, но не будет виден программам, работающим с неактивным (отключенным) реестром? Оказывается, если у вас есть возможность изменить лишь одну переменную ядра (например, с помощью драйвера), то да, способ есть.

Зачем это нужно?

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

1. сокрытие внесенных в реестр изменений от криминалистического исследования (например, сокрытие ключей определенного сервиса, которые будут корректно прочитаны и использованы операционной системой Windows в процессе загрузки, но не будут видны для сторонних программ, работающих с неактивным реестром, во время исследования накопителя);
2. сокрытие внесенных в реестр изменений от предзагрузочного контроля целостности (например, внесение таких изменений в ключи реестра, которые не будут видны для модулей доверенной загрузки во время контроля целостности, но будут видны для самой операционной системы Windows).

Как это происходит?

Реестр Windows состоит из двух частей: энергозависимая часть (ключи реестра и значения, которые будут потеряны после отключения куста из-за того, что они не сохраняются в файл; пример: ключ «CurrentControlSet» куста «SYSTEM»), энергонезависимая часть (синхронизируется с файлом куста реестра).

Поскольку во время записи энергонезависимой части в файл куста необходимо обеспечить целостность сохраняемых данных (например, в случае сбоя электропитания, прерывающего операции записи данных), ядро Windows использует журналирование реестра - записываемые данные сохраняются сначала в файл журнала (этот файл находится в одной директории вместе с основным файлом и имеет расширение «.LOG», «.LOG1» или «.LOG2») и только потом в основной файл куста (если запись в файл журнала не будет успешно завершена, то основной файл останется целым и нетронутым, а если запись в основной файл не будет успешно завершена, то его целостность можно восстановить с помощью данных из журнала, которые были успешно записаны до сбоя).

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

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

Журналирование до Windows Vista

В Windows XP и более ранних версиях Windows каждому энергонезависимому кусту реестра соответствует один основной файл и один файл журнала. Исключением из этого правила является куст SYSTEM в Windows 2000 и более ранних версиях Windows, который зеркалируется (в файл с именем «system.alt»), а не журналируется, чтобы упростить код загрузчика (который должен загрузить в память указанный куст) и не добавлять в него поддержку восстановления из журнала (под зеркалированием понимается поочередная запись данных в два основных файла, которые в результате будут иметь одинаковую логическую структуру ключей, значений и других элементов).

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

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

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

Журналирование начиная с Windows Vista (до Windows 8.1)

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

Если при записи в основной файл произошла ошибка, то происходит смена файла журнала (с «.LOG1» на «.LOG2» и наоборот). Таким подходом обеспечивается постоянное наличие корректного файла журнала, в котором есть данные от предыдущей попытки синхронизации. В результате сбой во время записи в файл журнала (после сбоя во время записи в основной файл) не приведет к неисправимому нарушению целостности куста реестра (кстати говоря, если такая ситуация все же возникнет, в ядре Windows есть механизмы самовосстановления, исправляющие явные ошибки в логической структуре куста).

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

Следует отметить, что в процессе подключения куста реестра ядро должно выбрать, какой из двух файлов журнала использовать для восстановления, для чего реализуется относительно сложный алгоритм, определяющий, какой из файлов журнала сохранил целостность, какой из них содержит более позднюю версию записываемых данных и т. д. До Windows 8 этот алгоритм содержал серьезную ошибку, в результате которой почти во всех случаях, вне зависимости от конкретных деталей, выбирался первый файл журнала («.LOG1»). В частности, для Windows 7 соответствующие исправления алгоритма были выпущены лишь в марте 2016 года (следовательно, все это время двойное журналирование в Windows 7 предоставляло защиту целостности не лучше, чем Windows XP). Для преодоления описанной ошибки необходимо не только блокировать запись в основной файл куста, но и блокировать переход ко второму файлу журнала («.LOG2») в случае сбоя (чтобы первый файл журнала всегда содержал наиболее поздние данные, пусть даже и в ущерб целостности в случае сбоя; в противном случае при следующей загрузке системные кусты реестра могут быть восстановлены в состояние, неожиданно более раннее, чем при завершении штатного выключения компьютера). К счастью, следующее значение обсуждаемой переменной позволяет достигнуть желаемого эффекта без смены файла журнала - 3.

Эта же переменная будет работать так же и в более новых версиях Windows (8.1 и 10), где применяется другой способ журналирования (вне рамок данной статьи).

Эксперимент

В качестве эксперимента создадим невидимые ключ и его значение в операционной системе Windows 7 (Service Pack 1). Для этого в запущенной операционной системе изменим (редактированием памяти) значение переменной ядра CmpFailPrimarySave с 0 на 3, а затем создадим ключ реестра «HKEY_LOCAL_MACHINE\SYSTEM\invisible_key» со значением с именем «invisible_value», содержащим строку «123456». Затем выключим операционную систему штатным способом и экспортируем файлы куста реестра SYSTEM.

После повторного включения операционной системы запустим редактор реестра и отметим, что искомые ключ и значение в нем видны (рис. 1).

Рис. 1: Редактор реестра Windows

В то же время в экспортированных файлах реестра искомые ключ и значение сторонние программы (например, Windows Registry Recovery и Registry Explorer) не отображают (рис. 2 и 3).

Рис. 2: Windows Registry Recovery

Рис. 3: Registry Explorer

Вывод

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

В соответствии с ПП 1119 от 1 ноября 2012г. вводятся угрозы 3-х типов так или иначе связанных с наличием недокументированных (недекларированных) возможностей в программном обеспечении.

Рассмотрим меры, направленные на нейтрализацию этих угроз для операторов ПДн не обрабатывающих информацию отнесенную к государственной тайне.

Итак, мы имеем два уровня угроз:

1.Угрозы, связанные с наличием недокументированных (недекларированных) возможностей в системном программном обеспечении.

2.Угрозы, связанные с наличием недокументированных (недекларированных) возможностей в прикладном программном обеспечении.

Меры, направленные на нейтрализацию угроз делятся на четыре основные составляющие:

1.Меры, направленные на недопущение появления угрозы.

2.Меры, направленные на выявление угрозы.

3.Меры, направленные на нейтрализацию выявленных угроз.

4.Меры, направленные на минимизацию вреда или эффективности реализации угрозы.

Теперь проведем оценку реализации мер, но перед этим учтем несколько важных условий:

1.Мы рассматриваем информационные системы (ИС), которые строятся операторами ПДн. Нужно понимать, что подавляющее число операторов решают задачи по созданию ИС только с использованием типовых продуктов как на системном так и на прикладном уровне (операционных систем, офисных систем обработки данных, СУБД и средств обеспечения). Разработка специальных информационных систем и технологий – редкое явление. Это дорого и у операторов в массе своей такая задача не стоит и не может быть решена имеющимися ресурсами.

2.Оператор получает программные компоненты ИС в готовом виде – без конструкторской документации, без исходных текстов и т.п. Только дистрибутив и эксплуатационную документацию. При этом важно понимать, что значительная часть операторов не строят ИС а только эксплуатирует ее.

3.К основным методам обеспечения безопасного применения программного обеспечения относятся:

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

Но указанные методы вряд ли доступны оператору.

Теперь попробуем выстроить реальные меры, которые может применять оператор для нейтрализации угроз.

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

Источники угроз на этапе формирования требований к системному ПО

• формирование требований направленных на создание условий для последующего небезопасного применения ПО;
• просчеты при формировании требований к ПО.

Источники угроз на этапе проектирования системного ПО

• целенаправленное внедрение уязвимости или закладки на уровне архитектуры и/или алгоритма функционирования ПО;
• целенаправленное проектирование таких методов тестирования, которые направлены на сокрытие уязвимостей/закладок;
• внесение уязвимостей/закладок используемыми средствами автоматизированного проектирования ПО;
• применение архитектурных решений, которые приводят к необходимости применения ресурсоемких методов тестирования и отладки ПО.

Источники угроз на этапе реализации (кодирования/компиляции/сборки) системного ПО

• целенаправленное внедрение закладки;
• целенаправленное внедрение уязвимости;
• использование сторонних недоверенных компонентов;
• скрытая реализация специальных настроек, позволяющих включить/инициировать закладки или уязвимости ПО;
• избыточная компиляция и сборка ПО из «грязных» исходных текстов содержащих различный «программный мусор»;
• внесение уязвимостей используемыми средствами компиляции и сборки ПО;
• реализация тестов, которые позволяют сокрыть уязвимости и недостатки в ПО.

Источники угроз на этапе тестирования системного ПО разработчиком

• Проведение тестирования разработчиком или заказчиком системного ПО

Проведение тестирования системного ПО независимой лабораторией в процессе сертификационных или иных испытаний

• целенаправленное использование методов тестирования, которые направлены на сокрытие уязвимостей;
• тестирование не проводится или проводится не в полном объеме;
• целенаправленное сокрытие результатов тестирования.

Источники угроз на этапе внедрения системного ПО

• подмена компонентов системного ПО;
• внедрение системного ПО без учета ограничений и условий эксплуатации как самого ППО так и среды его функционирования;
• использование скрытых настроек системного ПО для включения/инициации закладок или уязвимостей.

С учетом условий указанных выше, очевидно, что оператор не имеет возможностей по осуществлению контроля и обеспечения отсутствия недокументированных (недекларированных) возможностей в системном ПО.
Вывод: меры 1.1. – оператору недоступны.

(Угроза 1, мера 2 ) Меры, направленные на выявление угрозы оператору доступны. Для этого оператор может самостоятельно или с привлечением специалистов:

• осуществлять мониторинг различных источников информации о выявленных уязвимостях в используемом системном ПО;
• использовать встроенные в системное ПО средства самоконтроля;
• использовать различные инструментальные средства контроля защищенности в том числе и собственной разработки.

(Угроза 1, мера 3 ) С учетом мер (Угроза 1, мера 2) оператор может самостоятельно или с привлечением специалистов:

• производить установку сервиспаков, патчей для нейтрализации выявленных уязвимостей;
• применять дополнительные СрЗИ, позволяющие нейтрализовать выявленные уязвимости системного ПО;

(Угроза 1, мера 4 ) оператор может самостоятельно или с привлечением специалистов применять меры, направленные на минимизацию вреда или эффективности реализации уязвимостей (как выявленных, так и еще не выявленных) системного ПО:

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

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

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

Рассмотрев угрозы первого типа мы видим, что все тоже самое относится и к прикладному ПО.

Общие выводы:

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

Которые не были предусмотрены изготовителем или были им умышленно скрыты (например некоторые производители проприетарных ОС так поступают в целях недобросовестной конкуренции). Позже они могли быть обнаружены пользователями или сторонними специалистами.

В аналогичном смысле можно говорить и о недокументированных функциях .

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

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

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

• вычислительные и иные аппаратные средства: компьютеры, компьютерные комплектующие, периферия и аксессуары, а также различная электроника (сигнализация, mp3-проигрыватели), и т. д.;
• средства связи: сотовые телефоны, GPS-навигаторы, домофоны, коммуникаторы и т. д.;
• программное обеспечение: операционные системы, языки программирования, различное программное обеспечение, игры и т. д.;

Недокументированные возможности в разных сферах

В аппаратуре

В программном обеспечении

В компьютерных и электронных играх

Недекларированные возможности (информационная безопасность)

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

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

2.1. Недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.

Преднамеренно внесённые в ПО функциональные объекты, обладающие такими возможностями названы программными закладками . Эти термины использует и ГОСТ Р 51275-2006 . Иногда употребляется также сокращение «НДВ ».

В литературе шире встречается близкое по смыслу, но менее определённое понятие уязвимость (перевод англ. vulnerability ).

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

Доктрина информационной безопасности РФ среди угроз «безопасности информационных и телекоммуникационных средств и систем» называет также и «внедрение в аппаратные и программные изделия компонентов, реализующих функции, не предусмотренные документацией на эти изделия».

Примеры

Технические устройства и ПО

В качестве примеров недокументированных возможностей и команд могут быть приведены:

Массовая культура

• переход из «матрицы» в «реальность» в фильме «Матрица » осуществлялся главными героями через ввод недокументированного кода в кабине виртуального телефона-автомата в «матрице».
• в эпизоде 3.11 «Enter 77 » сериала «Остаться в живых » переход к режиму основных возможностей, который не знали герои сериала, был случайно реализован одним из персонажей путём выигрыша в компьютерные шахматы.

См. также

Примечания

Литература

На английском языке

• Gupta G . Computers in Engineering. American Society of Mechanical Engineers, 1991. ISBN 0791806227 , ISBN 9780791806227 , ISBN 0-7918-0622-7 (в особенности раздел «Documented and Undocumented Features», p.78)
• Szyperski C., Gruntz D., Murer S . Component software: beyond object-oriented programming. Pearson Education Publishers, 2003. ISBN 9780201178883 (в особенности раздел 5.1.5. Undocumented «features», p.54)
• Smith Sean W . Trusted computing platforms: design & applications. 2005, XX, 244 p. 28 illus., Hardcover. ISBN 978-0-387-23916-3 (в особенности раздел 3.4 Undocumented Functionality, p.35)

На русском языке

• Адаменко М.В . Секреты сотовых телефонов: сервисные коды мобильных телефонов; недокументированные возможности; изменение мелодии звонка; разблокировка телефонов. Изд. 2-е. М.: "ДМК Пресс, «СОЛОН-Пресс», 2002, 240 стр. - ISBN 5-98003-026-3 , ISBN 5-94074-191-6
• Букин М.С . Секреты сотовых телефонов. СПб.: «Питер», 2005, 208 стр. - ISBN 5-469-00638-7
• Зыков Н.К . Недокументированные возможности Windows: Справочник для программиста-практика. М.: «Радио и связь», 1994, 176 стр. - ISBN 5-256-01212-6 , ISBN 5-256-01212-6
• Кингслей-Хагис К . Недокументированные возможности GPS. СПб.: «Питер», 2007 г., 304 стр. - ISBN 978-5-469-01410-2
• Коберниченко А.В . Недокументированные возможности Windows NT. М.: «Нолидж», 287 стр. - ISBN 5-89251-048-4
• Свен Шрайбер . Недокументированные возможности Windows 2000. СПб., 2002 г., 544 стр. - ISBN 5-318-00487-3
• Фленов М. . Программирование в Delphi глазами хакера. Издательство: "БХВ-Петербург", 2007г. ISBN 978-5-9775-0081-4

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "Недокументированные возможности" в других словарях:

Электроника МК 52 с сообщением «ERROR» (из за специфического отображения буквы r зачастую читалось как «ЕГГОГ») Еггогология& … Википедия

Электроника МК 52 с сообщением ERROR (из за специфического отображения буквы r зачастую читалось как «ЕГГОГ» Еггогология изучение скрытых возможностей микрокалькуляторов. Содержание 1 Происхождение … Википедия

- (Windows) … Википедия

Microsoft Word (Windows) Скриншот Microsoft Word 2007 Тип Текстовый процессор Разработчик Майкрософт … Википедия

Microsoft Word (Windows) Скриншот Microsoft Word 2007 Тип Текстовый процессор Разработчик Майкрософт … Википедия

Microsoft Word (Windows) Скриншот Microsoft Word 2007 Тип Текстовый процессор Разработчик Майкрософт … Википедия

Microsoft Word (Windows) Скриншот Microsoft Word 2007 Тип Текстовый процессор Разработчик Майкрософт … Википедия

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

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

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

Классификация недекларированных возможностей (программ-имплантов)

В зависимости от целей возможностей программы-импланты можно разделить на несколько категорий:

• Полный доступ к удаленному компьютеру или системе . По сути такие программы аналогичны хакерским руткитам и бэкдорам с той лишь разницей, что их функциональность заложена в одну из легальных программ пользователя. Могут применяться для шпионажа либо нарушения работы компьютеров, телекоммуникационного оборудования и смартфонов коммерческих и общественных организаций, широких групп граждан.
• Кража паролей доступа, т.е. функции кейлоггера . Наличие пароля удаленного доступа к компьютеру обеспечивает столь же обширные возможности, как самый лучший бэкдор, а доступ к аккаунтам электронной почты и Skype позволит отслеживать переговоры и переписку даже в тех случаях, когда человек использует для общения другие компьютеры, на которых программ-закладок нет. Особый интерес кража паролей представляет в случаях, когда нужен доступ ко всей внутренней сети, где работает компьютер с закладкой.
• Несанкционированные изменение данных и вывод из строя компьютерных систем . Наибольшую угрозу такие программы представляют в системах АСУ ТП , в особенности критически важных объектов, управления техникой военного или двойного назначения. Установленные программные закладки позволял в случае необходимости вывести из строя инфраструктурные и военные объекты потенциального противника

Объекты внедрения программных имплантов:

• Компьютеры и серверы. Доступ к содержимому жестких дисков и оперативной памяти – извечная мечта всех хакеров и работников спецслужб. Программы-закладки могут как напрямую копировать и пересылать информацию, так и открывать доступ другому шпионскому ПО.
• Телекоммуникационное оборудование. Переговоры подозрительных лиц не менее, а порой и более ценны, чем содержимое их жестких дисков, поскольку позволяют выявить и пресечь актуальные преступные планы, а при наличие GPS спецслужбы могут еще и без всякого наружного наблюдения отслеживать все перемещения объекта. Закладки же в сетевом оборудовании позволят контролировать трафик от больших групп населения.
• Бортовые и промышленные компьютеры. Сейчас практически любая серьезная техника оснащается если не полноценным компьютером, то, как минимум, микропроцессором. Внедрив в него программы-закладки, спецслужбы смогут как получать информацию о периодах и режимах работы техники, так и, в случае необходимости, легко выводить ее из строя.

Источники угрозы

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

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

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

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

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

Анализ риска

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

Огромный интерес для спецслужб представляют и широко распространенные, используемые миллионами программы. Как правило при разработке ПО программисты используют чужие библиотеки и Открытое программное обеспечение (Open source), в котором могут быть открытые уязвимости используемые для сбора информации, например, “АНБ использовало уязвимость в OpenSSL для сбора информации ”.

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

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

Государственные предприятия, производители военной техники, а также предприятия стратегически важных отраслей могут стать объектом интереса заграничных спецслужб.

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