Internet outage in China on Jan 21

Yesterday we witnessed one of the largest Internet outages ever in China. We have three theories about why this outage may have occurred - two related to the Falun Gong but our third theory is that the Chinese authorities set out to attack our unblockable mirror websites.

From 15:30 to 16:30 (China time) on January 21, DNS lookup to any domain would incorrectly resolve to Websites inside and outside of China were affected. Even Baidu and Sina were inaccessible. Only software using IP directly (e.g. QQ, VPNs) worked during that time. Attempts to visit any website redirected to, which didn’t respond during that time.  The overwhelming traffic to this IP likely crashed the server.




GFW DNS poisoning begins. First recorded instance.


Local DNS servers began to cache incorrect responses. Some large websites in China began to be affected e.g Sina Weibo.


Incorrect DNS continue to spread through Chinese DNS servers. Major websites including Baidu, Sina affected.


DNS poisoning lifted by GFW. But local DNS resolvers cached incorrect responses. Users continued to experience outage.


ISPs around China were manually flushing DNS caches and connections were gradually restored.

We have conclusive evidence that this outage was caused by the Great Firewall (GFW). DNS poisoning is used extensively by the GFW. Some articles that have appeared about this outage suspected that the root DNS server in China was hacked and all domains hijacked to This could explain why DNS servers in China were poisoned. However, during that time, we see that a lookup to, a public DNS operated by Google, returned bogus results if the lookup was done from China. In fact, the Google public DNS was not poisoned; the bogus response could only have been returned by GFW.  If the Chinese root DNS server was hacked, a DNS lookup in China via should have returned a correct response. See the below image from Zhihu.

Our testing system is designed to detect these bogus responses by querying non-existent DNS servers outside of China. Any valid response must come via GFW. We indeed observed such behavior during that time on all domains.  

But why did GFW poison all domains and effectively block all website traffic in China?

This action must have been unintentional. is owned by Dynamic Internet Technology according to an IP lookup, and they are behind the famous circumvention tool FreeGate. Currently, is a mirror site for, a news portal operated by Falun Gong groups.


One hypothesis is that GFW might have intended to block the IP but accidentally used that IP to poison all domains.


Many Chinese media stated that yesterday’s outage may have been due to a hacking attempt. The IP is operated by Dynamic Internet Technology, “mortal enemy number one” of the Chinese government. Some are suggesting Dynamic Internet Technology is behind the outage. However, hacking into a root DNS resolver is not enough to cause this outage, as we explained earlier in this post. They have to hack into GFW. If they are indeed capable of doing that, they can accomplish so much more than messing the entire Chinese internet up. In addition, during that time was not serving any content and with such traffic, it looks more like a DDOS attack agasint They couldn't use that IP to spread sensitive content during that time. However, from today, they have indeed started to use to distribute mirrors and stopped within a few hours.

Blocking our mirror sites

Our mirror site for FreeWeibo has attracted considerable attention and GFW has tried multiple times to block us. We automatically rotate backend servers and the GFW automatically scans new URLs and DNS poisons them.  DNS poisoning is not commonly used compared to connection reset. GFW seems to only use DNS poisoning as a last resort when connection reset fails to block a site. Our mirror forces GFW to add hundreds of rule-sets to DNS poisoning daily and perhaps because of this we were responsible for the system crashing. This is supported by the fact that our new backend domains are no longer automatically blocked.

We’re also continuously improving our backends to prevent automatic discovery from GFW. Perhaps the script operated by GFW acquired a “null” domain from us and consequently blocked everything.



订阅 email
显示 博客 | Google+ | Twitter | 全部 的消息. 使用 RSS 订阅我们的博客。

星期四, 9月 24, 2015

Apple blocked CNNIC CA months after MITM attacks

In March of this year, Google found unauthorized digital certificates for several Google domains. The root certificate authority for these domains was the China Internet Network Information Center (CNNIC). CNNIC was controlled by the Chinese government through the Ministry of Industry and Information Technology and is now under the management of the Cyberspace Administration of China (CAC). CNNIC was recognized by all major browsers as a trusted Certificate Authority. If CNNIC signs a fake certificate used in a man-in-the-middle attack, no browser will warn of any unusual activity unless the certificate is pinned.

星期三, 9月 23, 2015

Malicious Xcode could spread via download manager Xunlei

What’s at stake?

