О недавних успехах кибермедведей
2020-12-16 06:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurНедавний взлом американских федеральных учреждений через обновление программы SolarWinds (которое было автоматическим и даже содержало валидную электронную цифровую подпись) показал всю опасность подхода "безусловно доверять автоматическим обновлениям и держать эту опцию постоянно включённой".
Если бы генералам из Department of Defenсe, Department of Homeland Security и State Department подчинённые в своё время честно сказали «мы вручаем "ключи от королевства" неизвестному индусу, который в компании SolarWinds является инженером по сборке», вряд-ли этот взлом случился бы. У федеральных ведомств тысячи подрядчиков, и если каждому из них и его собаке была предоставлена безотзывная возможность сейчас или в любой другой более удобный для них момент времени взломать любой сервер правительства США — то эту ситуацию в целом сложно охарактеризовать как "безопасную". Хотя именно этот "безопасностный" хайп постоянно разгоняют адепты секты свидетелей принудительных автоматических обновлений.
Эти адепты в своё время упустили из виду, что помимо преимуществ для безопасности (в виде оперативного исправления RCE-узявимостей типа "переполнение буфера"), открываемых автоматическими обновлениями, есть и недостатки, которых явно больше:
1) Очень сильно расширяется круг доверенных лиц, которые могут занести бэкдор в федеральное учреждение (раньше это были только внутренние админы типа Мэннинга и Сноудена, а теперь это ещё и каждый человек со стороны, у которого есть право подписи автоматически устанавливаемых обновлений для софта, используемого на хотя бы одном из компьютеров во внутренней сети; боюсь, что генералы даже и не подозревают, что таких людей гораздо больше, чем находится в штате их ведомств и в их непосредственном подчинении).
2) Вся схема очень сильно завязана на криптографию. Если завтра будет взломан алгоритм цифровой подписи RSA, или ECDSA, или криптографическая хэш-функция SHA2, или одна из популярных реализаций, или если где-то произойдёт утечка криптографических ключей, тогда обновления для "федералов" сможет подписывать каждый сантехник из ближайшего интернет-провайдера. Это будет настоящий хаос.
3) Общее увеличение связности системы влечёт общее увеличение хаоса. Снижаются требования к качеству кода, к тестированию и т.д., все разработчики начинают работать "на авось", по принципу "зачем париться, потом всё патчем исправим" и т.д.
4) Постоянно открытый бэкдор во внутренние сети федеральных учреждений фактически "сводит на нет" любую сертификацию софта или оборудования на предмет криптографической надёжности, конфиденциальности обрабатываемых данных и т.п. — все эти гарантии могут быть нивелированы ближайшим обновлением, которое вступит в силу ещё до того, как высохнут чернила на "сертификате безопасности", который был с таким трудом получен федеральным подрядчиком. Следовательно, всю систему подобной сертификации следует полностью упразднить. Или упразднить практику безусловно-доверенных автоматических обновлений. Одно из двух.
А теперь представьте на минуточку, что в следующий раз взятку "за невнимательность" от кибермедведей получит индус не из SolarWinds, а из Microsoft, и обновление с бэкдором прилетит не десяткам тысяч пользователей, а сотням миллионов.
Если бы генералам из Department of Defenсe, Department of Homeland Security и State Department подчинённые в своё время честно сказали «мы вручаем "ключи от королевства" неизвестному индусу, который в компании SolarWinds является инженером по сборке», вряд-ли этот взлом случился бы. У федеральных ведомств тысячи подрядчиков, и если каждому из них и его собаке была предоставлена безотзывная возможность сейчас или в любой другой более удобный для них момент времени взломать любой сервер правительства США — то эту ситуацию в целом сложно охарактеризовать как "безопасную". Хотя именно этот "безопасностный" хайп постоянно разгоняют адепты секты свидетелей принудительных автоматических обновлений.
Эти адепты в своё время упустили из виду, что помимо преимуществ для безопасности (в виде оперативного исправления RCE-узявимостей типа "переполнение буфера"), открываемых автоматическими обновлениями, есть и недостатки, которых явно больше:
1) Очень сильно расширяется круг доверенных лиц, которые могут занести бэкдор в федеральное учреждение (раньше это были только внутренние админы типа Мэннинга и Сноудена, а теперь это ещё и каждый человек со стороны, у которого есть право подписи автоматически устанавливаемых обновлений для софта, используемого на хотя бы одном из компьютеров во внутренней сети; боюсь, что генералы даже и не подозревают, что таких людей гораздо больше, чем находится в штате их ведомств и в их непосредственном подчинении).
2) Вся схема очень сильно завязана на криптографию. Если завтра будет взломан алгоритм цифровой подписи RSA, или ECDSA, или криптографическая хэш-функция SHA2, или одна из популярных реализаций, или если где-то произойдёт утечка криптографических ключей, тогда обновления для "федералов" сможет подписывать каждый сантехник из ближайшего интернет-провайдера. Это будет настоящий хаос.
3) Общее увеличение связности системы влечёт общее увеличение хаоса. Снижаются требования к качеству кода, к тестированию и т.д., все разработчики начинают работать "на авось", по принципу "зачем париться, потом всё патчем исправим" и т.д.
4) Постоянно открытый бэкдор во внутренние сети федеральных учреждений фактически "сводит на нет" любую сертификацию софта или оборудования на предмет криптографической надёжности, конфиденциальности обрабатываемых данных и т.п. — все эти гарантии могут быть нивелированы ближайшим обновлением, которое вступит в силу ещё до того, как высохнут чернила на "сертификате безопасности", который был с таким трудом получен федеральным подрядчиком. Следовательно, всю систему подобной сертификации следует полностью упразднить. Или упразднить практику безусловно-доверенных автоматических обновлений. Одно из двух.
А теперь представьте на минуточку, что в следующий раз взятку "за невнимательность" от кибермедведей получит индус не из SolarWinds, а из Microsoft, и обновление с бэкдором прилетит не десяткам тысяч пользователей, а сотням миллионов.
no subject
Date: 2020-12-16 05:55 pm (UTC)впрочем всё это закладывалось десятилетими и сознательно
no subject
Date: 2020-12-16 07:37 pm (UTC)no subject
Date: 2020-12-16 06:45 pm (UTC)no subject
Date: 2020-12-16 09:33 pm (UTC)no subject
Date: 2020-12-17 07:27 am (UTC)ну или для защиты трафика слесаря васи, который инах никому не нужен из серьёзных пацанов
о нём гулаглы с хуяндексами итак всё знают
no subject
Date: 2020-12-17 10:17 am (UTC)Kp — это публичный ключ, он распространяется вместе с программой и предназначен для проверки электронной цифровой подписи. Независимо от того, обновляет ли программу внешняя сущность (пакетный менеджер, платформа Adobe AIR, Microsoft Windows Store) или программа обновляет себя сама (классические Windows приложения), ключ Kp легко доступен злоумышленникам (которые хотят подделать подпись).
Ks — это приватный (секретный) ключ, который позволяет сформировать электронную цифровую подпись. Этим ключом разработчики не должны никогда делиться с внешним миром, т.к. в этом случае хакеры смогут подделать любую подпись и от имени разработчиков распространять вредоносное ПО. В случае SolarWinds именно это и случилось: обновление программы с вредоносным модулем было подписано тем же ключом, как будто новая версия старой, хорошо известной программы.
Существует математическая связь между Kp и Ks. На самом деле, Ks можно всегда вычислить из Kp. Ks — это решение одной безумной математической задачки, полным условием которой является Kp (и ещё пара констант, которые общеизвестны и не меняются от ключа к ключу). Этой безумной математической задачкой является "дискретное логарифмирование в кольце вычетов по модулю очень большого простого числа" (для схемы ЭЦП RSA) или "дискретное логарифмирование на эллиптической кривой над конечным полем" (для схемы ЭЦП ECDSA). Обзор алгоритмов есть в Википедии, и на данный момент все они считаются непрактичными (слишком медленными) при выбранной длине ключа. Если завтра будет открыт новый (более быстрый) метод дискретного логарифмирования, тогда обе схемы (RSA и ECDSA) могут очень быстро "посыпаться". Возможно, он уже существует, просто пока ещё неизвестен широкой общественности. Такая история была в своё время с дифференциальным криптоанализом, который стал известен NSA на 20 лет раньше, чем широкой общественности (из-за чего они в своё время рекомендовали внести соответствующие правки в черновик стандарта DES).
Хэш-функции типа SHA2 могут быть подвергнуты другому типу атак, известных как chosen preimage attack. Пока практические атаки такого типа неизвестны именно для SHA2, но известны для некоторых более ранних хэш-функций, MD5 и SHA1, ранее считавшимися безопасными. В этом случае цифровую подпись подделывать необязательно: достаточно изменить код программы так, чтобы её хэш остался прежним. Тогда подойдёт прежняя подпись.
Ещё один способ обойти защиту — это каким-то образом узнать начальное состояние генератора псевдослучайных чисел, из которого была сгенерирована пара ключей (Kp,Ks). Если это каким-то образом удастся (например, генератор псевдослучайных чисел был засеян из низкоэнтропийного источника случайных чисел), тогда можно воспроизвести весь процесс генерации ключей и при заранее известном Kp получить неизвестный Ks. Этим раньше грешили некоторые HSM: у публичных RSA-ключей из TLS-сертификатов на большой выборке обнаружились общие множители. Возможно, это просто "товарищ майор" облажался при закладке бэкдора в HSM: например, если вместо истинного rand() они реализовали генерацию гаммы AES-CTR на статическом секретном ключе.
Ещё один возможный способ, которым всё может сломаться — это так называемые "слабые ключи". Такая история уже была в своё время с DES: существует класс так называемых "слабых ключей", которые более подвержены некоторым видам криптоанализа. Поэтому после генерации ключей для DES необходимо проверить результат с помощью специального теста, и в случае его положительного исхода, повторить попытку генерации ключа. Хотя дискретное логарифмирование может быть сложным для общего случая, некоторые RSA/ECDSA-ключи тоже могут оказаться "слабыми" в том смысле, что для некоторого класса ключей найдётся более эффективный алгоритм дискретного логарифмирования. Пока об этом ничего не известно, по крайней мере, из открытых источников.
no subject
Date: 2020-12-17 03:50 am (UTC)