Бэкдор

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Бэкдор, backdoor (от англ. back door — «чёрный ход», буквально «задняя дверь») — дефект алгоритма, который намеренно встраивается в него разработчиком и позволяет получить несанкционированный доступ к данным или удалённому управлению операционной системой и компьютером в целом[1].

Предназначение[править | править код]

Основной целью бэкдора является скрытное и быстрое получение доступа к данным, в большинстве случаев — к зашифрованным и защищённым. Например, бэкдор может быть встроен в алгоритм шифрования для последующей прослушки защищённого канала злоумышленником[1][2].

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

Идеальный бэкдор[править | править код]

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

Распространённые принципы создания бэкдоров в алгоритмах[править | править код]

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

Гипотетические примеры бэкдоров в современных алгоритмах[править | править код]

Уязвимость генератора псевдослучайной последовательности DUAL_EC_DRBG[править | править код]

Данный генератор был разработан в АНБ и стандартизован в качестве криптографически стойкого генератора псевдослучайных чисел национальным институтом стандартов и технологий США NIST в 2006 году. Однако уже в 2007 году независимыми исследователями было высказано предположение, что в этот алгоритм мог быть встроен бэкдор.[3][4][5]

Иллюстрация работы алгоритма согласно спецификации АНБ[6]:

DUAL EC DRBG.jpg

Данный алгоритм использует эллиптические кривые.  — генератор группы точек на эллиптической кривой,  — точка на эллиптической кривой — константа, определённая стандартом, как она была выбрана неизвестно. Параметры самой кривой также заданы стандартом.

Принцип работы:

Уравнение кривой

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

, ,
 — внутреннее состояние генератора на текущем шаге
 — внутреннее состояние генератора на следующем шаге
 — выход генератора на текущем шаге
Предполагаемый бэкдор:

Так как  — простое число, то существуют такое число , что . Нахождение  — вычислительно сложная задача дискретного логарифмирования на эллиптической кривой, для решения которой на сегодняшний день не существует эффективных алгоритмов. Но если предположить, что злоумышленник знает , то получается следующая атака: Если  — очередной выход генератора, и если существует такое , что , то точка , лежит на кривой и для неё выполняется следующее равенство: . Зная число можно вычислить: . Таким образом, злоумышленник, знающий число , может не только вычислить следующий выход генератора, но и быстро перебрать все возможные внутренние состояния генератора и восстановить его начальное внутреннее состояние. Согласно независимым исследованиям[7][2], при знании достаточно всего 30 байт выходной последовательности генератора, чтобы простым перебором значений восстановить его начальное внутреннее состояние. По мнению исследователей, такая уязвимость может быть расценена как бэкдор.

Ошибка в реализации протокола проверки сертификатов TLS от компании Apple[править | править код]

Исследователями компании Яндекс была обнаружена уязвимость в реализации протокола TLS в одном из программных продуктов Apple[2]. По их мнению, данная ошибка вполне может оказаться бэкдором, намеренно встроенным в алгоритм кем-то из разработчиков.

Участок кода с ошибкой:
static DSStatus SSLVerifySignedServerKeyExchnge(....)
{
     DSStatus err;
     ....
     if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
          goto fail;
          goto fail;
     if ((SSHashSHA1.final(&hashCtx, &hashOut)) != 0)
          goto fail;
     ....
     fail:
          ....
          return err;
}

Как можно видеть, после первого оператора if стоят две строчки goto fail, и вторая строчка выполняется всегда, независимо от результата if. Таким образом процедура проверки сертификата проходит не полностью. Злоумышленник, знающий об этой уязвимости, может подделать сертификат и пройти проверку подлинности. Это позволит ему организовать атаку типа «Человек посередине», тем самым вмешаться в защищённое соединение между клиентом и сервером. Исследователи, обнаружившие данную ошибку в реализации, не могут точно сказать, намеренно она была сделана или случайно. Вполне возможно, что это бэкдор, встроенный в алгоритм кем-то из разработчиков.

Примеры методов создания бэкдоров[править | править код]

Специально подобранные константы[править | править код]

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

В качестве такого примера использования констант можно привести недавние исследовательские работы на тему так называемого «вредоносного хэширования»[8][9], где авторам удалось построить коллизии для криптографической хэш-функции SHA1 путём модификации её раундовых констант. Отметим, что предложенная авторами исследования атака не является атакой на саму хэш-функцию SHA1, она позволяет лишь находить коллизии при условии возможности изменения раундовых констант и только для определённых типов файлов.

