Thursday, September 24, 2015

Apple blocked CNNIC CA months after MITM attacks

Wednesday, September 23, 2015

Malicious Xcode could spread via download manager Xunlei

What’s at stake?

I reported last week that popular Chinese iOS apps were compromised in an unprecedented malware attack. I 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. I’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 I 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.
Because of Xunlei’s P2P and server cache, download speeds would be much faster than the Mac App Store. Downloading via Xunlei also means that developers do not need to be enrolled in the Apple developer program. Direct downloads of Xcode via the developer program cost $99. Because the URL belongs to Apple, users were tricked into thinking that the download link was authentic and hence the Xcode copy. But in actual fact, the file is not authentic because it comes from Xunlei’s P2P and server cache.
The way to “host” a compromised copy of Xcode on Apple’s server is to trick Xunlei locally and let the error propagate. For example, a malicious user can hijack locally via host file and download from a non-exsistant URL Xunlei will then correlate this URL with the file specified by the malicious user and provide this file to other innocent users.
This is what actually happens when you use Xunlei to download
But if you look at the details of the download source, you can see that 0% of the download is from the original server (i.e while the server cache accounts for 26% and P2P accounts for 3% of the download.
You can also see that attempts by Xunlei to connect to were redirected to  because Apple only allows users in the Apple developer program to access the page.
Malicious attackers can poison Xunlei with a URL similar to a real Apple Xcode URL and then post the fake URL on forums and download sites. Most Chinese users by default use Xunlei to download. In fact, they have to if they are not enrolled in the Apple developer program. Most will have a compromised copy of Xcode, seemingly downloaded from Apple.

What can developers do to prevent future attacks?

My suggestions are exactly the same from my last blog post.
  • Always download Xcode from the official Mac App Store. For other developer tools, always download these from official sources.
  • Always check the digital signature of developer tools. It is irresponsible for developers to ignore signature warnings. Xcode clearly should have been signed by Apple; all other versions should have produced user warnings.
  • Separate your development system with your everyday system. Development systems should be used solely for development and not for browsing random sites. If physical separation presents too much of a problem for developers, at the very least, a dedicated user account for development should be used.

Xunlei users should be cautious

As demonstrated above, Xunlei cannot be trusted to download the correct file, even if the download link is HTTPS. Users should manually check hash after download or use the browser’s download function.

Saturday, September 19, 2015

Popular Chinese iOS apps compromised in unprecedented malware attack

What happened?

According to recent reports, some versions of Xcode used by developers in China have been compromised and are being used to inject tracking codes in iOS apps without developer knowledge. (1,2). Unaware of the injection, those developers then released their compromised iOS apps to the App Store which were then later approved by Apple. At the time of writing this post, the compromised apps are still available in the App store. Any user who has installed and launched these compromised apps will be a victim of these tracking codes.

This is a significant compromise of Apple’s app store. Apple notoriously manually reviews all app submissions and, in comparison to Android stores, has been relatively malware-free. This is the most widespread and significant spread of malware in the history of the Apple app store, anywhere in the world.

The compromised version of Xcode was hosted on Baidu Pan. It is unlikely that Baidu was aware of the compromised version of Xcode. The company removed the files yesterday when news of the compromise surfaced. Because of slow download speeds from foreign websites in China, many Chinese developers prefer to download apps from domestic websites. Many Chinese also use download software like Xunlei, rather than downloading directly from the official Mac App Store.

According to users reports, many prominent Chinese apps are affected. I have included links to the compromised apps in the list below but DO NOT DOWNLOAD these apps. I am simply linking to them so that users can recognize the apps. Affected apps include:  
Wechat(link is external) The most popolar messaging app in China
网易云音乐(link is external) (NetEase Cloud Music) - Netease free Spotify-type app
网易公开课(link is external) (NetEase) - open education app, used by many students
中信银行动卡空间(link is external) (China CITIC Bank Card Space)
滴滴出行(link is external) (DiDi travel) - the popular car sharing app
12306(link is external) - only train ticketing website
It is important to note that the two Netease apps are official apps from Netease. Netease is one of the biggest internet companies in China. Wechat is the most popular messaging app in China. China Unicom is one of China’s major telecom companies and CITIC is one of the country’s largest banks. These apps are likely to be extremely popular and highly trusted by users. It is extremely irresponsible for developers in those companies to ignore digital signature warnings and to continue to use compromised Xcode. If the malware author did a targeted attack against wechat or CITIC, he would have been able to gain users credentials, collect chat history, contact list or even banking details!
Netease has already posted a warning about its music app for users:
Wechat also acknowleged the problem.

What can compromised users do to mitigate this attack?

If you are an iPhone user, there is little you can do. Do not download the above apps. Do not give permissions to apps unless absolutely necessary. Enable two-step verification for Apple ID. Even though this specific malware does not seem to target Apple IDs at this time, it is possible that in the future more aggressive malware will be used to display a fake window asking for sign-in credentials. According to paloaltonetworks, the current malware is affecting:
  • Current time
  • Current infected app name
  • The app bundle identifier
  • Current device name and type
  • Current system language and country
  • Current device UUID
  • Network type
If you are an iOS developer, however, a lot can be done to secure your development system:
  • Always download Xcode from the official Mac App Store. For other developer tools, always download these from official sources.
  • Always check the digital signature of developer tools. It is irresponsible for developers to ignore signature warnings. Xcode clearly should have been signed by Apple; all other versions should have produced user warnings.
  • Separate your development system with your everyday system. Development systems should be used solely for development and not for browsing random sites. If physical separation presents too much of a problem for developers, at the very least, a dedicated user account for development should be used.

What should Apple do to mitigate this compromise?

Apple should immediately scan their entire App Store to look for malware signatures and to remove all apps that are affected.
Apple’s Gatekeeper should implement a pre-loaded list of apps to enforce signature validation. For example, if Xcode and other crucial apps have invalid signatures, the OS should not allow users to bypass and proceed with installation. (This idea is similar to HSTS preload, in an effort to prevent network attacks.)
We have asked Apple to comment on their mitigation strategy in this instance and to outline their plans for future defense mechanisms to avoid a repeat of this situation.
Update: Apple scanned and took down infected apps in the App store and sent emails to urge developers to download Xcode from official sources.

Who is behind the attack and why would somebody create this compromise?

CoderFun first started to release compromised Xcode about 5 months ago.
It seems that this particular malware is being used to collect device information for data mining. However, the malware could have been used more aggressively to collect private information such as contacts, photos, and even iCloud passwords via phishing when combined with other evasion mechanisms to counter manual reviews.

Wednesday, September 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,但是非常有规律。我们认为主动探测的初始序号是按照时间产生的。
  • 我们发现GFW主动探测不仅仅针对了Tor。GFW还对 SoftEther 和GoAgent进行了主动探测。这说明主动探测系统是模块化的。GFW工程师能比较简单的对新翻墙软件改进主动探测功能。
  • GFW能(部分的)模拟  vanilla Tor protocol, obfs2, and obfs3 来主动探测网桥代理。有趣的是,node-Tor 因为是使用JavaScript 编写而导致不同的代码实现,从而对主动探测免疫。人为修改了Tor回复能躲避GFW的主动探测,但这应该不是长久之计。
  • 在2012年,主动探测系统每15分钟扫描一次。但现在,主动探测系统能实时扫描。平均来说,中国用户连接Tor网桥代理后半秒内就有主动探测连接。
  • 我们使用 traceroute 发现,GFW的主动探测系统是有状态的,但没有办法重组TCP流。
幸运的是,我们有 pluggable transports 来防止主动探测。ScrambleSuitobfs4 能使用预先分享的密钥来防止主动探测。 Meek 使用CDN来代理流量,虽然这不能阻止主动探测,但封锁造成的额外伤害会很大。我们在开发翻墙工具的同时需要注重可用性。大力开发的翻墙工具若很难使用,是没有价值的。这是用户界面的重要性所在。

Wednesday, August 26, 2015

Chinese developers forced to delete softwares by police


On August 22, an open source project called ShadowSocks(link is external)was removed from GitHub.

According to the project’s author, the police contacted him and asked him to stop working on the tool and to remove all of the code from GitHub.
He later removed the reference of the police, presumably under the pressure of the police.
After the news, many Chinese and foreign developers, as well as ShadowSocks users, paid tribute to the author. As a result of this attention, ShadowSocks became the top trending project on GitHub.


GoAgent’s Github repo is also removed today (Aug 25, 2015). GoAgent was the most popular circumvention tool in China. It relied on Google App Engine to tunnel traffic across GFW. It was hosted on Google Code and later moved to Github. The author phuslu deleted the repo without explanation but changed his account description to be “Everything that has a beginning has an end”.

What is ShadowSocks?

According to its official site, which is still running at the time of writing, ShadowSocks
is “A secure socks5 proxy, designed to protect your Internet traffic”. It is one of the most popular circumvention tools in China and is on par with VPNs and GoAgent .
ShadowSocks is merely a protocol, just like a VPN, that secures Internet traffic.  A similar example is torrenting. Torrenting pirate content is illegal, but the torrent protocol is totally legal and has many legitimate uses.The protocol is completely open-source and the author made no financial gain from the project. The author, whose user name is clowwindy, did not provide any service to let Chinese netizens bypass Internet censorship. Despite this, the police visited his home and pressured him to remove the project.

Trend of crackdown on tools

Since January, 2015, the authorities have stepped up their control over VPNs in China. This trend has continued into the summer and recently other circumvention tool developers have encountered problems.
In a recent statement, Qujing, another circumvention tool, said that the authorities told them that Internet users in China can only use legitimate means to get information. All services offered by Qujing closed down on July 28, 2015.  
Unlike ShadowSocks, Qujing is a commercial service. It sells a service similar to a VPN to bypass censorship.
Other famous VPN vendors have also shut down their websites after pressure from the authorities.

Other people who are mirroring the ShadowSocks code

Others have mirrored the ShadowSocks code and those mirrors are still available. However, if the author heeds the police warning and stops work on ShadowSocks, no updates will be made to the code. However, since the code is open source, other developers may take up the cause and continue to improve ShadowSocks, especially given the attention that this incident has generated in China.

Wednesday, April 15, 2015

CNNIC censors news about their own statement

On April 1, 2015 Google announced that they will no longer recognize the CNNIC Root and EV (extensive validation) certificate authorities (CAs).
On April 2, 2015 Mozilla concluded that CNNIC’s behaviour in issuing an unconstrained intermediate certificate to another company was ‘egregious practice’ and that Mozilla products would no longer trust any certificate issued by CNNIC’s roots. Mozilla also published a more detailed report about their actions.
After unauthorized digital certificates for several Google domains were exposed by Google and Mozilla on March 23, 2015, CNNIC censored any mention of these posts. CNNIC is not only a certificate authority, they are also China’s online censorship apparatus. CNNIC was, is and will continue to practice internet censorship.
News about the April 1 and 2 announcements has again been censored on social media and also on traditional media in China.
Below is a screenshot of Weibo posts about these announcements.
The first post in the screenshot is about Google revoking CNNIC. Notice that below the first post, there are three buttons while on the second post there are four buttons. The retweet function on the first post about CNNIC is missing. The Chinese authorities are getting more creative about how they prevent negative information from spreading! Later, however, the authorities resorted to ancient practices and the post was completely removed.
Even reports which appeared on traditional media websites, detailing how CNNIC were calling out Google for being “unintelligible”, have been censored.
NetEase’s report titled “Chrome and Mozilla revoke CNNIC CA” was deleted within two hours of publishing. NetEase is one of the largest Chinese internet service providers.
Engadget Chinese's report titled "Google revokes CNNIC CA" is blocked by GFW
Sina’s report titled “Google’s decision is unintelligible and unacceptable says CNNIC” was deleted. Sina is the largest Chinese-language web portal.
Sohu’s report titled “CNNIC condemn Google ” was deleted. Sohu sits 44th overall in Alexa's internet rankings.
Open Source China’s report titled “Google revokes CNNIC and EV root CAs” was deleted. Open Source China is the largest open source community in China.
Caijing’s report titled “Google revokes CNNIC CA; CNNIC says the decision unintelligible” was deleted. Caijing is an independent magazine that covers social, political, and economic issues.
In fact, almost all reports about CNNIC’s loss of face have been censored in China. This is in addition of to the wide scale censorship of Google and Mozilla’s posts about CNNIC CA last week.
CNNIC said in a statement that ‘the decision that Google has made is unacceptable and unintelligible to CNNIC, and meanwhile CNNIC sincerely urge that Google would take users’ rights and interests into full consideration.”