As you may have seen elsewhere, Apple has just approved publication of RB App Checker Lite 1.1.3 (build 320) on the Mac App Store, and I’ve simultaneously published the Developer ID version (build 321) and updated the product page.
While the main focus of this version is to do some additional checks, fix bugs and display some information that users have requested, the XcodeGhost story broke just after I uploaded the first binary for review, and I had to remove it in order to see what RB App Checker Lite could do to detect this breach of security.
Assuming you’ve read the excellent summaries linked to in the previous paragraph, you may be interested in what I found inside the “ghosted” version of Xcode. Briefly, the hack alters the script Xcode uses to link an app’s binary; it also inserts look-alike versions of the CoreServices framework into the iOS, iPhone Simulator and OS X SDKs inside Xcode.
All this of course breaks Xcode’s code signature and, under normal circumstances, running such a hacked version would — after the customary delay for checking, 2 to 5 minutes — be detected by GateKeeper and it would advise the developer that “‘Xcode.app’ will damage your computer. You should move it to the Trash.” And the previous version of RB App Checker Lite would advise that “…requirements and resources didn’t pass static validation” and point at the changed file.
You’d think that that would take care of the matter, but it turns out that the affected developers turned GateKeeper off entirely, no doubt to get rid of the several minutes delay. After that, versions of their apps uploaded to the App Store would have been linked with a static library containing categories on Cocoa classes such as UIApplication, UIWindow and so forth; this static library having been hidden inside the added frameworks.
Needless to say, the new version of RB App Checker Lite also detects the added frameworks and warns: “3 frameworks are suspect: they use system names but are NOT signed by Apple!”.
This is both good and bad news. The good news is that this specific version of XcodeGhost — or any similar hack that hides code inside bogus frameworks looking like Apple’s frameworks — can be detected. The bad news is that this specific tactic depends on passing a casual visual inspection of the SDKs inside Xcode; in other words, the names and file paths used look reasonable and mostly duplicate Apple’s names and conventions.
This works because Xcode is a huge application; it contains nearly 5 thousand auxiliary executables. The latest Xcode beta has several SDKs for each of the 7 platforms it supports, and each SDK has an included instance of all system frameworks, both public and private, for that particular combination. Unfortunately, not all these frameworks are currently signed by Apple — only 2/3 of them are, and not in a consistent manner. (In all fairness, the percentage has been creeping up a little with each release.)
Therefore, unless you check the entire app contents with GateKeeper, RB App Checker Lite (or even the codesign command-line utility), it will be humanly impossible to pick out visually — by inspection in the Finder — if anything has been changed inside Xcode. So keep GateKeeper turned on! One suggestion Apple should implement is running GateKeeper tests for Apple-signed software even if GateKeeper has been deliberately disabled.
So, what to do about “infected” apps? Unfortunately the news is not good there. (By the way, I’m surprised that no infected apps were — as yet — found on the Mac App Store.) As I said, infected apps contain linked-in categories on Cocoa classes, using plausible English method names. Writing such categories is perfectly legal and even plausible — I’ve done so myself. Having code inside these categories do things that are allowed by the app’s entitlements, such as sending/receiving data over the net, is also perfectly legal and plausible. There seem to be some utilities out already that purport detecting such code, but I suppose they’d turn up a lot of false positives unless they check for these specific combinations of symbols — not very future-proof.
By the same token, Apple can’t really do these tests comprehensively when an app is uploaded to the store. They can and do check for private or “suspect” APIs being called, but as far as I can see the present XcodeGhost doesn’t use anything like that.
Coming back to RB App Checker Lite: it currently does NOT look inside executable code at all. Should it do so? I’m reluctant to implement that; it’s not clear what exactly to look for, regarding hacks like XcodeGhost, and it would mean that checking Xcode and similar huge apps would take tens of minutes or even more. I’m open to suggestions, however… comment here or email me!
