National Anti-Fraud Center based plugins allegedly found in residential FTTR modem in China.

[IrradiatedKiwi]

Related issue:

https://github.com/net4people/bbs/issues/354

Reference link:

https://chinadigitaltimes.net/chinese/701596.html

According to v2ex, a chinese tech forum, in October 2023, someone in China found that their newly installed FTTR modem provided by a Chinese telecom company contains internet censorship plugins, including tools related to National Anti-Fraud Center.

1. The author stated that their censorship-circumvention tools was blocked since the installation of the new FTTR modem. Their tools had been usable and had no problem prior the FTTR modem installation.

2. They tried to visit a legit VPS website but the website was redirected to the Chinese anti-fraud webpage.

3. Soon after that they received phone call from police asking them if they were trying to visit that VPS website (the police also mentioned the exact domain name in the call). The police said that VPS website is a fraud website and asked if they needed some police sent to their home.

I also found an article in chinese regarding this incident. It has a little more analysis about the anti-fraud plugins in FTTR modem, I don't know if the author of that article is comfortable with sharing their web directly, so here are my rough summary.

According to the log of that FTTR modem, it contains the following plugins that are suspicious:

homegraudv3

antifraudv3

dnslogv3

sniproxyv3

homegraudv3 is probably a misspell of homeguardv3, it is a professional surveilliance tool which supports remote monitoring and management. Including screenshot, Website time limit, Website blocking, etc( 远程监控和控制计算机设备包括屏幕捕捉、上网时间限制、上网拦截等 ).

antifraudv3 The author think it probably just functions like the National Anti-Fraud Center app, but the author in that article says that they have little information about this and since they don't have it themselves so they can't provide a conclusive analysis.

dnslogv3 is a log of DNS usage including DNS queries.

sniproxyv3 is a reverse SNI Proxy. The author think it works in the follow way:

SNI Proxy 的工作流程大概如下：

    解析传入连接中的 TLS/SSL 握手消息，以获取客户端发送的 SNI 域名信息。

    检查域名是否在允许列表中（或开启了 allow_all_hosts），如果不在将中断连接，反之继续。

    使用系统 DNS 解析 SNI 域名获得 IP 地址（即该域名的源站服务器 IP 地址）。
    将流量转发给该域名的源站 

    IP:443，在客户端和源站服务器之间进行数据传输（即 TCP 中转/端口转发）。

The workflow of the SNI Proxy is roughly as follows:

• Parses the TLS/SSL handshake messages in the incoming connection to get information about the SNI domain name sent by the client.
• Check if the domain name is in the allowed list (or allow_all_hosts is turned on), if it is not, the connection is broken, or vice versa.
• Resolve the SNI domain name using the system DNS to obtain the IP address (i.e. the IP address of the origin server for the domain name). Forward the traffic to the source of the domain name
• IP:443 to transfer data between the client and the origin server (i.e. TCP relay/port forwarding).

I think the SNI Proxy is probably how they redirect users to the anti-fraud website.

[gaukas]

The workflow of SNI Proxy is roughly as follows:

    Parse the TLS/SSL handshake messages in the incoming connection to obtain the SNI domain name information sent by the client.

    Check whether the domain name is in the allowed list (or enable_all_hosts). If not, the connection will be interrupted. Otherwise, continue.

    Use system DNS to resolve the SNI domain name to obtain the IP address (that is, the origin server IP address of the domain name).
    Forward traffic to the origin site of the domain name

    IP:443, for data transmission between the client and the origin server (i.e. TCP relay/port forwarding).

Do we have any evidence supporting the hypothesis on sniproxyv3?

In our research paper on shadow-tls we did an experiments on almost the exact attack described above. Our data shows that out of 472K <SNI,IP> tuples (from 27M TLS connections over 24 hours), SNI of 6K of them does not resolve, and 325K of them is connecting to IPs that are not in the A record. Among these 325K, 4K failed TLS handshake with original IP and 2K failed TLS handshake with resolved IP. Their intersections contains 1K SNIs which made up 315K out of 27M (1.1%). Based on which we conclude this attack will be introducing too much collateral damage and is therefore not feasible.

On the other hand, it should be easy to verify. But I wouldn't be surprised to learn they are really doing this to crackdown ShadowTLS-like SNI-masked circumvention tools, since censors often have different tolerance on collateral damages from ours (in academia). It is completely possible for censors to see all TLS connections to "hidden servers" as illegal.

[wkrp]

Thank you. That's an interesting detail about the SNI proxy. Forcing a connection to an IP address actually associated with the external SNI could defeat some forms of TLS-based circumvention.

I and some colleagues wrote about SNI proxies discovered in the wild in 2016.

[wkrp]

Related to matching an SNI with an expected IP address, this is a recent (2022) patent from the Chinese firewall company Venustech (启明星辰). It is about building a database of expected IP addresses for hostnames through passive observation of natural DNS, HTTP, and HTTPS traffic. The database can be used to filter/block connections that use an unexpected IP address for the hostname.

基于局部敏感哈希算法的伴随域名检测方法 Companion domain name detection method based on locality-sensitive hash algorithm https://patents.google.com/patent/CN115051845 Chinese PDF English PDF (machine translation)

The database consists of (hostname, source IP, dest IP) records. For DNS, the hostname comes from the DNS response; for HTTP, it comes from the Host header; and for HTTPS, it comes from the TLS SNI. For each unique (hostname, dest IP), the number of unique source IP accessing it is counted and compared to a "rarity threshold" (potentially a different threshold for each protocol).

The text of the patent shows that it is intended against domain fronting–like techniques:

[0002] 在网络的信号安全领域中 ，网络攻击的发起者为更好地隐藏自己 ，往往会使用HTTP(超文本传输协议)或HTTPS(超文本安全传输协议)的一些特性将自身伪装成大站流量以躲避检测。由于恶意流量和网络正常访问的流量具有非常高的相似性，非常容易绕过常规检测设备的流量预处理机制，造成大量的漏报产生。如何实现对可疑流量高效精准的识别，已经成为了亟需解决的技术问题。

[0002] In the field of signaling security of networks, the initiators of network attacks, in order to hide themselves better, often use some features of HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure) to disguise themselves as large site traffic to avoid detection. Due to the high similarity between malicious traffic and normal network access traffic, it is very easy to bypass the traffic pre-processing mechanism of conventional detection devices, resulting in a large number of missed reports. How to realize efficient and accurate identification of suspicious traffic has become an urgent technical problem.

It also mentions domain borrowing by name:

[0090] 本发明上述实施例所提供的可疑流量识别方法、装置、设备和存储介质，在白名单过滤机制中，不是单纯IP或域名过滤，而是使用域名以及返回(对应的)IP地址为对象进行过滤，有效避免了伪装HTTP HOST或者Domain Borrowing等类型的恶意流量绕过流量预过滤系统。

[0090] The method, apparatus, device, and storage medium for recognizing suspicious traffic provided in the above embodiments of the present invention, in the whitelist filtering mechanism, instead of pure IP or domain name filtering, the domain name as well as the returned (corresponding) IP address are used as objects to be filtered, which effectively avoids the bypassing of malicious traffic of the type of masquerading as HTTP HOST or Domain Borrowing, etc., by the traffic pre-filtering system.