What You Need to Know About iOS Malware XcodeGhost

darn it, I thought only android gets malware.

wechat is used in many countires :(

Seriously what developer who knows anything about security is going to download an IDE from a non official source?

That's like downloading an OS from The Pirate Bay and being shocked the file was injected with malicious code.

i'm sorry but how can a developer be such an idiot (please don't ban me, there's no other word to describe patient's condition) to download Xcode from a chinese cloud file sharing service????

How do I protect myself against XcodeGhost?
iOS users should immediately uninstall any infected iOS app listed here ('http://researchcenter.paloaltonetworks.com/2015/09/malware-xcodeghost-infects-39-ios-apps-including-wechat-affecting-hundreds-of-millions-of-users/') on their devices, or update to a newer version that has removed the malware. Resetting your iCloud password, and any other passwords inputted on your iOS device, is also strongly recommended as a precautionary measure.

My thought is I am all done with any company that would use an Xcode version they got from a file sharing site rather than Apple directly. I would never trust them again.

Can't you just list all 39 apps? Looks like the servers from Palo Alto Networks can't handle it.

Infected iOS apps
网易云音乐 2.8.3
微信 6.2.5
讯飞输入法 5.1.1463
滴滴出行 4.0.0.6-4.0.0.0
滴滴打车 3.9.7.1 – 3.9.7
铁路12306 4.5
下厨房 4.3.2
51卡保险箱 5.0.1
中信银行动卡空间 3.3.12
中国联通手机营业厅 3.2
高德地图 7.3.8
简书 2.9.1
开眼 1.8.0
Lifesmart 1.0.44
网易公开课 4.2.8
马拉马拉 1.1.0
药给力 1.12.1
喜马拉雅 4.3.8
口袋记账 1.6.0
同花顺 9.60.01
快速问医生 7.73
懒人周末
微博相机
豆瓣阅读
CamScanner
CamCard
SegmentFault 2.8
炒股公开课
股市热点
新三板
滴滴司机
OPlayer 2.1.05
电话归属地助手 3.6.5
愤怒的小鸟2 2.1.1
夫妻床头话 1.2
穷游 6.6.6
我叫MT 5.0.1
我叫MT 2 1.10.5
自由之战 1.1.0

Fox-IT (fox-it.com ('http://fox-it.com/')), a Netherlands based security company, checked all C2 domain names from our reports in their network sensors and has found thousands of malicious traffic outside China. According to their data, these iOS apps were also infected:

Mercury
WinZip
Musical.ly
PDFReader
guaji_gangtai en
Perfect365
网易云音乐
PDFReader Free
WhiteTile
IHexin
WinZip Standard
MoreLikers2
CamScanner Lite
MobileTicket
iVMS-4500
OPlayer Lite
QYER
golfsense
同花顺
ting
installer
下厨房
golfsensehd
Wallpapers10000
CSMBP-AppStore
礼包助手
MSL108
ChinaUnicom3.x
TinyDeal.com
snapgrab copy
iOBD2
PocketScanner
CuteCUT
AmHexinForPad
SuperJewelsQuest2
air2
InstaFollower
CamScanner Pro
baba
WeLoop
DataMonitor
爱推
MSL070
nice dev
immtdchs
OPlayer
FlappyCircle
高德地图
BiaoQingBao
SaveSnap
WeChat
Guitar Master
jin
WinZip Sector
Quick Save
CamCard

So... It begins.

iOS has been breached through the one thing that kept us safe. The App Store.

I don't think that's a correct analysis of the situation.
What has really happened here? Developers have used the wrong tool (we'll discuss that later) and that tool has embedded some unwanted additional code in their apps. BUT look what still worked
- each broken app STILL has to be submitted to the app store, with identification and an audit trail

- even when the app is on an iOS device, there are severe limits to what it can do. It still can't break out of the OS protections, randomly control the device, etc. The type of info being sent back to base is, let's face it, not THAT serious --- not ideal, but not control of the machine.

- The items that ARE problematic (and which Apple should work on fixing) are items that were problematic before we knew about this, and that have been used in other contexts --- the ability to phish for passwords by throwing up fake dialog boxes, and the way the current sandboxing FORCES Password apps like 1Password to transfer data over the Clipboard.

What this REALLY provides is a way to throw out a bunch of these phishing scams in a way that can't be traced back to the real scammer; only to the developer using the wrong tool.

Which gets us to that issue. I don't know enough about XCode to know what was and was not breached on that front. Obviously the entire XCode package should be signed, and obviously if you're stupid enough to install an XCode package that complains about being unsigned, you're setting yourself up for trouble. But blaming the victim, especially when the security landscape changes every year is not helpful --- how could Apple do better?
You can't really avoid people being able to write their own compilers and dev tools, and you can't stop those dev tools from doing god knows what to the code they create --- this has been known since Pike's infamous C compiler of the early seventies.
What you SHOULD be able to do is not allow code that has been created by such dev tools into the app store. THAT seems to be the flaw that needs to be fixed --- that any tool that's generating binaries that will land up in the store needs to be provably signed. But I don't know how feasible that is. Obviously the last stage (the actual store submitter app) is provided by Apple and signed, and using the developers signature. But what about the linker beforehand? And the compiler before that? And you then need the binaries passed between the two to be encrypted? It's just totally inimical to the current expected model of how we code.

So what about at a higher level? Do something that's a ugly hack, but basically FORCE that any installer that calls itself "XCode" has to be signed no matter what? That's one package that you can't install regardless of your GateKeeper settings except from Apple. But then you get a wack-a-mole of packages called "XCode 7" and "XCode!" and "XCode Pro".

Good analysis, but there is something Apple could have done, and I have been saying as much for over a year. Here's the more strongly worded one:

They should ban their in-house teams from throwing up a password request box. Absolute ban. It has got out of hand recently with stock apps asking for the password without any justification or explanation and pretty much at random. I've said it over and over, Apple have been training their users for exactly this scenario - enter password whenever anyone asks. If an app needs the iCloud password it should instruct the user to enter it in the appropriate settings page. Train users: only the settings app should be trusted with passwords.