Пользователь
0,0
рейтинг
23 декабря 2013 в 14:31

Разработка → Остались ли ещё закладки в Telegram? из песочницы

Как уже упоминалось в недавнем посте "Безопасен ли Telegram? Или как я искал закладку в MTProto" — Telegram — супер защищённый мессенджер для смартфонов, на столько безопасный, что за его взлом объявлен конкурс с внушительным призом. В том посте была описана эффективная атака на его протокол (MTProto), краткая суть которой состоит в том, что "сервер Telegram может подобрать такую nonce, при которой ключи пользователей совпадут даже при MITM-атаке и никто не будет знать, что его слушают", где под nonce подразумевалась «случайная» последовательность данных участвующая в установлении ключа казалось бы просто для увеличения энтропии, а реально она давала возможность администраторам серверов Telegram легко и, самое главное, не обнаружимо для пользователей выполнять Man-in-the-middle (MITM) атаку на протокол по обмену ключами. Некоторые даже посчитали участок кода ответственный за уязвимость — закладкой.

К чести Telegram, довольно быстро было признано, что уязвимость присутствует и было анонсировано его исправление в следующей версии мессенджера, а автору обещано вознаграждение — ibeatle пишет: "с настоящего момента в nonce всегда будет приходить ноль, и в следующем слое мы обязательно удалим это поле из схемы и поясним в документации." Тем временем в описании протокола1 мы уже видим, что злосчастное 'xor nonce' исчезло, и код поменялся в лучшую сторону. Pavel Durov сказал: "На всякий случай, поясню для массовых пользователей: утечки данных не было, уязвимость закрыта, опасности нет." Всё хорошо, что хорошо кончается.

Но исчезла ли уязвимость и стал ли Telegram защищён от не обнаружимого MITM? Есть мнение, что не стал и администраторы Telegram серверов всё ещё могут прослушать пользователей так, что проверка ключей покажет, что они совпадают.

Для этого достаточно применить атаку вырожденного ключа на протокол Diffie-Hellman (DH). Предыдущая атака была на часть алгоритма протокола установления ключа, которая происходит сразу после DH, но ведь есть же ещё и сам DH. В документации есть попытка защититься от от некоторых атак на DH — предписано проверять публичные параметры p и g: "client is expected to check whether p is a safe 2048-bit prime, and that g generates a cyclic subgroup of order (p-1)/2." Но ничего не говорится о проверке открытых ключей g_a и g_b.

Для проведения атаки серверу достаточно заменить присылаемые от клиентов А и В оба параметра g_a и g_b на единицу (1). В этом случае у обоих пользователей в результате расчета приватного ключа так-же получатся единицы. Сервер (и любой другой наблюдающий атакованную сессию) зная это свойство DH протокола сможет спокойно расшифровывать и читать их сообщения. Хотя внешне всё будет выглядеть «зашифрованным». Более того, key_fingerprint этого вырожденного ключа будет визуально не отличим от нормального сложного ключа, так как fingerprint, это не сам ключ, а sha1 криптохэш от ключа.

Для исправления этой уязвимости мессенджеру достаточно было бы проверить, что присылаемые g_a и g_b не равны единице.

