XcodeSpy Malware
Phil Stokes (via Patrick Wardle, MacRumors):
Threat actors are abusing the Run Script feature in Apple’s Xcode IDE to infect unsuspecting Apple Developers via shared Xcode Projects.
XcodeSpy is a malicious Xcode project that installs a custom variant of the EggShell backdoor on the developer’s macOS computer along with a persistence mechanism.
The backdoor has functionality for recording the victim’s microphone, camera and keyboard, as well as the ability to upload and download files.
[…]
The sample we analyzed used a copy of a legitimate open-source project that can be found on Github called TabBarInteraction.
Jonathan Zdziarski (in 2015, via mikey):
Early this morning, The Intercept posted several documents pertaining to CIA’s research into compromising iOS devices (along with other things) through Sandia National Laboratories, a major research and development contractor to the government. The documents outlined a number of project talks taking place at a closed government conference referred to as the Jamboree in 2012.
[…]
Strawhorse, a malicious implementation of Xcode, where App Store developers (likely not suspected of any crimes) would be targeted, and their dev machines backdoored to give CIA injection capabilities into compiled applications. The malicious Xcode variant was capable of stealing the developer’s private codesign keys, which would be smuggled out with compiled binaries. It would also disable securityd so that it would not warn the developer that this was happening. The stolen keys could later be used to inject and sign payloads into the developer’s own products without their permission or knowledge, which could then be widely disseminated through the App Store channels. This could include trojans or watermarks, as the document suggests. With the developer keys extracted, binary modifications could also be made at a later time, if such an injection framework existed.
In spite of what The Intercept wrote, there is no evidence that Strawhorse was slated for use en masse, or that it even reached an operational phase.
Previously:
4 Comments RSS · Twitter
Excel macros, re-invented.
Difficult to handle, though, I think:
If such a project is downloaded via a web browser, it would get quarantined and Xcode could warn the user when opening it in quarantined state _if_ the project includes build scripts.
However, if one installs the project by downloading it thru a git client (or Cocoapods, not sure), there'll be no quarantining. And we do not want Xcode to warn us every time we open it. So Xcode would have to add a computer/user-specific tag either in the project file or in its local filesystem to remember that it has asked the user once and doesn't need to ask again. Tricky.
All complaining and limitations aside, this is exactly why we need sandboxing. And the sandbox needs to be better to permit more workflows. (Xcode isn’t sandboxed, because it can’t be with today’s sandbox implementation.)
A build script should not be allowed to touch anything outside the project dir.
@Thomas "So Xcode would have to add a computer/user-specific tag either in the project file or in its local filesystem to remember that it has asked the user once and doesn't need to ask again. Tricky."
This sounds a lot like the XML item that is used in Xcode project file to know whether Xcode needs to annoy you with the "Update the Project Settings" warning.
@Peter "A build script should not be allowed to touch anything outside the project dir."
This would make developing with Xcode even more painful that it already is.
someone: "This sounds a lot like the XML item that is used in Xcode project file to know whether Xcode needs to annoy you with the "Update the Project Settings" warning."
Except the whole point of quarantining an untrusted file is that the bypass flag *can't* be in-band data, or else a malicious actor could simply commit an Xcode project file that has the "I'm totally safe" flag set. It needs to be stored somewhere that git doesn't touch (xattrs, defaults db, etc), or it's useless.
Peter "A build script should not be allowed to touch anything outside the project dir."
I agree, at least until the user running the build has approved (once!) the specific resources they wish to allow it access to. This is exactly the type of situation the sandbox was built for, and it's exactly the same kind of security restriction (and user interface challenge) that ordinary Mac developers face every day. I don't think it should be terribly difficult to implement, and if it is, then that's a problem.
