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.

Мошенники начали рассылать «работу мечты» через Google AppSheet

«Лаборатория Касперского» предупредила о новой фишинговой схеме: мошенники используют Google AppSheet, чтобы рассылать письма с заманчивыми предложениями о работе. Письмо приходит с настоящего сервисного адреса noreply@appsheet.com, отправитель выглядит как рекрутинговая команда крупной компании, а внутри — предложение обсудить карьерные возможности.

Схема в целом интересная: злоумышленники регистрируются в Google AppSheet, оформляют рассылку и маскируют её под сообщение от рекрутеров технологических компаний, FMCG-брендов или автопроизводителей.

Получателю предлагают перейти по ссылке, чтобы выбрать время встречи и оставить контактные данные.

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

Есть и другой сценарий: ссылки в письме может вообще не быть. Вместо этого адресата просят ответить команде рекрутеров. Скорее всего, дальше жертву начинают обрабатывать уже в переписке.

Почему такие письма проходят в почту? Потому что они идут через инфраструктуру Google. А значит, часто успешно проходят проверки SPF, DKIM и DMARC. Для пользователя это выглядит солидно, для фильтров — менее подозрительно.

Плюс AppSheet позволяет отправлять не только письма, но и СМС. Чтобы запустить такую кампанию, достаточно платной подписки даже на базовом тарифе. То есть порог входа низкий, а доверия к домену Google — много.

В «Лаборатории Касперского» отмечают, что злоумышленники всё чаще используют легитимные облачные сервисы в атаках. Раньше похожие схемы фиксировали с Google Формы, Google Задачи, Google Таблицы и даже OpenAI. Теперь в список добавился AppSheet.

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