В итоге выяснилась занятная история: для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.
Атака повторного воспроизведения (replay) — атака на систему аутентификации путём записи и последующего воспроизведения ранее посланных корректных сообщений или их частей(wiki)
Пакеты установления соединения с proxy «записываются» третьим лицом, и через некоторое время производится попытка подключения, при этом используется сохраненный заголовок пакета вместе с «испорченными» данными.
Если посмотреть на структуру пакета MTProxy
(картинка взята вот из этой статьи)то получается примерно представить, как оно может работать:
прокси-сервер анализирует заголовок пакета, признает его валидным, и отправляет дальше непосредственно на сервера Telegram. Сервера Telegram принимают пакет, но отвечают на него сообщением об ошибке, которое пересылается прокси-сервером обратно, и детектировать его можно просто по длине пакета (пакеты с сообщением об ошибке гораздо короче чем нормальные).
На основании этого и происходит блокировка адреса сервера.
Разработчики обоих прокси-серверов уже выпустили обновления. При соединении выполняется проверка, что коннектов с таким auth_key_id (по сути дела представляющим собой 64-битное случайное число) еще не было:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
В дополнение ко всему, несколько дней назад в российских сетевых сообществах и телеграм-каналах появилась весьма занимательная информация, что наш родной РКН начал использовать открытые прокси для проверки публичных mtproxy-серверов. С одной стороны, это вполне логичный шаг, т.к. со своих адресов заниматься такими проверками они не хотят или не могут, потому что их диапазоны подсетей станут быстро известны владельцам серверов, а с другой стороны, во многих случаях «публичные прокси» представляют собой взломанные soho-роутеры, что делает ситуацию весьма пикантной.
Подробную статью об этом можно прочитать на tjournal.
Энтузиасты уже разработали скрипт, автоматически получающий актуальный список открытых прокси и применяющий правила ipset для эффективной фильтрации адресов из этого списка.
В дополнение к скрипту идет краткая инструкция по его использованию, написанная очень живым и воодушевляющим языком.
Комментарии (29)
GLaNIK
16.05.2019 16:49… с момента появления этого MTProxy уже несколько статей мелькало, что его как-то там детектируют и блочат.
Все никак понять не могу, в чем прикол его использовать, если ТГ поддерживает SOCKS5?
Whuthering Автор
16.05.2019 17:05+1До этого выявляли и блочили только одним способом — по определению размера пакета, и разработчики эту уязвимость довольно оперативно прикрыли.
SOCKS5 использовать вообще нет смысла хотя бы потому, что он вообще не шифрованный, и логин-пароль, и адрес хоста назначения там передаются в открытом виде. То есть любой хоть сколь-нибудь работающий DPI сможет на раз-два детектировать саму проксю и коннекты к серверам телеграмма через неё.
RomanStrlcpy
16.05.2019 22:17можно пробрасывать SOCKS5 через ssh
Whuthering Автор
16.05.2019 23:36+1Можно. Но тогда при каждом включении передачи данных на мобильном устройстве придется поднимать ssh-туннель.
Может, конечно, и есть клиенты, которые умеют автоматически подключаться при появлении интернета, но, опять же, это будет ещё одно приложение которое занимает память и потребляет ресурсы.
Nexon
17.05.2019 01:53Shadowsocks для этого есть, оно не жрёт аккум, универсальное и простое.
Whuthering Автор
17.05.2019 09:28А оно может работать без переподключений (или автоматически переподключаясь без участия пользователя) при долгих пропаданиях связи (например, зашел с улицы в метро) или смене сетей (4g -> wifi -> 4g)?
ksenobayt
17.05.2019 11:00Персонально я упрощаю ситуацию ещё больше посредством Orbot. На роуминг между сетями он реагирует вполне нормально, на какое-то время ставя сессию на паузу и довольно бодро поднимает её обратно. По крайней мере, в метро, будучи подключенным к мобильной сети (не вайфаю) всё работает умеренно стабильно.
В современном своём виде он жрёт батарейку куда аккуратнее, чем даже год назад. Фундаментального импакта на длительность жизни смартфона я не заметил (речь про Poco F1 с батарейкой на 4к мАч).
deadNightTiger
17.05.2019 19:10Там на каждую TCP-сессию приложения создается отдельная TCP-сессия (в отличие от VPN-решений, где все заворачивается в одно соединение). То есть если приложение умеет переподключаться, то и через Shadowsocks проблем не будет.
kraglik
16.05.2019 17:11Да они и вполне себе частные прокси блокируют. Арендовал я, значит, машину, поставил там сервера MTProxy и OpenVPN, настроил и некоторое время был очень доволен.
Неладное заподозрил, когда, наткнувшись уже на десятый или одиннадцатый заблокированный «за компанию» сайт, решил, что, видимо, теперь уже и научную информацию пора через VPN читать. Запустил OpenVPN и… Ничего. Открыл Telegram — прокси недоступен. Попытался сделать ssh — нет, никак. При этом IP в базах РКН не фигурирует. Из других стран к серверу вполне себе возможно подключиться, но из России — уже никак. Причем, что самое забавное, по времени эта блокировка ну очень совпадает с разгоном демонстрантов в том самом сквере (примерно в это время проявились первые симптомы, через МТС сервер стал недоступен).
Как же правительство обо мне заботится: негоже по утрам статьи про аксональное наведение или регистровые VM читать, от лукавого это, лучше поспи еще часик-другой. А меньше знаешь — крепче спишь, вот и не нужны тебе эти все VPN, ишь чего удумал. Спасибо, дорогой РКН, что бы я без тебя делал.Whuthering Автор
16.05.2019 17:13Ключ шифрования был с префиксом 'dd'? Если нет, то не удивительно.
kraglik
16.05.2019 17:18Так в том и дело, что с dd. Видимо, переняли опыт китая, описанный в статье выше.
Percollus
16.05.2019 18:27Аналогичная ситуация меньше недели назад — отрубился прокси, ssh ни в какую, rebuild сервака не помог. Из некоторых местах пингуется, из некоторых нет. Вот думаю, что в связи с этим всем делать...
Tatikoma
17.05.2019 12:01Сделать трассировку. Написать провайдеру жалобу. Пусть объяснят, на каком основании блокируют, если его нет в списках РКН. Подать в суд по причине незаконного ограничения свободы доступа к информации. Обратится в полицию в конце-концов, — ведь именно они должны охранять наши права?
hssergey
16.05.2019 17:48Там не только 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.
Без комментариев…Whuthering Автор
16.05.2019 17:59Если я правильно понимаю, то это происходит только на очень старых версиях прокси (до января 2019), и только на системах с активированным IPv6 (кто-нибудь, кстати, может объяснить, как это связано)?
upd. судя по всему, ipv6 тут не причем, но все равно непонятно, как оно вообще работало.
F0iL
16.05.2019 18:22Там у них в случае включенной поддержки ipv6 в коде адрес биндился не на in6addr_loopback, а на in6addr_any, то есть ::, а это открывает сокет и для 0.0.0.0 ipv4 тоже.
Ну и пофиксили они это своеобразно — вместо изменения адреса просто отключили ipv6 в этом месте кода :)Whuthering Автор
17.05.2019 20:38Получается, что на OpenBSD эта прокся вообще не завелась бы — как пишут в интернетах, на опенке сервер, слушающий только на :: по умолчанию будет недоступен для IPv4.
zxxc
17.05.2019 10:53Я правильно понял что прокси может auth-пакеты запоминать и не блочить пакеты или адреса, а отправлять такие пакеты несколько раз чтобы заблочить пользователя на сервере телеграмма как будто его аккаунт кто-то пытается взломать? или к примеру увидеть успешно авторизовавшегося юзера и попытаться поменять ему сразу же пароль? Т.е. блочить не сам телеграм а вызывать отказ в обслуживании для конкртеных юзеров?
seriyPS
17.05.2019 20:38Небольшое замечание: картинка с описанием формата пакета не имеет отношения к mtproto proxy. То что на картинке это просто mtproto пакет. Mtproto proxy еще 2 слоя поверх этих пакетов добавляет
Whuthering Автор
18.05.2019 01:53А есть картинка или таблица с описание формата пакета прокси-протокола? Я писал по обрывкам упоминаний и со слов третьих лиц, если можно будет изложить корректнее, буду только рад.
seriyPS
19.05.2019 19:55Картинки нет, но на словах могу объяснить.
Есть 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 версиях.
tvr
Не в бровь, а в глаз.
Whuthering Автор
Ну так логично, сначала "каким-то образом", а потом стало понятно, каким:)
tvr
Да я как бы и не об этом вовсе…
Whuthering Автор
А, вы про «злоумышленников». Ну тут да. Умысел однозначно есть, а вот во имя зла он, или во благо, каждый решает для себя сам.
Razunter
Во имя зла или во благо зла…