Пользователь
0,0
рейтинг
2 декабря 2014 в 04:16

Разработка → Безопасен ли Telegram? v2 recovery mode

С момента самого появления Telegram его не критиковал только ленивый. Этим с одинаковым энтузиазмом занимались резиденты Reddit, Hacker News, etc.

В порыве урезонить самых яростных критиков был объявлен конкурс с главным призом в 200 000$ для первого из тех, кому удастся взломать протокол, и прочесть содержимое секретного чата между двумя вымышленными пользователями.
Конкурс, как судя по всему и рассчитывали устроители, привлек к себе внимание, однако вызвал шквал еще большей критики в силу ограниченности потенциальных исследователей в выборе инструментов для анализа: доступно было лишь зашифрованное содержимое переписки, без возможности влиять на ее содержимое или вступать в какое-либо взаимодействие с ее авторами (исключая таким образом возможности для MITM, replay-атак, etc).

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

Спустя год, учтя критику, Telegram объявил о новом контесте с призовым фондом в 300 000$ за взлом протокола и дополнительным в 100 000$ за успешно проведенную атаку, итогом которой станет прием ботом зашифрованного сообщения от атакующего.

На этот раз любой исследователь может выступать не только в пассивной роли наблюдателя, но и имеет возможность для проведения активных атак (MITM, CPA, tampering, etc.).

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

Apple’s 'goto fail' (CVE-2014-1266)
OpenSSL’s 'Heartbleed' (CVE-2014-0160).
Bash's 'ShellShock' (CVE-2014-6271)

Это лишь небольшой список тех, что обрели существенный резонанс в силу критичности и охвата.

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



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





И считываются двумя функциями `read_secret_chat_file`



И `read_secret_chat`:



Что легко подтверждается отладчиком:



Что это означает для конечного пользователя?

Поскольку протокол Telegram не гарантирует forward secrecy (PFS), это означает, что злоумышленник, долгое время находившийся в режиме пассивного прослушивания (eavesdropping), получив контроль над вашим устройством, помимо содержимого всех секретных чатов (открытых на данном устройстве), получит также возможность продолжить от вашего имени любой из них, не являющийся к тому моменту принудительно завершенным.

Насколько надежным выглядит протокол с такой перспективы?

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

Stay tuned.

P.S. Проблема оказалась эндемичной не только для консольного клиента но и для Android-клиента (https://github.com/DrKLO/Telegram)



P.P.S. Разработчики Telegram в курсе проблемы и считают ее приемлимым компромиссом:

The protocol’s principal drawback is that an intruder passively intercepting messages and then somehow appropriating the authorization key (for example, by stealing a device) will be able to decrypt all the intercepted messages post factum. This probably is not too much of a problem (by stealing a device, one could also gain access to all the information cached on the device without decrypting anything); however, the following steps could be taken to overcome this weakness

Умалчивая однако, тот факт, что атакующий будет иметь возможность не только расшифровать все** сообщения post factum, но и перехватить и продолжить сессию таким образом, что собеседник скомпрометированного пользователя не заметит подмены.

P.P.P.S. Недавно введенный в протокол механизм ratcheting'а (re-keying protocol), проблему не решает, а при некоторых обстоятельствах только усугубляет: благодаря тому, что ratchet (re-keying protocol), призванный гарантировать perfect forward secrecy, не гарантирует PFS в строгом смысле (окно для ratchet'а — 100 сообщений или 1 неделя), атакующий может перехватить сессию и принудительно инициировать новый ratchet, «отрезая» таким образом скомпрометированного пользователя от сессии.

* Что, конечно же, неправда.
** До 20-й версии (20 layer) протокола абсолютно все, начиная с 20-й версии протокола, все, начиная с последнего ratchet'а.
Alexey Kudinkin @f0rbidik
карма
–1,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (17)

  • +2
    Что-то я не понял. Дуров орал на всю деревню, что WhatsApp стырил его идею по генерации новых ключей на каждое новое сообщение, а сам такую штуку не заюзал? Или здесь проблема в хранении сообщений на диске? Если второе, то протокол тут не причем
    • 0
      • 0
        Они там генерятся after a period of time, а в вотцапе после каждого сообщения
    • +7
      --WhatsApp стырил его идею по генерации новых ключей на каждое новое сообщение

      Я конечно дико извиняюсь, но эта идея изначально была реализована в Blackberry Messenger задолго до того как.
  • +42
    Но как связаны безопасность Телеграма и его кривая реализация на гитабе? Клиент же под него может написать любой.
    • +4
      Справедливости ради этот клиент написан серверным разработчиком Телеграма
  • +24
    Хм, клиент, приведенный автором в качестве примера, на сайте Телеграма есть. Но вот находится он в разделе «Unofficial apps». Ну и как совершенно справедливо заметили выше, проблемы с хранением данных пользователя в стороннем приложении — это проблемы автора приложения и тех, кто будет этим клиентом пользоваться, протокол тут не при чем.
  • +24
    Извините, но уязвимость из серии «О, боже — всю переписку можно прочитать, стоя за спиной пользователя»
  • +23
    Только я дошел до конца, увидел звездочку и полез искать где она была? :-)
    • 0
      А я еще предварительно завис на пару секунд, в мыслях, «это что, развод был или что?». Надо выспаться…
  • +18
    А отобрать у пользователя телефон в момент переписки, высоко поднять его над головой и бегать, улюлюкая, уже предлагали? Я еще могу получить 200 тысяч по 60 рублей?
  • +1
    В любом случае это маргинальный клиент, оценивать безопасность по нему просто неадекватно.
  • +5
    Статья к реальной безопасности отношения не имеет, зато теперь все точно будут на всех углах кричать, что «тилиграм-гумно».
    • 0
      Уже кричат. Из кричащих пока не нашлось ни единого, который хотя бы удосужился комменты почитать.
  • 0
    Друзья, а Cryptoсat безопасный вид для общения?
    • 0
      Да, относительно. Если беседа идёт один-на-один, то используется протокол OTR, который достаточно старый (2004 год). А при в случае групповых чатов, используется протокол mpOTR, и вот здесь могут быть некоторые проблемы. Также, не следует забывать о возможных ошибках реализации (например, как это уже было, недостаточно рандомном рандоме для генерации ключей) и тому подобным вещам.

      Но даже при некоторых возможных проблемах, те качества, которые предоставляет протокол сами по себе достаточно интересны. В любом случае, никто не запрещает поднимать свои серверы cryptocat и пробрасывать к ним vpn :)
  • 0
    … а самой слабой компонентой системы, как правило, является прокладка между стулом и клавиатурой

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.