Краткое описание SHA1:

SHA1 — современная раундовая хэш-функция. Алгоритм хэширования следующий:

  • Инициализируются 32-битные значения
  • Входное сообщение разбивается на блоки длиной 512 бит
  • Каждый блок сообщения обрабатывается и дополняется специальным образом, по алгоритму, определённому в стандарте
  • Полученный блок сообщения хэшируется в 4 этапа по 20 раундов в каждом, причём для каждого этапа используется своя константа или
  • Выходом функции для каждого блока будут новые значения , которые добавляются к результату:
  • Итоговым результатом хэширования будет 160-битное значение полученное конкатенацией пяти 32-битных значений после обработки последнего блока сообщения.
Построение коллизий:

Целью рассматриваемой атаки является нахождение таких констант и таких сообщений и , что . Данная атака модифицирует только первые 512 бит (1-ый блок) сообщений для которых требуется построить коллизию. Алгоритм базируется на уже известной разностной атаке на SHA1, предложенной в 2005 году[10][11] и имеющей сложность порядка операций, что делает её трудноосуществимой на практике. Поэтому до настоящего времени ни одной реальной коллизии для SHA1 найдено не было.

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

Одноблоковая коллизия:

Mal sha1.jpg

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

Пример использования вредоносного хэширования для создания бэкдоров[править | править код]

С помощью описанной атаки были созданы два sh-скрипта, которые при выборе дают одинаковую хэш-сумму SHA1, но работают по-разному.

Malicious sh.jpg

Как можно видеть, различие между этими двумя скриптами заключается только в первых блоках по 512 бит, которые представляют из себя закоментированный мусор. Но содержимое этих блоков затем используется в условии if , следовательно скрипты при запуске работают по-разному. Подобные файлы могут быть использованы создателем со злым умыслом.

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

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

Аппаратные бэкдоры имеют ряд преимуществ над программными:

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

Примером аппаратного бэкдора может быть вредоносная прошивка BIOS. Согласно исследованиям[12], такая прошивка может быть построена на основе свободных прошивок Coreboot[13] и SeaBIOS. Coreboot не является полноценным BIOS: он отвечает только за обнаружение имеющегося на машине оборудования и передачу управления самой «начинке BIOS», в качестве которой может быть использован модифицированный злоумышленником под свои нужды SeaBIOS.

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

Примечания[править | править код]

  1. 1 2 J.P. Aumasson Cryptographic bacdooring
  2. 1 2 3 Евгений Сидоров, Криптографические баги и бэкдоры, Yandex security meet up, 24.07.2015
  3. Dan Shumow, Niels Ferguson, On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng, CRYPTO 2007, august 2007
  4. Брюс Шнайер. Did NSA Put a Secret Backdoor in New Encryption Standard?, Wired News (15 ноября 2007). Архивировано 19 сентября 2012 года.
  5. Киви Берд, Неслучайные случайности // Компьютерра, 07 декабря 2007
  6. John Bryson, Patrick Gallagher, Recommendation for Random Number Generation Using Deterministic Random Bit Generators Архивная копия от 20 февраля 2016 на Wayback Machine, p. 60, 2012
  7. Dan Shumow, Niels Ferguson, On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng, pages 6-7, CRYPTO 2007, august 2007
  8. Ange Albertini, Jean-Philippe Aumasson, Maria Eichlseder, Florian Mendel, Martin Schlaeffer, Malicious SHA-1, 14.08.2014
  9. 1 2 Ange Albertini, Jean-Philippe Aumasson, Maria Eichlseder, Florian Mendel, Martin Schlaffer, Malicious Hashing: Eve’s Variant of SHA-1 Архивная копия от 22 октября 2015 на Wayback Machine, 2014 year
  10. Wang, X., Yao, A.C., Yao, Cryptanalysis on SHA-1. NIST — First Cryptographic Hash Work-shop Архивная копия от 7 ноября 2016 на Wayback Machine, 31 October 2005
  11. Wang, X., Yin, Y.L., Yu, H. , Finding collisions in the full SHA1 Архивная копия от 30 апреля 2015 на Wayback Machine, CRYPTO 2005
  12. Jonathan Brossard, Аппаратные бэкдоры — это практично, 12 марта 2012
  13. Обзор проекта свободного BIOS — Coreboot, 9 октября 2014

Ссылки[править | править код]

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