Бэкдор (вычислительная техника)

Материал из wikixw
Перейти к навигации Перейти к поиску

В заднюю дверь - это, как правило, скрытое способ обхода проверки подлинности и шифрование на компьютере, продукта, внедренного устройства (например, домашнего роутера), или его воплощение (например, часть криптосистемы, алгоритм, набор микросхем, или даже "гомункул компьютер" —крохотный компьютер-в-компьютере, например, в компании Intel АМТ технология).[1] [2] бэкдоры чаще всего используются для обеспечения удаленного доступа к компьютеру или получения доступа к открытому тексту в криптографических системах. Оттуда он может быть использован для получения доступа к привилегированной информации, такой как пароли, поврежденные или удалить данные на жестких дисках, или передавать информацию в рамках autoschediastic сетей.

Бэкдор может принимать форму скрытой части программы, отдельной программы (например, Back Orifice может подрывать систему через руткит), кода во встроенном программном обеспечении аппаратного обеспечения, [4] или частей операционной системы, таких как Windows . троянские кони могут быть использованы для создания уязвимостей в устройстве. Троянский конь может показаться полностью законной программой, но при выполнении он запускает действие, которое может установить бэкдор.[8] Хотя некоторые из них установлены тайно, другие бэкдоры преднамеренно и широко известны. Эти виды бэкдоров имеют "законное" использование, например, предоставляя производителю способ восстановления паролей пользователей.

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

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

В 1993 году правительство Соединенных Штатов попыталось внедрить систему шифрования, чип Clipper, с явным бэкдором для доступа правоохранительных органов и национальной безопасности. Чип оказался неудачным

Обзор[править]

Угроза бэкдоров всплыла, когда многопользовательские и сетевые операционные системы получили широкое распространение. Петерсен и Turn обсудили компьютерную подрывную деятельность в статье, опубликованной в трудах конференции AFIPS 1967 года. они отметили класс активных инфильтрационных атак, которые используют точки входа "люк" в систему, чтобы обойти средства безопасности и разрешить прямой доступ к данным. Использование слова " люк " здесь явно совпадает с более поздними определениями бэкдора. Однако с появлением криптографии с открытым ключом термин trapdoor приобрел иное значение (см. функция люка), и поэтому термин "черный ход" теперь предпочтителен, только после того, как термин люк вышел из употребления. В более общем плане такие нарушения безопасности подробно обсуждались в докладе целевой группы корпорации RAND, опубликованном под эгидой ARPA Дж.П. Андерсоном и Д. Дж. Эдвардсом в 1970 году.

Бэкдор в системе входа может принимать форму жестко закодированной комбинации пользователя и пароля, которая дает доступ к системе. Пример такого рода бэкдора был использован в качестве сюжетного устройства в фильме WarGames 1983 года , в котором архитектор компьютерной системы "WOPR" вставил жестко закодированный пароль, который давал пользователю доступ к системе и к недокументированным частям системы (в частности, режиму моделирования видеоигр и непосредственного взаимодействия с искусственным интеллектом ).

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

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

Политика и атрибуция[править]

Существует целый ряд общих соображений, которые вступают в игру при распределении ответственности.

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

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

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

Даже прямое признание ответственности должно быть тщательно изучено, если исповедующая сторона связана другими могущественными интересами.

Примеры[править]

Черви[править]

Многие компьютерные черви , такие как Sobig и Mydoom, устанавливают бэкдор на уязвимом компьютере (обычно это компьютер с широкополосным доступом под управлением Microsoft Windows и Microsoft Outlook ). Такие бэкдоры, по-видимому, установлены, чтобы спамеры могли отправлять нежелательную электронную почту с зараженных машин. Другие , такие как Sony/BMG rootkit, размещенные тайно на миллионах музыкальных компакт—дисков до конца 2005 года, предназначены для измерения DRM-и в этом случае в качестве агентов сбора данных, поскольку обе тайные программы , которые они установили, регулярно связывались с центральными серверами.

Изощренная попытка внедрить бэкдор в ядро Linux, обнаруженная в ноябре 2003 года, добавила небольшое и тонкое изменение кода, разрушив систему контроля версий .[13] в этом случае двухстрочное изменение появилось для проверки прав доступа root вызывающего объекта к функции sys_wait4, но поскольку он использовал назначение =вместо проверки равенства==, он фактически предоставил разрешения системе. Это различие легко упускается из виду и может даже интерпретироваться как случайная типографская ошибка, а не преднамеренная атака.

