В информационной безопасности мы выработали ряд аксиом, с которыми не принято спорить:

• Никогда не внедряйте собственную криптографию.
  
• Всегда используйте TLS.
  
• Безопасность через неясность (security by obscurity) это плохо.

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

Риск, эшелонированная оборона и швейцарский сыр

Одной из главных задач ИБ является снижение рисков. Согласно методологии OWASP, риск возникновения проблемы рассчитывается по формуле:

Риск = Вероятность * Воздействие

По этой формуле, проблема удалённого выполнения кода (RCE) представляет больший риск, чем проблема межсайтового скриптинга, поскольку RCE несёт большее воздействие. Здесь всё просто. Но что насчёт метрики вероятности? Согласно OWASP, вероятность определяется так:

На самом высоком уровне это приблизительная оценка шансов, что конкретная уязвимость будет раскрыта и использована злоумышленником

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



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

Безопасность через неясность

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

Рассмотрим несколько сценариев:

• На моём сервере SSH запускается на дефолтном порту 22, а учётные данные root:123456. Какова вероятность компрометации?

Вероятность почти 100%, так как хакеры по всему интернету брутят сервисы со стандартными учётными данными.

• SSH работает на порту 22, а учётные данные utku:123456. Какова вероятность компрометации?

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

• SSH работает в порту 64323, а учетные данные utku:123456. Какова вероятность компрометации?

Мы изменили номер порта по умолчанию. Поможет ли это? Во-первых, мы снова устранили опасность стандартного брутфорса, поскольку он сканирует только общие порты. А как насчёт остальных? Я провёл небольшой опрос в своём твиттере, чтобы выяснить поведение людей при сканировании портов.


Как видите, многие склонны сканировать только стандартные и самые популярные порты. Таким образом, если вы измените порт с 22 на 64323, то устраните некоторые из потенциальных атак. Вы уменьшите вероятность и риск.

То же самое относится и к уязвимостям программного обеспечения. Если уязвимость обнаружена в протоколе Microsoft Remote Desktop Protocol, весь интернет начнёт сканировать порт 3389. Вы можете уменьшить риски, просто изменив порт по умолчанию.

Другие области применения

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

• Обфускация кода: конечно, это общеизвестно. Хакеры тоже люди. Если вы хорошенько обфусцируете код, им придётся уделить больше времени на поиск проблем. В конце концов они могут сдаться.
  
• Случайные имена переменных для веб-приложения: Вместо понятных имён переменных можно использовать случайные символы. Это может помочь точно так же, как обфускация кода.
  
• Симметричное шифрование в базе данных: при записи данных в БД используйте функцию вроде encryption_algorithm(data, key). Аналогично, при считывании данных decryption_algorithm(data, key). Если злоумышленник получил доступ к внутреннему коду, то, очевидно, сможет расшифровать БД. Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.

Применение в реальной жизни

Безопасность через неясность широко используется в физической/реальной безопасности. Например, президент едет из пункта А в пункт Б с кортежем из 30-ти автомобилей. Но он не сидит в своей президентской машине, чтобы не стать лёгкой мишенью. Он может находиться в любой машине из кортежа, и это снижает риск нападения.



Животные также используют безопасность через неясность это камуфляж. Скрытность снижает вероятность быть убитым. Поэтому в процессе эволюции они приобрели такую способность.

Вывод

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

Разработка своей криптографии в чём-то сравнима с созданием собственного авиадвигателя, говорит эксперт по безопасности Руна Сандвик. Фото: Виталий Кузьмин

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

Казалось бы, почему не использовать открытые стандарты типа WebSocket и JSON, зачем собственный закрытый протокол? На это обычно приводят ряд причин. Во-первых, для безопасности, чтобы его было сложнее отреверсить и никто не понял, какие данные вы передаёте. Во-вторых, для эффективности. У нас ведь уникальный случай использования, поэтому стандартные решения не самые оптимальные. Наш собственный протокол будет работать с меньшими задержками, потреблять меньше трафика и меньше расходовать батарею (на мобильных устройствах). И третья причина функции. В своём протоколе специально для нашего приложения мы реализуем уникальные возможности, каких нет ни в открытом стандарте, ни у конкурентов.

Это распространённые причины, из-за которых разрабатывают проприетарные протоколы.

