May 16, 2019 at 14:39China and Iran use replay attacks to fight Telegram
In the bug trackers of the popular MTProxy servers mtg and mtprotoproxy , reports appeared that in Iran and China, supervisors have somehow learned to detect and block telegram proxies, even using packet length randomization (dd prefix).
As a result, an interesting story turned out: to identify MTProxy proxies, attackers used replay attacks.
Packets for establishing a connection with a proxy are “recorded” by a third party, and after a while an attempt is made to connect, using the saved packet header along with “corrupted” data.
If you look at the structure of the MTProxy package
(the picture is taken from this article),
you can roughly imagine how it can work: the
proxy server analyzes the packet header, recognizes it as valid, and sends it directly to the Telegram server. Telegram servers accept a packet, but respond to it with an error message that is sent back by the proxy server, and you can detect it simply by the length of the packet (packets with an error message are much shorter than normal).
Based on this, the server address is blocked.
Proxy developers have already released updates. When connected, a check that the connection from this auth_key_id (in essence is a 64-bit random number) has not yet been:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
github. com / seriyps / mtproto_proxy / commit / 0f4d180a06eefb8aaa92c1d202ead8015a938a4c
In addition to this, a few days ago very interesting information appeared in Russian network communities and telegram channels that our native ILV started using open proxies to check public mtproxy servers. On the one hand, this is a logical step, because they don’t want or cannot do such checks from their addresses, because their ranges of subnets will quickly become known to the owners of the servers, and on the other hand, in many cases “public proxies” are hacked soho routers, which makes the situation very piquant.
A detailed article on this can be read on tjournal.
Enthusiasts have already developed a script, which automatically receives the current list of open proxies and applies ipset rules to effectively filter addresses from this list.
In addition to the script, there is a brief instruction on its use, written in a very lively and inspiring language.
As a result, an interesting story turned out: to identify MTProxy proxies, attackers used replay attacks.
Replay attack - an attack on an authentication system by recording and then playing back previously sent correct messages or parts thereof( wiki )
Packets for establishing a connection with a proxy are “recorded” by a third party, and after a while an attempt is made to connect, using the saved packet header along with “corrupted” data.
If you look at the structure of the MTProxy package
(the picture is taken from this article), you can roughly imagine how it can work: the
proxy server analyzes the packet header, recognizes it as valid, and sends it directly to the Telegram server. Telegram servers accept a packet, but respond to it with an error message that is sent back by the proxy server, and you can detect it simply by the length of the packet (packets with an error message are much shorter than normal).
Based on this, the server address is blocked.
Proxy developers have already released updates. When connected, a check that the connection from this auth_key_id (in essence is a 64-bit random number) has not yet been:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
github. com / seriyps / mtproto_proxy / commit / 0f4d180a06eefb8aaa92c1d202ead8015a938a4c
In addition to this, a few days ago very interesting information appeared in Russian network communities and telegram channels that our native ILV started using open proxies to check public mtproxy servers. On the one hand, this is a logical step, because they don’t want or cannot do such checks from their addresses, because their ranges of subnets will quickly become known to the owners of the servers, and on the other hand, in many cases “public proxies” are hacked soho routers, which makes the situation very piquant.
A detailed article on this can be read on tjournal.
Enthusiasts have already developed a script, which automatically receives the current list of open proxies and applies ipset rules to effectively filter addresses from this list.
In addition to the script, there is a brief instruction on its use, written in a very lively and inspiring language.