_________
1 Копия описания протокола от 22 декабря: archive.is/Z8Keu
@aabc
карма
11,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +16
    Благодарим за ценное замечание, мы тоже заметили важность этой проверки в конце прошлой недели.
    Нужно отметить, что проблема на клиентской стороне и не затрагивает безопасность самого протокола.
    Вчера ночью были несколько расширены рекомендации авторам клиентов, реализующих функциональность Secret Chats на базе API Telegram:

    core.telegram.org/api/end-to-end#sending-a-request

    (Кстати, проверять важно еще и на p-1.)

    Разработчиками клиентов были исправлены исходники официальной версии для iPhone (http://telegram.org/resources/telegram_iphone.src.zip) и Android.
    В течение пары дней в Google Market появится обновленная версия официального приложения, где помимо новой функциональности (пересылка документов) будут усилена безопасность секретных чатов. Обновление клиента под iPhone (тоже документы + усиление секретных чатов) ушло в ревью, и скорее всего будет доступен после окончания праздников в США.

    Тем не менее, мы продолжаем ревью клиентского кода. Будем благодарны, если найдете что-то еще, что пока не удалось заметить.
    • +8
      А, ну я постил этот топик вчера в 19:47, после чего он висел на пре-модерации. Так что здорово совпало, что вы буквально ночью всё дополнили.
      • +32
        Не прокатило :)
        • +37
          Boomburum слил инфу и уже поехал в салон за новым Х6
          • +13
            Надеялся что хоть в этот раз будет без теории заговора )
            p.s. Жаль, что Х6 стоит больше 100к, а моделька в масштабе 1:18 уже есть.
            p.p.s: чтобы подобных «не успел, не прокатило» больше не было, заводите полноценные Хабра-аккаунты заранее ;)
            • +6
              >> p.s. Жаль, что Х6 стоит больше 100к
              Т.е. всё-же такой вариант рассматривал, да? =)
              • 0
                Только высокая цена и спасла :)
      • +32
        Раз Ваш пост был отправлен в 19:47, то это, действительно, многое меняет.

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

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

        Для получения Вашей части награды, пожалуйста, напишите нам на security@telegram.org

        А мы тем временем приступим к составлению четкой системы поощрения за найденные баги, чтобы неопределенности больше не существовало.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        А его нет? Что, серьёзно?
      • 0
        Голосовой трафик предъявляет совершенно другие требования к инфраструктуре, нежели текстовые чаты. Если задержка доставки сообщений подскочит до 2 секунд и будет прыгать ± 1 секунда, почти никто этого не заметит, для голосового же трафика это аналогично неработоспособности сервиса.
        И зачем вам для этого телеграм, если уже 7 лет как есть zrtp?
        • +1
          С такой логикой, зачем нам тогда телеграм, если есть XMPP OTR
        • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Не совсем по теме, но меня крайне напрягло, что ссылка на якобы исходники программы, которые я никогда не трогал, у меня была фиолетовая. Лишний повод еще внимательнее присматриваться к используемым ссылкам где бы то ни было, доверие — враг безопасности.
      • +1
        Да, к сожалению, при постинге, видимо, нажал куда-то не туда, поэтому ссылка осталась только в тексте, а ведёт почему-то на сам топик. Вот кликабельная, чтобы было удобнее скачивать:

        telegram.org/resources/telegram_iphone.src.zip
    • 0
      скорее всего я ошибаюсь, но выглядит так, словно после прошлых 100 000, вам сказали «Больше никаких 100 000».
      • +7
        А был ли x7mz (человек с рэндомным ником)? На момент поста изменений в коде ещё не было. Они появились час назад, в такой спешке, что оказались с не компилябельной ошибкой (исправленной через пол часа).
        • +1
          думаете он подставной ради 100 000?
          • +13
            Я знаю только про себя и как прикольно всё вышло.
  • –2
    А поскольку пользователи могут безопасно проверить равенство ключей только находясь географически рядом друг с другом, можно достаточно легко осуществлять MITM атаки при условии, что пользователи находятся не рядом (например, определяя их положение по базовым станциям, к которым они на данный момент привязаны). Вряд ли кто-то будет отправлять друг другу скриншот картинки по ещё более защищённому соединению (да и вообще какой процент пользователей будет сверять картинки даже находясь рядом с собеседником?).
    • 0
      Представьте, что вы находитесь на Марсе, и доступ к интернету на Земле целиком осуществляется через один спутник. Если вы раньше никогда не были на Земле (никакой заранее запасённой информации), и у вас нет никакого канала доступа туда (наблюдением в телескоп пренебрегаем), то вы никогда не узнаете, настоящий ли интернет вам подсовывает спутник. Так же и здесь. Поэтому ключи нужно сравнивать обязательно. Удобнее всего создавать секретный чат, когда вы находитесь рядом с собеседником.
      • 0
        А теперь учтите тот факт, что собеседники может быть никогда рядом не будут, а также тот факт, что ключи генерируются временные. Представляете, сколько проблем принесёт сравнение ключей каждый раз?
        • 0
          Тогда можно использовать любые другие доверенные независимые каналы информации. В любом случае, без наличия альтернативного доверенного сервера или канала передачи эта задача не решается. Тем не менее, мы планируем в будущем улучшить механизм секретных чатов, чтобы упростить эти проверки и уменьшить их количество.
          • +3
            Если клиенты являются opensource, то было бы здорово иметь механизм deterministic (reproducible) builds (как это сейчас пытается сделать Tor и TrueCrypt), чтобы быть уверенным в том, что в маркете и аппсторе именно та версия, код которой приведен на github'е. Наверняка можно придумать вариант чекера, который отсеивает всякие подписи и проверяет именно бинарник (конечно, потребуется воссоздание среды компиляции и т.д. в виртуалке). Версия под iOS шифруется под конкретного клиента, но желающие могли бы снимать образ из памяти и сверять с эталоном.
        • +3
          gpg keyserver от MIT для меня выглядит более доверенным, чем шарашка Дурова.
  • 0
    Вопрос немного не по теме, но, думаю, в этой теме люди знают ответ. У телеграм принципиальная архитектура в перспективе как у Jabber-а — распределённые серверы? Т.е. есть ли возможность ссылаться на пользователя в формате, аналогичном user@server.com? Или всё заточено на конкретный сервер? Про то, что серверное ПО недоступно, я знаю, но это вопрос решаемый,
    • 0
      Пока там аналог WhatsApp с привязкой к номеру телефона, который и есть адрес пользователя.
  • +8
    Действительно, выглядит все так, будто Телеграмовский алгоритм никто до этого вообще не проверял, включая самих разрабов, не имеющих в крипто-области нужных знаний. Будто сочиняли его как-то так — а давай пароль в MD5 завернем, а сверху еще SHA накатим, никто ж не расшифрует! И при этом пароль сохранили в открытом виде где-то рядом «на всякий пожарный».

    А когда предложили приз, и каждый второй начал указывать на дыры в протоколе, началось судорожное исправление (при этом с попутными косяками), что фактически означает изменение условий самого конкурса.
    • 0
      Знаете, читая протокол, его автор не выглядит глупым. Например, используются криптоголоволомки для защиты от DoS (при этом их смысл не поясняется) — решение стандартное, но его нужно знать. При этом, почему в DH был такая серьезная уязвимость — не понятно, если считать её ошибкой. Так же мне не понятно желание авторов постоянно делать xor со «случайными» данными с сервера.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      Только инвайт? А как же 100 000$?((
      • 0
        Мне и aabc тоже обещали утешительный приз :)
        Пруф: habrahabr.ru/post/206900/#comment_7130934
      • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    супер защищённый мессенджер для смартфонов, на столько безопасный, что за его взлом объявлен конкурс с внушительным призом.


    Я даже сделаю вид, что в упор не вижу ошибку, но — недавно писали про ловушки конкурсов, и многие не верили, что между внушительным призом и защищенностью быстро поставят знак равенства. Зря, видимо.
  • 0
    Не пойму, человеку за нахождение уязвимости заплатили обещанные 300 000 долларов (или сколько вы обещали) или нет?
    • 0
      Эта уязвимость, формально, не является частью протокола. В их официальном описании протокола есть ссылка на Диффи-Хеллмана из википедии, где подробно не написано, как валидировать данные. У них в клиенте тоже была допущена ошибка и данные валидировались не все. Но это не значит, что слова «используйте Диффи-Хеллмана» — это потенциальная закладка. А вот та версия Диффи-Хеллмана, которая была до поста x7mz действительно содержит закладку именно на уровне потокола.
      • –1
        Тоже не понял. Разве это не уязвимость? По описанию уязвимость протокола, клиентов от сервера. И даже если эта часть не описана в протоколе явно, это уязвимость базового алгоритма. И эта уязвимость тоже не подходит под условия конкурса. Тем не менее, вроде бы говорили, что наградят? Тоже интересно было бы узнать общий бюджет намайненных уязвимостей в Telegram (и у кого из зарплаты будут их вычитать).
        • –1
          Это уязвимость конкретной реализации (официальной). Отличие в том, что если некий Чак Нориис от программирования напишет (без единого бага) клиент по протоколу до поста x7mz — он всё равно будет уязвим. А после — возможно, уже нет. Они уже написали, что по таким мелким багам формализуют критерии оценки находок: habrahabr.ru/post/206900/#comment_7130934
          • 0
            Если я (не Чак Норрис) напишу клиента по описанию протокола, он будет уязвим. Так что уязвимость протокола пока не внесено исправление в документацию. Ждем когда они решат во сколько оценивать.
            • 0
              Они уже оценили, но официально пусть сами озвучивают, если хотят.
            • 0
              В протоколе не написано и про то, как правильно рандом инициализировать. Тем не менее, в официальном клиенте это сделано.

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