We reported last week that popular Chinese iOS apps were compromised in an unprecedented malware attack. We discovered that the source of the infection was compromised copies of Xcode hosted on Baidu Pan. Apple has published an article urging developers to download Xcode directly from the Mac App Store, or from the Apple Developer website and validate signatures. We’ve now discovered that even if a developer uses a download link seemingly from Apple, he might still be possible to obtain a compromised copy of Xcode.

Please note that we do not have evidence that such attacks has happened. But it is an easy attack that anyone can implement.

How does it work?

This compromise happened because of Xunlei. Xunlei is the most popular download manager in China. Much of its popularity is due to the fact they can accelerate download speeds by pulling resources from other Xunlei users as well as cached copies on the Xunlei server. All of this, however, is invisible to users. Users can simply enter a regular http download address into Xunlei  download manager and the download will start. Chinese developers were using direct download addresses such as to download Xcode.

星期一, 9月 21, 2015



星期六, 9月 19, 2015




据最近的报道,中国开发者使用的某些版本的Xcode被感染,在开发者不知情的情况iOS应用中就被注入了用于跟踪的代码。(1、2)。被注入后,开发者们将他们被感染的iOS应用程序的上架了App Store并得到苹果批准。截止完稿前,这些被感染的应用在App store仍可访问(外部链接)。任何安装并启动了这些被感染应用的用户都将是追踪代码的受害者。




这些被感染Xcode被托管在百度云上。百度本身似乎并没有意识到这些Xcode是被感染的。在这次事件逐渐浮出水时该公司于昨日删除了这些被感染的文件。由于在中国下载外国网站的文件时速度非常慢,许多中国人希望能够从国内网站来下载。很多人也会使用下载软件,如迅雷,而不是直接从官方的Mac App Store中下载。




微信(link is external) 中国最流行的聊天应用

网易云音乐(link is external) (NetEase Cloud Music) - 网易的免费音乐应用

网易公开课(link is external) (NetEase) - 被许多学生所使用的公开教育应用

中信银行动卡空间(link is external) (China CITIC Bank Card Space)

中国联通手机营业厅(link is external) (China Unicom Shop)

星期三, 9月 16, 2015



Roya, David, Nick, nweaver, Vern, 和我刚刚完成了关于GFW主动探测系统的研究。这个系统在几年前就被用来探测翻墙工具,比如Tor。我们在之前的博文中介绍过GFW主动探测系统是如何工作的。但有几个问题我们没有回答。比如这个系统的物理结构是怎样的。那些用来主动探测的IP是归GFW所有的么? 有猜测GFW短时间内劫持了部分IP来用来主动探测,但没有证据。这次研究回答了这些问题。


  • 通常来说,如果Tor的某个网桥代理被GFW检测并封锁,它会一直被封锁。但是这意味着网桥代理完全无法访问吗? 我们让中国的VPS一直连接我们控制的网桥代理。我们发现,每25小时,中国的VPS可以短暂的连接到我们的代理网桥。下图显示了这个现象。每个数据点表示中国的VPS试图与网桥代理建立连接。中国联通和中国教育网都有这个周期性现象。有时候,网络安全设备在更新规则时会默认允许所有流量,但我们不知道GFW周期性现象是不是因为这个原因导致的。

  • 我们找到了规律,GFW主动探测的TCP头暗示那几千个IP都来自与同一个地方。下图显示了数据包的初始序号和时间。每个数据点都是一个主动探测连接。如果每个主动探测都是从不同地方发出的,我们应该看到随机的数据点,因为数据包的初始序号是随机选择的。但是下图显示主动探测连接虽然来自不同IP,但是非常有规律。我们认为主动探测的初始序号是按照时间产生的。


使用 RSS 订阅我们的博客。


и сюда запостил.

inspired a lot from this post am following this blog regularly and found very good for bookmarking thanks admin
new year sms in hindi 2015
happy new year sms 2015
happy new year 2015 wallpapers
happy new year 2015 quotes
happy new year 2015
happy new year wishes 2015

this post is awesome, great msg for us, plz update ur blog for daily basis, i am regular visitor of this site, so keep posting for us,

click the below links to create backlink
best free backlink website
click here for msg movie

thanks for this post, keep it up for updating us, i am waiting for ur new article.
IPL 2015 Cricket live score
Harjinder Singh
thanks again


Filtered HTML

  • 自动将网址与电子邮件地址转变为链接。
  • 允许的HTML标签:<a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • 自动断行和分段。

Plain text

  • 不允许HTML标记。
  • 自动将网址与电子邮件地址转变为链接。
  • 自动断行和分段。
By submitting this form, you accept the Mollom privacy policy.