В январе 2014 года бэкдор был обнаружен в некоторых продуктах Samsung для Android, таких как устройства Galaxy. Фирменные версии Android от Samsung оснащены бэкдором, который обеспечивает удаленный доступ к данным, хранящимся на устройстве. Samsung Samsung Android программное обеспечение, которое отвечает за обработку связи с модемом, используя протокол Samsung IPC, реализует класс запросов, известный как команды удаленного файлового сервера (RFS), что позволяет оператору бэкдора выполнять через модем удаленные операции ввода-вывода на жестком диске устройства или другом хранилище. Поскольку модем работает под управлением фирменного программного обеспечения Samsung для Android, вполне вероятно, что он предлагает дистанционное управление по воздуху, которое затем может быть использовано для выдачи команд RFS и, таким образом, для доступа к файловой системе на устройстве.

Объектный код бэкдоры[править]

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

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

Поскольку объектный код может быть восстановлен путем перекомпиляции (повторной сборки, пересоединения) исходного исходного кода, создание постоянного бэкдора объектного кода (без изменения исходного кода) требует подрыва компилятора сам – так что, когда он обнаруживает, что он компилирует программу под атакой он вставляет бэкдор – или альтернативно ассемблер, компоновщик или загрузчик. Поскольку это требует подрыва компилятора, это, в свою очередь, может быть исправлено путем перекомпиляции компилятора, удаления кода вставки бэкдора. Эта защита, в свою очередь, может быть разрушена путем размещения исходного мета-бэкдора в компиляторе, так что, когда он обнаруживает, что он компилирует себя, он затем вставляет этот генератор мета-бэкдора вместе с оригинальным генератором бэкдора для исходной программы, подвергающейся атаке. После этого исходный мета-бэкдор может быть удален,а компилятор перекомпилирован из исходного источника с помощью скомпрометированного исполняемого файла компилятора: бэкдор был загружен. Эта атака датируется Karger & Schell (1974) и была популяризирована в статье Томпсона 1984 года, озаглавленной "размышления о доверии доверию"; [16] поэтому она в разговорном языке известна как атака "доверяя доверию". Смотрите раздел бэкдоры компилятора , ниже, для получения дополнительной информации. Аналогичные атаки могут быть направлены на более низкие уровни системы, например, операционная система, и может быть вставлен во время загрузки системы процесс; они также упомянуты в Karger & Schell (1974), и теперь существуют в виде вирусов загрузочного сектора .

Асимметричные бэкдоры[править]

Традиционный бэкдор-это симметричный бэкдор: любой, кто находит бэкдор, может в свою очередь использовать его. Понятие асимметричного бэкдора было введено Адамом Янгом и Моти Юнгом в трудах Advances in Cryptology: Crypto '96 . Асимметричный бэкдор может быть использован только злоумышленником, который его установит, даже если полная реализация бэкдора становится общедоступной (например, через публикацию, будучи обнаруженной и раскрытой обратным инжинирингом, прием.). Кроме того, вычислительно трудно обнаружить наличие асимметричного бэкдора под запросами черного ящика. Этот класс атак был назван клептографией ; они могут осуществляться в программном обеспечении, аппаратных средствах (например, смарт-картах) или их комбинации. Теория асимметричных бэкдоров является частью более широкой области, в настоящее время называемой криптовирологией . Примечательно, что АНБ вставило клептографический бэкдор в стандарт Dual_EC_DRBG.

Существует экспериментальный асимметричный бэкдор в генерации ключей RSA. Этот бэкдор OpenSSL RSA, разработанный Young and Yung, использует витую пару эллиптических кривых и был доступен.

Компилятор бэкдоры[править]

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

Эта атака была первоначально представлена в Каргер и Шелл (1974, с. 52, раздел 3.4.5: "люк вставки"), который был ВВС США безопасности анализ Multics была, где они описывали такую атаку на ПЛ/я компилятор, и называть это "компилятор люк"; они также упомянуть вариант, когда система инициализации код изменен, чтобы вставить в фоновом режиме во время загрузки, так как это является сложной и малоизученной, и называть это "инициализация люка"; это теперь известно как загрузочного сектора вирус.

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

