Comments 174
После я установил клиент, ввел номер телефона и больше всего меня удивило то, что мне не нужно вводить паролей, вместо этого на телефон приходит смс с одноразовым пятизначным ключом подтверждения номера. Я взял второй телефон, установил клиент, ввел тот же номер что и в первый раз, так же пришло пятизначное число, которое я ввел на телефоне №2 и успешно авторизовался. Т.е. вот и первая уязвимость. В Telegram накрутили множество алгоритмов, исключили возможность перехвата и подмены трафика, а про банальный пароль забыли. Злоумышленнику не нужно слушать трафик мессенджера, а всего лишь нужно перехватить смс и доступ получен без проблем.
Я не очень понял, что даст перехват смс. Ну перехватили вы смс ииии… что?
И получаете сообщения, адресованные другому пользователю
Возможно я не правильно объяснил. Действия злоумышленника могут быть следующими… Он вводит номер жертвы в своем клиенте, перехватывает смс с одноразовым кодом (необходимый минимум — дождаться пока жертва сидит в туалете без телефона :) ), вводит пароль в своем клиенте и получает полный доступ к аккаунту жертвы.
На самом деле проблем с привязкой аккаунта к номеру телефона (да еще и без пароля) очень много. Например, на хабре была статья о том как злоумышленник умудрился украсть номер телефона. Или может случиться так что я куплю свежую симку, а на этот номер уже пореган аккаунт.
На самом деле проблем с привязкой аккаунта к номеру телефона (да еще и без пароля) очень много. Например, на хабре была статья о том как злоумышленник умудрился украсть номер телефона. Или может случиться так что я куплю свежую симку, а на этот номер уже пореган аккаунт.
Насколько я помню суть уязвимости A5/1, при большом желании можно перехватить и дешифровать трафик вполне разумными усилиями, даже если атакуемый не выпускает телефон из рук и спит с ним в обнимку.
Понимаю неудобство двухфакторной авторизации для конечных пользователей, но без нее никуда.
Понимаю неудобство двухфакторной авторизации для конечных пользователей, но без нее никуда.
Двукратная авторизация однозначно того стоит. Особенно мне нравится вариант с приложением на телефоне которое генерит временный пароль в зависимости от текущего времени и ранее введенного длинющего ключа.
Но в данном случае проблема в том что первой авторизации (ввод пароля из головы) в Телеграме нет, сразу же вторая.
Но в данном случае проблема в том что первой авторизации (ввод пароля из головы) в Телеграме нет, сразу же вторая.
В варианте с временным паролем есть проблема сторонних клиентов. Вполне реально создать алгоритм, который генерирует предсказуемые временные пароли.
Уж лучше по старинке — пароль + смс.
Уж лучше по старинке — пароль + смс.
А разве там не TOTP? RFC6238, недавно топик тут был. И все программы его используют.
А. Ну, в случае с TOTP надо, чтобы secret задавался не из приложения, а, скажем, на сайте Телеграма (то есть вообще не давать такой возможности в API). Иначе кто-нибудь может написать клиент, который, допустим, всем ставит secret=123.
Впрочем, к обычной регистрации с вводом пароля это точно так же относится. Поэтому, видимо, разработчики и ограничились SMS: заставлять регистрироваться на сайте — плохо с точки зрения usability, а клиенты по определению неподконтрольны.
Впрочем, к обычной регистрации с вводом пароля это точно так же относится. Поэтому, видимо, разработчики и ограничились SMS: заставлять регистрироваться на сайте — плохо с точки зрения usability, а клиенты по определению неподконтрольны.
Есть возможность послать HLR-запрос на номер абонента. По этому запросу можно получить уникальный код сим-карты и в случае смены сим-карты уже не давать возможность авторизоваться по номеру. Абсолютно точно знаю, что так поступают некоторые банки, думаю, это известная практика. Непонятно, правда, как всё-таки авторизовать пользователя, если он сам сменит симку…
xor nonceЭто прекрасно, просто прекрасно. Закладка на будущее совершенно очевидная. Требуйте $200k ;)
nonce – “случайная” полученная от сервера Telegram последовательность для вычисления ключа.
Если бы существовала открытая реализация сервера… Демонстрация атаки выглядит тривиальной.
Не получит, требовалось получить данные из сообщения.
Если x7mz получит исходные коды сервера, запустит модифицированную версию, и трафик Дурова пойдет через его сервер — данные из сообщения ему будет получить несложно.
Это к вопросу о корректности условий конкурса. Все же, нужна градация по «серьезности» уязвимости.
Это к вопросу о корректности условий конкурса. Все же, нужна градация по «серьезности» уязвимости.
Если x7mz получит исходные коды сервера...
Жил бы в Сочи
Заменим одно слово:
стало реалистичнее?
Если АНБ получит исходные коды серверастало реалистичнее?
Когда ФСБ получила и далее по тексту ?)
+1
Код винды тоже всегда считался «закрытым». Но потом исходники WinXP совершенно легально получила ФСБ.
И это не говоря о том, что исходный код сервера где-то существует, и был кем-то придуман, и этот «кто-то» вполне возможно в будущем будет куплен за большие деньги, рассказав все секреты. Вероятность выше нуля, и, скорее всего, выше вероятности взлома пароля брутфорсом.
Код винды тоже всегда считался «закрытым». Но потом исходники WinXP совершенно легально получила ФСБ.
И это не говоря о том, что исходный код сервера где-то существует, и был кем-то придуман, и этот «кто-то» вполне возможно в будущем будет куплен за большие деньги, рассказав все секреты. Вероятность выше нуля, и, скорее всего, выше вероятности взлома пароля брутфорсом.
Большое спасибо, автор поста полностью прав. Со своей стороны хотим пояснить, что сделано это было из лучших побуждений: исправление плохого рандома на клиентах.
С настоящего момента в nonce всегда будет приходить ноль, и в следующем слое мы обязательно удалим это поле из схемы и поясним в документации.
Автор топика безусловно заслужил награды, просьба обратиться хабраюзера x7mz на email support@telegram.org для уточнения деталей.
С настоящего момента в nonce всегда будет приходить ноль, и в следующем слое мы обязательно удалим это поле из схемы и поясним в документации.
Автор топика безусловно заслужил награды, просьба обратиться хабраюзера x7mz на email support@telegram.org для уточнения деталей.
Плохой рандом на клиенте связан с источником энтропии я так понимаю? Почему тогда не попросить пользователя подуть в микрофон или каким-либо аналогичным способом использовать его в качестве источника случайности?
Понял проблему в своих рассуждениях — любой может создать клиент для этого приложения, соответственно сторонний злоумышленник может специально ослабить рандом и использовать эту уязвимость для дешифровки трафика.
эммм… если nonce служит для исправления рандома на клиентах, зачем тогда поле «random» в DhConfig, который можно получить указав random_length > 0, как это описано в core.telegram.org/api/end-to-end?
Там отдельный параграф про «random», который в самом начале приходит с p и g, и примешивается к рандому клиента. И отдельный параграф про nounce, который приходит после того, как сервер может вычислить секретный ключ для Алисы и знает секретный ключ у Боба. Почему бы не передавать nounce с самого начала? Зачем он вообще нужен если random уже примешали?
Там отдельный параграф про «random», который в самом начале приходит с p и g, и примешивается к рандому клиента. И отдельный параграф про nounce, который приходит после того, как сервер может вычислить секретный ключ для Алисы и знает секретный ключ у Боба. Почему бы не передавать nounce с самого начала? Зачем он вообще нужен если random уже примешали?
Не переживайте Вы так. Бекдор встроят в другом месте, незаметнее, всё будет нормально.
Протокол открытый, клиент в принципе может написать кто угодно. Хотелось форсировать подмешивание серверного рандома даже в том случае, если клиент был написан не слишком грамотно в плане генерации псевдослучайных чисел и подмешивания серверных данных. К сожалению, способ был выбран совершенно негодный. Однако несколько человек — включая меня — изучали тот протокол, что получился, и не заметили его фундаментального недостатка. Так что вина теперь не только на том, кто предложил эту схему, но и в том числе на мне. А «x7mz» молодец.
На мой взгляд, nonce, да и random (который от сервера) – абсолютно бесполезны в плане повышения безопасности. Если злоумышленник перехватил открытые ключи, значит ему известны и random, и nonce, и вычислить итоговый ключ не составит труда сколько левых (и всем известных) параметров туда не подмешивай.
Пример: ленивый (очень ленивый) разработчик клиента использовал вместо хорошего рандома unixtime, но подмешал в него random (key = unixtime xor random). Вопрос: сильно ли тут поможет random при условии что он известен злоумышленнику?
Пример: ленивый (очень ленивый) разработчик клиента использовал вместо хорошего рандома unixtime, но подмешал в него random (key = unixtime xor random). Вопрос: сильно ли тут поможет random при условии что он известен злоумышленнику?
Не составит труда? Пруфы или не было (unixtime не в счет).
Наверно я не правильно выразился. Имелось в виду то что если на клиенте используется уязвимый алгоритм генерации случайных чисел, то всякие random этот алгоритм не спасут. time это просто пример очень плохого рандома, для наглядности. Вы не разу не видели в чьем-нибудь коде такое: super_secret_key = md5(time())? Если же алгоритм генерации случайных чисел хорош то random никак не повлияет на надежность ключа.
Ребята, раз уж вы предложили награду, то не надо ничего менять в коде. Или выплатите приз парню.
Стоп, стоп.
Все поверили в добрые побуждения при создании закладки?
Или в то, что всегда будет ноль?
Или что телеграмм действительно удалит поле и обновит документацию?
Или порадовались что <irony//>представитель телеграмма<//irony> во всем признался? Я правда не понимаю, палками не бейте.
Все поверили в добрые побуждения при создании закладки?
Или в то, что всегда будет ноль?
Или что телеграмм действительно удалит поле и обновит документацию?
Или порадовались что <irony//>представитель телеграмма<//irony> во всем признался? Я правда не понимаю, палками не бейте.
В доке уже есть random, который можно примешать к клиентскому генератору. Вместо убедительного «it's highly recommended ...» или даже «client SHOULD» там мягкое предложение: «If the client has an inadequate random number generator, it makes sense ...».
И тут оказывается, что второе случайное число выполняет ту же функцию, но теперь чтоб уж точно. Вопросов куча: зачем первый random если второй nounce и так обязателен? Почему вводится обязательный nounce, когда первый предлагается очень мягко? Почему непонятное имя nounce? Почему в доке не раскрыт смысл nounce, как random? И почему Алисе он выдается в самом конце, а не когда она только начала инициализировать соединение, как random? Всё выглядит ну очень нелогично, пока в теории не появляется Большой Брат и всё быстро становится на свои места. Что ещё нужно для параноика, не так ли?
Но вероятность, что так и было, есть. Сам был на другой стороне, когда простая ошибка со стороны выглядела как заговор. Видел, как работа нескольких людей в сумме давала непоследовательный и нелогичный результат (прям как здесь). Верится очень слабо, но исключить добрые намерения не могу. :) (хотя бы у тех, кто проверял)
И тут оказывается, что второе случайное число выполняет ту же функцию, но теперь чтоб уж точно. Вопросов куча: зачем первый random если второй nounce и так обязателен? Почему вводится обязательный nounce, когда первый предлагается очень мягко? Почему непонятное имя nounce? Почему в доке не раскрыт смысл nounce, как random? И почему Алисе он выдается в самом конце, а не когда она только начала инициализировать соединение, как random? Всё выглядит ну очень нелогично, пока в теории не появляется Большой Брат и всё быстро становится на свои места. Что ещё нужно для параноика, не так ли?
Но вероятность, что так и было, есть. Сам был на другой стороне, когда простая ошибка со стороны выглядела как заговор. Видел, как работа нескольких людей в сумме давала непоследовательный и нелогичный результат (прям как здесь). Верится очень слабо, но исключить добрые намерения не могу. :) (хотя бы у тех, кто проверял)
Ну что вы до них докапались?
У них такой стиль разработки. Имеет свои плюсы и свои минусы. Про плюсы не буду, ибо холивар это. Некошерный код на кошерном хабре. Про минусы — забыли как у контакта можно было ОТРИЦАТЕЛЬНЫЕ суммы голосов переводить? А уязвимости первых АПИ? Там же всё было совершенно несуразно с точки зрения тщательного планирования, моделирования и прочих классических паттернов проектирования. Однако ущербы от ошибок значительно меньше были чем экономия на упрощении методологии проектирования… Черт, таки сказал про преимущества. В общем ладно, благодаря или вопреки неклассической модели разработки у ребят один из лучших продуктов в области социальных сетей.
Ну а вообще я о том, что такая несуразица очень даже влазит в их методы работы.
Помню пару месяцев назад коллега решил дописать пару модулей в моей сфере ответственности и долго спамил меня кусками кода где я проверял те вещи которые уже были проверены до того. Однако я в упор не согласен с тем, что это говнокод. Когда код писался он имел смысл, когда потом после текущих рефакторингов когда он оказался внутри других структур он актуальность потерял. Однако я заметив это даже пальцем не пошевелил — дедлайн важнее, мало ли что я могу не додумать если удалю лишнюю проверку. А гонять тесты ради такой мелочи? Да ну их. Вместо этого я у «ПМ» выбил чтобы он у заказчика выделил третий месяц после запуска чисто на код-ревью и рефакторинги. К чему я это? К тому что у разработчиков здесь примерно такая же логика прослеживается — лишний рандом лишним не будет. По стилю на них похоже, сам я так делаю иногда, так что вполне себе верю. Ну а уязвимость да, уязвимость допустили. Но допустили они ее в самом слабом месте — хуже всего внутренний аудит замечает уязвимости типа «а что если я сам буду злоумышленником».
У них такой стиль разработки. Имеет свои плюсы и свои минусы. Про плюсы не буду, ибо холивар это. Некошерный код на кошерном хабре. Про минусы — забыли как у контакта можно было ОТРИЦАТЕЛЬНЫЕ суммы голосов переводить? А уязвимости первых АПИ? Там же всё было совершенно несуразно с точки зрения тщательного планирования, моделирования и прочих классических паттернов проектирования. Однако ущербы от ошибок значительно меньше были чем экономия на упрощении методологии проектирования… Черт, таки сказал про преимущества. В общем ладно, благодаря или вопреки неклассической модели разработки у ребят один из лучших продуктов в области социальных сетей.
Ну а вообще я о том, что такая несуразица очень даже влазит в их методы работы.
Помню пару месяцев назад коллега решил дописать пару модулей в моей сфере ответственности и долго спамил меня кусками кода где я проверял те вещи которые уже были проверены до того. Однако я в упор не согласен с тем, что это говнокод. Когда код писался он имел смысл, когда потом после текущих рефакторингов когда он оказался внутри других структур он актуальность потерял. Однако я заметив это даже пальцем не пошевелил — дедлайн важнее, мало ли что я могу не додумать если удалю лишнюю проверку. А гонять тесты ради такой мелочи? Да ну их. Вместо этого я у «ПМ» выбил чтобы он у заказчика выделил третий месяц после запуска чисто на код-ревью и рефакторинги. К чему я это? К тому что у разработчиков здесь примерно такая же логика прослеживается — лишний рандом лишним не будет. По стилю на них похоже, сам я так делаю иногда, так что вполне себе верю. Ну а уязвимость да, уязвимость допустили. Но допустили они ее в самом слабом месте — хуже всего внутренний аудит замечает уязвимости типа «а что если я сам буду злоумышленником».
Обоснование достаточно убедительное, его сложно придумать сходу.
Что касается нуля, удаления поля и обновления документации — скоро все увидим.
Что касается нуля, удаления поля и обновления документации — скоро все увидим.
Товарищ прав — похоже, сервер в принципе может с помощью манипуляции с nonce выполнить MiTM на DH между клиентами. Не знаю, кто именно внедрил этот nonce в такой форме, хотя и знаю, какое предъявлялось обоснование — он был нужен для того, чтобы защититься от слабого рандома на клиентах, которых в принципе может писать кто угодно. Очевидно, нужно сделать этот nonce нулём и написать, что клиенты впредь не должны принимать секретные чаты с ненулевым nonce.
Удивительно, что человек, называющий себя «чайником» в криптографии, нашёл действительно серьёзный недостаток протокола, в отличие от многих якобы «профессионалов», постоянно придирающихся не по существу.
Не знаю как насчёт 200k$ — расшифровать трафик это не поможет, а сервер не знает ключа от секретного чата, поскольку на нём нет такой закладки. Но мне очень не нравится, что в будущем такая закладка могла бы быть в принципе кем-нибудь добавлена.
Тем не менее, считаю, за это ценное наблюдение Вам положен ценный приз. Пусть и не такой большой.
Если Вы или кто-либо ещё найдёт какие-либо ещё потенциальные дыры в протоколе — сообщайте, будем награждать.
Удивительно, что человек, называющий себя «чайником» в криптографии, нашёл действительно серьёзный недостаток протокола, в отличие от многих якобы «профессионалов», постоянно придирающихся не по существу.
Не знаю как насчёт 200k$ — расшифровать трафик это не поможет, а сервер не знает ключа от секретного чата, поскольку на нём нет такой закладки. Но мне очень не нравится, что в будущем такая закладка могла бы быть в принципе кем-нибудь добавлена.
Тем не менее, считаю, за это ценное наблюдение Вам положен ценный приз. Пусть и не такой большой.
Если Вы или кто-либо ещё найдёт какие-либо ещё потенциальные дыры в протоколе — сообщайте, будем награждать.
Я бы не назвал это «потенциальной» дырой. Получаемое с сервера поле nonce требует доверия к DF, что не выдерживает никакой критики с точки зрения криптостойкости протокола.
Очень показательный пример того, как небольшая модификация устоявшегося криптоалгоритма, сделанная во благих целях, но без проведения публичного серьезного анализа, приводит к серьезным уязвимостям.
Считаю, что пользователь x7mz заслужил хорошей награды.
Со своей стороны могу порекомендовать для улучшения энтропии на клиентах использовать алгоритм Yarrow. Понятно, что клиент может писать кто угодно, я о рекомендации и об официальных клиентах.
Очень показательный пример того, как небольшая модификация устоявшегося криптоалгоритма, сделанная во благих целях, но без проведения публичного серьезного анализа, приводит к серьезным уязвимостям.
Считаю, что пользователь x7mz заслужил хорошей награды.
Со своей стороны могу порекомендовать для улучшения энтропии на клиентах использовать алгоритм Yarrow. Понятно, что клиент может писать кто угодно, я о рекомендации и об официальных клиентах.
Да, именно это мы и собирались сделать — встроить в клиенты вариант Yarrow, и скармливать в него все источники случайности, и клиентские, и полученные с сервера, не доверяя исключительно одному источнику, даже якобы надёжному вроде /dev/random. Вспоминается недавняя история про /dev/random во FreeBSD, где оказалось, что интеловская инструкция для генерации псевдослучайных чисел может содержать закладку, и они отказались от её использования.
UFO just landed and posted this here
Формально говоря, это мы утверждаем, что закладки не было и нет — но мы не можем доказать это стороннему наблюдателю в принципе. Даже открытый код сервера был бы бесполезен, поскольку никак не проверить, что на серверах запущен именно он.
Секретные чаты должны быть основаны на том, что сервер даже в принципе не может их расшифровать, и это должно обеспечиваться открытым протоколом и в меньшей степени — открытым исходным кодом клиентов. Все желающие должны обладать всей необходимой информацией для того, чтобы самостоятельно убедиться, что сервер даже в принципе не может расшифровать переписку из секретных чатов — или, как это произошло в данном случае, продемонстрировать возможную атаку со стороны владельца сервера.
Поэтому x7mz поступил абсолютно правильно, как и надо поступать при открытом обсуждении криптографических алгоритмов — справедливо указал на существующий недостаток, что привело к его оперативному устранению. Общество от этого только выигрывает.
Секретные чаты должны быть основаны на том, что сервер даже в принципе не может их расшифровать, и это должно обеспечиваться открытым протоколом и в меньшей степени — открытым исходным кодом клиентов. Все желающие должны обладать всей необходимой информацией для того, чтобы самостоятельно убедиться, что сервер даже в принципе не может расшифровать переписку из секретных чатов — или, как это произошло в данном случае, продемонстрировать возможную атаку со стороны владельца сервера.
Поэтому x7mz поступил абсолютно правильно, как и надо поступать при открытом обсуждении криптографических алгоритмов — справедливо указал на существующий недостаток, что привело к его оперативному устранению. Общество от этого только выигрывает.
UFO just landed and posted this here
А что вы можете сказать о другой уязвимости, которую упомянул автор — авторизации по одной только sms? Перехват sms возможен множеством способов, самый банальный — сотрудник оператора видит ключ и номер телефона, уже может авторизоваться и прочитать переписку. Без пароля, известного одному только пользователю, схема становится не надёжной.
А уж про СОРМ я молчу.
Всё равно под колпаком.
Всё равно под колпаком.
Что касается секретных чатов в телеграме, то для каждой новой сессии генерируется свой ключ, поэтому сотрудник оператора не сможет посмотреть ни историю переписки, ни текущую переписку с другого устройства, если я правильно понимаю.
Насчет доступа к несекретным чатам через клонирование симки — мы рассматривали эту возможность с самого начала, и собираемся добавить защиту через пароль. Внедрение задерживается из-за того, что пока не найдены хорошие ответы на следующие вопросы:
Что делать, если пользователь забыл пароль? Если давать создавать новый аккаунт, то как это должно быть отражено у старых и новых контактов?
Нужно решение, которое совместит безопасность и удобство использования.
Кстати, сейчас при перехвате СМС и попытке входа пользователь сразу же получает уведомление с информацией о новом устройстве и его IP-адресе. Есть также возможность сбросить все сессии кроме текущей, тем самым отменить новую авторизацию.
Что делать, если пользователь забыл пароль? Если давать создавать новый аккаунт, то как это должно быть отражено у старых и новых контактов?
Нужно решение, которое совместит безопасность и удобство использования.
Кстати, сейчас при перехвате СМС и попытке входа пользователь сразу же получает уведомление с информацией о новом устройстве и его IP-адресе. Есть также возможность сбросить все сессии кроме текущей, тем самым отменить новую авторизацию.
А вот если она разная то сервер Telegram может подобрать такую nonce, при которой ключи пользователей совпадут даже при MITM-атаке и никто не будет знать, что его слушают. И даже если nonce совпадает для 2х собеседников сегодня, нет никаких гарантий что nonce будет совпадать завтра, когда в офис Digital Fortress придет АНБ / ФСБ / другая не хорошая организация.
Может подобрать? Если nonce для клиентов — разный, то сервера Telegram и есть MITM, знающий secret_key, иначе ключи на клиентах не совпадут.
P.S. Николай W_K, сорвите покрова: разный был nonce для клиентов или же нет?
Если одинаковый, то какой от него был толк? А если же разный, то, как так вышло, что разработчики «не заметили», что сервер в процессе генерации узнает secret_key и компрометирует DH?
Просьба к x7mz — так как ваша статья публичная, всем будет очень интересно узнать, какую награду вам пожалуют разработчики. Соотношение величины уязвимости и величины награды может как заинтересовать, так и отпугнуть других исследователей.
100 000 $ vk.com/wall-52630202_7858
100к тому, кто первым сломает учетку x7mz и свяжется с ребятами из Telegram.
Очень странный аккант x7mz, зарегистрирован в мае, активности, кроме этого поста никакой (ну хоть бы один комментарий), пост из песочницы. А не сотрудник ли это телеграмма?
А что странного? Человек зарегистрировался в мае, был в рид-онли, подвернулся случай — написал пост в песочницу, получил инвайт.
Немного смущает единственный пост так нужный для пиара телеграмма, дабы заинтересовать настоящих специалистов его ломать.
Еще вызывающая приписка
P.P.S. Экспертом в пиаре не являюсь, поправьте, если сомневаюсь неправомерно
Еще вызывающая приписка
P.S. Экспертом в криптографии не являюсь, поправьте если я ошибся.
P.P.S. Экспертом в пиаре не являюсь, поправьте, если сомневаюсь неправомерно
Да нет, не смущает. Я вообще не изучал протокол, но в ворчливых статьях с глубиной проработки на уровне Ализара звучало что есть некий условно случайный параметр который передается сервером. Для неспециалиста вроде меня ни на что кроме мыслей о MiM это не наводит. Далее — сложность расшифровки трафика без вмешательства (как в конкурсе) довольно очевидна, да и условия конкурса только ленивый не критикует. Так что идея довольно тривиальна, нужно было только поверить что уязвимость есть и не пожалеть своего времени чтобы сформулировать реализацию. (Я например поленился, поскольку это не попадало в условия конкурса). Конечно это никак не опровергает идеи с тем, что человек подсадной, но даже если вы параноик это не означает что за вами не следят.
Интересно в этом контексте с вопросом смс и паролей. С одной стороны это дополнительное исследование, хоть и довольно простое. С другой стороны если бы это был засланный казачек, то логично было бы привести пару других замечаний которые администрация не признает — для правдоподобности.
Так что ИМХО человек свою денежку получил вполне справедливо, без подстав. Тут кстати интересно в каком виде будет выплата, и как будет с налогами :)
Интересно в этом контексте с вопросом смс и паролей. С одной стороны это дополнительное исследование, хоть и довольно простое. С другой стороны если бы это был засланный казачек, то логично было бы привести пару других замечаний которые администрация не признает — для правдоподобности.
Так что ИМХО человек свою денежку получил вполне справедливо, без подстав. Тут кстати интересно в каком виде будет выплата, и как будет с налогами :)
В том то и дело что надпись в профиле вводит в заблуждение:
По-хорошему, дата регистрации и дата приглашения должны были бы быть разделены. Но это уже вопрос к создателям Хабра, а не к x7mz.
Зарегистрирован: 21 мая 2013 в 12:48 по приглашению НЛО
По-хорошему, дата регистрации и дата приглашения должны были бы быть разделены. Но это уже вопрос к создателям Хабра, а не к x7mz.
UFO just landed and posted this here
Можно считать доказанным тот факт, что разработчики Telegram некомпетентны не в самой криптографии (ошибиться может каждый), но некомпетентны как организаторы разработки защищенного протокола.
Разрабытывали в изоляции от криптографического сообщества и должным образом не проверяли алгоритм.
На справедливую критику не отреагировали должным образом. Что я имею в виду: когда опубликовали алгоритм, им было замечено, что условия конкурса негодны, что алгоритм может быть ненадежен. Но они не приостановили рекламную компанию и заявления о надежности, не заявили что будет выполняется квалифицированная проверка и каково текущее состояние. Все как было на их сайте, рекламные заявления, так и осталось.
То есть заявления размещенные на их сайте по факту получаются всего-лишь рекламой. Доверия нет. Я не могу доверять теперь ни алгоритму, ни организаторам его разработки.
Вот этот пример с XOR:
— Вот смотрите а вот тут у вас вот ошибка…
— А да беспраблем, пять сек щас уберем, делов-та…
Это вообще что это было? Так вот легко, добавили-убрали на живую? Это сверхзащищенный алгоритм что ле? Завтра что-нибудь другое добавят или удалят, все проверки-сертификации ведь снова провести нужно, понимание этого у организаторов существует или отсутствует как класс?
Разрабытывали в изоляции от криптографического сообщества и должным образом не проверяли алгоритм.
На справедливую критику не отреагировали должным образом. Что я имею в виду: когда опубликовали алгоритм, им было замечено, что условия конкурса негодны, что алгоритм может быть ненадежен. Но они не приостановили рекламную компанию и заявления о надежности, не заявили что будет выполняется квалифицированная проверка и каково текущее состояние. Все как было на их сайте, рекламные заявления, так и осталось.
То есть заявления размещенные на их сайте по факту получаются всего-лишь рекламой. Доверия нет. Я не могу доверять теперь ни алгоритму, ни организаторам его разработки.
Вот этот пример с XOR:
— Вот смотрите а вот тут у вас вот ошибка…
— А да беспраблем, пять сек щас уберем, делов-та…
Это вообще что это было? Так вот легко, добавили-убрали на живую? Это сверхзащищенный алгоритм что ле? Завтра что-нибудь другое добавят или удалят, все проверки-сертификации ведь снова провести нужно, понимание этого у организаторов существует или отсутствует как класс?
Так им и не стоит доверять, как и любому другому. Доверять нужно алгоритму. Проверяйте, ищите уязвимости…
W_K по этому поводу правильно сказал:
Формально говоря, это мы утверждаем, что закладки не было и нет — но мы не можем доказать это стороннему наблюдателю в принципе. Секретные чаты должны быть основаны на том, что сервер даже в принципе не может их расшифровать, и это должно обеспечиваться открытым протоколом и в меньшей степени — открытым исходным кодом клиентов.
W_K по этому поводу правильно сказал:
Формально говоря, это мы утверждаем, что закладки не было и нет — но мы не можем доказать это стороннему наблюдателю в принципе. Секретные чаты должны быть основаны на том, что сервер даже в принципе не может их расшифровать, и это должно обеспечиваться открытым протоколом и в меньшей степени — открытым исходным кодом клиентов.
Проверяйте, ищите уязвимости…Прошу ответить на два вопроса:
1. Вы уже проверили?
2. Вы доверяете алгоритму? Насколько? Гипотетически, поставили бы вы сейчас свою жизнь в зависимость от надежности клиента скачанного с их сайта и защищенности их сервера?
Нет, не проверял. Меня изначально оттолкнула идеология с привязкой к мобильному телефону.
Для меня этого достаточно чтобы не попадать в ЦА данного продукта. С одной стороны я могу и данные хостинга и root-пароли кидать в чатике контакта, если сервера не критичные, с другой стороны я никогда не привяжу сильно чувствительные данные к мобильному телефону. Уж очень много чего я насмотрелся в контексте мобилок и смартфонов/планшетов. К сожалению подробнее не могу сказать ибо NDA жмет, и обычным «один мой знакомый(ТМ)» не обойтись. В общем для домашнего использования Телеграм пока не достаточно популярен, а для профессионального не удобен в связи с привязкой к телефону.
Вопрос про жизнь считаю уж очень некорректным. При определенном стечении обстоятельств я и монетке мог бы доверить. Уж очень абстрактно.
Для меня этого достаточно чтобы не попадать в ЦА данного продукта. С одной стороны я могу и данные хостинга и root-пароли кидать в чатике контакта, если сервера не критичные, с другой стороны я никогда не привяжу сильно чувствительные данные к мобильному телефону. Уж очень много чего я насмотрелся в контексте мобилок и смартфонов/планшетов. К сожалению подробнее не могу сказать ибо NDA жмет, и обычным «один мой знакомый(ТМ)» не обойтись. В общем для домашнего использования Телеграм пока не достаточно популярен, а для профессионального не удобен в связи с привязкой к телефону.
Вопрос про жизнь считаю уж очень некорректным. При определенном стечении обстоятельств я и монетке мог бы доверить. Уж очень абстрактно.
> все проверки-сертификации ведь снова провести нужно
Какие еще сертификации? И, по-вашему, надо было ждать чьего-то одобрения, чтобы перейти от уязвимосй модификации DH к классической схеме? У вас к последней есть какие-то претензии?
Какие еще сертификации? И, по-вашему, надо было ждать чьего-то одобрения, чтобы перейти от уязвимосй модификации DH к классической схеме? У вас к последней есть какие-то претензии?
>У вас к последней есть какие-то претензии?
В связи с катастрофической безграмотностью разработчиков, вангую что и классический DH у них подвержен MITMу.
В спеке на протокол ничего не написано про проверку параметров DH, поэтому стоит серверу послать 1 или 0 в качестве g_a и g_b, и обе стороны получат единичный или нулевой ключ. Одинаковый у обоих, но известный серверу.
В связи с катастрофической безграмотностью разработчиков, вангую что и классический DH у них подвержен MITMу.
В спеке на протокол ничего не написано про проверку параметров DH, поэтому стоит серверу послать 1 или 0 в качестве g_a и g_b, и обе стороны получат единичный или нулевой ключ. Одинаковый у обоих, но известный серверу.
UFO just landed and posted this here
Я че-то не поннимаю как вообще в условиях проведения конкурса можно алгоритмы менять. Ну давайте их менять каждые 100мс, точно никто не сломает тогда.
А вы предлагаете уже выявленные дыры в системе с реальными пользователями, находящейся в эксплуатации, держать открытыми до окончания конкурса (у которого только первый этап — 2,5 месяца, а, вообще, он бессрочный)?
Я вижу три варианта в случае объявления награды:
1. Заморозить код до окончания срока
2. Изменить условия конкурса на лету
3. Выплатить награду автору топика и девелопить дальше с учетом набитых шишек
Или любая комбинация из трех
1. Заморозить код до окончания срока
2. Изменить условия конкурса на лету
3. Выплатить награду автору топика и девелопить дальше с учетом набитых шишек
Или любая комбинация из трех
Кроме того значение dh_prime взято непонятно откуда, без каких-либо пояснений и доказательств. А вдруг это какое-то «плохое» простое число, при использовании которого задача дискретного логарифмирования становится проще в разы?
В документации написано, что клиент должен выполнить соответствующие проверки, чтобы избежать известных атак. Все правильно
Я говорю не о secret chats, а о процессе аутентификации, где dh_prime приводится в качестве константы: link.
И вообще зачем кому-либо генерировать новые параметры для DH, если их можно сгенерировать один раз (или использовать набор параметров, как в ssh)?
И вообще зачем кому-либо генерировать новые параметры для DH, если их можно сгенерировать один раз (или использовать набор параметров, как в ssh)?
Константный dh_prime можно проверить и руками. Зачем/почему так — таких вопросов насчет mtproto можно много придумать :)
В документации предлагается выполнять проверку на безопасность простого числа. Помимо этого, есть ещё понятие «сильное простое число» с более строгими условиями, которые проверить уже намного сложнее. Как вы предлагаете это делать?
Импонирует позиция W_K, сходу признать чужую правоту, это весьма не часто встретишь.
Статья на hackernews, с переводом через google :)
Я тоже не эксперт, но…
Думаю, не секрет, что 100% — слишком громкая оценка вероятности. Считать NFC злоумышленник может и на расстоянии, равно как и QR-код.
Не вселяет уверенности.
Многие пользователи мессенджера требуют дать возможность обмениваться открытыми ключами через NFC и QR-коды, чтобы на 100% исключить возможность MITM-атак, в том числе и со стороны сервера Telegram.
Думаю, не секрет, что 100% — слишком громкая оценка вероятности. Считать NFC злоумышленник может и на расстоянии, равно как и QR-код.
Не вселяет уверенности.
Павел Дуров:
Эта история заставляет в очередной раз восхититься российскими программистами. Целую неделю маститые американские криптографы на HackerNews безуспешно цеплялись к протоколу — в основном, с требованием заменить наше решение на алгоритмы, которые продвигает АНБ в своем Suite B. А российский программист, называющий себя «новичком», смог в рамках статьи на Хабре с ходу определить потенциально уязвимое место в секретных чатах.
На всякий случай, поясню для массовых пользователей: утечки данных не было, уязвимость закрыта, опасности нет.
Еще раз убедился в том, насколько правильным решением было полностью открывать протокол и исходный код. Это позволяет привлекать тысячи умных людей, которые могут помогать постоянно совершенствовать систему, находя потенциально уязвимые места.
Разработчик, нашедший слабое место в нашем алгоритме, заслужил награду в $100,000. Подобную награду заслуживает любой, кто найдет возможности схожей атаки (напоминаю, за расшифровку потока трафика мной была объявлена награда в $200,000). Продолжаем искать — вместе мы сделаем протокол нерушимым.
Поздравляю x7mz с наградой в $100,000
Telegram уже успели выпустить новую версию
Во вторник защита диплома, кафедра защита информации, с восхищением расскажу и комиссии и своим сокурсникам Вашу историю. Браво!
Боюсь представить сколько нужно будет платить Дурову если подключатся специалисты в криптографии с Хабра :)
Вопрос команде Телеграма:
Безотносительно всего остального — а каким образом реализован механизм отзыва RSA ключей сервера? Допустим, тем или иным способом, приватный ключ сервера утек. Вам придется единовременно обновить все клиентские приложения?
Интересно, почему вы отказались от общепринятой схемы PKI (например, с использованием своего CA) — были ли на это какие-то причины?
Безотносительно всего остального — а каким образом реализован механизм отзыва RSA ключей сервера? Допустим, тем или иным способом, приватный ключ сервера утек. Вам придется единовременно обновить все клиентские приложения?
Интересно, почему вы отказались от общепринятой схемы PKI (например, с использованием своего CA) — были ли на это какие-то причины?
Создается ощющение, что это PR спектакль…
UFO just landed and posted this here
Вам не угодишь. Дали бы мало — жаловались бы, что «обманул Дуров!». Дали много — пошли жалобы «пиар, спектакль». Разумеется это пиар, не просто же так Дуров объявил о награде. Но не надо завидовать ее получившему, называя и его частью спектакля.
Чесно, я перед тем как напсиал свой пост неоднакратно подумал завидую ли я ему или нет. Пришол к выводу, что я только рад, что кто-то смог сделать телеграм безопаснее и получил 100 000$ в BTC. Никакой зависти у меня нет. Я ведь написал ниже, что готов предположить это Ананимус на глайдере, а остальное что бы вы не считали(репутация Дурова, регистрация и нулевая активность топикстартера...). По мне так и вариант с заклаткой и того, что сдал уязвимость 1 из разработчиков тоже вполне вероятен.
А вот дальше перебрав все варианты, срабатывает Бритва Окама. Которая для меня отрезала все кроме з PR компании. Но я не исключаю и другие варианты. И перерасчитывая их вероятность по китайский полагаю, что они вполне равноправные.
А вот дальше перебрав все варианты, срабатывает Бритва Окама. Которая для меня отрезала все кроме з PR компании. Но я не исключаю и другие варианты. И перерасчитывая их вероятность по китайский полагаю, что они вполне равноправные.
офф. x7mz, ты пытался взять какой-то рекорд по количеству одновременных подписок на хабы, или тоже тестил
:)
что-то
:)
Может это из серии: «Я тоже x7mz дайте мне 100 000$»
Вроде многие подписаны на все хабы(как и я), чтобы не пропускать статьи.
На хабре просто как-то было нововведение по фильтрации новостей в ленте. Толком не объяснили (что можно просто «галки» в Центре подписок проставить), а контент урезали — вот все судорожно и подписывались на все хабы подряд (в т. ч. и я), чтобы не пропустить ни одной новой статьи.
Вот оно что, а давно было это нововедение?
Больше пары лет назад.
Тогда дело наверное не в этом. Загляните в профиль z7mz он прибыл по приглашению НЛО за месяц до анонса конкурса на реализацию mtproto c менеджером. Насколько мне подсказывает мой профиль речь идет именно о регистрации, а не приглашении НЛО на сайт.
Также интересен факт отсутствия комментариев и активности. Заговор? Нет, не обязательно. Возможно перед нами гений, который ценит свою анонимность.
Также интересен факт отсутствия комментариев и активности. Заговор? Нет, не обязательно. Возможно перед нами гений, который ценит свою анонимность.
Скорее, на хабре непрозрачная система публикаций. Мне, например, важно получать все статьи; я уж сам разберусь, что мне важно, а что нет. Но в «захабренных» нет всех статей из «новых» и т. д.
Даже сейчас со всеми галками в Центре подписок, мимо меня проходят некоторые посты из хабов компаний. Или, например, при появлении нового хаба, он не проставляется автоматически в Центре подписок (и статьи вы, соответственно, можете не видеть).
Мечтаю об одной просто кнопке «показывать всё».
Даже сейчас со всеми галками в Центре подписок, мимо меня проходят некоторые посты из хабов компаний. Или, например, при появлении нового хаба, он не проставляется автоматически в Центре подписок (и статьи вы, соответственно, можете не видеть).
Мечтаю об одной просто кнопке «показывать всё».
Такие легкие деньги. Даже не верится ))))
Кстати, если протокол будет корректироваться, хочу добавить от себя по поводу
Как нам рассказывал D. Boneh на курсах криптографии, это выражение выдает не равномерно распреленную величину, поэтому его следует пропустить через KDF, на основе какого-нибуть стойкого хэша (SHA-256?), а не использовать на прямую как материал ключа.
И еще вопрос. Почему бы не использовать устоявшийся подход TLS (SSL) для обмена ключами? В нем всякие подобные детали (в том числе проблема слабой энтопии на клиенте) уже проверены (и исправлены) временем.
key = (pow(g_b, a) mod dh_prime)
Как нам рассказывал D. Boneh на курсах криптографии, это выражение выдает не равномерно распреленную величину, поэтому его следует пропустить через KDF, на основе какого-нибуть стойкого хэша (SHA-256?), а не использовать на прямую как материал ключа.
И еще вопрос. Почему бы не использовать устоявшийся подход TLS (SSL) для обмена ключами? В нем всякие подобные детали (в том числе проблема слабой энтопии на клиенте) уже проверены (и исправлены) временем.
Я слышал такое мнение: потому что он адски медленный и на EDGE его использовать невозможно.
Я в этом деле не разбираюсь. Но у меня появляется вопрос по поводу:
И Вы получите неравномерно распределенную величину, но в виде хеша. Что это даст? Разве величина станет «более распределенной»?
Как нам рассказывал D. Boneh на курсах криптографии, это выражение выдает не равномерно распреленную величину, поэтому его следует пропустить через KDF, на основе какого-нибуть стойкого хэша
И Вы получите неравномерно распределенную величину, но в виде хеша. Что это даст? Разве величина станет «более распределенной»?
Товарищи минусующие, неужели я такую глупость спросил? Как я себе это представляю:
Для начала, забудем про Диффи — Хеллмана и представим, что у нас есть некие данные, которые шифруются ключом, который задает пользователь.
В этом случае, если наш пользователь в качестве ключа использует «asdf», то дальше уже не важно как вы будете хешировать этот ключ. Т.к. ключ изначально «плохой» и никакие ухищрения его не сделают лучше.
Исходя из этого, мне совсем не ясно, как хеширование может «исправить» неравномерную распределенность.
Для начала, забудем про Диффи — Хеллмана и представим, что у нас есть некие данные, которые шифруются ключом, который задает пользователь.
В этом случае, если наш пользователь в качестве ключа использует «asdf», то дальше уже не важно как вы будете хешировать этот ключ. Т.к. ключ изначально «плохой» и никакие ухищрения его не сделают лучше.
Исходя из этого, мне совсем не ясно, как хеширование может «исправить» неравномерную распределенность.
Спасибо за вопросы. Здесь есть два момента.
1. Многие схемы шифрования не обеспечивают должной защиты, если для шифрования сообщений используются ключи, которые не сильно отличаются один от другого. При этом сообщение, зашифрованное с ключом «asdf» и другое сообщение, зашифрованное с ключем «bsdf», будет иметь статистическое отклонение от случайной последовательности данных, а значит возможна потенциальная атака. Кстати, таким свойством обладает и ASE-256. Хэши от «asdf» и «bsdf» будут сщественно отличаться, поэтому шифрованные ими сообщения уже не будут обладать статистическим отклонением.
2.Конкретно применительно к DH: применение хэша к выходной последовательности «рамазывает» мощное множество выходных данных, не обладающих равномерным распределением значений, и делает его как-бы равномерным. Обратите внимание, что ключ, сгенерированный DF имеет длину 2048, а для генерации пары ключей AES-256 нам достаточно 512 бит. С одной стороны хэш уменьшает длину ключа, но с другой — делает этот ключ неотличимым от равномерно распределенного.
1. Многие схемы шифрования не обеспечивают должной защиты, если для шифрования сообщений используются ключи, которые не сильно отличаются один от другого. При этом сообщение, зашифрованное с ключом «asdf» и другое сообщение, зашифрованное с ключем «bsdf», будет иметь статистическое отклонение от случайной последовательности данных, а значит возможна потенциальная атака. Кстати, таким свойством обладает и ASE-256. Хэши от «asdf» и «bsdf» будут сщественно отличаться, поэтому шифрованные ими сообщения уже не будут обладать статистическим отклонением.
2.Конкретно применительно к DH: применение хэша к выходной последовательности «рамазывает» мощное множество выходных данных, не обладающих равномерным распределением значений, и делает его как-бы равномерным. Обратите внимание, что ключ, сгенерированный DF имеет длину 2048, а для генерации пары ключей AES-256 нам достаточно 512 бит. С одной стороны хэш уменьшает длину ключа, но с другой — делает этот ключ неотличимым от равномерно распределенного.
Т.е. KDF на основе хеша обеспечивает нам лавинный эффект на входе AES и обеспечивает «конвертацию» нашего ключа в «пригодный» для AES формат.
Интересно, сколько людей увидев эту новость присоединились к поискам уязвимостей в протоколе? Особенно когда стало ясно, что можно получить награду не только за полный перехват сообщения.
Как говорится, ногами не бейте, за то, что не по теме, но до сих пор не могу понять — зачем этот telegram позиционирует себя как очень защищённый мессенджер. Большинству пользователей до фонаря — очень он защищённый или нет, главное, чтобы у всех знакомых был. Т.е. этот пункт скорее посыл к какому-то бизнес сектору, но что-то не уверен, что кто-то доверится этому telegram… Вот скорость — это да, возможно. Но опять упирается в людей, кто пользуется (мне до сих пор приходится держать аккаунт icq, чтобы связь с людьми не потерять, а заставить их пересесть на что-то ещё — это невозможно). Плюс скорость — понятие достаточно растяжимое. Большинству скорее всего не важно — уйдёт текст через 0.1с или через 1с.
Никого не хотел бы ни в чем обвинять, но выглядит очень странным тот факт, что два разработчика MTProto пришли в комментарии спустя всего лишь 45 минут после публикации топика. Ночью!
И всё это сразу после корпоративной вечеринки вконтакта. Или во время неё, что ещё пикантнее. Прошу прощения за невольный «параноидальный оффтоп».
Как-то меня в этой истории удивляют несколько моментов.
1). Топикстартер не пытался по канонам «белого хаккинга» сначала сообщить об уязвимости во ВКонтакте, а сразу прибег к public disclosure. А если бы разработчики Telegram не пофиксили все это дело за 40 минут, то какой ущерб мог нанести этот public disclosure?
2). Фиксация косяка за 40 минут уже само по себе странно. Я понимаю, что это возможно, особенно в маленьких командах, где никакого QA нет, но в масштабе компаний — это подозрительно. Я часто слежу за конкурсами типа Pwn2Own/Pwnium и прочих мероприятий Zero Day Initiative, но даже Google с Mozilla, которые выводят в продакшен свои исправления за ~24 часа, не демонстрируют таких скоростей, и это учитывая, что в дни таких конкурсов security team частью присутствует на самом конкурсе, а другая сидит на цепи в офисе и ждет вестей, и всё равно цикл со всеми необходимыми тестированиями занимает не меньше рабочего дня.
А тут за 40 минут разработчики изучили уязвимость, придумали решение, получили подтверждение ревьюеров и PMа, и засадили в продакшен? Ну это как-то гениально прямо. Почему вы ещё во ВКонтакте, а не в компаниях посолиднее с такими-то навыками?
3). PR-вакханалия с условиями конкурса с дальнейшим озалупливанием Павлом всей заокеанской тусовки как-то подозрительно резво была провернута.
4). Да и призовой фонд любопытный. 200k награды за конкурс с мутноватыми условиями, на которые бросается вся криптоанализирующая тусовка, и после того, как она выразила своё «фи», появляется принц на белом коне с блистательным открытием, которое за час разруливают прекрасные разработчики мессенджера, и Павел торжествующе «съедает» криптовиков. Все эти пафосные конкурсы типа Pwnium, где находят просто убойные уязвимости и пишут madskillz-эксплойты для браузеров, выплачивают награды типа 30-50k USD, а тут все 100k.
Я не сторонник теорий заговора, но раздирают сомненья меня. Я понимаю, что это могут быть просто совпадения, стечения обстоятельств и щедрость Павла, но как-то за историю ВКонтакте я уяснил, что все эти совпадения не всегда совпадения.
1). Топикстартер не пытался по канонам «белого хаккинга» сначала сообщить об уязвимости во ВКонтакте, а сразу прибег к public disclosure. А если бы разработчики Telegram не пофиксили все это дело за 40 минут, то какой ущерб мог нанести этот public disclosure?
2). Фиксация косяка за 40 минут уже само по себе странно. Я понимаю, что это возможно, особенно в маленьких командах, где никакого QA нет, но в масштабе компаний — это подозрительно. Я часто слежу за конкурсами типа Pwn2Own/Pwnium и прочих мероприятий Zero Day Initiative, но даже Google с Mozilla, которые выводят в продакшен свои исправления за ~24 часа, не демонстрируют таких скоростей, и это учитывая, что в дни таких конкурсов security team частью присутствует на самом конкурсе, а другая сидит на цепи в офисе и ждет вестей, и всё равно цикл со всеми необходимыми тестированиями занимает не меньше рабочего дня.
А тут за 40 минут разработчики изучили уязвимость, придумали решение, получили подтверждение ревьюеров и PMа, и засадили в продакшен? Ну это как-то гениально прямо. Почему вы ещё во ВКонтакте, а не в компаниях посолиднее с такими-то навыками?
3). PR-вакханалия с условиями конкурса с дальнейшим озалупливанием Павлом всей заокеанской тусовки как-то подозрительно резво была провернута.
4). Да и призовой фонд любопытный. 200k награды за конкурс с мутноватыми условиями, на которые бросается вся криптоанализирующая тусовка, и после того, как она выразила своё «фи», появляется принц на белом коне с блистательным открытием, которое за час разруливают прекрасные разработчики мессенджера, и Павел торжествующе «съедает» криптовиков. Все эти пафосные конкурсы типа Pwnium, где находят просто убойные уязвимости и пишут madskillz-эксплойты для браузеров, выплачивают награды типа 30-50k USD, а тут все 100k.
Я не сторонник теорий заговора, но раздирают сомненья меня. Я понимаю, что это могут быть просто совпадения, стечения обстоятельств и щедрость Павла, но как-то за историю ВКонтакте я уяснил, что все эти совпадения не всегда совпадения.
«то какой ущерб мог нанести этот public disclosure?»
я думаю, что пока сервера телеграма под контролем авторов, то ни какого.
Хотя открытие такого бага как раз таки стимулирует задуматься — быстро открылся и починился безвредный баг.
я думаю, что пока сервера телеграма под контролем авторов, то ни какого.
Хотя открытие такого бага как раз таки стимулирует задуматься — быстро открылся и починился безвредный баг.
Я просто напомню, что Вконтакте и Digital Fortress — это разные компании.
Я попробую ответить на второй пункт: потому что в компаниях посолиднее (Mozilla, Google) такое просто невозможно, как вы уже сами заметили. Надо согласовать с PM, безопасниками, уборщиками и прочими людьми, выкатить в ветку раз, в ветку два, прогнать кучу тестов и прочая, прочая, прочая. Зачем переходить куда-то, если на текущем месте интересно, есть деньги, а на потенциальном — то же самое, но без этакой «свободы»? Мне кажется, когда команда небольшая и все друг друга знаю — выкатить что-то можно намного оперативнее. Например, за 40 минут.
Судя по тому, что я знаю о ВК (и позволю себе проэкстраполировать на Digital Fortress) — процесс работы у них выстроен образом, отличающимся от стандартного «предложили — выкатили — неделю тестили — альфа — бета — пререлиз — релиз».
Судя по тому, что я знаю о ВК (и позволю себе проэкстраполировать на Digital Fortress) — процесс работы у них выстроен образом, отличающимся от стандартного «предложили — выкатили — неделю тестили — альфа — бета — пререлиз — релиз».
Вы с $банке не работали, бывало фиксы и быстрее рожали и цена вопроса/риски на порядок больше!
При знании дела и понимании ситуации никто на «ревьюеров и PMа» не смотрит.
При знании дела и понимании ситуации никто на «ревьюеров и PMа» не смотрит.
Есть ещё одна «закладка» для MITM (по крайней мере, в андроидовском клиенте она, вроде, есть, и в документации к протоколу о проверках, необходимых для её избежания, не говорится):
Сервер может даже в исправленной версии Диффи-Хелмана (без nonce) подсунуть клиентам в качестве g_a (или g_b) число, являющееся нулём по модулю p (поскольку документация говорит о 2048-битной последовательности — это может быть либо 0, либо само p). Тогда оба клиента увидят одинаковый identicon («визуализацию ключа», она будет являться представлением SHA1 от нуля).
Однако, судя по дальнейшим манипуляциям с ключом, домножения на ноль с клиентскими сообщениями не случится и они будут гоняться через «голый» AES (а значит, пользователи будут думать, что всё нормально и смогут передавать секретные данные в таком режиме). Причём, так их сможет подслушать не только сервер, но и внешний наблюдатель, который прознает про то, что сервер так себя повёл!
P. S.: Поправьте меня, если я что-то пропустил. Да, случай вырожденный, но, всё-таки, формально он от авторского отличается не сильно (как минимум, нужны фиксы в клиенте). Или я, всё-таки, где-то ошибся?
Сервер может даже в исправленной версии Диффи-Хелмана (без nonce) подсунуть клиентам в качестве g_a (или g_b) число, являющееся нулём по модулю p (поскольку документация говорит о 2048-битной последовательности — это может быть либо 0, либо само p). Тогда оба клиента увидят одинаковый identicon («визуализацию ключа», она будет являться представлением SHA1 от нуля).
Однако, судя по дальнейшим манипуляциям с ключом, домножения на ноль с клиентскими сообщениями не случится и они будут гоняться через «голый» AES (а значит, пользователи будут думать, что всё нормально и смогут передавать секретные данные в таком режиме). Причём, так их сможет подслушать не только сервер, но и внешний наблюдатель, который прознает про то, что сервер так себя повёл!
P. S.: Поправьте меня, если я что-то пропустил. Да, случай вырожденный, но, всё-таки, формально он от авторского отличается не сильно (как минимум, нужны фиксы в клиенте). Или я, всё-таки, где-то ошибся?
Добавлю: визуализация SHA1 от нуля выглядит вполне случайно, так что при сверке картинок броситься в глаза не должно.
А, ну да, ещё сейчас в андроид-версии клиента длина p проверяется только с точностью до байт (исходя из того, что 256 * 8 = 2048, есть сравнение с 256). Таким образом, сервер может ещё и выслать p чуть короче (скажем, 2041 бит), а потом в качестве g_a (или g_b) присылать не только 0 и само p, но и некоторое количество нетривиальных кратных p (где-то 2^7 — 1 вариант). И то если длина g_a_or_b тоже проверяется, в чём я не уверен :) Но это уже совсем мелочь в рамках того же бага про нулевой результат для секретного ключа.
Да тут ИМХО фиксы в клиенте не помогут.
Тем не менее, в репозитории появился довольно интересный фикс: github.com/DrKLO/Telegram/commit/50a92dc44a7e6f85d55bccede4607394ccd5b378
В документацию недавно добавили:
Правда «i.e. is a quadratic residue mod p» зря дописали, т.к. 0 тоже квадратичный вычет :)
А то, что на клиенте недростаточные проверки — плохо, напишите им.
Client is expected to check whether p is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime, and that 2^2047 < p < 2^2048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e. is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily
Правда «i.e. is a quadratic residue mod p» зря дописали, т.к. 0 тоже квадратичный вычет :)
А то, что на клиенте недростаточные проверки — плохо, напишите им.
Я говорю про валидацию g^a и g^b, пришедших от сервера, а не самого g на клиенте, про неё в доке ничего не было и нет.
В документации этой ночью было добавлено:
core.telegram.org/api/end-to-end#sending-a-request
core.telegram.org/mtproto/auth_key
core.telegram.org/api/end-to-end#sending-a-request
core.telegram.org/mtproto/auth_key
Больше спасибо. Изначально наше внимание к этой проблеме привлекли в Твиттере вчера вечером – и мы стали разбираться. Кстати, в англоязычной документации на момент Вашего комментария это должно было уже быть — возможно, Вы читали русскую версию?
Если вновь заметите нечто подобное, пожалуйста, пишите нам на security@telegram.org — будем награждать.
Если вновь заметите нечто подобное, пожалуйста, пишите нам на security@telegram.org — будем награждать.
Это странно, потому что фикс появился не глубоко ночью, когда был коммит «update to 1.3.4» а только недавно. А где эта проблема была описана в твиттере? И почему этим ребятам из твиттера не достанется приз?
Наше внимание к проблеме привлек твит от @DefuseSec (https://twitter.com/DefuseSec/status/414827607687843840), мы с ним вчера связались. Кроме того, проблема была описана Хабраюзером aabc, как он утверждает, еще вчера в 19:47: habrahabr.ru/post/207038/
Строго говоря, aabc был хронологически первым, хотя мы о проблеме узнали из другого источника.
Чтобы не было путаницы, мы решили на будущее сформулировать четкую политику bug-bounty (сколько, за что, как определять, кто первый и пр). А в данном случае в качестве одноразового решения в какой-то степени наградить всех троих. Пожалуйста, напишите нам на security@telegram.org – расскажем, как получить награду
Строго говоря, aabc был хронологически первым, хотя мы о проблеме узнали из другого источника.
Чтобы не было путаницы, мы решили на будущее сформулировать четкую политику bug-bounty (сколько, за что, как определять, кто первый и пр). А в данном случае в качестве одноразового решения в какой-то степени наградить всех троих. Пожалуйста, напишите нам на security@telegram.org – расскажем, как получить награду
Справедливости ради, стоит отметить, что я бы на месте aabc сразу дал бы комментарий сюда для пруфов, а потом уже бы ждал премодерации. А твит Taylor Hornby вообще бесполезный (сам по себе, а так-то вас на правильный путь могло и яблоко, упавшее с дерева, натолкнуть — это же не повод его награждать) и про другое. Так что лучше на двоих, чем на троих, по поводу aabc — согласен.
И нет, я читал английскую версию.
Тем более, если вы так долго разбирались, почему даже фикс клиента на гитхабе, на который я давал выше ссылку, пришлось дофикшивать поверх?
Первой мыслью была возможность MITM-атаки (человек посередине) и я пошел читать api протокола. Где выяснилось, что тут защита достаточно надежная: в момент первого запуска клиента создается авторизационный ключ, создается он непосредственно на клиентском устройстве с помощью протокола обмена ключами Диффи-Хелмана, но с небольшим отличием — открытый ключ сервера Telegram уже прошит в коде клиента, что исключает его подмену третьими лицами.
Сразу скажу, что не являюсь специалистом в области криптографии, поэтому мой вопрос может показаться невежественным. Если так, то заранее прошу простить за это.
Насколько мне удалось понять, защита от атаки «человек посередине» обеспечивается протоколом уже на начальном этапе при авторизации приложения.
Разложив pq на множители, клиент генерирует NewNonce (32 байта), а затем необходимая информация оборачивается в pqInner
new pqRequest {Nonce = Sugar.GetRandomBytes(16)}.Send(Channel);
var pqResponce = Channel.Receive().Of<pqResponce>();
var pq = pqResponce.PQ;
var p = PrimeUtils.findSmallMultiplier(pq);
var q = pq/p;
var pqInner = new pqInner // constructor 4 bytes
{
PQ = pqResponce.PQ, // 12 bytes
P = p, // 8 bytes
Q = q, // 8 bytes
Nonce = pqResponce.Nonce, // 16 bytes
ServerNonce = pqResponce.ServerNonce, // 16 bytes
NewNonce = Sugar.GetRandomBytes(32)
};
Заметим, что злоумышленник в состоянии перехватить сгенерированную клиентом при pq-запросе последовательность Nonce, а также ответ сервера, содержащий ServerNonce и число PQ (поэтому он также может разложить его на множители), ведь пока ещё никакие данные не шифруются. То есть у него есть частичная информация о структуре pqInner — 64 байта из 96-ти, не известно только поле NewNonce.
Затем происходит следующее.
pqInner сериализуется в массив байт и находится хэш сериализации (20 байт), также добавляется рандомная последовательность из 139-ти байт (20+96+139=255). После чего данная информация шифруется с помощью публичного ключа и используется в структуре dhRequest. Злоумышленник не может её так просто расшифровать, поскольку не обладает приватным серверным ключом. То есть криптозащита обеспечивается 256 байтным (2048-битным) ключом, что само по себе считается достаточно надёжным.
var pqInnerBytes = pqInner.ToBytes();
var data = new List<byte>();
data.AddRange(pqInnerBytes.Hash());
data.AddRange(pqInnerBytes);
data.AddRange(Sugar.GetRandomBytes(255 - data.Count));
var keySet = KeySet.PublicKeySets.First(s => s.Fingerprint == pqResponce.Fingrprints[0]);
var modulus = keySet.Modulus;
var exponent = keySet.Exponent;
var message = new BigInteger(data.ToArray());
var encriptedData = message.modPow(exponent, modulus);
new dhRequest
{
P = p,
Q = q,
Nonce = pqResponce.Nonce,
ServerNonce = pqResponce.ServerNonce,
FingerPrint = pqResponce.Fingrprints[0],
EncriptedData = encriptedData.getBytes(),
}.Send(Channel);
var dhResponce = Channel.Receive();
if (dhResponce is dhOkResponce) { ... }
Обратим внимание ещё на одну деталь: dhRequest — запрос, уже содержащий зашифрованную информацию, дополнительно включает поля P, Q, Nonce и ServerNonce, сам по себе передаётся в нешифрованном виде, поэтому у подслушивающего есть очередная возможность узнать эти параметры.
Теперь мы подошли к главному вопросу…
RSA в чистом виде надёжен, но как сказывается на его устойчивости тот факт, что нам частично уже известны сами зашифрованные данные и их структура?.. Мы точно знаем значения и местоположение 64-х байт из 256 в массиве, а ещё нам известно, как формируются 20 первых байт хэша.
Я не математик, но интуитивно предполагаю, что подобные условия понижают уровень защиты алгоритма. Не могу сказать насколько, но сам факт этот настораживает.
Но что вызывает ещё больше вопросов, так это то, что pqInner дублирует соответствующие поля PQ, P, Q, Nonce, ServerNonce в нешифрованных запросах, ведь именно эти поля дают нам некоторое представление о зашифрованной информации. Не являются ли они там лишними?
Что это? Может быть, «очередная закладка» или эти поля остались в наследство от первых версий протокола, и их забыли потом убрать?
Ведь намного чище было бы оставить в pqInner только поле NewNonce и добавить больше рандомных данных. А лучше вообще убрать оболочку pqInner, поскольку нам известны четыре байта сериализации номера конструктора этой структуры. То есть тогда мы просто будем шифровать полностью рандомную последовательность, поэтому злоумышленник не сможет сделать никаких предположений насчёт передаваемой информации.
Но что нам всё это даёт? Имея потенциально ослабленный RSA и возможность активного перехвата пакетов, мы можем расшифровать NewNonce, то есть сможем получить временные ключи, которые использует клиент для расшифровки серверных сообщений и шифровки своих во время процесса dh-авторизации. А теперь главный трюк — притворимся для клиента сервером, а для сервера клиентом и договоримся с каждым об авторизационном ключе. По сути, проведём MITM-атаку.
Конечно, разработать подобную программу-шпион одновременно выдающую себя за сервер и за клиент — задача непростая, но всё же выполнимая за разумные сроки, ведь API открытый. Думаю, какое-нибудь АНБ может себе это позволить. Остаётся один не очень удобный момент — это проверочный смс-код при регистрации пользователя, но если спецслужбы имеют доступ к мобильному оператору, то подделать его, думаю, тоже возможно.
В общем главный вопрос мой сейчас к структуре pqInner. Зачем в ней нужны поля, которые дублируются в других запросах и частично раскрывают шифруемые данные? Может быть, открытость pqInner и не ведёт к существенному ухудшению надёжности RSA, но хотелось бы тогда где-нибудь про это прочитать.
Возможно, я что-то недопонял или упустил из виду, поэтому отнеситесь, пожалуйста, с пониманием ко всему, что здесь написано.
Заметил у себя маленькую неточность
Мы точно знаем значения и местоположение 64-х байт из 255 в исходном массиве
Мы точно знаем значения и местоположение 64-х байт из 256 в массиве
Мы точно знаем значения и местоположение 64-х байт из 255 в исходном массиве
dataЕщё немного подумав я, кажется, начал догадываться, зачем в pqInner поместили PQ, P, Q, Nonce и ServerNonce — чтобы удостовериться, что этот запрос никто не подделал или он правильно зашифрован. Но с другой стороны, не слишком ли много данных используется для такой проверки? По крайней мере, все три параметра PQ, P и Q избыточно помещать, ведь достаточно будет только двух, да и достаточно знать только Nonce либо ServerNonce, ведь они однозначно определяют друг друга. Не пойдёт ли вся эта избыточность во вред устойчивости RSA? Да и нужно ли вообще именно так поступать?
Странно, то ли никто не заметил моего сообщения, то ли я непонятно всё написал =)
Однако нашлась сегодня интересная статья по теме:
Fault Attacks on RSA Signatures with Partially Unknown Messages
и её продолжение:
Fault Attacks Against emv Signatures
К сожалению, с моими узкоспециальными знаниями программиста и неглубокими математическими, мне трудно объективно оценить её ценность применительно к протоколу Telegram. Но насколько мне всё же удалось понять, тот факт, что мы частично знаем шифруемое сообщение, ослабляет RSA.
Всё-таки хотелось бы получить комментарии компетентных лиц по этому поводу…
Однако нашлась сегодня интересная статья по теме:
Fault Attacks on RSA Signatures with Partially Unknown Messages
и её продолжение:
Fault Attacks Against emv Signatures
К сожалению, с моими узкоспециальными знаниями программиста и неглубокими математическими, мне трудно объективно оценить её ценность применительно к протоколу Telegram. Но насколько мне всё же удалось понять, тот факт, что мы частично знаем шифруемое сообщение, ослабляет RSA.
Всё-таки хотелось бы получить комментарии компетентных лиц по этому поводу…
Sign up to leave a comment.
Безопасен ли Telegram? Или как я искал закладку в MTProto