Безопасность

Поговорим о безопасности.

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

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

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

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

В общем, проприетарный протокол кажется очень выгодным для фирмы.

Но жизнь иногда показывает обратное. А именно:

1. Принцип безопасность через неясность не работает. Любой протокол можно отреверсить.
   
2. Проприетарная реализация шифрования это очень рискованно.
   
3. Никто не поможет закрыть критические дыры в закрытом софте.

Принцип безопасность через неясность не работает в криптографии

Принцип безопасность через неясность (security through obscurity) заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.

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

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

В итоге получается, что собственный проприетарный протокол, максимально закрытый от посторонних глаз и обфусцированный, вовсе не увеличивает безопасность системы, а уменьшает её!

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

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

Собственная криптография

Вопрос Почему не разработать собственную криптографию? чем-то похож на вопрос Почему не спроектировать авиадвигатель?, говорит Руна Сандвик, исследователь по безопасности. Конечно, теоретически мы можем это сделать. Но это чрезвычайно сложно. Гораздо более простой и надёжный вариант выбрать готовое решение, проверенные и надёжные протоколы и алгоритмы.

Поэтому в сообществе информационной безопасности вызывает большое подозрение, если какая-то компания реализует собственный проприетарный протокол. Например, проприетарный протокол MTProto в Telegram поначалу вызвал массу критических отзывов. Взлом MTProto1.0 стал одной из самых популярных статей на Хабре в 2013 году: Безопасен ли Telegram? Или как я искал закладку в MTProto (спойлер: глупые ошибки в проприетарной криптографии).

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

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

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

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

Конечно, в опенсорсе есть свои специфические риски. Например, проблемы с сотнями зависимостей, которые вы не контролируете. Например, 20% багов в проектах на GitHub явно внесены в проекты специально, со злым умыслом. То есть вредоносными контрибуторами, которые действовали умышленно. Ещё не забыта история c мейнтейнером ESLint, который 12 июля 2018 года опубликовал вредоносные версии пакетов eslint-scope и eslint-config-eslint в репозитории npm.

Такое может случиться с каждым опенсорсным проектом, потому что мейнтейнеры работают бесплатно, на износ:

• Каково быть мейнтейнером свободного ПО
  
• Мейнтейнеры не масштабируются
  
• Трудно быть мейнтейнером проекта Open Source

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

Но все проблемы безопасности решаемы. Независимый аудит открытого кода профессиональными экспертами лучшая гарантия его надёжности.

Кстати, в 2013 году проприетарный софт впервые обогнал опенсорсные проекты по среднему количеству багов на 1000 строк кода.


Источник: Coverity Scan Open Source Report

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

Возвращаясь к примеру Telegram. 5 декабря 2020 года двое итальянских математиков Марино Микулан и Никола Витоколонна опубликовали на сайте препринтов arXiv.org исследование Автоматическая символическая проверка протокола MTProto 2.0 в Telegram (вторая версия опубликована 30 апреля 2021 года, arXiv:2012.03141v1). Оно подтверждает безопасность обновлённой версии фирменного протокола MTProto 2.0.


Набор протоколов MTProto 2.0 (в голубой рамке) и область покрытия данной научной работы (светло-зелёным цветом). Схема из научной статьи Марино Микулана и Никола Витоколонны, arXiv:2012.03141v1

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


Протокол аутентификации MTProto 2.0. Здесь означает асимметричное шифрование открытым ключом . В свою очередь, означает симметричное шифрование общим ключом с вектором инициализации . Схема из научной статьи


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

---

Эта математическая работа чуть ослабила озабоченность экспертов по поводу проприетарного протокола MTProto2.0. Редкий случай, когда собственная нестандартная криптографическая система (пока) работает надёжно. В ней ещё не нашли таких фатальных уязвимостей, как в MTProto 1.0.

Неужели разработчики Telegram всё-таки научились и смогли сделать уникальный авиадвигатель без ошибок? Можно только порадоваться за них, ведь все пользователи Telegram участвовали в этом обучении как бета-тестеры. В каком-то смысле это наш общий успех.

---

На правах рекламы

Наша компания предлагает серверы с Linux или Windows. Не экономим на железе только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Присоединяйтесь к нашему чату в Telegram.