Иллюстрация thehackernews.com
Signal обрел популярность после того, как стал известен в качестве «любимого мессенджера» Эдварда Сноудена. В 2015 г. он рассказал, что ежедневно пользуется приложением Signal для связи с журналистами.
Мессенджер Signal позиционируется как особо защищённое средство обмена информацией, в котором используется сквозное шифрование, что должно исключать доступ посторонних к содержимому переписки. Однако, как выяснилось, существуют ситуации, когда всё старания по шифрованию информации Signal оказываются тщетными.
Первоначально Signal был доступен только как приложение для мобильных телефонов, но удобство требовало настольной версии, которая в результате появилась в виде расширения для Chrome. С конца октября 2017 пользователям стал доступен новый вариант автономного приложения, не зависящего от браузера. С этого же момента расширение для Chrome получило статус end-of-life, и на момент публикации данной статьи срок его поддержки истекает менее чем через месяц. Здесь и начинается грустная история.
Делай раз
Исследователь в области информационной безопасности Мэтью Сюиш поделился открытием, что один из самых защищенных крипто-мессенджеров «подложил» своим пользователям «свинью» впечатляющих размеров. Мессенджер Signal в процессе миграции от расширения для Chrome до полноценного десктопного клиента экспортирует сообщения пользователя в незашифрованные текстовые файлы.
Мэтью Сюиш обнаружил этот опасный баг при работе в macOS, когда обновлял Signal. Журналисты BleepingComputer пошли дальше и выяснили, что такая же точно проблема проявляется и в Linux Mint.
При экспорте диалогов на диск Signal формирует отдельные папки, именованные по имени и телефонному номеру контактов. Всё содержимое диалогов хранится в формате JSON открытым текстом. Никаких предупреждений о том, что информация расшифровывается и сохраняется на диск, программа не выводит. Этот момент и является ключевым для угрозы утечки конфиденциальных данных.
Самое плохое же в этой ситуации — незашифрованные сообщения остаются на диске даже после завершения апгрейда, и удалять их придется вручную, если, конечно, пользователь вообще догадается…
Делай два
Но этого было мало! Вторую проблему в Signal Desktop выявил другой исследователь, Нэйтан Сёчи.
Нэйтан Сёчи узнал, что во время установки Signal Desktop создается зашифрованная база данных db.sqlite с архивом сообщений пользователя. Ключ шифрования для базы данных генерируется мессенджером без взаимодействия с пользователем и используется каждый раз, когда нужно прочитать базу с архивом сообщений. Кто бы мог подумать, что ключ хранится локально и открытым текстом? Этот ключ можно найти на PC в файле %AppData%\Signal\config.json и на Mac в ~/Library/Application Support/Signal/config.json.
Делай три, Signal синим пламенем гори!
По-видимому, на этом проблемы с Signal не заканчиваются. Например, ещё один эксперт, Кит МакКэммон указывает, что Signal Desktop плохо справляется с удалением вложений из «исчезающих» сообщений.
Функция «исчезающих» сообщений задумывалась разработчиками Signal как дополнительный эшелон безопасности, но на деле работает она не очень ненадёжно. По заявлению МакКэммона, все вложения остаются на диске пользователей Signal даже после того, как должны были быть удалены.
lixmix
Прочитав заголовок статьи подумал о том, что сигнал тайно сохраняет сообщения и ключи открытым текстом на удаленных серверах, но похоже здесь речь о другом. Получив локальный доступ к устройству можно много чего сделать
vyaradaikin
Ох уж это мастерство загаловка. ладно хоть обошлось без «ШОК! Signal тайно стал делать это...»
Jeditobe Автор
А что не так с заголовком? Сигнал никак не предупреждает о расшифровке. Для пользователей не прочитавших эту статью, это будет очень «приятным» сюрпризом. Особенно если учесть, что не каждый станет пользоваться Signal просто потому, что захотелось. Наверняка были веские причины.
vyaradaikin
Во-первых, заголовок кликбейтный, ну ладно, щас без этого никто не живет. Во-вторых, signal выбирают из-за его проверенной надежности в плане шифрования данных при передаче и не складировании где-то посередине. В-третьих, signal не для рядовых пользователей, а те, кто в теме всегда оценивют модель угроз при использовании средств общения (ставки высокие). В-четвертых, не видел, чтобы signal утверждал, что он обеспечивает локальное шифрование и надежное хранение (да, есть вещи, о которых нужно думать самому). То, что кто-то себе напридумывал с оверсекурностью сигнала, его личные проблемы. Вот поэтому заголовок со словом «тайно» ничего, кроме кликбейтности не имеет.
Jeditobe Автор
Отвечу мультфильмом 1993 года.
vyaradaikin
Да как угодно, это ничего не меняет, кроме желания хайпа:)
ValdikSS
В заголовке написано:
Как есть на самом деле:Человек, создавший баг в багтрекере, сделал экспорт для обновления с (вероятно, очень старой, с несовместимой базой) версии программы на версию новее, 3 дня назад. Авторы пока не ответили на этот баг. Кроме того, пишут:
Jeditobe Автор
Последняя фраза дополняется другой фразой того же человека:
Что значит, я тут мимокрокодил и заметил, что оно не шифруется, но я не разработчик и не знаю зрада это чи перемога.
Сигналу следовало бы лучше информировать своих пользователей о дизайне локального способа хранения потенциально конфиденциальных данных.
ValdikSS
Покуда десктопные ОС позволяют программе, запущенной от учетной записи, получить доступ ко всем файлам этой учетной записи, способы локального хранения не играют значительной роли, и типичные реализации шифрования с использованием пароля на запуск программы могут только замедлить расшифровку данных, но не предотвратить её.
Сохраняет ли Signal историю и ключи шифрования тайно? Вероятно, нет. Заголовок не соответствует действительности.
Chamie
leventov
Можно считать что Дуров был прав, или это не тот случай?
Vindicar
Ну я бы сказал, что это предсказание из разряда «или халиф, или ишак, или я». Всё-таки сейчас пять лет — это очень много. =)
Тем более что отличить хороший бэкдор от обычной ошибки/непроработанности непросто.
7audio
— создатель централизованного мессенджера с проприетарным шифрованием, про децентрализованный опенсорсный мессенджер
Sabubu
Сигнал централизованный, как я понимаю. Плюс, привязан к номерам телефонов (читай: к личности и местоположению).
7audio
Точно, извиняюсь, перепутал с Matrix.
Это только на 1/3 уменьшает иронию ситуации — вопросы к открытости кода (https://github.com/signalapp/Signal-Server vs код серверов тг закрыт) и проверенности криптографии остаются.
И Телеграм также без подтверждения номера не работает.
Chamie
vyaradaikin
Давно математики доказали, что общедоступные алгоритмы шифрования надежнее, чем самописные. Еще вопрос, кто первым профейлится, AES с бэкдором или Дуров со своей самопиской
Jeditobe Автор
Если бэкдор есть, то значит его уже используют.
vyaradaikin
Если бэкдор есть в алгоритме, используемом правительством США, то потенциальные противники могут его также эксплуатировать. Не слишком умно как-то.
Jeditobe Автор
А вы не думаете, что у них для особо важных дел есть своя версия алгоритма или рекомендации как избежать действия бэкдора? Это ж банально горшок с медом. Примерно как у нас есть ГОСТ 28147-89, у которого есть гражданский вариант, и был секретный военный вариант, немного модернизированный.
vyaradaikin
Наличие сноуденов всяких показывает, что не бывает ничего уж слишком секретного. Кроме того, дырявость систем в США показывает, что это далеко не главная угроза. А последствия от раскрытия подобного бэкдора были бы катастрофическими. Мало того, что куча правительственных систем остались бы без защиты, так и еще и подорвано доверие к системе международной стандартизации алгоритмов шифрования.
Jeditobe Автор
Ваша гипотеза мою гипотезу опровергнуть не может. Вероятность остается.
tzps
Весь смысл «безопасных мессенджеров» строго в невозможности доступа третих лиц к переписке с использованием незащищенных каналов связи.
Если у вас есть есть доступ к железу на котором крутится что-то «безопасное», то оно в любом случае не может считаться «безопасным». Как бы не новость.
p.s. Но, конечно, косяк :)
Temmokan
Уязвимость, но при наличии доступа на локальное устройство.
Занятно, что именно сегодня пакет Signal потребовал обновиться.
Jeditobe Автор
У моего знакомого пропали скромные сбережения в крипте, из-за того, что было слабое обратимое шифрование файла данных локального кошелька. Кроме него к компу доступа никто не имел. Всего-лишь нужно человеку интересующему забросить на комп пейлоад вредоносный каким-то способом.
simplix
Сбережения пропали из-за знакомого, а не из-за слабого шифрования — с тем же успехом троян мог перехватить пароль при вводе. Полумеры в безопасности недопустимы и если пользователь не предусматривает все векторы атак, то виноват в этом только он сам.
Jeditobe Автор
Кошелек лежал не тронутым несколько месяцев, никакие пароли он не вводил, перехватить было нельзя. Пользователь не может знать всего. А в кошельке была уязвимость, которую разработчики игнорировали полгода.
Я это сказал к тому, что оправдание «при наличии доступа на локальное устройство» в реальности очень слабая отговорка.
simplix
Вы перекладываете ответственность пользователя на софт в то время, когда софт отлично выполняет свою задачу. А если разработчик сделает сильное шифрование, но не будет требовать минимум 14-значный пароль в разном регистре с цифрами и спецсимволами, и пользователь введёт «12345», то виноват снова разработчик?
Безопасность — комплексная мера, с разделением уровней доступа в софте и даже физическим ограничением доступа к железу, кто этого не понимает обвиняет кого только можно, но не себя, вот только от этого он не станет прав и продолжит терять данные.
Jeditobe Автор
Ничего я не перекладываю. Касательно Signal, программа должна была в явном виде предупредить пользователя, что сейчас все чаты будут расшифрованы и сохранены на диск, что ключ от базы тоже лежит на диске в открытом виде. Предупредить: примите дополнительные меры или хотя бы имейте это ввиду. Signal этого не сделал.
А вот, к примеру, Тор всегда предупреждает, о необходимости принятия дополнительных мер по анонимизации.
По криптокошельку вот ссылка на историю vxlabs.com/2017/06/10/extracting-the-jaxx-12-word-wallet-backup-phrase Там ровно такая же история, там создатели начали оправдываться и говорить, что «наш кошелек вовсе не то, что вы могли подумать», но только после того, как куча людей уже попали на бабки. А нужно было предупреждать всех при первом запуске программы.
Temmokan
Полагаю, выносить суждение можно, только когда все данные перед глазами.
В любом случае, если на систему занесли вредонос, боржом пить поздно. В такой ситуации нужен уже следующий пункт инструкции: как минимизировать ущерб, если вас всё-таки pwn'ули.
olis
Не хватает пункта опроса «Ничего не поменялось. Использую как компромиссное временное решение»
RusTech
Где вариант «Не пользуюсь» (Давно про него знаю и не пользуюсь)?
Jeditobe Автор
Добавил.
simplix
Ждём новость «шок — системы по умолчанию не шифруют данные, наглые производители бездействуют».
lostmsu
Несмотря на многие саркастические комментарии к этой статье, в определённой степени это — действительно провал. Приложение могло бы хранить ключи в TPM или его аналогах (secure enclave).
saipr
Или на токенах/смарткартах PKCS#11!
powerman
Даже не смешно. Единственный реальный вариант — запрашивать у юзера мастер-пароль, который используется для получения ключа шифрования. Если приложение такого пароля не запрашивает при каждом запуске — локальные данные этого приложения, по определению, не могут быть адекватно защищены.
Вообще, защита локальных данных — это довольно скользкая тема. От мессенджера я лично ожидаю исключительно защиты данных при передаче по сети (в т.ч. от разработчиков мессенджера, чтобы исключить хранение моей переписки у них на серверах). От менеджера паролей, gnupg, ssh, криптокошелька — надёжной защиты данных хранящихся у меня на винте и хотя бы формальных попыток защитить пароли/ключи находящиеся в памяти этих приложений. Шифрование логов мессенджера у меня на винте для меня задача не очевидная — вопрос от каких именно рисков это шифрование должно помогать? При ответе на этот вопрос нередко выясняется, что основной риск — это физический доступ к компу посторонних, но для защиты от этого самое адекватное решение это шифрование диска целиком.
Единственное, с чем я согласен в статье — то, что вложения в самоуничтожающиеся сообщения не удалялись — это фейл.
Valle
А если tpm нет? К тому же это все равно security through obscurity — если ключ в какой-то момент находится в памяти его можно достать точно так же как например кейлоггер может записать мастер пароль. Единственное для чего делают локальное шифрование — это защита от белок-паникеров "Аааа!!! Не зашифровано!!! Опасность! Бэкдор! Ужас!"
lostmsu
Если TPM нет, то и вариантов-то особо нет. Только если внешний ключ, как предложили выше.
Некоторые TPM умеют (де-)шифровать ключом без раскрытия оного.
titbit
А каким пользоваться тогда? Такое впечатление создается, что несмотря на некоторое «изобилие» придется писать свой, ага, 15-ый как на карикатуре xkcd. Большинство имеющихся, увы, либо смотрит на безопасность сквозь пальцы, либо допускает сомнительные решения, которые тут же становятся векторами атаки.
Jeditobe Автор
Да можно и Сигналом наверное пользоваться, просто теперь нужны дополнительные меры безопасности.
OnelaW
Карандаш и бумага. После прочтения сжечь.
bogolt
«Перед прочтением сжечь!» Классика же =)
powerman
OMEMO если используется Jabber. OTR для остальных протоколов. Вероятно, Matrix тоже подходит. Для совсем гиков можно ещё Keybase. Шифрование в популярных мессенджерах вроде вотсапа или телеграм у меня лично вызывает большие сомнения, из таких разве что Signal выглядит приемлемым на крайний случай, но лучше не рисковать и ограничиться OMEMO и OTR.
andreymal
Не забываем, что OMEMO сделан на базе протокола Signal
powerman
Ничего не имею против протокола Signal, но привязка самого клиента к номеру телефона, самому телефону, контактам — это на любителя. Я предпочитаю мессенджеры, которым не нужно сообщать номер телефона.
ValdikSS
Вы имеете в виду Double Ratchet Algorithm, а не протокол Signal (который описывает сетевое взаимодействие).
sergeyns
Хе-хе. Вы не представляете сколько ПРОМЫШЛЕННО эксплуатируемых систем хранит ключи в открытом виде. Обычная реакция техподдержки вендора на обращение с вопросом «как зашифровать» отвечает «что предполагается что доступ к серверу есть только у администратора».
psman
Ну всегда будет проблема хранения ключа где то. И доступу к этому носителю.
SergeyMax
vanxant
Ну и в общем-то правильно. Если по вашим серверам с ПРОМЫШЛЕННО эксплуатируемыми системами шляется кто угодно с правами админа, то это не проблема разработчиков приклада. С такими правами можно и отладчик запустить, и память сдампить, и диск целиком скопировать через драйвер. Шифрование добавит много геморроя и примерно 0 защиты.
sergeyns
Вот точка зрения обычной ТП (техподдержки). У кого как минимум есть доступ: администратор непосредственно той ИС, которая установлена на сервере, железячники, бэкап… в общем много людей у которых доступ к диску вроде как должен быть, но видеть что на нем — не должен
vanxant
От железячников придумано шифрование диска целиком силами ОС. Бэкапы ну не ручками же делаются, а один раз настроенным софтом из-под учётной записи ОС, при этом к самим бэкапам имеют доступ полтора админа под присмотром офицера СБ. Админ локалхоста после установки ОСи запрещается, всё управление-обновление производится силами тех же полутора доверенных админов.
PS. Я действительно не понимаю, как может помочь шифрование внутри прикладного софта. Вариант а) пароль записан тут же рядом на диске, или на флешке, или в usb-ключе, т.е. человек с физическим доступом к железу — расшифрует. Вариант б) пароль записан на бумажке. Тогда при каждой перезагрузке сервера, например, из-за пропадавшего питания завести систему может только специально обученный офицер с бумажкой. И пока он по всем серверам не пробежится — система так и будет лежать. Ну ок. Ещё варианты?
0x9d8e
А существует ли вообще способ шифровать, но не хранить ключи где-либо? Вариант с постоянным вводом пароля не сильно поможет. Разве что на отдельном защищённом устройстве шифровать, но такое вряд ли будет популярно.
А не удалять временные файлы это конечно фейл. Но где их не бывает?
Я к тому, что это не компрометирует сигнал. Просто его, «оказывается», нужно использовать только на доверенной машине. А как ещё?
Konachan700
Шифровать на отдельном устройстве с неизвлекаемым ключом. Только так.
psman
Ключ на usb брелке с закрытым для чтения ключом и шифрованием на стороне девайса. Но не отнимает шанса на кражу брелка.
Mad__Max
В некоторых аппаратных криптокошельков в расширенном режиме интересная и надежная схема реализована:
1. Основная часть ключа хранится (и происходит шифрование, точнее в случае кошелька формирование цифровых подписей) — на отдельном аппаратном девайсе. И генерируется и хранится она на этом устройстве в неизвлекаемом виде
2. Дополнительная часть ключа («соль») выводится из пароля вводимого пользователем для доступа к кошельку. Эта часть нигде не хранится кроме памяти пользователя. Вводится перед каждым использованием и пересылается на устройство.
В результате взлом компьютера и хищение/перехват вводимого пароля ничего не дают, т.к. основной ключ в отдельном устройстве и на компьютер вообще никогда не передается.
Физическая утеря/кража устройства доступа к защищаемым данным злоумышленникам тоже не даст, т.к. у них не будет доступа ко 2й части ключа хранимой в памяти владельца.
Единственный более-менее реальный вектор атаки — это похищение устройства одновременно вместе с его владельцем и применением к последнему условного терморектального криптоанализа.
ValdikSS
В современных компьютерах есть крипточип Trusted Platform Module (TPM), либо выделенным чипом, либо эмулируемый средствами современных процессоров (Intel PTT). Он позволяет выполнять некоторые криптографические операции непосредственно на чипе, не копируя ключ в ОС/RAM.
nafgne
moderator, некорректный заголовок. Язабан.
MaxALebedev
Вы ошиблись сайтом
Alter2
А ведь это затрагивает куда более глубокую проблему: продукт с открытым исходным кодом и тысячами активных пользователей, существующий более 4 лет, при этом сфокусированный на анонимности и безопасности, и никто так и не удосужился провести аудит кода? Все пользовались, считая что кто-то уж точно все независимо проверил. А ведь со множеством opensource продуктов и модулей может быть аналогичная ситуация.
ChymeNik
А проблема ли это вообще? Переписку можно прочитать лишь получив физический или удаленный доступ к ПК. Если нужна защита и на таком уровне — надёжный вариант — TrueCrypt диск с виртуальной машиной. А полагаться на то, что мессенджер будет шифровать или удалять без возможности восстановления локальные данные, — в любом случае не стоило.
andreymal
Heartbleed уже давно продемонстрировал, что так и есть
ValdikSS
Протокол и его реализация проходили аудит кода.
savostin
Аааааа! Паника!!! Ssh тайно хранит приватный ключ прямо на диске в незашифрованном виде!
0x9d8e
Ещё и при первом коннекте не проверяет подлинность сервера
sumanai
Ssh ключи нигде не хранит.
Googolplex
Ну в случае с ssh хотя бы есть выбор, шифровать ключ пассфразой или нет.
Zettabyte
Коллеги, я не пользуюсь десктопными WhatsApp/Signal, но не является ли причиной изложенного в статье поведения то, что они используют end-to-end шифрование, в котором «центром мира» является телефон (который всё время должен быть онлайн)?
А точнее не из-за того ли, что их десктопные «клиенты» — это электрон, который упакован в браузер, который работает в докер-контейнере, который крутится в виртуальной машине?
На самом деле, тамошние сто одёжек не такие (я просто не помню точных подробностей), но в целом слоёный пирог там тот ещё.
OnelaW
А точнее не из-за того ли, что их десктопные «клиенты» — это электрон, который упакован в браузер, который работает в докер-контейнере, который крутится в виртуальной машине?
Вот я понимаю люди извращаются как могут
helgevans
Используйте PGP ключи и хоть mail.ru, хоть бумажной почтой информацию можно отправлять. Ради действительно секурного общения, для шифрования и дешифрования можно использовать отдельный компьютер (неважно с какой ОС), который не нужно подключать к интернету. А все эти криптомессенджеры, торификация трафика и прочее баловство одно.