Автообновление: это безопасно?

Question

Автоматическое обновление Dot Net

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

Вот шаги:

• Клиентское программное обеспечение заполняется открытым ключом и URI для опроса.
• Клиент опрашивает URI для файла манифеста.
• Манифест загружен, а подпись (в отдельной «.signature») используется для проверки правильности манифеста.
• Список ожидающих обновлений анализируется из манифеста (для показа пользователю).
• Файл установщика загружается и снова проверяется соответствующим файлом ".signature". (загруженный файл будет защищен списками ACL)
• Установщик запущен.

Смягченные угрозы:

• Подпись манифеста должна предотвращать любые злонамеренные загрузки (" ковровая бомбардировка ")
• Подпись установщика должна предотвращать любые атаки MITM от отправки вредоносных установщиков
• Защита загруженного установщика с помощью ACL должна предотвратить любые локальные атаки на эскалацию.

Непосредственные угрозы:

• A MITM атака, при которой злоумышленник всегда сообщает "нет доступных обновлений". (Может держать клиента на уязвимой версии)

Ссылки

• Безопасные обновления программного обеспечения: разочарования и новые вызовы
• Black Ops 2008: конец кэша, каким мы его знаем
• Evilgrade уничтожит нас всех

Что я пропустил?

Answer 1

У Дана Камински есть хороший набор рекомендаций по обновлению:

Чтобы добиться успеха, ваш пакет обновления должен быть:

• Signed.
• Подписано вами.
• Подписано вами, используя правильный EKU (Расширенное использование ключа)
• Подписано без аннулированной подписи
• Будь таким же товаром
• Будь новой версией

Из вашего описания в этом вопросе видно, что у вас есть первые 3.

Answer 2

Собрав собственный развертыватель в корпоративной среде, я приведу несколько вариантов использования:

• поддержка цифровой подписи

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

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

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

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

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

• ваш инструмент должен быть подписан сильным сертификационным органом.

Что касается атаки на MITM, о которой вы упомянули, то ее легко решить с помощью общедоступной криптографии (как отмечено unknown )

Answer 3

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

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

Answer 4

Не хочу быть здесь троллем, но вы пытаетесь решить уже решенную проблему. Использование SSL было бы намного лучшим выбором. Это решит все проблемы, перечисленные в вашем вопросе.

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

Не забывайте: «Сложность - враг безопасности».

Answer 5

В этом посте есть очень хороший комментарий и решение. Но я полностью согласен с доктором. злой. Вы должны использовать SSL-соединение для обновления, и сертификат должен быть сохранен (встроен) на клиенте. Таким образом, вы можете убедиться, что клиент не примет поддельный сертификат. Я думаю, что это эффективно защитит клиента от атаки MiTM.

ПРИМЕЧАНИЕ. Если клиент может принять неавторизованный сертификат, атака MiTM может быть успешной, поэтому не давайте эту опцию клиенту.

Редактировать: Я думаю, что сертификат SSL может быть самозаверяющим в этом случае.

Answer 6

Так что я ничего не понимаю; загрузчик проверяет, что манифест является тем, который он ожидает, через сигнатуру, делает ли он то же самое для фактических патчей, которые он устанавливает?

Answer 7

Как дополнение, добавьте контрольную сумму MD5 к загруженному файлу, в противном случае выглядите неплохо:) - Честный комментарий ниже.

Добавлено:

Единственное, что я могу здесь увидеть, это углубиться в такие вещи, как запутывание кода или архивирование установочного файла и блокировка архива, а затем его загрузка, разблокировка. Этот тип вещи. Однако я думаю, что то, что вы сделали в настоящее время, должно быть на 100%.

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