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.

У CrowdSec украли код примерно 300 репозиториев через атаку на TanStack

Французская ИБ-компания CrowdSec подтвердила утечку исходного кода из GitHub. Злоумышленники добрались примерно до 300 репозиториев, около 170 из которых были закрытыми.

В официальном заявлении CrowdSec уточняется, что инцидент произошёл ещё в мае 2026 года, однако компания узнала о нём только 16 сентября.

В похищенный массив вошёл код SaaS-консоли, некоторых процедур для AWS, коннекторов и средств автоматизации. Остальные более 130 репозиториев содержали открытый код, который и так был публично доступен.

Предполагаемым входным билетом стала атака на цепочку поставок TanStack. В мае CrowdSec использовала скомпрометированный компонент, который, вероятно, вытащил API-ключ с правами на чтение закрытой кодовой базы.

Компания утверждает, что клиентские данные, имена, пароли и сведения об организациях в утечку не попали. Специалисты также не обнаружили токенов или других секретов, которые позволили бы атакующим двигаться по инфраструктуре дальше. Тем не менее все потенциально затронутые ключи и учётные данные CrowdSec сразу заменила.

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

Расследование продолжается, а CrowdSec обещает следить за подозрительной активностью.

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