Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Разработчики мессенджера Signal решили наконец повысить безопасность версии приложения для десктопов. В частности, девелоперы поменяли способ хранения ключей шифрования, за что их критиковали с 2018 года.

Ранее при установке Signal на Windows- или macOS-устройства мессенджер создавал зашифрованную SQLite-базу для хранения сообщений пользователя. Эта БД шифровалась с помощью ключа, сгенерированного программой, без пользовательского ввода.

Чтобы программа могла расшифровывать базу и использовать её для хранения данных, нужен ключ шифрования. В случае с логикой работы Signal ключ хранился в виде простого текста в локальном файле по пути «%AppData%\Signal\config.json» в Windows и «~/Library/Application Support/Signal/config.json» — в macOS.

Источник: BleepingComputer

 

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

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

«Ключ от БД и не задумывался как нечто закрытое. Шифрование при хранении никогда не упоминалось в качестве функциональности десктопной версии Signal».

Однако девелоперы, судя по всему, пересмотрели своё отношение после одного из твитов Илона Маска, в котором миллиардер указывал на уязвимость в мессенджере.

Своё недоумение также высказывали исследователи в области кибербезопасности — например, Томми Миск.

Теперь, по словам разработчиков, они имплементировали поддержку Electron safeStorage. Нововведение скоро должно появиться в бета-версии Signal.

ФСТЭК России определилась со списком угроз для ИИ-систем

В банке данных угроз (БДУ), созданном ФСТЭК России, появился раздел о проблемах, специфичных для ИИ. Риски в отношении ИБ, связанные с качеством софта, ML-моделей и наборов обучающих данных, здесь не рассматриваются.

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

В инфраструктуре разработчика ИИ-систем оценки на предмет безопасности информации требуют следующие объекты:

 

Объекты, подлежащие проверке на безопасность в инфраструктуре оператора ИИ-системы:

 

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

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

В комментарии для «Ведомостей» первый замдиректора ФСТЭК Виталий Лютиков пояснил, что составленный ими перечень угроз для ИИ ляжет в основу разрабатываемого стандарта по безопасной разработке ИИ-систем, который планировалась вынести на обсуждение до конца этого года.

Представленная в новом разделе БДУ детализация также поможет полагающимся на ИИ госструктурам и субъектам КИИ данных скорректировать процессы моделирования угроз к моменту вступления в силу приказа ФТЭК об усилении защиты данных в ГИС (№117, заработает с марта 2026 года).

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

RSS: Новости на портале Anti-Malware.ru