Китай и Иран используют replay-атаки для борьбы с Telegram

    В баг-трекерах популярных MTProxy-серверов mtg и mtprotoproxy появились сообщения о том, что в Иране и Китае надзорные органы научились каким-то образом выявлять и блокировать телеграм-прокси, даже использующие рандомизацию длины пакета (dd-префикс).
    В итоге выяснилась занятная история: для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.

    Атака повторного воспроизведения (replay) — атака на систему аутентификации путём записи и последующего воспроизведения ранее посланных корректных сообщений или их частей
    (wiki)

    Пакеты установления соединения с proxy «записываются» третьим лицом, и через некоторое время производится попытка подключения, при этом используется сохраненный заголовок пакета вместе с «испорченными» данными.

    Если посмотреть на структуру пакета MTProxy

    image(картинка взята вот из этой статьи)

    то получается примерно представить, как оно может работать:

    прокси-сервер анализирует заголовок пакета, признает его валидным, и отправляет дальше непосредственно на сервера Telegram. Сервера Telegram принимают пакет, но отвечают на него сообщением об ошибке, которое пересылается прокси-сервером обратно, и детектировать его можно просто по длине пакета (пакеты с сообщением об ошибке гораздо короче чем нормальные).

    На основании этого и происходит блокировка адреса сервера.

    Разработчики прокси-серверов уже выпустили обновления. При соединении выполняется проверка, что коннектов с таким auth_key_id (по сути дела представляющим собой 64-битное случайное число) еще не было:

    github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
    github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
    github.com/seriyps/mtproto_proxy/commit/0f4d180a06eefb8aaa92c1d202ead8015a938a4c

    В дополнение ко всему, несколько дней назад в российских сетевых сообществах и телеграм-каналах появилась весьма занимательная информация, что наш родной РКН начал использовать открытые прокси для проверки публичных mtproxy-серверов. С одной стороны, это вполне логичный шаг, т.к. со своих адресов заниматься такими проверками они не хотят или не могут, потому что их диапазоны подсетей станут быстро известны владельцам серверов, а с другой стороны, во многих случаях «публичные прокси» представляют собой взломанные soho-роутеры, что делает ситуацию весьма пикантной.

    Подробную статью об этом можно прочитать на tjournal.

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

    Похожие публикации

    Комментарии 29

      +12
      в Иране и Китае надзорные органы научились каким-то образом выявлять и блокировать телеграм-прокси,

      для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.

      Не в бровь, а в глаз.
        +1

        Ну так логично, сначала "каким-то образом", а потом стало понятно, каким:)

          +4
          Да я как бы и не об этом вовсе…
            +6
            А, вы про «злоумышленников». Ну тут да. Умысел однозначно есть, а вот во имя зла он, или во благо, каждый решает для себя сам.
              +16
              Во имя зла или во благо зла…
        0

        … с момента появления этого MTProxy уже несколько статей мелькало, что его как-то там детектируют и блочат.


        Все никак понять не могу, в чем прикол его использовать, если ТГ поддерживает SOCKS5?

          +3
          До этого выявляли и блочили только одним способом — по определению размера пакета, и разработчики эту уязвимость довольно оперативно прикрыли.

          SOCKS5 использовать вообще нет смысла хотя бы потому, что он вообще не шифрованный, и логин-пароль, и адрес хоста назначения там передаются в открытом виде. То есть любой хоть сколь-нибудь работающий DPI сможет на раз-два детектировать саму проксю и коннекты к серверам телеграмма через неё.
            0
            можно пробрасывать SOCKS5 через ssh
              +1

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

                0

                Shadowsocks для этого есть, оно не жрёт аккум, универсальное и простое.

                  0

                  А оно может работать без переподключений (или автоматически переподключаясь без участия пользователя) при долгих пропаданиях связи (например, зашел с улицы в метро) или смене сетей (4g -> wifi -> 4g)?

                    0
                    Персонально я упрощаю ситуацию ещё больше посредством Orbot. На роуминг между сетями он реагирует вполне нормально, на какое-то время ставя сессию на паузу и довольно бодро поднимает её обратно. По крайней мере, в метро, будучи подключенным к мобильной сети (не вайфаю) всё работает умеренно стабильно.

                    В современном своём виде он жрёт батарейку куда аккуратнее, чем даже год назад. Фундаментального импакта на длительность жизни смартфона я не заметил (речь про Poco F1 с батарейкой на 4к мАч).
                      0
                      Там на каждую TCP-сессию приложения создается отдельная TCP-сессия (в отличие от VPN-решений, где все заворачивается в одно соединение). То есть если приложение умеет переподключаться, то и через Shadowsocks проблем не будет.
                        0
                        Интересно. Стоит попробовать.
                        0

                        Да, конечно. Я вообще не замечаю переходов между переключениями.

              +4
              Да они и вполне себе частные прокси блокируют. Арендовал я, значит, машину, поставил там сервера MTProxy и OpenVPN, настроил и некоторое время был очень доволен.

              Неладное заподозрил, когда, наткнувшись уже на десятый или одиннадцатый заблокированный «за компанию» сайт, решил, что, видимо, теперь уже и научную информацию пора через VPN читать. Запустил OpenVPN и… Ничего. Открыл Telegram — прокси недоступен. Попытался сделать ssh — нет, никак. При этом IP в базах РКН не фигурирует. Из других стран к серверу вполне себе возможно подключиться, но из России — уже никак. Причем, что самое забавное, по времени эта блокировка ну очень совпадает с разгоном демонстрантов в том самом сквере (примерно в это время проявились первые симптомы, через МТС сервер стал недоступен).
              Как же правительство обо мне заботится: негоже по утрам статьи про аксональное наведение или регистровые VM читать, от лукавого это, лучше поспи еще часик-другой. А меньше знаешь — крепче спишь, вот и не нужны тебе эти все VPN, ишь чего удумал. Спасибо, дорогой РКН, что бы я без тебя делал.
                0
                Ключ шифрования был с префиксом 'dd'? Если нет, то не удивительно.
                  0
                  Так в том и дело, что с dd. Видимо, переняли опыт китая, описанный в статье выше.
                  +1

                  Аналогичная ситуация меньше недели назад — отрубился прокси, ssh ни в какую, rebuild сервака не помог. Из некоторых местах пингуется, из некоторых нет. Вот думаю, что в связи с этим всем делать...

                    +2
                    Сделать трассировку. Написать провайдеру жалобу. Пусть объяснят, на каком основании блокируют, если его нет в списках РКН. Подать в суд по причине незаконного ограничения свободы доступа к информации. Обратится в полицию в конце-концов, — ведь именно они должны охранять наши права?
                  +2
                  Там не только replay-атакой выявляли. Вон недавно пробегал интересный документ: telegra.ph/Raznosim-vranyo-Roskomnadzora-i-pomogaem-zablokirovat-ih-anus-na-vashih-proksi-dlya-Telegram-05-15
                  И меня там впечатлила одна фраза:
                  — Обновите docker-контейнер (или демон, если запускаете его напрямую) MTProto proxy до последней версии: РКН вычисляет старые версии по порту статистики, который биндился на 0.0.0.0 и однозначно себя идентифицировал для всего интернета. А лучше — откройте нужны порты с помощью iptables, а остальные — закройте (помните, что в случае с docker-контейнером следует использовать правило FORWARD).

                  То есть старые версии MTProto по дефлолту торчат в интернет 8888-портом и отвечают на HTTP-запросы со строкой MTProto: www.shodan.io/search?query=MTProxy%2F1.0
                  $ telnet 212.80.217.109 8888
                  Trying 212.80.217.109...
                  Connected to 212.80.217.109.
                  Escape character is '^]'.
                  GET / HTTP 1.0
                  HTTP/1.1 400 Bad Request
                  Server: MTProxy/1.0
                  Date: Thu, 16 May 2019 14:47:19 GMT
                  Content-Type: text/html
                  Connection: close
                  Content-Length: 172

                  400 Bad Request
                  400 Bad Request

                  MTProxy/1.0


                  Connection closed by foreign host.


                  Без комментариев…
                    +2
                    Если я правильно понимаю, то это происходит только на очень старых версиях прокси (до января 2019), и только на системах с активированным IPv6 (кто-нибудь, кстати, может объяснить, как это связано)?

                    upd. судя по всему, ipv6 тут не причем, но все равно непонятно, как оно вообще работало.
                      +1
                      Там у них в случае включенной поддержки ipv6 в коде адрес биндился не на in6addr_loopback, а на in6addr_any, то есть ::, а это открывает сокет и для 0.0.0.0 ipv4 тоже.
                      Ну и пофиксили они это своеобразно — вместо изменения адреса просто отключили ipv6 в этом месте кода :)
                        0
                        Получается, что на OpenBSD эта прокся вообще не завелась бы — как пишут в интернетах, на опенке сервер, слушающий только на :: по умолчанию будет недоступен для IPv4.
                      –1
                      Ух! Сударь, вы случайно не в одной подсети (/8) со мной? :)
                      0
                      Я правильно понял что прокси может auth-пакеты запоминать и не блочить пакеты или адреса, а отправлять такие пакеты несколько раз чтобы заблочить пользователя на сервере телеграмма как будто его аккаунт кто-то пытается взломать? или к примеру увидеть успешно авторизовавшегося юзера и попытаться поменять ему сразу же пароль? Т.е. блочить не сам телеграм а вызывать отказ в обслуживании для конкртеных юзеров?
                        0

                        Небольшое замечание: картинка с описанием формата пакета не имеет отношения к mtproto proxy. То что на картинке это просто mtproto пакет. Mtproto proxy еще 2 слоя поверх этих пакетов добавляет

                          0

                          А есть картинка или таблица с описание формата пакета прокси-протокола? Я писал по обрывкам упоминаний и со слов третьих лиц, если можно будет изложить корректнее, буду только рад.

                            +1

                            Картинки нет, но на словах могу объяснить.


                            Есть 2 стороны подключения: одна от телеграм-клиента к прокси, вторая от прокси к серверам телеграм. Обе стороны используют разные форматы пакетов и алгоритмы шифрования.


                            Клиент-прокси подключение использует 2 "слоя" поверх тех пакетов, которые изображены на картинке в статье — один для шифрования и один для разбивки TCP потока на пакеты:


                            Самый "внешний" — это потоковый AES_CTR. Ключи шифрования передаются в первом 64-байт пакете при подключении клиента. Так же в этом пакете передаётся (в зашифрованном виде) номер датацентра телеграма, к которому прокси должна подключить клиента и ID протокола следующего слоя.
                            Протоколов разбивки на пакеты 3: abridged, intermediate, mtp_secure
                            первые 2 отличаются тем, как кодируется длина пакета. Третий mtp_secure — это тот же mtp_intermediate, но с подмешиванием в каждый пакет 0-3 байт случайных данных (dd-режим).


                            Для подключения прокси-телеграм сервер используется 3 "слоя" — внешний для шифрования, средний для разбивки потока данных на пакеты и последний для поддкржки мультиплексирования:


                            Шифрование блочное AES_CBC. Ключ шифрования включает в себя unix timestamp и IP адрес прокси-сервера. Поэтому важно чтоб на прокси были корректно настроены часы и возможны проблемы при работе через NAT.
                            Слой пакетирования — mtp_full. От abridged и intermediate отличается наличием crc32 контрольной суммы.
                            Слой RPC добавляет поддержку своего рода RPC с небольшим набором команд для управления передачей пакетов, принудительного дисконнекта клиентов и мультиплексирования.


                            Мультиплексирование вообще очень интересная штука: множество подключений клиент-прокси направляется в одно подключение прокси-телеграм сервер. Это экономит время на подключение, позволяет проксировать больше 63к одновременных подключений и избавляет от проблемы с множеством TIME_WAIT сокетов. Если реализация прокси-сервера её не поддерживает, на достаточно высоких нагрузках будет много проблем на уровне ОС. На данный момент реализовано только в официальной и Erlang версиях.

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

                        Самое читаемое