Войти
A Бэкдор - это обычно скрытый метод обхода обычной аутентификации или шифрования в компьютер, продукт, встроенное устройство (например, домашний маршрутизатор ) или его вариант (например, часть криптосистемы, алгоритма, набор микросхем или даже «компьютер-гомункул» - крошечный компьютер внутри компьютера, подобный тому, что используется в технологии Intel AMT ). Бэкдоры чаще всего используются для защиты удаленного доступа к компьютеру или получения доступа к незашифрованному тексту в криптографических системах. Оттуда его можно использовать для получения доступа к конфиденциальной информации, такой как пароли, повреждение или удаление данных на жестких дисках, а также для передачи информации в автоматических сетях.
Бэкдор может принимать форму скрытой части программы, отдельной программы (например, Back Orifice может нарушить работу системы с помощью руткита ), код в прошивка оборудования или части операционной системы, например Windows. Троянские кони могут использоваться для создания уязвимостей в устройство. Троянский конь может показаться вполне законной программой, но при запуске он запускает действие, которое может установить бэкдор. Хотя некоторые из них устанавливаются тайно, другие бэкдоры являются преднамеренными и широко известны. Подобные бэкдоры используются «законно», например, для предоставления производителю возможности восстановить пароли пользователей.
Многие системы, хранящие информацию в облаке, не могут обеспечить точные меры безопасности. Если в облаке подключено много систем, хакеры могут получить доступ ко всем другим платформам через наиболее уязвимую систему.
Пароли по умолчанию (или другие учетные данные по умолчанию) могут функционировать как бэкдоры, если они не изменяются пользователем. Некоторые функции отладки могут также действовать как бэкдоры, если они не удалены в выпускной версии.
В 1993 году правительство США предприняло попытку развернуть систему шифрования, чип Clipper с явным бэкдором для доступа правоохранительных органов и национальной безопасности. Чип оказался неудачным.
Угроза бэкдоров обнаружилась, когда многопользовательские и сетевые операционные системы получили широкое распространение. Петерсен и Терн обсуждали компьютерную подрывную деятельность в статье, опубликованной в трудах конференции AFIPS 1967 года. Они отметили класс активных атак проникновения, которые используют точки входа в систему «лазейки» для обхода средств безопасности и предоставления прямого доступа к данным. Использование слова "лазейка" здесь явно совпадает с более поздними определениями бэкдора. Однако с появлением криптографии с открытым ключом термин "лазейка" приобрел другое значение (см. функция "лазейка" ), и, следовательно, термин "бэкдор" теперь предпочтителен, только после термина люк вышел из строя. В более общем плане такие нарушения безопасности подробно обсуждались в отчете рабочей группы RAND Corporation, опубликованном при спонсорской поддержке ARPA J.P. Anderson и D.J. Эдвардс в 1970 году.
Бэкдор в системе входа в систему может принимать форму жестко запрограммированной комбинации пользователя и пароля, которая дает доступ к системе. Пример такого рода бэкдора был использован в качестве сюжета в фильме 1983 WarGames, в который архитектор компьютерной системы «WOPR » вставил жестко запрограммированный пароль, который давал пользователю доступ к системе и недокументированным частям системы (в частности, режим симуляции, подобный видеоиграм, и прямое взаимодействие с искусственным интеллектом ).
Хотя количество бэкдоров в системах, использующих проприетарное программное обеспечение (программное обеспечение, исходный код не является общедоступным), широко не упоминается, тем не менее, они часто раскрываются. Программистам даже удалось тайно установить большие объемы безвредного кода, например, пасхальных яиц,, в программы, хотя в таких случаях может потребоваться официальная снисходительность, если не фактическое разрешение.
Мера противодействия бэкдорам - бесплатное программное обеспечение, где исходный код может быть исследован на предмет потенциальных бэкдоров, и поэтому обычно труднее ″ спрятать ″ бэкдор внутри. В сочетании с воспроизводимыми сборками можно также быть уверенным, что предоставленный двоичный файл соответствует общедоступному исходному коду.
Существует ряд плащей и кинжалов, которые необходимо учитывать при распределении ответственности.
Скрытые бэкдоры иногда маскируются под непреднамеренные дефекты (ошибки) по причинам правдоподобного отрицания. В некоторых случаях они могут начинаться как настоящая ошибка (непреднамеренная ошибка), которая, будучи обнаруженной, затем намеренно остается нефиксированной и не раскрываемой, будь то мошенник из соображений личной выгоды или с учетом осведомленности и надзора руководителей высшего звена.
Также возможно, что технологическая база полностью контролируемой корпорации может быть скрыто и не отслеживаемая внешними агентами (хакерами), хотя считается, что этот уровень сложности существует в основном на уровне национальных государственных субъектов. Например, если фотомаска , полученная от поставщика фотомаски, на несколько пунктов отличается от ее спецификации на фотомаску, производителю микросхемы будет трудно обнаружить это, если в противном случае функционально молчание; скрытый руткит, работающий в оборудовании для травления фотомаски, также может вызвать это несоответствие без ведома производителя фотомаски, и таким образом один бэкдор потенциально ведет к другому. (Этот гипотетический сценарий по сути представляет собой силиконовую версию необнаруживаемого бэкдора компилятора, обсуждаемого ниже.)
В общем, длинные цепочки зависимостей в современной узкоспециализированной технологической экономике и бесчисленное множество Человеческие элементы процесса контрольные точки затрудняют окончательное определение ответственности в тот момент, когда открывается скрытый бэкдор.
Даже прямое признание ответственности должно быть тщательно изучено, если признавшаяся сторона обязана другим влиятельным интересам.
Многие компьютерные черви, такие как Sobig и Mydoom, устанавливают бэкдор на зараженном компьютере (обычно это ПК на широкополосном, работающем под Microsoft Windows и Microsoft Outlook ). Похоже, что такие бэкдоры установлены для того, чтобы спамеры могли отправлять спам по электронной почте с зараженных машин. Другие, такие как руткит Sony / BMG, тайно размещенный на миллионах музыкальных компакт-дисков до конца 2005 года, предназначены как меры DRM - и, в этом случае, как сбор данных агентов, поскольку обе установленные ими тайные программы обычно связывались с центральными серверами.
Изощренная попытка заложить бэкдор в ядро Linux, представленная в ноябре 2003 года, добавила небольшое и тонкое изменение кода, подорвав систему контроля версий . В этом случае появилось двухстрочное изменение для проверки прав доступа root вызывающего к функции sys_wait4, но потому что оно использовало присвоение =вместо равенства проверяя ==, он действительно предоставил разрешения системе. Эту разницу легко упустить из виду, и ее можно даже интерпретировать как случайную типографскую ошибку, а не преднамеренную атаку.
Помечено желтым: пароль администратора бэкдора, скрытый в коде В январе 2014 г. в некоторых Продукты Samsung Android, например устройства Galaxy. Собственные версии Android от Samsung оснащены бэкдором, который обеспечивает удаленный доступ к данным, хранящимся на устройстве. В частности, программное обеспечение Samsung Android, отвечающее за обмен данными с модемом с использованием протокола Samsung IPC, реализует класс запросов, известный как команды удаленного файлового сервера (RFS), что позволяет оператору бэкдора выполнять удаленные операции через модем. Операции ввода-вывода на жестком диске устройства или другом хранилище. Поскольку модем работает под управлением проприетарного программного обеспечения Android от Samsung, вполне вероятно, что он предлагает удаленное управление по воздуху, которое затем можно использовать для выполнения команд RFS и, таким образом, для доступа к файловой системе на устройстве.
Сложнее обнаружить бэкдоры, связанные с изменением объектного кода, а не исходного кода - объектный код намного сложнее проверить, поскольку он разработан для машинного чтения, а не для человека. удобочитаемый. Эти бэкдоры могут быть вставлены либо непосредственно в объектный код на диске, либо вставлены в какой-то момент во время компиляции, компоновки сборки или загрузки - в последнем случае бэкдор никогда не появляется на диске, а только в памяти. Бэкдоры объектного кода трудно обнаружить путем проверки объектного кода, но их легко обнаружить, просто проверив наличие изменений (различий), особенно в длине или в контрольной сумме, а в некоторых случаях их можно обнаружить или проанализировать путем дизассемблирования объектного кода. Кроме того, бэкдоры объектного кода можно удалить (при условии, что исходный код доступен) путем простой перекомпиляции из источника в надежной системе.
Таким образом, чтобы такие бэкдоры избегали обнаружения, все существующие копии двоичного файла должны быть взломаны, и любые контрольные суммы проверки также должны быть скомпрометированы, а источник должен быть недоступен, чтобы предотвратить перекомпиляцию. В качестве альтернативы, эти другие инструменты (проверка длины, сравнение, контрольная сумма, дизассемблеры) могут быть скомпрометированы, чтобы скрыть бэкдор, например, обнаружив, что испорченный двоичный файл подвергается контрольной сумме, и возвращая ожидаемое значение, а не фактическое значение. Чтобы скрыть эти дальнейшие подрывные действия, инструменты также должны скрывать изменения в себе - например, испорченная контрольная сумма должна также определять, подсчитывает ли она себя (или другие подрывные инструменты), и возвращать ложные значения. Это приводит к обширным изменениям в системе и инструментам, необходимым для скрытия одного изменения.
Поскольку объектный код может быть регенерирован путем перекомпиляции (повторной сборки, повторного связывания) исходного исходного кода, создание постоянного бэкдора объектного кода (без изменения исходного кода) требует подрыва самого компилятора - чтобы когда он обнаруживает, что компилирует атакованную программу, он вставляет бэкдор - или, альтернативно, ассемблер, компоновщик или загрузчик. Поскольку это требует подрыва компилятора, это, в свою очередь, можно исправить, перекомпилировав компилятор, удалив код вставки бэкдора. Эту защиту, в свою очередь, можно подорвать, поместив исходный мета-бэкдор в компилятор, чтобы, когда он обнаруживает, что он компилируется, он затем вставляет этот генератор мета-бэкдора вместе с исходным генератором бэкдора для исходной программы, подвергающейся атаке. После этого исходный мета-бэкдор можно удалить, а компилятор перекомпилировать из исходного источника с скомпрометированным исполняемым файлом компилятора: бэкдор был загружен. Эта атака относится к Karger Schell (1974) и была популяризирована в статье Томпсона 1984 г., озаглавленной «Размышления о доверии»; следовательно, в просторечии она известна как атака «Доверие». Подробнее см. бэкдоры компилятора ниже. Аналогичные атаки могут быть нацелены на более низкие уровни системы, такие как операционная система, и могут быть вставлены во время процесса загрузки системы; они также упоминаются в Karger Schell (1974) и теперь существуют в форме вирусов загрузочного сектора.
Традиционный бэкдор - это симметричный бэкдор: в свою очередь, любой, кто найдет бэкдор, может им воспользоваться. Понятие асимметричного бэкдора было введено Адамом Янгом и Моти Юнгом в Proceedings of Advances in Cryptology: Crypto '96. Асимметричный бэкдор может использоваться только злоумышленником, который его внедряет, даже если полная реализация бэкдора становится общедоступной (например, посредством публикации, обнаружения и раскрытия посредством обратного проектирования и т. Д.). Кроме того, сложно с вычислительной точки зрения обнаружить наличие асимметричного бэкдора в запросах черного ящика. Этот класс атак получил название клептография ; они могут выполняться программно, аппаратно (например, смарт-карты ) или их комбинацией. Теория асимметричных бэкдоров является частью более широкой области, которая теперь называется криптовирология. Примечательно, что NSA вставило клептографический бэкдор в стандарт Dual EC DRBG.
Существует экспериментальный асимметричный бэкдор в генерации ключей RSA. Этот бэкдор OpenSSL RSA, разработанный Янгом и Юнгом, использует витую пару эллиптических кривых и стал доступным.
Изощренная форма черного ящика бэкдор - это бэкдор компилятора, в котором компилятор не только подрывается (чтобы вставить бэкдор в какую-либо другую программу, например, программу входа в систему), но и дополнительно модифицируется, чтобы определять, когда он компилируется, и затем вставляет как код вставки бэкдора (нацеленный на другую программу), так и самокомпиляцию, изменяющую код, подобно механизму, посредством которого ретровирусы заражают свой хост. Это можно сделать, изменив исходный код, и получившийся скомпрометированный компилятор (объектный код) может скомпилировать исходный (немодифицированный) исходный код и вставить себя: эксплойт был заблокирован при загрузке.
Эта атака была первоначально представлена в Karger Schell (1974, стр. 52, раздел 3.4.5: «Вставка люка»), которые были ВВС США анализ безопасности Multics, в котором описана такая атака на компилятор PL / I и названа «ловушкой компилятора»; они также упоминают вариант, в котором код инициализации системы модифицируется для вставки бэкдора во время загрузки, поскольку это сложно и плохо понимается, и называют его «лазейкой при инициализации»; Теперь это известно как вирус загрузочного сектора.
. Эта атака была фактически реализована и популяризирована Кеном Томпсоном в его благодарственной речи Премии Тьюринга в 1983 г. (опубликовано в 1984 г.)), «Размышления о доверии», в котором указывается, что доверие относительно, и единственное программное обеспечение, которому можно действительно доверять, - это код, в котором проверяется каждый шаг начальной загрузки. Этот механизм бэкдора основан на том факте, что люди просматривают только исходный (написанный человеком) код, а не скомпилированный машинный код (объектный код ). Программа , называемая компилятором, используется для создания второго из первого, и компилятору обычно доверяют честную работу.
В статье Томпсона описана модифицированная версия компилятора Unix C, которая:
Поскольку сам компилятор был скомпилированной программой, пользователи вряд ли заметят машину инструкции кода, которые выполняли эти задачи. (Из-за второй задачи исходный код компилятора выглядел бы «чистым».) Что еще хуже, в реализации доказательства концепции Томпсона искаженный компилятор также разрушил программу анализа (дизассемблер ), так что любой, кто исследует двоичные файлы обычным способом, на самом деле не увидит реального выполняемого кода, а увидит что-то другое.
Обновленный анализ исходного эксплойта дан в Karger Schell (2002, Раздел 3.2.4: Люки компилятора), а исторический обзор и обзор литературы даны в Уиллер (2009, Раздел 2: Предпосылки и связанные работы ).
Версия Томпсона официально никогда не выпускалась в открытый доступ. Однако считается, что версия была распространена на BBN и было зарегистрировано как минимум одно использование бэкдора. В последующие годы появляются отдельные анекдотические сообщения о таких бэкдорах.
В августе 2009 года подобная атака была обнаружена лабораторией Sophos. Вирус W32 / Induc-A заразил компилятор программы для Delphi, языка программирования Windows. Вирус представил свой собственный код при компиляции новых программ на Delphi, что позволило ему заражать и распространяться на многие системы без ведома программиста. Особенно сложно обнаружить атаку, которая распространяется путем создания собственного троянского коня. Считается, что вирус Induc-A распространялся не менее года, прежде чем был обнаружен.
После того, как система была взломана с помощью бэкдора или троянского коня, например компилятор Trusting Trust, «законному» пользователю очень трудно восстановить контроль над системой - обычно нужно перестраивать чистую систему и передавать данные (но не исполняемые файлы) через нее. Тем не менее, было предложено несколько практических недостатков схемы Trusting Trust. Например, достаточно мотивированный пользователь может тщательно просмотреть машинный код ненадежного компилятора перед его использованием. Как упоминалось выше, есть способы скрыть троянского коня, такие как подрыв дизассемблера; но есть способы противостоять и этой защите, например, написание собственного дизассемблера с нуля.
Общий метод противодействия атакам на доверительные отношения называется Diverse Double-Compiling (DDC). Для этого метода требуется другой компилятор и исходный код тестируемого компилятора. Этот источник, скомпилированный обоими компиляторами, дает два разных компилятора стадии 1, которые, однако, должны иметь одинаковое поведение. Таким образом, один и тот же исходный код, скомпилированный обоими компиляторами стадии 1, должен затем привести к двум идентичным компиляторам стадии 2. Приводится формальное доказательство того, что последнее сравнение гарантирует соответствие предполагаемого исходного кода и исполняемого файла тестируемого компилятора при некоторых предположениях. Этот метод был применен его автором для проверки того, что компилятор C пакета GCC (v. 3.0.4) не содержал трояна, используя icc (v. 11.0) в качестве другого компилятор.
На практике такие проверки не выполняются конечными пользователями, за исключением крайних случаев обнаружения и анализа вторжений из-за редкости таких сложных атак и из-за того, что программы обычно распространяются в двоичной форме. Удаление бэкдоров (включая бэкдоры компилятора) обычно выполняется путем простого восстановления чистой системы. Тем не менее, сложные проверки представляют интерес для поставщиков операционных систем, чтобы гарантировать, что они не распространяют скомпрометированную систему, а также в настройках с высоким уровнем безопасности, где такие атаки являются реальной проблемой.