Статья Томпсона описывает модифицированную версию компилятора Unix C, которая будет:

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

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

Обновленный анализ оригинального эксплойта приведен в Karger & Schell (2002, раздел 3.2.4: compiler trap doors), а исторический обзор и обзор литературы приведен в Wheeler (2009, Раздел 2: Справочная информация и связанная с ней работа).

Вхождения[править]

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

Эта атака была недавно (август 2009 г.) Обнаружена Sophos labs: вирус W32/Induc-a заразил компилятор программ для Delphi , языка программирования Windows. Вирус ввел свой собственный код в компиляцию новых программ Delphi,что позволило ему заражать и распространяться во многие системы, не зная об этом программиста. Атака, которая распространяется путем создания своего собственного троянского коня, может быть особенно трудно обнаружить. Считается, что Индуцибельный вирус распространялся по меньшей мере за год до того, как был обнаружен.

Контрмеры[править]

После того, как система была скомпрометирована с помощью бэкдора или троянского коня, такого как Trusting Trust compiler, "законному" пользователю очень трудно восстановить контроль над системой – обычно нужно перестроить чистую систему и передать данные (но не исполняемые). Тем не менее, несколько практических недостатков в доверительном доверии схема была предложена. Например, достаточно мотивированный пользователь может тщательно изучить машинный код ненадежного компилятора перед его использованием. Как уже упоминалось выше, есть способы скрыть троянского коня, такие как подрыв дизассемблера; но есть и способы противостоять этой защите, такие как написание собственного дизассемблера с нуля.

Универсальный метод для противодействия атакам на доверие доверия называется Diverse Double-Compiling (DDC). Этот метод требует другого компилятора и исходного кода тестируемого компилятора. Этот источник, скомпилированный с обоими компиляторами, приводит к двум различным компиляторам stage-1, которые, однако, должны иметь одинаковое поведение. Таким образом, один и тот же источник, скомпилированный с обоими компиляторами stage-1, должен затем привести к двум идентичным компиляторам stage-2. Приведено формальное доказательство того, что последнее сравнение гарантирует соответствие предполагаемого исходного кода и исполняемого файла тестируемого компилятора при некоторых допущениях. Этот метод был применен его автором для проверки того, что компилятор C пакета GCC (V. 3.0.4) не содержал троянца, используя icc (V.11.0) в качестве другого компилятора.

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

Список известных бэкдоров[править]

  • Back Orifice был создан в 1998 году хакерами из группы Cult of the Dead Cow в качестве инструмента удаленного администрирования. Это позволило удаленно управлять компьютерами Windows по сети и пародировать имя BackOffice Microsoft .
  • Генератор криптографически безопасных псевдослучайных чисел Dual_EC_DRBG был обнаружен в 2013 году, возможно, имеет клептографический бэкдор, намеренно вставленный АНБ, у которого также был закрытый ключ к бэкдору.
  • Несколько бэкдоров в нелицензированных копиях плагинов WordPress были обнаружены в марте 2014 года. они были вставлены в виде запутанного кода JavaScript и молча созданы, например, учетная запись администратора в базе данных веб-сайта. Подобная схема позже была представлена в плагине Joomla.
  • У Borland Interbase версий 4.0 - 6.0 был жестко закодированный бэкдор, поставленный туда разработчиками. Серверный код содержит скомпилированную учетную запись бэкдора (имя пользователя: политически , пароль: правильно ), доступ к которой можно получить через сетевое подключение; пользователь, входящий с этой учетной записью бэкдора, может получить полный контроль над всеми базами данных Interbase. Бэкдор был обнаружен в 2001 году, и был выпущен патч.
  • Juniper Networks backdoor вставлен в 2008 году в версии прошивки ScreenOS от 6.2.0r15 до 6.2.0r18 и от 6.3.0r12 до 6.3.0r20 , что дает любому пользователю административный доступ при использовании специального мастер-пароля.

Смотрите также[править]

Читать[править]

dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html

Пруф[править]

.owasp.org/images/a/ae/OWASP_10_Most_Common_Backdoors.pdf